[kubernetes-users] Re: SIG Architecture

[pmorie]

+1 to this - I have wanted this to be a thing at many times while working 
on service-catalog.

On Thursday, June 22, 2017 at 4:12:48 PM UTC-4, Brian Grant wrote:
>
> At the leadership summit a few weeks ago, I believe there was consensus 
> that we should start an Architecture SIG. There were also discussions of 
> Working Groups around extensibility and repo refactoring, but I'd like to 
> fold that into SIG Architecture, since they are all related, and because 
> I've been driving these areas, directly or indirectly, and there are only 
> so many meetings I can attend.
>
> This is the proposal for such a SIG, as the first step in the SIG creation 
> procedure:
>
> https://github.com/kubernetes/community/blob/master/sig-governance.md#sig-creation-procecure
>
> Initial mission statement (thanks to Jaice):
>
> The SIG would be intended to guide the design principles of Kubernetes, as 
> well as provide a consistent body of expertise necessary to ensure 
> architectural consistency over time.
>
>
> The scope would cover the whole project -- issues that span/encompass all 
> the components, how they fit together, how they interact, etc. But the SIG 
> would not get involved with issues specific to a particular component or 
> functional area, which would be the purview of some other SIG, except where 
> they deviate from project-wide principles/conventions.
>
> The specific areas I propose are:
>
> Defining the scope of the Kubernetes project:
>
>- https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
>- Ecosystem examples 
>
> 
>
> Documenting and evolving the system architecture:
>
>- 
>
> https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture.md
>- Kubernetes Architecture presentation 
>
> 
>- Kubernetes Architectural roadmap working document 
>
> 
>
> Defining and driving necessary extensibility points 
> 
> .
>
> Establishing and documenting design principles and conventions for the 
> overall system and user-facing APIs:
>
>- 
>
> https://github.com/kubernetes/community/blob/master/contributors/design-proposals/principles.md
>- 
>
> https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md
>Note that the API conventions aren't part of API machinery because 
>that SIG is about the mechanisms for building the apiservers, APIs, and 
>client libraries, not the principles/conventions driving the design of the 
>APIs and their contents.
>
> Driving improvement of overall code organization -- multiple repos, etc.
>
> Developing necessary review processes, such as the proposal and API 
> review processes.
>
> Educating approvers/owners of other SIGs (e.g., by holding office hours).
>
>
> Suggested meeting day/time: Thursday @ 9am Pacific, before the community 
> meeting, biweekly
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

[kubernetes-users] Re: SIG Architecture

['Vishnu Kannan' via Kubernetes user discussion and Q]

+1

On Thu, Jun 22, 2017 at 1:49 PM, 'Eric Tune' via Kubernetes
developer/contributor discussion  wrote:

> +1.
>
>
> On Thu, Jun 22, 2017 at 1:39 PM, Andy Goldstein  wrote:
>
>> +1 from me too
>>
>> On Thu, Jun 22, 2017 at 4:37 PM, Clayton Coleman 
>> wrote:
>>
>>> +1 - there have been several sig discussions recently about having a
>>> more streamlined way to seek consensus on broad reaching technical changes,
>>> and this seems like a natural (possibly overdue) sig.
>>>
>>> On Jun 22, 2017, at 3:13 PM, 'Brian Grant' via Kubernetes
>>> developer/contributor discussion 
>>> wrote:
>>>
>>> At the leadership summit a few weeks ago, I believe there was consensus
>>> that we should start an Architecture SIG. There were also discussions of
>>> Working Groups around extensibility and repo refactoring, but I'd like to
>>> fold that into SIG Architecture, since they are all related, and because
>>> I've been driving these areas, directly or indirectly, and there are only
>>> so many meetings I can attend.
>>>
>>> This is the proposal for such a SIG, as the first step in the SIG
>>> creation procedure:
>>> https://github.com/kubernetes/community/blob/master/sig-gove
>>> rnance.md#sig-creation-procecure
>>>
>>> Initial mission statement (thanks to Jaice):
>>>
>>> The SIG would be intended to guide the design principles of Kubernetes,
>>> as well as provide a consistent body of expertise necessary to ensure
>>> architectural consistency over time.
>>>
>>>
>>> The scope would cover the whole project -- issues that span/encompass
>>> all the components, how they fit together, how they interact, etc. But the
>>> SIG would not get involved with issues specific to a particular component
>>> or functional area, which would be the purview of some other SIG, except
>>> where they deviate from project-wide principles/conventions.
>>>
>>> The specific areas I propose are:
>>>
>>> Defining the scope of the Kubernetes project:
>>>
>>>- https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
>>>- Ecosystem examples
>>>
>>> 
>>>
>>> Documenting and evolving the system architecture:
>>>
>>>- https://github.com/kubernetes/community/blob/master/contribu
>>>tors/design-proposals/architecture.md
>>>
>>> 
>>>- Kubernetes Architecture presentation
>>>
>>> 
>>>- Kubernetes Architectural roadmap working document
>>>
>>> 
>>>
>>> Defining and driving necessary extensibility points
>>> 
>>> .
>>>
>>> Establishing and documenting design principles and conventions for the
>>> overall system and user-facing APIs:
>>>
>>>- https://github.com/kubernetes/community/blob/master/contribu
>>>tors/design-proposals/principles.md
>>>
>>> 
>>>- https://github.com/kubernetes/community/blob/master/contribu
>>>tors/devel/api-conventions.md
>>>Note that the API conventions aren't part of API machinery because
>>>that SIG is about the mechanisms for building the apiservers, APIs, and
>>>client libraries, not the principles/conventions driving the design of 
>>> the
>>>APIs and their contents.
>>>
>>> Driving improvement of overall code organization -- multiple repos, etc.
>>>
>>> Developing necessary review processes, such as the proposal and API
>>> review processes.
>>>
>>> Educating approvers/owners of other SIGs (e.g., by holding office hours).
>>>
>>>
>>> Suggested meeting day/time: Thursday @ 9am Pacific, before the community
>>> meeting, biweekly
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Kubernetes developer/contributor discussion" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to kubernetes-dev+unsubscr...@googlegroups.com.
>>> To post to this group, send email to kubernetes-...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/kubernetes-dev/CAKCBhs6Wmq%2BKgo8ayrnHvS-jL-MBFgv%3DoUj%
>>> 2BpS7-u_jFdM-QHQ%40mail.gmail.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this 

