Re: [kubernetes-users] Load balancer drops backend while leaving frontend connected

[Tyler Johnson]

No this is during regular operation.

On Wed, Apr 4, 2018 at 11:39 AM, 'Nicks' via Kubernetes user discussion and
Q <kubernetes-users@googlegroups.com> wrote:

> Did you remove a node from the cluster? Even if a node was in the cluster
> and didn't run any workload, it could still be used to proxy connections
> from the LB and the service pod.
>
> On Friday, March 30, 2018 at 7:42:42 AM UTC-7, Tyler Johnson wrote:
>>
>> Environment: GKE 1.7.12-gke.1
>> I believe the ingress controller is GLBC[1]
>>
>> [1] https://github.com/kubernetes/ingress-gce
>>
>> On Thu, Mar 29, 2018 at 11:56 PM, 'Tim Hockin' via Kubernetes user
>> discussion and Q <kubernet...@googlegroups.com> wrote:
>>
>>> Which environment and which Ingress controller?
>>>
>>> On Thu, Mar 29, 2018 at 8:42 PM Tyler Johnson <tyler@risevision.com>
>>> wrote:
>>>
>>>> Is it possible that an HTTP load balancer (auto-configured as part of
>>>> an Ingress) could occasionally drop backend connections while leaving the
>>>> frontend connected?
>>>>
>>>> I'm running a websocket backend service (the backend-service timeout is
>>>> high) and on very rare occasions I'll see the service pod log that the
>>>> client dropped connection, while on the client side the HTTP connection is
>>>> still ESTABLISHED. So I'm guessing it must be the LB.
>>>>
>>>> Is there a recommended way to troubleshoot the LB?
>>>>
>>>> Any other potential scenarios that could cause this problem?
>>>>
>>>> --
>>>> 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 a topic in the
>>> Google Groups "Kubernetes user discussion and Q" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>> pic/kubernetes-users/LQJCmd3SYDE/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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 a topic in the
> Google Groups "Kubernetes user discussion and Q" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/kubernetes-users/LQJCmd3SYDE/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Load balancer drops backend while leaving frontend connected

[Tyler Johnson]

Environment: GKE 1.7.12-gke.1
I believe the ingress controller is GLBC[1]

[1] https://github.com/kubernetes/ingress-gce

On Thu, Mar 29, 2018 at 11:56 PM, 'Tim Hockin' via Kubernetes user
discussion and Q <kubernetes-users@googlegroups.com> wrote:

> Which environment and which Ingress controller?
>
> On Thu, Mar 29, 2018 at 8:42 PM Tyler Johnson <
> tyler.john...@risevision.com> wrote:
>
>> Is it possible that an HTTP load balancer (auto-configured as part of an
>> Ingress) could occasionally drop backend connections while leaving the
>> frontend connected?
>>
>> I'm running a websocket backend service (the backend-service timeout is
>> high) and on very rare occasions I'll see the service pod log that the
>> client dropped connection, while on the client side the HTTP connection is
>> still ESTABLISHED. So I'm guessing it must be the LB.
>>
>> Is there a recommended way to troubleshoot the LB?
>>
>> Any other potential scenarios that could cause this problem?
>>
>> --
>> 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 a topic in the
> Google Groups "Kubernetes user discussion and Q" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/kubernetes-users/LQJCmd3SYDE/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Load balancer drops backend while leaving frontend connected

[Tyler Johnson]

Is it possible that an HTTP load balancer (auto-configured as part of an 
Ingress) could occasionally drop backend connections while leaving the 
frontend connected?

I'm running a websocket backend service (the backend-service timeout is 
high) and on very rare occasions I'll see the service pod log that the 
client dropped connection, while on the client side the HTTP connection is 
still ESTABLISHED. So I'm guessing it must be the LB.

Is there a recommended way to troubleshoot the LB?

Any other potential scenarios that could cause this problem?  

-- 
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] GKE PersistentVolumeClaim in Deployment vs StatefulSet

[Tyler Johnson]

Sorry, I had understood the preference for SS but written it out backwards
:)

On Tue, Mar 20, 2018 at 3:46 PM, 'Michelle Au' via Kubernetes user
discussion and Q <kubernetes-users@googlegroups.com> wrote:

> To be clear, I am recommending using StatefulSets over Deployments when
> using any Read-Write-Once volume type like PDs.
>
>
> On Tue, Mar 20, 2018 at 11:58 AM Tyler Johnson <
> tyler.john...@risevision.com> wrote:
>
>> Thanks Michelle, that helps to clarify the reason to prefer Deployments
>> over StatefulSets when using PDs.
>>
>> On Tue, Mar 20, 2018 at 2:34 PM, 'Michelle Au' via Kubernetes user
>> discussion and Q <kubernetes-users@googlegroups.com> wrote:
>>
>>> Hi Tyler,
>>>
>>> StatefulSets will also give you a stable network identity, if you need
>>> that.  Since GCE PDs can only be mounted in write mode by one node, you
>>> should only have one pod referencing it.  It is easy to misconfigure
>>> Deployments to end up in scenarios with multiple pods referencing the same
>>> GCE PD (see discussion https://github.com/kubernetes/kubernetes/issues/
>>> 48968#issuecomment-315490408), which will fail.  For that reason,
>>> StatefulSets is also recommended to avoid the multi-pod scenario.
>>>
>>> Thanks,
>>> Michelle
>>>
>>>
>>> On Tue, Mar 20, 2018 at 10:35 AM Tyler Johnson <
>>> tyler.john...@risevision.com> wrote:
>>>
>>>> I've seen documentation, blog posts, and stackoverflow responses
>>>> indicating two different solutions for persisting data across pod restarts.
>>>>
>>>> In one solution, it's a volume mounted as persistent volume claim
>>>> within a Deployment. [3]
>>>>
>>>> In the other, the persistent volume claim is mounted within a
>>>> StatefulSet.
>>>>
>>>> The official documentation clearly indicates Deployments for stateless
>>>> [1] applications and StatefulSets for stateful [2] applications.
>>>>
>>>> The question is, does the Deployment as stateful application set up
>>>> work even though the documentation appears to indicate otherwise? Is there
>>>> a significant difference between the two options?
>>>> And does it make sense to use the StatefulSet for one pod just to set
>>>> up persistence? The Kubernetes documentation [4] describes an unrelated
>>>> goal for StatefulSets, indicating that they "manage the deployment and
>>>> scaling of a set of Pods
>>>> <https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/>,
>>>> and provides guarantees about the ordering and uniqueness of these Pods."
>>>>
>>>> [1] https://cloud.google.com/kubernetes-engine/docs/how-to/
>>>> stateless-apps
>>>> [2] https://cloud.google.com/kubernetes-engine/docs/how-to/
>>>> stateful-apps
>>>> [3] https://devopscube.com/persistent-volume-google-kubernetes-engine/
>>>> [4] https://kubernetes.io/docs/concepts/workloads/
>>>> controllers/statefulset/
>>>>
>>>> --
>>>> 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 a topic in the
>>> Google Groups "Kubernetes user discussion and Q" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/
>>> topic/kubernetes-users/2jG8nr-WA3A/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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 

Re: [kubernetes-users] GKE PersistentVolumeClaim in Deployment vs StatefulSet

[Tyler Johnson]

Thanks Michelle, that helps to clarify the reason to prefer Deployments
over StatefulSets when using PDs.

On Tue, Mar 20, 2018 at 2:34 PM, 'Michelle Au' via Kubernetes user
discussion and Q <kubernetes-users@googlegroups.com> wrote:

> Hi Tyler,
>
> StatefulSets will also give you a stable network identity, if you need
> that.  Since GCE PDs can only be mounted in write mode by one node, you
> should only have one pod referencing it.  It is easy to misconfigure
> Deployments to end up in scenarios with multiple pods referencing the same
> GCE PD (see discussion https://github.com/kubernetes/kubernetes/issues/
> 48968#issuecomment-315490408), which will fail.  For that reason,
> StatefulSets is also recommended to avoid the multi-pod scenario.
>
> Thanks,
> Michelle
>
>
> On Tue, Mar 20, 2018 at 10:35 AM Tyler Johnson <
> tyler.john...@risevision.com> wrote:
>
>> I've seen documentation, blog posts, and stackoverflow responses
>> indicating two different solutions for persisting data across pod restarts.
>>
>> In one solution, it's a volume mounted as persistent volume claim within
>> a Deployment. [3]
>>
>> In the other, the persistent volume claim is mounted within a StatefulSet.
>>
>> The official documentation clearly indicates Deployments for stateless
>> [1] applications and StatefulSets for stateful [2] applications.
>>
>> The question is, does the Deployment as stateful application set up work
>> even though the documentation appears to indicate otherwise? Is there a
>> significant difference between the two options?
>> And does it make sense to use the StatefulSet for one pod just to set up
>> persistence? The Kubernetes documentation [4] describes an unrelated goal
>> for StatefulSets, indicating that they "manage the deployment and scaling
>> of a set of Pods
>> <https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/>, and
>> provides guarantees about the ordering and uniqueness of these Pods."
>>
>> [1] https://cloud.google.com/kubernetes-engine/docs/how-to/stateless-apps
>> [2] https://cloud.google.com/kubernetes-engine/docs/how-to/stateful-apps
>> [3] https://devopscube.com/persistent-volume-google-kubernetes-engine/
>> [4] https://kubernetes.io/docs/concepts/workloads/
>> controllers/statefulset/
>>
>> --
>> 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 a topic in the
> Google Groups "Kubernetes user discussion and Q" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/kubernetes-users/2jG8nr-WA3A/unsubscribe.
> To unsubscribe from this group and all its topics, 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] GKE PersistentVolumeClaim in Deployment vs StatefulSet

[Tyler Johnson]

I've seen documentation, blog posts, and stackoverflow responses indicating 
two different solutions for persisting data across pod restarts.

In one solution, it's a volume mounted as persistent volume claim within a 
Deployment. [3]

In the other, the persistent volume claim is mounted within a StatefulSet.

The official documentation clearly indicates Deployments for stateless [1] 
applications and StatefulSets for stateful [2] applications.

The question is, does the Deployment as stateful application set up work 
even though the documentation appears to indicate otherwise? Is there a 
significant difference between the two options?
And does it make sense to use the StatefulSet for one pod just to set up 
persistence? The Kubernetes documentation [4] describes an unrelated goal 
for StatefulSets, indicating that they "manage the deployment and scaling 
of a set of Pods 
, and 
provides guarantees about the ordering and uniqueness of these Pods."

[1] https://cloud.google.com/kubernetes-engine/docs/how-to/stateless-apps
[2] https://cloud.google.com/kubernetes-engine/docs/how-to/stateful-apps
[3] https://devopscube.com/persistent-volume-google-kubernetes-engine/
[4] https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

-- 
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.