How to manage stateful containers with Kubernetes

Containers are inherently lightweight, ephemeral, and stateless. But organizations have many options when it comes to using containers for stateful applications.

Orchestrators like Kubernetes start, stop, destroy, and create containers in response to changing workload demands. While this approach works well for small workloads and stateless applications, it doesn’t work well for applications originally designed to be stateful.

By containerizing stateful applications, organizations can leverage the flexibility, resiliency, and speed of containers. To do this, however, they need ways to persist storage and manage state.

Learn how to containerize stateful applications and app components with Kubernetes, including the following:

  • the difference between stateless and stateful applications;
  • how to persist state in Kubernetes with PersistentVolumes and StatefulSets; and
  • top Kubernetes-based tools for container storage.

Stateless vs. stateful applications

A stateless application or component does not store client data generated in the current session for use in future sessions. Each operation in a stateless application is performed as if it were the first time. Common use cases for stateless applications are content delivery networks and print services that process short-duration print jobs.

A stateful application, on the other hand, stores certain data from previous sessions. Stateful applications are often used when user settings and actions need to be remembered across sessions—for example, saving items in an online shopping cart, chat history in a messaging app, or data in an analytics app that processes the same information repeatedly .

It is virtually impossible to run an enterprise-level application without maintaining a specific application state. However, the containerization of stateful applications and application components can create storage, state and data management challenges for IT teams.

How to run stateful applications on Kubernetes

PersistentVolumes and StatefulSets are the main approaches to running stateful applications on Kubernetes.

1. Persistent Volumes

In a stateful containerized application, data must be persistent, preserved, and easily accessible outside of the application. This is where PersistentVolumes come into play.

PersistentVolumes are Kubernetes cluster resources: storage elements in a cluster that point to a physical data location. PersistentVolumes provide reclaimable storage for applications running in Kubernetes pods outside of the pod lifecycle, meaning data is not lost when Kubernetes destroys or recreates a pod.

The Kubernetes master listens for PersistentVolumeClaims (PVCs), which are requests for persistent volume resources made using a specific storage class—referred to as StorageClass—such as Ceph File System (CephFS) or Azure Disks. After users set up a new PVC for Kubernetes, a control loop finds or mounts a matching PersistentVolume and binds it to the PVC to mount the volume in the requesting pod.

At the time of publication, Kubernetes supports the following PersistentVolume plugins:

  • AWS Elastic Block Store
  • Microsoft Azure Disk
  • Microsoft Azure files
  • CephFS volumes
  • Container storage interface
  • Fiber Channel storage
  • Persistent Google Compute Engine memory
  • GlusterFS volumes
  • hostPath volumes
  • iSCSI storage
  • Storage in the network file system
  • Portworx Volumes
  • RADOS Block Device Volumes
  • Disk volumes of the VMware vSphere virtual machine

2. StatefulSets

StatefulSets are Kubernetes objects that IT admins can use to deploy pods with persistent properties in a stateful application. StatefulSets maintain a sticky identity for each pod and attached storage—an identity that persists despite rescheduling. StatefulSets include the following features:

  • unique network identifiers, such as B. Consistent instance names;
  • persistent storage volumes based on user-defined storage classes; and
  • orderly deployments, scaling and updates.

StatefulSets make pod identity predictable by using an ordinal index to order pods – for example web-01, web-02, web-03 – instead of assigning random IDs to pods. By default, Kubernetes creates, deploys, and terminates pods in reverse order.

Once created, StatefulSets ensure that the desired number of pods are running at all times. In the event of a failure, StatefulSets terminate and replace pods and automatically map new detached pods to persistent storage as defined in the specifications. The following code is an example manifest file for deploying a stateful web app service using StatefulSets.

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web-statefulset
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx-svc"
  replicas: 2
  minReadySeconds: 10
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: pvdata
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

Common Kubernetes-based container storage tools

Container storage tools make it easy to run stateful containerized applications with Kubernetes.

OpenEBS

OpenEBS is an open source project for stateful workloads on Kubernetes. Enterprises can adopt cloud-native storage by treating persistent storage like any other container. OpenEBS features include the following:

  • Container-native storage follows the architecture of Container Attached Storage (CAS). Container storage volumes are deployed in Kubernetes as a dedicated pod or as pod replicas.
  • OpenEBS implements high availability through synchronous replication of data volumes.
  • OpenEBS has an abstraction layer over storage infrastructure implementations. It works with various underlying cloud deployments.
  • Because OpenEBS follows the CAS architecture for metrics like latency and throughput, IT teams can track and monitor them using Kubernetes Dashboard, Prometheus, or Grafana.

Portworx

Portworx by Pure Storage is enterprise container storage and data management software for Kubernetes focused on highly available clusters across multiple nodes and cloud instances. Portworx offers a range of software-based options for storage, disaster recovery, and security.

Portworx features include the following:

  • security and encryption;
  • Autoscaling, where the platform automatically adjusts the size of containers and storage volumes;
  • programmatic control over memory resources; and
  • Backups and snapshots.

Although containers are designed to be stateless, many applications today need to retrieve information across sessions. With container storage tools and the state-keeping options of Kubernetes, IT and DevOps teams can meet the need for stateful applications while reaping the benefits of the flexibility, consistency, and efficiency of containers.

Leave a Reply

Your email address will not be published. Required fields are marked *