Re: [kubernetes-users] How to access a service through a https?

['Ahmet Alp Balkan' via Kubernetes user discussion and Q]

I wrote an answer to this at https://stackoverflow.com/
questions/44708272/how-to-access-a-kubernetes-service-
through-https/44709245#44709245.

If you are actually planning to expose an application running on Kubernetes
to the outside world with HTTPs, you should consider buying HTTPs
certificates (or take a look at kube-lego if you are interested in Let's
Encrypt) and use an Ingress resource to configure a load balancer with TLS
termination.

On Thu, Jun 22, 2017 at 12:44 PM,  wrote:

> This is my cluster info
> --
> kubectl cluster-info
> Kubernetes master is running at https://129.146.10.66:6443
> Heapster is running at https://129.146.10.66:6443/api
> /v1/proxy/namespaces/kube-system/services/heapster
> KubeDNS is running at https://129.146.10.66:6443/api
> /v1/proxy/namespaces/kube-system/services/kube-dns
> --
>
> So, I have a service(mysqlbrokerservice) running as NodePort and the
> configuration looks like this
>
> kubectl describe svc mysqlbrokerservice
> Name:   mysqlbrokerservice
> Namespace:  mysqlbroker
> Labels: 
> Annotations:
> Selector:   app=mysqlbroker
> Type:   NodePort
> IP: 10.99.194.191
> Port:   mysqlbroker 8080/TCP
> NodePort:   mysqlbroker 3/TCP
> Endpoints:  10.244.1.198:8080
> Session Affinity:   None
> Events: 
>
>
> I can access the service through my public IP like this.
> http://129.146.34.181:3/v2/catalog.
>
> 29.146.34.181 is the public ip where the pod is running.
>
>
> Then what I wanted to see if I can access the service through https. I
> followed the direction  in https://kubernetes.io/docs/tas
> ks/access-application-cluster/access-cluster/#manually-
> constructing-apiserver-proxy-urls
>
> I followed the example but it's not giving me any response.
> 129.146.10.66:6443 is my master ip.
>
> This is the output of curl https://129.146.10.66:6443/api
> /v1/namespaces/mysqlbroker/services/mysqlbrokerservice --header
> "Authorization: Bearer $TOKEN" --insecure
> {
>   "kind": "Service",
>   "apiVersion": "v1",
>   "metadata": {
> "name": "mysqlbrokerservice",
> "namespace": "mysqlbroker",
> "selfLink": "/api/v1/namespaces/mysqlbroke
> r/services/mysqlbrokerservice",
> "uid": "40239ca3-577a-11e7-a6a7-17002179",
> "resourceVersion": "10581319",
> "creationTimestamp": "2017-06-22T18:40:23Z"
>   },
>   "spec": {
> "ports": [
>   {
> "name": "mysqlbroker",
> "protocol": "TCP",
> "port": 8080,
> "targetPort": 8080,
> "nodePort": 3
>   }
> ],
> "selector": {
>   "app": "mysqlbroker"
> },
> "clusterIP": "10.99.194.191",
> "type": "NodePort",
> "sessionAffinity": "None"
>   },
>   "status": {
> "loadBalancer": {}
>   }
> }
>
> but doing a curl on the port give me this
> curl -i -H "Accept: application/json" -H "Content-Type: application/json"
> -X GET  https://129.146.10.66:6443/api/v1/namespaces/mysqlbroker/ser
> vices/mysqlbrokerservice:8080/proxy/v2/catalog --header "Authorization:
> Bearer $TOKEN" --insecure
> HTTP/1.0 200 Connection established
>
>
> curl just waits there... and i looked at my pod logs and it does not show
> that any request received.
>
> Can somebody explain what i am doing wrong here? What's the ideal solution
> if want a service to be exposed through https?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes user discussion and Q" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to kubernetes-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/kubernetes-users.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

[kubernetes-users] Re: SIG Architecture

['Eric Tune' via Kubernetes user discussion and Q]

+1.


On Thu, Jun 22, 2017 at 1:39 PM, Andy Goldstein  wrote:

