Discussing StatefulSets

Kubernetes started providing a resource to manage stateful workloads with the alpha release of PetSets in the 1.3 release. This capability has matured and is now known as StatefulSets. A StatefulSet has some similarities to a ReplicaSet in that it is responsible for managing the lifecycle of a set of Pods, but how it goes about this management has some noteworthy differences. PetSet might seem like an odd name for a Kubernetes resource, and it has since been replaced.

Still, it provides fascinating insights into the Kubernetes community’s thought process for supporting stateful workloads. The fundamental idea is that there are two ways of handling servers: to treat them as pets that require care, feeding, and nurturing or to treat them as cattle to which you don’t develop an attachment or provide much individual attention. If you’re logging into a server regularly to perform maintenance activities, you treat it as a pet.

**Contrasting Application Models**

As applications serve a growing user base around the globe, single cluster and data center solutions are no longer satisfying. Clustered applications and federations enable workloads to spread across multiple locations and container clusters for improved efficiency and scale. You will find contrasting deployment models when you examine the application types and scaling modes (for example, scale-up and scale-out clustering ).

There are substantial differences between deploying and running single applications to applications that operate within a cluster. Different application architectures require different deployment solutions and network identities. For example, a database node requires persistent volumes, or a node within a cluster uses specific elections where identity is essential. 

**Kubernetes Pets **

Kubernetes has recently ramped up by introducing a new Kubernetes object called PetSets. PetSets is geared towards improving stateful support and is currently an alpha resource in Kubernetes release 1.3. It holds a group of Kubernetes Pets, aka stateful applications that require stable hostnames, persistent disks, a structured lifecycle process, and group identity. 

PetSets are used for non-homogenous instances where each POD has a stable distinguishable identity. A different identity is viewed in terms of stable network and storage. 

A ) Stable network identities such as DNS and hostname.

B ) Stable storage identity.

Before PetSets, stateful applications were supported but exceedingly challenging to deploy and manage, especially regarding distributed stateful clusters. In addition, PODs had random names that could not be relied upon. With the introduction of PetSets controllers and Kubernetes Pets, Kubernetes has sharpened its support for stateful and distributed stateful applications.

Challenges: PODs and their shortcomings 

Kubernetes enables the specification of applications as a POD file, expressed in YAML or JSON format. The file specifies what containers are to be in a POD. PODs are the smallest deployment unit in Kubernetes and present several challenges for some stateful services. They do not offer a singleton pattern and are temporary by design.

Their constructs are mortal as they are born and die but never resurrected. When a POD dies, it’s permanently gone and replaced with a new instance and fresh identity. This operation model may suit some applications but falls short for others who want to retain identity and storage across restart / reschedule. 

Challenges: Replication Controllers and their shortcomings

If you want a POD to resurrect, you need a Replication Controller ( RC ). The RC enables a singleton pattern to set replication patterns to a specific number of PODs.

The introduction of the RC is undoubtedly a step in the right direction, as it ensures the correct number of replicas are always running at any given time. The RC works alongside services before the RC, using labels to map inbound requests to certain PODs.

Services provide a level of abstraction so that the application endpoint never changes. RC is suitable for application deployments requiring weak uncoupled identities, and when naming individual PODs doesn’t matter to the application architecture.

However, they lack certain functionalities that the new PetSet controller provides. So you could say that a PetSet controller is an enhanced RC controller in shiny new clothes.

A key point: “Pets and Cattle.” 

The best way to understand Kubernetes Pets and PetSets is to perceive the cloud infrastructure with the “Pets and Cattle” metaphor. A“Pet” is a special snowflake you have emotional ties towards and requires special handling, for example, when it’s sick, unlike “Cattle,” which is viewed as an easily replaceable commodity.

Cattle are similar enough to each other that you can treat them all as equals. Therefore, the application does not suffer much if a cattle dies or needs replacement.

