When one of the zones where application is running is gone, the application (a1) moves to one of the other zones and can access the data from the available replicas.

1. Quick Intro - July 13 2018
As a scalable and resilient
storage solution, that pods
from any az can utilize

2. ● Kubernetes - Fault Zones
● Setting up GKE cluster with nodes across zones
● Deploying a Application Volume with 3 Replicas across Zones
● Deploying a StatefulSet Application with 3 Volumes across Zones
Agenda

3. ● Always co-located in the same node or not!
Affinity and Anti-Affinity
https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
https://cloud.google.com/compute/docs/regions-zones/
topologyKey
● kubernetes.io/hostname
● failure-domain.beta.kubernetes.io/zone
● failure-domain.beta.kubernetes.io/region
● beta.kubernetes.io/instance-type
● beta.kubernetes.io/os
● beta.kubernetes.io/arch
podAntiAffinity:
… :
- labelSelector:
matchLabels:
app : application1
topologyKey:
failure-domain.beta.kubernetes.io/zone

4. Cluster with nodes Across Zones
us-central-1a
node1
node2
node3
us-central-1b
node4
node5
node6
us-central-1c
node7
node8
node9
kubectl get nodes --show-labels

5. Cluster with nodes Across Zones
kubectl get nodes --show-labels

6. Cluster with nodes Across Zones
kiran_mova@kmova-dev:~$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
gke-kmova-helm-default-pool-1fd63be5-3w0j Ready <none> 9h v1.10.4-gke.2
gke-kmova-helm-default-pool-1fd63be5-gnb8 Ready <none> 9h v1.10.4-gke.2
gke-kmova-helm-default-pool-86bcd4aa-lmkm Ready <none> 9h v1.10.4-gke.2
gke-kmova-helm-default-pool-86bcd4aa-sjb4 Ready <none> 9h v1.10.4-gke.2
gke-kmova-helm-default-pool-ecaeb5c5-r5s6 Ready <none> 9h v1.10.4-gke.2
gke-kmova-helm-default-pool-ecaeb5c5-v78j Ready <none> 9h v1.10.4-gke.2

7. Cluster with nodes Across Zones
kiran_mova@kmova-dev:~$ kubectl get nodes --show-labels
NAME STATUS ROLES AGE VERSION
LABELS
gke-kmova-helm-default-pool-1fd63be5-3w0j Ready <none> 9h v1.10.4-gke.2
beta.kubernetes.io/arch=amd64,beta.kubernetes.io/fluentd-ds-ready=true,beta.kubernetes.io/in
stance-type=n1-standard-2,beta.kubernetes.io/os=linux,cloud.google.com/gke-nodepool=default-
pool,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/
zone=us-central1-a,kubernetes.io/hostname=gke-kmova-helm-default-pool-1fd63be5-3w0j
gke-kmova-helm-default-pool-86bcd4aa-lmkm Ready <none> 9h v1.10.4-gke.2
beta.kubernetes.io/arch=amd64,beta.kubernetes.io/fluentd-ds-ready=true,beta.kubernetes.io/in
stance-type=n1-standard-2,beta.kubernetes.io/os=linux,cloud.google.com/gke-nodepool=default-
pool,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/
zone=us-central1-b,kubernetes.io/hostname=gke-kmova-helm-default-pool-86bcd4aa-lmkm

8. Scenario 1 : Deploy replicas across AZ
us-central-1a us-central-1b us-central-1c
v1
a1
v1 v1
● Application (a1) is
deployed in one of the
availability zones, while
the data copies
(replica=3) are
maintained across
different availability
zones.
● (Optional) Some nodes in
a zone can be
designated as storage
nodes where the copies
are maintained.

9. Scenario 1 : Deploy replicas across AZ
us-central-1a us-central-1b us-central-1c
v1
a1
v1 v1
● When one of the zones
where application is
running is gone, the
application (a1) moves to
one of the other zones
and can access the data
from the available
replicas.
a1

10. Scenario 1 : Deploy replicas across AZ
us-central-1a us-central-1b us-central-1c
v1 v1 v1
● When either the older
zone is made available or
a new zone is added back
to the cluster, a new
replica for the volume (v1)
is configured back by
OpenEBS.
a1

11. Scenario 1 : Deploy replicas across AZ
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: demo-vol1-claim
labels:
"volumeprovisioner.mapi.openebs.io/replica-topology-key-domain": "failure-domain.beta.kubernetes.io"
"volumeprovisioner.mapi.openebs.io/replica-topology-key-type": "zone"
spec:
storageClassName: openebs-standard
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 4G
- labelSelector:
matchLabels:
vsm: pvc-a246b23d-85e3-11e8-9ef7-42010a800016
openebs/replica: jiva-replica
topologyKey: failure-domain.beta.kubernetes.io/zone

12. Scenario 2 : Deploy volumes of STS
across AZ
us-central-1a us-central-1b us-central-1c
v1 v2 v3
● A statefulset application like
MongoDB can be configured to
run 3 instances ( s1, s2,s3), with
their corresponding volumes
(v1, v2, v3) provisioned in
different Availability Zone.
● (Optional) Volumes for a
Statefulset like Mongo can be
configured with single replica -
since application can handle
replication.
● (Optional) The stateful
instances themself (s1, s2, s3)
need not be tied to a zone.
s2 s3s1

13. Scenario 2 : Deploy volumes of STS
across AZ
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
name: mongo
spec:
serviceName: "mongo"
replicas: 2
template:
metadata:
labels:
role: mongo
environment: test
"volumeprovisioner.mapi.openebs.io/application": "mongo-app1"
"volumeprovisioner.mapi.openebs.io/replica-topology-key-domain": "failure-domain.beta.kubernetes.io"
"volumeprovisioner.mapi.openebs.io/replica-topology-key-type": "zone"
spec:
- labelSelector:
matchLabels:
application: mongo-app1
openebs/replica: jiva-replica
topologyKey: failure-domain.beta.kubernetes.io/zone

14. Show me the code!
https://github.com/openebs/maya/pull/380
https://github.com/openebs/maya/pull/390

15. Thank you!