> +1 from me too
>
> On Thu, Jun 22, 2017 at 4:37 PM, Clayton Coleman 
> wrote:
>
>> +1 - there have been several sig discussions recently about having a more
>> streamlined way to seek consensus on broad reaching technical changes, and
>> this seems like a natural (possibly overdue) sig.
>>
>> On Jun 22, 2017, at 3:13 PM, 'Brian Grant' via Kubernetes
>> developer/contributor discussion  wrote:
>>
>> At the leadership summit a few weeks ago, I believe there was consensus
>> that we should start an Architecture SIG. There were also discussions of
>> Working Groups around extensibility and repo refactoring, but I'd like to
>> fold that into SIG Architecture, since they are all related, and because
>> I've been driving these areas, directly or indirectly, and there are only
>> so many meetings I can attend.
>>
>> This is the proposal for such a SIG, as the first step in the SIG
>> creation procedure:
>> https://github.com/kubernetes/community/blob/master/sig-gove
>> rnance.md#sig-creation-procecure
>>
>> Initial mission statement (thanks to Jaice):
>>
>> The SIG would be intended to guide the design principles of Kubernetes,
>> as well as provide a consistent body of expertise necessary to ensure
>> architectural consistency over time.
>>
>>
>> The scope would cover the whole project -- issues that span/encompass all
>> the components, how they fit together, how they interact, etc. But the SIG
>> would not get involved with issues specific to a particular component or
>> functional area, which would be the purview of some other SIG, except where
>> they deviate from project-wide principles/conventions.
>>
>> The specific areas I propose are:
>>
>> Defining the scope of the Kubernetes project:
>>
>>- https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
>>- Ecosystem examples
>>
>> 
>>
>> Documenting and evolving the system architecture:
>>
>>- https://github.com/kubernetes/community/blob/master/contribu
>>tors/design-proposals/architecture.md
>>
>> 
>>- Kubernetes Architecture presentation
>>
>> 
>>- Kubernetes Architectural roadmap working document
>>
>> 
>>
>> Defining and driving necessary extensibility points
>> 
>> .
>>
>> Establishing and documenting design principles and conventions for the
>> overall system and user-facing APIs:
>>
>>- https://github.com/kubernetes/community/blob/master/contribu
>>tors/design-proposals/principles.md
>>
>> 
>>- https://github.com/kubernetes/community/blob/master/contribu
>>tors/devel/api-conventions.md
>>Note that the API conventions aren't part of API machinery because
>>that SIG is about the mechanisms for building the apiservers, APIs, and
>>client libraries, not the principles/conventions driving the design of the
>>APIs and their contents.
>>
>> Driving improvement of overall code organization -- multiple repos, etc.
>>
>> Developing necessary review processes, such as the proposal and API
>> review processes.
>>
>> Educating approvers/owners of other SIGs (e.g., by holding office hours).
>>
>>
>> Suggested meeting day/time: Thursday @ 9am Pacific, before the community
>> meeting, biweekly
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Kubernetes developer/contributor discussion" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to kubernetes-dev+unsubscr...@googlegroups.com.
>> To post to this group, send email to kubernetes-...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/kubernetes-dev/CAKCBhs6Wmq%2BKgo8ayrnHvS-jL-MBFgv%3DoUj%
>> 2BpS7-u_jFdM-QHQ%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Kubernetes developer/contributor discussion" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to kubernetes-dev+unsubscr...@googlegroups.com.
>> To post to this 

[kubernetes-users] Re: SIG Architecture

[Andy Goldstein]

+1 from me too

On Thu, Jun 22, 2017 at 4:37 PM, Clayton Coleman 
wrote:

> +1 - there have been several sig discussions recently about having a more
> streamlined way to seek consensus on broad reaching technical changes, and
> this seems like a natural (possibly overdue) sig.
>
> On Jun 22, 2017, at 3:13 PM, 'Brian Grant' via Kubernetes
> developer/contributor discussion  wrote:
>
> At the leadership summit a few weeks ago, I believe there was consensus
> that we should start an Architecture SIG. There were also discussions of
> Working Groups around extensibility and repo refactoring, but I'd like to
> fold that into SIG Architecture, since they are all related, and because
> I've been driving these areas, directly or indirectly, and there are only
> so many meetings I can attend.
>
> This is the proposal for such a SIG, as the first step in the SIG creation
> procedure:
> https://github.com/kubernetes/community/blob/master/sig-
> governance.md#sig-creation-procecure
>
> Initial mission statement (thanks to Jaice):
>
> The SIG would be intended to guide the design principles of Kubernetes, as
> well as provide a consistent body of expertise necessary to ensure
> architectural consistency over time.
>
>
> The scope would cover the whole project -- issues that span/encompass all
> the components, how they fit together, how they interact, etc. But the SIG
> would not get involved with issues specific to a particular component or
> functional area, which would be the purview of some other SIG, except where
> they deviate from project-wide principles/conventions.
>
> The specific areas I propose are:
>
> Defining the scope of the Kubernetes project:
>
>- https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
>- Ecosystem examples
>
> 
>
> Documenting and evolving the system architecture:
>
>- https://github.com/kubernetes/community/blob/master/contribu
>tors/design-proposals/architecture.md
>
> 
>- Kubernetes Architecture presentation
>
> 
>- Kubernetes Architectural roadmap working document
>
> 
>
> Defining and driving necessary extensibility points
> 
> .
>
> Establishing and documenting design principles and conventions for the
> overall system and user-facing APIs:
>
>- https://github.com/kubernetes/community/blob/master/contribu
>tors/design-proposals/principles.md
>
> 
>- https://github.com/kubernetes/community/blob/master/contribu
>tors/devel/api-conventions.md
>Note that the API conventions aren't part of API machinery because
>that SIG is about the mechanisms for building the apiservers, APIs, and
>client libraries, not the principles/conventions driving the design of the
>APIs and their contents.
>
> Driving improvement of overall code organization -- multiple repos, etc.
>
> Developing necessary review processes, such as the proposal and API
> review processes.
>
> Educating approvers/owners of other SIGs (e.g., by holding office hours).
>
>
> Suggested meeting day/time: Thursday @ 9am Pacific, before the community
> meeting, biweekly
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to kubernetes-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/kubernetes-dev/CAKCBhs6Wmq%2BKgo8ayrnHvS-jL-
> MBFgv%3DoUj%2BpS7-u_jFdM-QHQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to kubernetes-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/kubernetes-dev/-737520277828820344%40unknownmsgid
> 

