skip to Main Content

I have deploy my application in kubernetes using deployment.

  1. Whenever user gets login to application pod will generate session for that user.
  2. To maintain session stickiness I have set session cookie using Nginx ingress annotations.
  3. When hpa scale down pods application user is phasing a logout problem when pod is get terminated. If ingress has generated a session using this pod. It needs to log in again.
  4. What I want is some sort of graceful termination of the connection. when pod is in a terminating state it should serve existing sessions until grace period.

2

Answers


  1. What i want is some sort of graceful termination of connection. when
    pod is in terminating state it should serve existing sessions
    until grace period.

    You can use the key in POD spec : terminationGracePeriodSeconds

    this will wait for the mentioned second and after that POD will get terminated.

    You can read more at : https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-terminating-with-grace

    Login or Signup to reply.
  2. The answer Harsh Manvar is great, However, I want to expand it a bit 🙂

    You can of course use terminationGracePeriodSeconds in the POD spec. Look at the example yaml:

    apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod
    spec:
      containers:
      - name: my-container
        image: my-image
      terminationGracePeriodSeconds: 60
    

    At this point, Kubernetes waits for a specified time called the termination grace period. By default, this is 30 seconds. It’s important to note that this happens in parallel to the preStop hook and the SIGTERM signal. Kubernetes does not wait for the preStop hook to finish.

    If your app finishes shutting down and exits before the terminationGracePeriod is done, Kubernetes moves to the next step immediately.

    If your pod usually takes longer than 30 seconds to shut down, make sure you increase the grace period. You can do that by setting the terminationGracePeriodSeconds option in the Pod YAML. For example, to change it to 60 seconds.

    For more look here.

    If you want to know how exactly looks like pod lifecycle see this link to the official documentation. The part about the termination of pods should be most interesting. You will also have it described how exactly the termination takes place.

    It is recommended that applications deployed on Kubernetes have a design that complies with the recommended standards.
    One set of standards for modern, cloud-based applications is known as the Twelve-Factor App:

    Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.
    Some web systems rely on “sticky sessions” – that is, caching user session data in memory of the app’s process and expecting future requests from the same visitor to be routed to the same process. Sticky sessions are a violation of twelve-factor and should never be used or relied upon. Session state data is a good candidate for a datastore that offers time-expiration, such as Memcached or Redis.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search