liveBook · Manning

Stateless system

As explained in Google Anthos in Action

A stateless application does not retain client-session state between requests.

A stateless application does not retain knowledge of client sessions or past transactions between requests. Each request can therefore be handled without requiring the same server. section 15.4.3

A Kubernetes deployment uses statelessness to:

  • Run identical Pods from a container image under a Deployment. section 15.4.3
  • Group Pods behind a Service with a stable cluster IP and label-based endpoint discovery. section 15.4.3
  • Expose the workload externally by changing the Service to type LoadBalancer. section 15.4.3

Migrated Tomcat workload

A Migrate for Anthos-generated deployment_spec.yaml creates a Tomcat Deployment and Service. Applying it with kubectl starts the Pod; a LoadBalancer Service makes the application externally reachable. section 15.4.3

Listing 15.1 The deployment_spec.yaml generated by M4A
# Stateless application specification
# The Deployment creates a single replicated Pod, indicated by the 'replicas' field
apiVersion: apps/v1
kind: Deployment
metadata:
 creationTimestamp: null
 labels:
   app: tomcat-vm-gulli-vm
   migrate-for-anthos-optimization: "true"
   migrate-for-anthos-version: v1.5.0
 name: tomcat-vm-gulli-vm
spec:
 replicas: 1
 selector:
   matchLabels:
     app: tomcat-vm-gulli-vm
     migrate-for-anthos-optimization: "true"
     migrate-for-anthos-version: v1.5.0
 strategy: {}
 template:
   metadata:
     creationTimestamp: null
     labels:
       app: tomcat-vm-gulli-vm
       migrate-for-anthos-optimization: "true"
       migrate-for-anthos-version: v1.5.0
   spec:
     containers:
     - image: gcr.io/named-tome-295414/tomcat-vm-gulli-vm:11-13-2020--15-0-39
       name: tomcat-vm-gulli-vm
       readinessProbe:
         exec:
           command:
           - /code/ready.sh
       resources: {}
       securityContext:
         privileged: true
       volumeMounts:
       - mountPath: /sys/fs/cgroup
         name: cgroups
     volumes:
     - hostPath:
         path: /sys/fs/cgroup
         type: Directory
       name: cgroups
status: {}

---
# Headless Service specification -
# No load-balancing, and a single cluster internal IP, only reachable from within the cluster
# The Kubernetes endpoints controller will modify the DNS configuration to return records (addresses) that point to the Pods, which are labeled with "app": "tomcat-vm-gulli-vm"
apiVersion: v1
kind: Service
metadata:
 creationTimestamp: null
 name: tomcat-vm-gulli-vm
spec:
 clusterIP: None
 selector:
   app: tomcat-vm-gulli-vm
 type: ClusterIP
status:
 loadBalancer: {}

---

Inspect the generated YAML showing the stateless Deployment, replica setting, image, selectors, and Pod template. section 15.4.3

How Google Anthos in Action covers it

How deep it goes
Defines session independence and demonstrates generated Deployment and Service YAML, but does not detail session-storage design.
Examples
Uses a migrated Tomcat VM, deployment_spec.yaml, kubectl apply, and a LoadBalancer Service.
What you can do after
Operate a migrated stateless workload by applying generated YAML and exposing its Pods through a Service.
How it connects
Connects stateless applications to Kubernetes Deployments, Pods, Services, container images, and load balancing.

Also explained in

Compare how 14 books explain stateless system →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Google Anthos in Action. The section links point to the parts of the book it draws on.