[kubernetes-users] Re: SIG Architecture

[Clayton Coleman]

+1 - there have been several sig discussions recently about having a more
streamlined way to seek consensus on broad reaching technical changes, and
this seems like a natural (possibly overdue) sig.

On Jun 22, 2017, at 3:13 PM, 'Brian Grant' via Kubernetes
developer/contributor discussion  wrote:

At the leadership summit a few weeks ago, I believe there was consensus
that we should start an Architecture SIG. There were also discussions of
Working Groups around extensibility and repo refactoring, but I'd like to
fold that into SIG Architecture, since they are all related, and because
I've been driving these areas, directly or indirectly, and there are only
so many meetings I can attend.

This is the proposal for such a SIG, as the first step in the SIG creation
procedure:
https://github.com/kubernetes/community/blob/master/sig-governance.md#sig-creation-procecure

Initial mission statement (thanks to Jaice):

The SIG would be intended to guide the design principles of Kubernetes, as
well as provide a consistent body of expertise necessary to ensure
architectural consistency over time.


The scope would cover the whole project -- issues that span/encompass all
the components, how they fit together, how they interact, etc. But the SIG
would not get involved with issues specific to a particular component or
functional area, which would be the purview of some other SIG, except where
they deviate from project-wide principles/conventions.

The specific areas I propose are:

Defining the scope of the Kubernetes project:

   - https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
   - Ecosystem examples
   


Documenting and evolving the system architecture:

   - https://github.com/kubernetes/community/blob/master/
   contributors/design-proposals/architecture.md
   

   - Kubernetes Architecture presentation
   

   - Kubernetes Architectural roadmap working document
   


Defining and driving necessary extensibility points

.

Establishing and documenting design principles and conventions for the
overall system and user-facing APIs:

   - https://github.com/kubernetes/community/blob/master/
   contributors/design-proposals/principles.md
   

   - https://github.com/kubernetes/community/blob/master/
   contributors/devel/api-conventions.md
   

   Note that the API conventions aren't part of API machinery because that
   SIG is about the mechanisms for building the apiservers, APIs, and client
   libraries, not the principles/conventions driving the design of the APIs
   and their contents.

Driving improvement of overall code organization -- multiple repos, etc.

Developing necessary review processes, such as the proposal and API review
processes.

Educating approvers/owners of other SIGs (e.g., by holding office hours).


Suggested meeting day/time: Thursday @ 9am Pacific, before the community
meeting, biweekly


-- 
You received this message because you are subscribed to the Google Groups
"Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to kubernetes-dev+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs6Wmq%2BKgo8ayrnHvS-jL-MBFgv%3DoUj%2BpS7-u_jFdM-QHQ%40mail.gmail.com

.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

[kubernetes-users] Re: SIG Architecture

[Ihor Dvoretskyi]

Big +1 from me. It's long-awaited and we definitely need a place to discuss
architecture questions and make architecture decisions.

On Thu, Jun 22, 2017 at 10:12 PM 'Brian Grant' via Kubernetes
developer/contributor discussion  wrote:

> At the leadership summit a few weeks ago, I believe there was consensus
> that we should start an Architecture SIG. There were also discussions of
> Working Groups around extensibility and repo refactoring, but I'd like to
> fold that into SIG Architecture, since they are all related, and because
> I've been driving these areas, directly or indirectly, and there are only
> so many meetings I can attend.
>
> This is the proposal for such a SIG, as the first step in the SIG creation
> procedure:
>
> https://github.com/kubernetes/community/blob/master/sig-governance.md#sig-creation-procecure
>
> Initial mission statement (thanks to Jaice):
>
> The SIG would be intended to guide the design principles of Kubernetes, as
> well as provide a consistent body of expertise necessary to ensure
> architectural consistency over time.
>
>
> The scope would cover the whole project -- issues that span/encompass all
> the components, how they fit together, how they interact, etc. But the SIG
> would not get involved with issues specific to a particular component or
> functional area, which would be the purview of some other SIG, except where
> they deviate from project-wide principles/conventions.
>
> The specific areas I propose are:
>
> Defining the scope of the Kubernetes project:
>
>- https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
>- Ecosystem examples
>
> 
>
> Documenting and evolving the system architecture:
>
>-
>
> https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture.md
>- Kubernetes Architecture presentation
>
> 
>- Kubernetes Architectural roadmap working document
>
> 
>
> Defining and driving necessary extensibility points
> 
> .
>
> Establishing and documenting design principles and conventions for the
> overall system and user-facing APIs:
>
>-
>
> https://github.com/kubernetes/community/blob/master/contributors/design-proposals/principles.md
>-
>
> https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md
>Note that the API conventions aren't part of API machinery because
>that SIG is about the mechanisms for building the apiservers, APIs, and
>client libraries, not the principles/conventions driving the design of the
>APIs and their contents.
>
> Driving improvement of overall code organization -- multiple repos, etc.
>
> Developing necessary review processes, such as the proposal and API
> review processes.
>
> Educating approvers/owners of other SIGs (e.g., by holding office hours).
>
>
> Suggested meeting day/time: Thursday @ 9am Pacific, before the community
> meeting, biweekly
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to kubernetes-...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs6Wmq%2BKgo8ayrnHvS-jL-MBFgv%3DoUj%2BpS7-u_jFdM-QHQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