• Cattle refers to stateless applications, and Pets refer to stateful, “build once, run anywhere” applications.

Discussing Stateless applications

A stateless application takes in a request and responds, but nothing is left behind to fulfill subsequent connections. The stateless pattern derives from another independent system’s ability to satisfy subsequent requests/responses. Stateful applications store data for further use. These types of applications can be inspected with a stateful inspection firewall.

Note: PetSet Objects

Stateful applications are grouped into what’s known as a PetSet object. The PetSet controller has a family-orientated approach, as opposed to the traditional RC, which is mainly concerned with the number of replicas. PODs are stateless disposable units that can be removed and interchanged without affecting the application. The Pets, conversely, are groups of stateful PODs requiring stronger different identities.

Note: PetSet Identities 

Within a PetSet, Pets ( stateful applications ) have a unique, distinguishable identity. The identities stick and do not change when restarting/rescheduling. They have an explicit purpose/role in life that is known throughout the family—a definitive startup carried out in a structured order that fits within its responsibility in the application’s framework.

Initially, the cattle approach forced us to view cloud components as anonymous resources. However, this approach does not fit all application requirements. Stateful applications require us to rethink the new pet-style approach. 

Workloads and Application Types Suitable for Pets:

Stateful application within a PetSet object requires unique identities such as : 

1. Storage
2. Ordinal index
3. Stable Hostname

The PetSet object supports clustered applications that require stricter membership and identity requirements, such as : 

1. Discovery of peers for quorum
2. Startup and Teardown

Workloads that benefit from PetSets include, for example :

1. NoSQL databases – clustered software like Cassandra, Zookeeper, etcd, requiring regular membership.
2. Relationshional Databases – MySQL or PostgreSQL requiring persistent volumes. 

Application Roles & Responsibilities 

Applications have different roles and responsibilities, requiring different deployment models. For example, a Cassandra cluster has strict membership and identity requirements; specific nodes are designated seed nodes used during startup to discover the cluster.

They come first and act as the contact points for all other nodes to get information about the cluster. All nodes require one seed node, and all nodes within a cluster must have the same seed node. No node can join the cluster without a seed node, meaning their role is vital for the application framework.

Note: Zookeeper – Identification of Peers

Zookeeper or etcd requires the identification of peers and instances clients should contact. Other databases have a master/slave model where the master has unidirectional control over the slave. The “primary” server has a different role and identity requirements than the “slave.” Properly running these types of services requires more complex features in Kubernetes.

Closing Points on Kubernetes PetSets

PetSets, now more commonly known as StatefulSets, are a Kubernetes resource designed to manage stateful applications. Unlike the standard ReplicaSets that manage stateless applications by treating all replicas as identical, PetSets offer a more sophisticated way to manage pods. Each pod in a PetSet has a guaranteed unique identity, stable networking, and persistent storage, making them ideal for databases, caches, and other applications that require stable identities.

One of the standout features of PetSets is their ability to maintain a stable identity for each pod, which is crucial for stateful applications. This includes:

– **Persistent Storage:** Each pod in a PetSet can have its own persistent volume, ensuring that data is retained across restarts.

– **Ordered Deployment and Scaling:** PetSets ensure that pods are deployed or scaled up in a specific order, which is essential for applications with interdependencies.

– **Stable Network Identity:** Each pod retains its network identity, which is important for applications that rely on consistent access to resources.

Deploying a stateful application using PetSets involves defining a StatefulSet resource in your Kubernetes cluster. This resource specifies the desired number of replicas, the template for the pods, and any associated persistent volumes. By following best practices in your configurations, you can ensure that your stateful applications benefit from the stability and reliability that PetSets offer.

PetSets are particularly beneficial for applications like databases (e.g., MySQL, Cassandra), distributed file systems (e.g., HDFS), and other systems that require stable identities and persistent storage. By utilizing PetSets, organizations can ensure high availability and resilience for their critical stateful applications, even in dynamic environments.