1. What is statefulSet?

StatefulSets in Kubernetes (K8s) is a workload API object used for managing stateful applications. It manages the deployment and scaling of a set of Pods and provides guarantees about the ordering and uniqueness of these Pods. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. This feature is particularly important for stateful applications that require stable, unique network identifiers, stable persistent storage, and ordered, graceful deployment and scaling.

Here are some key aspects of StatefulSets:

1. Stable, Unique Network Identifiers: Each Pod in a StatefulSet derives its hostname from the name of the StatefulSet and the ordinal of the Pod. The pattern is <statefulset name>-<ordinal>. This means that each Pod’s name is predictable and maintains its identity across rescheduling.

2. Stable, Persistent Storage: StatefulSets can use PersistentVolumes to provide stable storage through restarts and rescheduling of Pods. When using StatefulSets, you can assign a unique PersistentVolume for each Pod in the set.

3. Ordered, Graceful Deployment and Scaling: StatefulSets respect the order of deployment, scaling, and termination. For example, when Pods are being deployed, they are created sequentially, in order from {0..N-1}. When Pods are being deleted, they are terminated in reverse order, from {N-1..0}.

4. Ordered, Automated Rolling Updates: When the Pod template is updated, the Pods are terminated and recreated in a controlled and predictable way. By default, this follows the same ordering rules as during scaling.

Applications suited for StatefulSets include databases like MySQL and PostgreSQL, clustered applications like Cassandra, and any other application that requires one or more of these properties. StatefulSets make it easier to deploy and manage such applications in a Kubernetes environment while providing the necessary guarantees for stateful workloads.

2. StatefulSets VS Deployments

Similarities

1. Manage Pods: Both StatefulSets and Deployments are higher-level abstractions that manage the lifecycle of pods.
2. Scalability: They both support scaling operations, allowing you to increase or decrease the number of pod replicas.
3. Update Strategy: Both support rolling updates, ensuring that application changes can be deployed with minimal downtime.
4. Declarative Configuration: You define both StatefulSets and Deployments using YAML configurations in Kubernetes.
5. Self-Healing: They both ensure that the specified number of pods are always running and replace pods that fail.

Differences

1. State Management:
   • StatefulSets: Designed for stateful applications. Each pod in a StatefulSet is given a stable and unique network identifier that is maintained across rescheduling.
   • Deployments: Suited for stateless applications. Pods in a Deployment are interchangeable, with no unique identity.
2. Storage:
   • StatefulSets: Commonly used with persistent storage. Each pod can be associated with its own PersistentVolume, ensuring data persistence.
   • Deployments: Often use ephemeral or shared storage, as pods don’t need to maintain state.
3. Pod Identity:
   • StatefulSets: Pods have a persistent identity. The identity sticks to the pod, regardless of which node it's scheduled on.
   • Deployments: Pods are anonymous; a new pod is indistinguishable from the replaced ones.
4. Scaling and Updates:
   • StatefulSets: Scaling and updates are ordered and sequential. For example, pods are created and terminated in a specific order.
   • Deployments: Scaling and updates can happen in parallel and do not guarantee any order.
5. Use Cases:
   • StatefulSets: Ideal for applications like databases, clustered applications, and other scenarios where the order and identity are important.
   • Deployments: Best for stateless applications like web servers, front-end interfaces, and REST APIs where scaling and load balancing are primary concerns.

Conclusion

• Choose StatefulSets for applications where the identity, order, and state persistence of each pod are crucial.
• Opt for Deployments when dealing with stateless applications that require fast scaling and dynamic load balancing, where pod identity is not important.

3. Sticky Session in ECS VS StatefulSet in EKS

Sticky Sessions in ECS with Load Balancers

Sticky Sessions in Amazon Elastic Container Service (ECS) when used with load balancers, are a method to ensure that a user's session requests are directed to the same backend instance. This is particularly useful in scenarios where session state is stored locally on the instance. Here's how they work in ECS:

1. Enabling Sticky Sessions: Sticky sessions are enabled through load balancer settings in the ECS service configuration. This can be done with both Application Load Balancers (ALB) and Classic Load Balancers.
2. Session Affinity: When a client makes a request, the load balancer sends the request to a target (like an ECS task). With sticky sessions enabled, the load balancer creates a session cookie. Future requests from the same client are directed to the same target based on this cookie, maintaining session affinity.
3. Duration of Stickiness: You can configure the duration for which the load balancer should maintain the stickiness. After this period, the session may be directed to a different target.

Equivalent in Kubernetes StatefulSets

In Kubernetes, StatefulSets provide a different approach to maintaining state. While they don't directly correspond to sticky sessions in load balancers, they offer a way to manage stateful applications:

1. Stable Identity: Each pod in a StatefulSet has a stable hostname and network identity. This means that even if a pod is rescheduled, it retains its identity, and any stateful connections or data can be consistently accessed.
2. Persistent Storage: StatefulSets can be used with PersistentVolumeClaims to ensure that each pod has a dedicated and persistent storage attached to it. This way, even if the pod is rescheduled to a different node, its state remains intact.
3. Ordered Deployment and Scaling: Pods in a StatefulSet are created and deleted in a specific order, which can be crucial for stateful applications where the order of scaling or updates matters.

Key Differences

• Nature of State Management:

  • ECS with Sticky Sessions: Focuses on routing client requests to the same backend instance for session consistency.
  • Kubernetes StatefulSets: Focuses on maintaining a consistent identity and storage for pods, suitable for applications like databases or clustered applications.

• Use Cases:

  • ECS is typically used for applications where the session state is lightweight and can be stored temporarily on the instance.
  • StatefulSets are used for applications where data persistence and order are crucial, such as database applications.

In summary, sticky sessions in ECS are about directing traffic to the same instance for session consistency, whereas StatefulSets in Kubernetes offer a more integrated solution for running applications that require stable identity, persistent storage, and ordered operations.