[kubernetes-users] SIG Architecture

['Brian Grant' via Kubernetes user discussion and Q]

At the leadership summit a few weeks ago, I believe there was consensus
that we should start an Architecture SIG. There were also discussions of
Working Groups around extensibility and repo refactoring, but I'd like to
fold that into SIG Architecture, since they are all related, and because
I've been driving these areas, directly or indirectly, and there are only
so many meetings I can attend.

This is the proposal for such a SIG, as the first step in the SIG creation
procedure:
https://github.com/kubernetes/community/blob/master/sig-governance.md#sig-creation-procecure

Initial mission statement (thanks to Jaice):

The SIG would be intended to guide the design principles of Kubernetes, as
well as provide a consistent body of expertise necessary to ensure
architectural consistency over time.


The scope would cover the whole project -- issues that span/encompass all
the components, how they fit together, how they interact, etc. But the SIG
would not get involved with issues specific to a particular component or
functional area, which would be the purview of some other SIG, except where
they deviate from project-wide principles/conventions.

The specific areas I propose are:

Defining the scope of the Kubernetes project:

   - https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
   - Ecosystem examples
   


Documenting and evolving the system architecture:

   - https://github.com/kubernetes/community/blob/master/
   contributors/design-proposals/architecture.md
   

   - Kubernetes Architecture presentation
   

   - Kubernetes Architectural roadmap working document
   


Defining and driving necessary extensibility points

.

Establishing and documenting design principles and conventions for the
overall system and user-facing APIs:

   - https://github.com/kubernetes/community/blob/master/
   contributors/design-proposals/principles.md
   

   - https://github.com/kubernetes/community/blob/master/
   contributors/devel/api-conventions.md
   

   Note that the API conventions aren't part of API machinery because that
   SIG is about the mechanisms for building the apiservers, APIs, and client
   libraries, not the principles/conventions driving the design of the APIs
   and their contents.

Driving improvement of overall code organization -- multiple repos, etc.

Developing necessary review processes, such as the proposal and API review
processes.

Educating approvers/owners of other SIGs (e.g., by holding office hours).


Suggested meeting day/time: Thursday @ 9am Pacific, before the community
meeting, biweekly

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

[kubernetes-users] How to access a service through a https?

[isazzad79]

This is my cluster info
--
kubectl cluster-info
Kubernetes master is running at https://129.146.10.66:6443
Heapster is running at 
https://129.146.10.66:6443/api/v1/proxy/namespaces/kube-system/services/heapster
KubeDNS is running at 
https://129.146.10.66:6443/api/v1/proxy/namespaces/kube-system/services/kube-dns
--

So, I have a service(mysqlbrokerservice) running as NodePort and the 
configuration looks like this

kubectl describe svc mysqlbrokerservice
Name:   mysqlbrokerservice
Namespace:  mysqlbroker
Labels: 
Annotations:
Selector:   app=mysqlbroker
Type:   NodePort
IP: 10.99.194.191
Port:   mysqlbroker 8080/TCP
NodePort:   mysqlbroker 3/TCP
Endpoints:  10.244.1.198:8080
Session Affinity:   None
Events: 


I can access the service through my public IP like this. 
http://129.146.34.181:3/v2/catalog.

29.146.34.181 is the public ip where the pod is running.


Then what I wanted to see if I can access the service through https. I followed 
the direction  in 
https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls

I followed the example but it's not giving me any response. 129.146.10.66:6443 
is my master ip.

This is the output of curl 
https://129.146.10.66:6443/api/v1/namespaces/mysqlbroker/services/mysqlbrokerservice
 --header "Authorization: Bearer $TOKEN" --insecure
{
  "kind": "Service",
  "apiVersion": "v1",
  "metadata": {
"name": "mysqlbrokerservice",
"namespace": "mysqlbroker",
"selfLink": "/api/v1/namespaces/mysqlbroker/services/mysqlbrokerservice",
"uid": "40239ca3-577a-11e7-a6a7-17002179",
"resourceVersion": "10581319",
"creationTimestamp": "2017-06-22T18:40:23Z"
  },
  "spec": {
"ports": [
  {
"name": "mysqlbroker",
"protocol": "TCP",
"port": 8080,
"targetPort": 8080,
"nodePort": 3
  }
],
"selector": {
  "app": "mysqlbroker"
},
"clusterIP": "10.99.194.191",
"type": "NodePort",
"sessionAffinity": "None"
  },
  "status": {
"loadBalancer": {}
  }
}

but doing a curl on the port give me this
curl -i -H "Accept: application/json" -H "Content-Type: application/json" -X 
GET  
https://129.146.10.66:6443/api/v1/namespaces/mysqlbroker/services/mysqlbrokerservice:8080/proxy/v2/catalog
 --header "Authorization: Bearer $TOKEN" --insecure
HTTP/1.0 200 Connection established


curl just waits there... and i looked at my pod logs and it does not show that 
any request received.

