Skip to content

09. StorageĀ¶

Headless ServicesĀ¶

Each connection to the service is forwarded to one randomly selected backing pod. But what if the client needs to connect to all of those pods? What if the backing pods themselves need to each connect to all the other backing pods. Connecting through the service clearly isnā€™t the way to do this. What is?

For a client to connect to all pods, it needs to figure out the IP of each individual pod. One option is to have the client call the Kubernetes API server and get the list of pods and their IP addresses through an API call, but because you should always strive to keep your apps Kubernetes-agnostic, using the API server isnā€™t ideal

Luckily, Kubernetes allows clients to discover pod IPs through DNS lookups. Usually, when you perform a DNS lookup for a service, the DNS server returns a single IP ā€” the serviceā€™s cluster IP. But if you tell Kubernetes you donā€™t need a cluster IP for your service (you do this by setting the clusterIP field to None in the service specification ), the DNS server will return the pod IPs instead of the single service IP. Instead of returning a single DNS A record, the DNS server will return multiple A records for the service, each pointing to the IP of an individual pod backing the service at that moment. Clients can therefore do a simple DNS A record lookup and get the IPs of all the pods that are part of the service. The client can then use that information to connect to one, many, or all of them.

Setting the clusterIP field in a service spec to None makes the service headless, as Kubernetes wonā€™t assign it a cluster IP through which clients could connect to the pods backing it.

Persistency & Sharing Data

Storage TopicsĀ¶

  • CSI
  • Persist Volumes
  • Persist Volumes Claims
  • Storage Class
  • Stateful Sets
  • Headless Services
  • Storage in Stateful Sets

Container Storage InterfaceĀ¶

CSIs are a set of RPCs (Remove Procedure Call) that used by one of orchestrator such as Kubernetes, Nomad and should implement by storage platform such as Ceph, glusterFS, MinIo.

+---------------+----------+--------------------+
| Orchestrator  =   RPCs   =  Storage Platform  |
+---------------+----------+--------------------+

Persistent VolumesĀ¶

PVĀ¶

Persistent Volumes or PV in short, manages and predefined by K8S administrator

Access ModeĀ¶

  • ReadOnlyMany: Mount more than one pod but just in ReadOnly mode
  • ReadWriteOnce: Mount with just one pod in ReadWrite mode
  • ReadWriteMany: Mount to many pods in ReadWrite mode

Persistent Volumes ClaimĀ¶

PVCĀ¶

Persistent Volume Claim or PVC in short,

Binding PolicyĀ¶

  • Sufficient Capacity
  • Access Mode
  • Volume Mode
  • Storage Class
  • Selectors

persistentVolumeReclaimPolicyĀ¶

  • Retain: After it's PVC is deleted, the PV is still remain and must delete manually by kubernetes administrator, and useless by other PVCs

  • Delete: As soon as it's related PVC is deleted, the related PV is deleted too.

  • Recycle: Like Retain by one special difference, if PVC is deleted PV is still and it's own data will be deleted and ready to serve another PVC

Storage ClassesĀ¶

Storage Class automates all the processes after user creates its own PVC. In fact Storage Class create a create storage request, create a proper PV and bind PVC to PV automatically.

Storage Class WorkflowĀ¶

  1. Pod requests request for a PVC
  2. User creates PVC
  3. StorageClass makes request to a storage provider (Provisioner)
  4. StorageClass makes PV
  5. StorageClass binds PV to PVC

StateFulSetĀ¶

When we need to set sequence priority (one after another) between services and also set a static name for resources (pod).

MySQL scenario for STSĀ¶

In this scenario we need from 3 MySQL nodes. One master, and two worker.

Note 1: If each pod is crashed, STS up it again with previous resource name.

Note 2: Scale up and down is also sequential in STS.

Scenario SequenceĀ¶

  1. Setup master first and then workers
  2. Clone data from master to worker-1
  3. Enable continuous replication from master-1 to worker-1
  4. Wait for worker-1 to be ready
  5. Clone data from worker-1 to worker-2
  6. Enable continuous replication from master to worker-2
  7. Configure master address on workers (static name)