Воспроизводимость создания кластера
Давайте разберём ситуацию из предыдущей главы, в которой мы создали кластер, удалили реплику, а она восстановилась. Дело в том, что мы не управляем командами на прямую, а с помощью команд создаём описания необходимой конфигурации кластера и помещаем его в распределённое хранилище, после чего состояние нод поддерживаются в соответствии с этим описанием в распределённом хранилище. Мы также можем получить и отредактировать эти описании или же написать самим и потом загрузить их в распределённое хранилище. Это позволит нам сохранять состояние на диске в виде YAML файлов и восстанавливать его обратно, так часто поступают при переносе с рабочего сервера на тестовый. К тому же мы получаем возможность более гибко настраивать состояние, но, так как мы не ограниченны командами.
esschtolts@cloudshell:~ (essch)$ kubectl get deployment/Nginx output=yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
creationTimestamp: 2018-12-16T10:23:26Z
generation: 1
labels:
run: Nginx
name: Nginx
namespace: default
resourceVersion: "1612985"
selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/Nginx
uid: 9fb3ad6a-011c-11e9-bfaa-42010aa60088
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
run: Nginx
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
run: Nginx
spec:
containers:
image: Nginx
imagePullPolicy: Always
name: Nginx
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
status:
availableReplicas: 1
conditions:
lastTransitionTime: 2018-12-16T10:23:26Z
lastUpdateTime: 2018-12-16T10:23:26Z
message: Deployment has minimum availability.
reason: MinimumReplicasAvailable
status: "True"
type: Available
lastTransitionTime: 2018-12-16T10:23:26Z
lastUpdateTime: 2018-12-16T10:23:28Z
message: ReplicaSet "Nginx-64f497f8fd" has successfully progressed.
reason: NewReplicaSetAvailable
status: "True"
type: Progressing
observedGeneration: 1
readyReplicas: 1
replicas: 1
updatedReplicas: 1
Для нас это будет излишним, поэтому удалю ненужное, ведь когда создавали, мы указали лишь имя и образ, остальное было заполнено значениями по умолчанию:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
run: Nginx
name: Nginx
spec:
selector:
matchLabels:
run: Nginx
template:
metadata:
labels:
run: Nginx
spec:
containers:
image: Nginx
name: Nginx
Также можно создать шаблон:
gcloud services enable compute.googleapis.com project=${PROJECT}
gcloud beta compute instance-templates create-with-container ${TEMPLATE} \
-machine-type=custom-1-4096 \
-image-family=cos-stable \
-image-project=cos-cloud \
-container-image=gcr.io/kuar-demo/kuard-amd64:1 \
-container-restart-policy=always \
-preemptible \
-region=${REGION} \
-project=${PROJECT}
gcloud compute instance-groups managed create ${TEMPLATE} \
-base-instance-name=${TEMPLATE} \
-template=${TEMPLATE} \
-size=${CLONES} \
-region=${REGION} \
-project=${PROJECT}
Высокая доступность сервиса
Чтобы обеспечить высокую доступность нужно в случае падения приложения перенаправлять трафик на запасной. Также, часто важно, чтобы нагрузка была распределена равномерно, так как приложение в единичном экземпляре не способно обрабатывать весь трафик. Для этого создаётся кластер, для примера возьмём более сложный образ, чтобы разобрать большее количество нюансов:
esschtolts@cloudshell:~/bitrix (essch)$ cat deploymnet.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: Nginxlamp
spec:
selector:
matchLabels:
app: lamp
replicas: 1
template:
metadata:
labels:
app: lamp
spec:
containers:
name: lamp
image: mattrayner/lamp:latest-1604-php5
ports:
containerPort: 80
esschtolts@cloudshell:~/bitrix (essch)$ cat loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
name: frontend
spec:
type: LoadBalancer
ports:
name: front
port: 80
targetPort: 80
selector:
app: lamp
esschtolts@cloudshell:~/bitrix (essch)$ kubectl get pods
NAME READY STATUS RESTARTS AGE
Nginxlamp-7fb6fdd47b-jttl8 2/2 Running 0 3m
esschtolts@cloudshell:~/bitrix (essch)$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend LoadBalancer 10.55.242.137 35.228.73.217 80:32701/TCP,8080:32568/TCP 4m
kubernetes ClusterIP 10.55.240.1 none> 443/TCP 48m
Теперь мы можем создать идентичные копии наших кластеров, например, для Production и Develop, но балансировка не будет работать должным образом. Балансировщик будет находить POD по метке, а этой метке соответствуют и POD в production, и в Developer кластере. Также не станет препятствием размещение кластеров в разных проектах. Хотя, для многих задач, это большой плюс, но не в случае кластера для разработчиков и продакшне. Для разграничения области видимости используются namespace. Мы незаметно их используем, когда мы выводим список POD без указания области видимости нам выводится область видимости по умолчанию default, но не выводятся POD из системной области видимости:
esschtolts@cloudshell:~/bitrix (essch)$ kubectl get namespace