Can somebody explain what i am doing wrong here? What's the ideal solution if 
want a service to be exposed through https?

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

[kubernetes-users] Re: Information Sharing; Distributed Computing

[Warren Strange]

DNS is used for service name lookup, but there is no shared memory between 
pods. 

On Thursday, June 22, 2017 at 9:57:52 AM UTC-6, Tobias Rahloff wrote:
>
> Can sb point me towards sources that explain how information sharing in 
> k8s works? Especially in a academic, distributed computing sense.
>
> If I understand correctly, Pods/Clusters use DNS to distribute traffic 
> between dynamically scaled containers and have some kind of shared memory? 
> Kind Regards 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

[kubernetes-users] Information Sharing; Distributed Computing

[Tobias Rahloff]

Can sb point me towards sources that explain how information sharing in k8s
works? Especially in a academic, distributed computing sense.

If I understand correctly, Pods/Clusters use DNS to distribute traffic
between dynamically scaled containers and have some kind of shared memory?
Kind Regards

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

Re: [kubernetes-users] Getting Google's Cloud SQL Proxy to work

[Evan Jones]

The Cloud SQL Proxy logs suggest to me that it may not be using the right 
credentials? It is possible that it is trying to use the cluster's "default 
service account"?

If you use "kubectl exec ... -ti /bin/sh" you should be able to examine the 
contents of the credentials file that is being passed to ensure that the 
contents match what you expect. You can also try to interactively start 
/cloud_sql_proxy with different flags to see if you can get it to start and 
print the "expected" log message.

Good luck I hope that helps!



On Thursday, June 22, 2017 at 9:46:52 AM UTC-4, Traiano Welcome wrote:
>
> Hi Evan
>
>
> On Thu, Jun 22, 2017 at 5:34 PM, Evan Jones  > wrote:
>
>> I know nothing about wordpress, but for what it is worth, we are using 
>> this Cloud SQL Proxy container with success. A few notes about the config 
>> you posted:
>>
>>
>> * I'm assuming that where you have 
>> "-instances=[INSTANCE_CONNECTION_NAME]=tcp:[PORT]" you've replaced this 
>> with your Cloud SQL instance name (project:region:cloud_sql_name), and port 
>> with 3306, right?
>>
>
>
> I have this:
>
>   command: ["/cloud_sql_proxy", "--dir=/cloudsql",
> 
> "-instances=lol-staging:europe-west2:lol-staging-001=tcp:3306",
> "-credential_file=/secrets/cloudsql/credentials.json"]
>
> I've redeployed and can see logs now, the wordpress container is failing 
> because it's failing connection to SQL via the proxy:
>
>
>  MySQL Connection Error: (2006) MySQL server has gone away
>  Warning: mysqli::mysqli(): MySQL server has gone away in - on line 10
>  Warning: mysqli::mysqli(): Error while reading greeting packet. 
> PID=167 in - on line 10
>  Warning: mysqli::mysqli(): (HY000/2006): MySQL server has gone away 
> in - on line 10
>
> The cloud sql proxy container complains about an account not having 
> correct permissions (however  I have given it editor permissions):
>
> kubectl logs pods/wordpress-2608214628-9bc9b cloudsql-proxy
>
>
> 2017/06/22 13:40:15 Throttling 
> refreshCfg(lol-staging:europe-west2:lol-staging-001): it was only called 
> 24.005689746s ago
> 2017/06/22 13:40:15 couldn't connect to 
> "lol-staging:europe-west2:lol-staging-001": ensure that the account has 
> access to "lol-staging:europe-west2:lol-staging-001" (and make sure there's 
> no typo in that name). Error during createEphemeral for 
> lol-staging:europe-west2:lol-staging-001: googleapi: Error 403: The client 
> is not authorized to make this request., notAuthorized
> 2017/06/22 13:40:18 New connection for 
> "lol-staging:europe-west2:lol-staging-001"
>
>
> So I'm now wondering how to better validate which account is being 
> referred to here and whether the permissions are correct.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>  
>
>>
>> * If you run kubectl logs pod cloudsql-proxy you should see something 
>> like the following:
>>
>> 2017/06/21 20:45:06 Listening on (whatever) for (your instance name)
>> 2017/06/21 20:45:06 Ready for new connections
>>
>> * If the cloudsql-proxy container is running, you can run kubectl exec 
>> (pod) -c cloudsql-proxy -ti /bin/sh to get a shell and try to verify the 
>> cloudsql-proxy configuration, or to start a new instance and make sure it 
>> is configured correctly.
>>
>> * We are using this with local Unix socket connections in the /cloudsql 
>> directory, but localhost sockets should also work.
>>
>>
>> I'm surprised you don't see any logs from your wordpress container, but I 
>> can't help with that part.
>>
>> Good luck!
>>
>>
>> On Thursday, June 22, 2017 at 3:15:26 AM UTC-4, Traiano Welcome wrote:
>>>
>>> Hi Ahmet
>>>
>>> On Thursday, 22 June 2017 02:25:05 UTC+4, Ahmet Alp Balkan wrote:

 Can you run "kubectl logs -l app=wordpress"? I am assuming there will 
 be some logs from the crashing mysql container.


