Load Balancing

Not all apps are compatible!

Predictable hostnames

Needed for none load-balancing apps

Not possible with Deployments

Statefulsets

Intended for "stateful" applications

---
apiVersion: apps/v1
kind: StatefulSet         # Different kind
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  serviceName: mysql      # Must match Service object
  replicas: 1
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - name: "db"
          image: "ten7/flight-deck-db:develop"
          ports:
            - containerPort: 3306
              name: mysql
              protocol: TCP

Like a Deployment

kubectl get statefulsets

kubectl describe statefulset name

kubectl edit statefulset name

Fault tolerant

New pod assumes "place" of failed pod

Includes hostname and volumes

Yes!

Service advertises network accessibility

But not load balancing

Headless Services

Advertises access

No load balancing

---
apiVersion: v1
kind: Service
metadata:
  name: mysql       # Matches Statefulset.serviceName
spec:
  clusterIP: None
  ports:
    - name: mysql
      port: 3306
      protocol: TCP
  selector:         # Matches Statefulset.selector
    app: mysql

How is this headless?

clusterIP: None

Disables any load balancing

Volumes

Managed disk storage

Allocated as an object, mounted in pod

Allocation

1. Persistent Volume Claim (PVC)
2. Volume Claim template on Statefulset

Volume Claim Template

Allocates disk for each replica

Disk reattached if pod is deleted, restarted

Best for MySQL replicated setup

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:

# Rest of spec goes here.

  volumeClaimTemplates:
    - metadata:
        name: vol-mysql    # Name of Claim
      spec:
        accessModes:
          - ReadWriteOnce  # Shareability
        resources:
          requests:        # Requirements of request
            storage: 10Gi
                

Shareability

Specified by accessModes

Most managed k8s do not support multi-writer!

Requests

Specifies how to allocate the disk

Size, class, other host-specific options

Mounting

Volume must be mounted into pod

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  serviceName: mysql
  replicas: 1
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - name: "db"
          image: "ten7/flight-deck-db:develop"
          ports:
            - containerPort: 3306
              name: mysql
              protocol: TCP
          volumeMounts:                        # Mount volumes...
            - mountPath: /var/lib/mysql        # ...at this path...
              name: vol-mysql                  # ...with this claim.
  volumeClaimTemplates:
    - metadata:
        name: vol-mysql
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 10Gi

Who owns the disk?

The unix root account

Causes problems if containers run as non-root

Masking ownership

Mount disk as group...

...and run the user as part of that group.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      securityContext:    # Specify security options
        fsGroup: 1000     # Mask disk with GID 1000
      containers:
        - image: ten7/flight-deck-drupal:latest
          name: web
          ports:
            - containerPort: 80

Allows us to set special permission options

fsGroup masks disk, applies GID to user

Brute-force method

Run a container as root first...

And chown the files.

---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  serviceName: mysql
  replicas: 1
  template:
    metadata:
      labels:
        app: mysql
    spec:
      initContainers:                    # Runs before containers
        - name: "fix-pvc-permissions"
          image: "alpine:3.9"
          command:                       # chmod all files
            - "sh"
            - "-c"
            - "chown -R 1000:1000 /var/lib/mysql"
          volumeMounts:
            - mountPath: /var/lib/mysql  # Same mountpoint
              name: vol-mysql
      containers:
        - name: "db"
          image: "ten7/flight-deck-db:develop"
          ports:
            - containerPort: 3306
              name: mysql
              protocol: TCP
          volumeMounts:
            - mountPath: /var/lib/mysql
              name: vol-mysql
  volumeClaimTemplates:
    - metadata:
        name: vol-mysql
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 10Gi

Claims aren't disks!

They request storage...

...not embody it!

Represent fulfilled claims

Are not deleted with claim!

Listing

kubectl get persistentvolumes

...or...

kubectl get pv

$ kubectl --kubeconfig="/path/to/kubeconfig.yml" get pv
NAME                      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                        STORAGECLASS       REASON   AGE
pvc-abcdef-0123-4567-89   10Gi       RWO            Delete           Bound    default/vol-mysql-mysql-0                   do-block-storage            79d

Deleting volumes

Must be done explicitly

Avoid the portal!

Delete through kubectl instead

May leave "dangling" PVs

Make a backup first

Kubernetes has no "undo".

$ kubectl --kubeconfig="/path/to/kubeconfig.yml" delete pv pvc-abcdef-0123-4567-89