>>> Thanks for your response. I get no output from running that command (I 
>>> suppose no logs are being generated). I tried both the command, and running 
>>> it in a loop, just in case:
>>>
>>>  for i in `seq 1 100`;do echo "checking $i " - $(kubectl logs -l app=web 
>>> );done
>>>
>>> No result.
>>>
>>> Just to be clear, wordpress container is in a pod, and the cloud sql 
>>> container is a sidecar container connected to pod.
>>>
>>> Google's documentation seems pretty thin on getting this working 
>>> properly with GKE containers, and non-existent on troubleshooting 
>>> connectivity issues with cloud sql proxy.
>>>
>>> Do you know of an alternative method of getting a container access to 
>>> Cloud SQL from GKE ?
>>>
>>>
>>>
>>> On Wed, Jun 21, 2017 at 7:58 AM, Traiano Welcome  
 wrote:

> I'm following this example of how to get wordpress running on GKE 
> connected to Google Cloud SQL via the Google Cloud SQL Proxy:
>
>
> https://cloud.google.com/sql/docs/mysql/connect-container-engine
>
>
> 

Re: [kubernetes-users] Getting Google's Cloud SQL Proxy to work

[Traiano Welcome]

Hi Evan


On Thu, Jun 22, 2017 at 5:34 PM, Evan Jones 
wrote:

> I know nothing about wordpress, but for what it is worth, we are using
> this Cloud SQL Proxy container with success. A few notes about the config
> you posted:
>
>
> * I'm assuming that where you have 
> "-instances=[INSTANCE_CONNECTION_NAME]=tcp:[PORT]"
> you've replaced this with your Cloud SQL instance name
> (project:region:cloud_sql_name), and port with 3306, right?
>


I have this:

  command: ["/cloud_sql_proxy", "--dir=/cloudsql",

"-instances=lol-staging:europe-west2:lol-staging-001=tcp:3306",
"-credential_file=/secrets/cloudsql/credentials.json"]

I've redeployed and can see logs now, the wordpress container is failing
because it's failing connection to SQL via the proxy:


 MySQL Connection Error: (2006) MySQL server has gone away
 Warning: mysqli::mysqli(): MySQL server has gone away in - on line 10
 Warning: mysqli::mysqli(): Error while reading greeting packet.
PID=167 in - on line 10
 Warning: mysqli::mysqli(): (HY000/2006): MySQL server has gone away in
- on line 10

The cloud sql proxy container complains about an account not having correct
permissions (however  I have given it editor permissions):

kubectl logs pods/wordpress-2608214628-9bc9b cloudsql-proxy


2017/06/22 13:40:15 Throttling
refreshCfg(lol-staging:europe-west2:lol-staging-001): it was only called
24.005689746s ago
2017/06/22 13:40:15 couldn't connect to
"lol-staging:europe-west2:lol-staging-001": ensure that the account has
access to "lol-staging:europe-west2:lol-staging-001" (and make sure there's
no typo in that name). Error during createEphemeral for
lol-staging:europe-west2:lol-staging-001: googleapi: Error 403: The client
is not authorized to make this request., notAuthorized
2017/06/22 13:40:18 New connection for
"lol-staging:europe-west2:lol-staging-001"


So I'm now wondering how to better validate which account is being referred
to here and whether the permissions are correct.




















>
> * If you run kubectl logs pod cloudsql-proxy you should see something like
> the following:
>
> 2017/06/21 20:45:06 Listening on (whatever) for (your instance name)
> 2017/06/21 20:45:06 Ready for new connections
>
> * If the cloudsql-proxy container is running, you can run kubectl exec
> (pod) -c cloudsql-proxy -ti /bin/sh to get a shell and try to verify the
> cloudsql-proxy configuration, or to start a new instance and make sure it
> is configured correctly.
>
> * We are using this with local Unix socket connections in the /cloudsql
> directory, but localhost sockets should also work.
>
>
> I'm surprised you don't see any logs from your wordpress container, but I
> can't help with that part.
>
> Good luck!
>
>
> On Thursday, June 22, 2017 at 3:15:26 AM UTC-4, Traiano Welcome wrote:
>>
>> Hi Ahmet
>>
>> On Thursday, 22 June 2017 02:25:05 UTC+4, Ahmet Alp Balkan wrote:
>>>
>>> Can you run "kubectl logs -l app=wordpress"? I am assuming there will be
>>> some logs from the crashing mysql container.
>>>
>>>
>> Thanks for your response. I get no output from running that command (I
>> suppose no logs are being generated). I tried both the command, and running
>> it in a loop, just in case:
>>
>>  for i in `seq 1 100`;do echo "checking $i " - $(kubectl logs -l app=web
>> );done
>>
>> No result.
>>
>> Just to be clear, wordpress container is in a pod, and the cloud sql
>> container is a sidecar container connected to pod.
>>
>> Google's documentation seems pretty thin on getting this working properly
>> with GKE containers, and non-existent on troubleshooting connectivity
>> issues with cloud sql proxy.
>>
>> Do you know of an alternative method of getting a container access to
>> Cloud SQL from GKE ?
>>
>>
>>
>> On Wed, Jun 21, 2017 at 7:58 AM, Traiano Welcome 
>>> wrote:
>>>
 I'm following this example of how to get wordpress running on GKE
 connected to Google Cloud SQL via the Google Cloud SQL Proxy:


 https://cloud.google.com/sql/docs/mysql/connect-container-engine


 

 Unfortunately, my wordpress pod is failing with a crashloop error, and
 it's not clear from the documentation how to dig deeper into the reason for
 this. Here is a sample of the error:


 bash-3.2$ kubectl get pods| egrep wordpress
 wordpress-713960421-v4f49 0/2   CrashLoopBackOff   16 20m

 (kubectl describe pod ...)

 11m   22s 36  kubelet, gke-noon-staging-default-  
 pool-d500b601-dfb6Warning FailedSync   
   Error syncing pod, skipping: [failed to "StartContainer" for "web" 
 with   CrashLoopBackOff: "Back-off 5m0s restarting failed container=web   
 pod=wordpress-713960421-v4f49_default(f64276d2-5660-11e7-a565-42010a9a0023)"
  , failed to "StartContainer" for 

Re: [kubernetes-users] Close access to node services

[Rodrigo Campos]

On different cloud providers, there is probably something to do. On AWS
just don't open those ports in the security group, and you are safe.

Also, you can avoid nodes having a public IP, for example.

But where are you running?

On Thursday, June 22, 2017, Evg  wrote:

> Thank you for answer!
> Yes indeed I use NodePorts for external load balancer, and there is need
> to restrict access
> to kube-proxy ports and NodePorts as well.
>
> What type is the service? You are probably using load balancer or
>> nodeport. Right?
>>
>> In that case, just change them to cluster IP.
>>
>> Also, see here for services types: https://kubernetes.io/d
>> ocs/concepts/services-networking/service/#publishing-
>> services---service-types
>>
>> And don't hesitate to ask if it doesn't do the trick or something :)
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes user discussion and Q" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-users+unsubscr...@googlegroups.com
> 
> .
> To post to this group, send email to kubernetes-users@googlegroups.com
> .
> Visit this group at https://groups.google.com/group/kubernetes-users.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

Re: [kubernetes-users] Use minikube in windows subsystem for linux?

[dsanders]

Hmmm, I didn't think about it that way.  Good point.

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

Re: [kubernetes-users] Getting Google's Cloud SQL Proxy to work

[Traiano Welcome]

Hi Ahmet

On Thursday, 22 June 2017 02:25:05 UTC+4, Ahmet Alp Balkan wrote:
>
> Can you run "kubectl logs -l app=wordpress"? I am assuming there will be 
> some logs from the crashing mysql container.
>
>
Thanks for your response. I get no output from running that command (I 
suppose no logs are being generated). I tried both the command, and running 
it in a loop, just in case:

 for i in `seq 1 100`;do echo "checking $i " - $(kubectl logs -l app=web 
);done

No result.

Just to be clear, wordpress container is in a pod, and the cloud sql 
container is a sidecar container connected to pod.

Google's documentation seems pretty thin on getting this working properly 
with GKE containers, and non-existent on troubleshooting connectivity 
issues with cloud sql proxy.

Do you know of an alternative method of getting a container access to Cloud 
SQL from GKE ?



On Wed, Jun 21, 2017 at 7:58 AM, Traiano Welcome  > wrote:
>
>> I'm following this example of how to get wordpress running on GKE 
>> connected to Google Cloud SQL via the Google Cloud SQL Proxy:
>>
>>
>> https://cloud.google.com/sql/docs/mysql/connect-container-engine
>>
>>
>> 
>>
>> Unfortunately, my wordpress pod is failing with a crashloop error, and 
>> it's not clear from the documentation how to dig deeper into the reason for 
>> this. Here is a sample of the error:
>>
>>
>> bash-3.2$ kubectl get pods| egrep wordpress
>> wordpress-713960421-v4f49 0/2   CrashLoopBackOff   16 20m
>>
>> (kubectl describe pod ...)
>>
>> 11m   22s 36  kubelet, gke-noon-staging-default-  pool-d500b601-dfb6 
>>Warning FailedSync Error syncing 
>> pod, skipping: [failed to "StartContainer" for "web" with   
>> CrashLoopBackOff: "Back-off 5m0s restarting failed container=web   
>> pod=wordpress-713960421-v4f49_default(f64276d2-5660-11e7-a565-42010a9a0023)"
>>  , failed to "StartContainer" for "cloudsql-proxy" withCrashLoopBackOff: 
>> "Back-off 5m0s restarting failed container=cloudsql-proxy
>> pod=wordpress-713960421-v4f49_default(f64276d2-5660-11e7- 
>> a565-42010a9a0023)"  
>>  ]
>>
>> My questions are: 
>>
>>- How to dig further into why the pod is failing to deploy with cloud 
>>sql proxy
>>- Has anyone got an example working for using cloud sql proxy with as 
>>simple mysql client pod?
>>
>> Here is a description of the deployment (kubectl describe wordpress):
>>
>>
>>  https://pastebin.com/DjYM97R7 
>>
>>
>> 
>>
>> And a description of the pod (kubectl describe ):
>>
>>
>> 
>>
>>  https://pastebin.com/pN7gUZg8 
>>
>>
>>
>> I deployed the cloud sql proxy and wordpress container separately and 
>> found the cloud sql proxy runs fine, but the wordpress blog container fails 
>> to startup on kubernetes. 
>> Error syncing pod, skipping: 
>>
>> failed to "StartContainer" for "wordpress" with CrashLoopBackOff
>>
>> 
>>  
>> Looking at the pod logs for wordpress, it seems wordpress is dying 
>> because it cannot connect to the MySQL DB: 
>>
>> MySQL Connection Error: (2002) Connection refused – Traiano Welcome 
>>  3 hours ago 
>> 
>>   
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Kubernetes user discussion and Q" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to kubernetes-use...@googlegroups.com .
>> To post to this group, send email to kubernet...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/kubernetes-users.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.