Знакомство с Kubernetes. Часть 16: Различия в Replication Controller, Replica Set и Deployments
Sep 14, 2018 07:04 · 874 words · 5 minute read
Как инструмент оркестрации контейнеров, Kubernetes предусматривает управление несколькими экземплярами (репликами) контейнеров. На сегодняшний день существует несколько способов организации репликации - в данной статье мы рассмотрим три варианта: Replication Controllers, Replica Sets и Deployments. Давайте разберемся!
Прежде всего, нужно знать зачем нужна репликация контейнеров в кластере Kubernetes. Чаще всего, это нужно для:
- надежности. C несколькими экземплярами приложения вы избавляетесь от проблем в случае отказа одного (или нескольких) из них;
- балансировки. Наличие нескольких экземпляров приложения позволяет распределять траффик между ними, предотвращая перегрузку одного инстанса (под / контейнер) или ноды;
- масштабирования. При возрастающей нагрузке на уже существующие экземпляры приложения
Kubernetesпозволяет легко увеличивать количество реплик по необходимости.
Репликация также хорошо подходит в случае работы с микросервисами, облачными (cloud-native) и мобильными приложениями.
Replication Controller - традиционный (изначальный) способ организации репликации в кластере Kubernetes. В данный момент он заменяется более “свежим” вариантом - Replica Sets, но не будет лишним понять, что это и как работает.
С помощью объекта Replication Controller можно создать несколько экземпляров подов и отслеживать их состояние. Если один (или несколько) подов завершаются с ошибкой, то контроллер создаст и запустит новый экземпляр (чтобы количество подов всегда соответствовало желаемому). Кроме того, Replication Controller предоставляет возможность масштабирования подов.
Создадим файл rc.yaml следующего содержания:
apiVersion: v1
kind: ReplicationController
metadata:
name: testrc
spec:
replicas: 3
selector:
app: testrc
template:
metadata:
name: testrc
labels:
app: testrc
spec:
containers:
- name: testrc
image: ealebed/test
ports:
- containerPort: 80
Далее создадим объект Replication Controller в кластере на основе описания выше:
kubectl create -f rc.yaml
replicationcontroller "testrc" created
Получим детальное описание созданного объекта:
kubectl describe rc testrc
Name: testrc
Namespace: default
Image(s): ealebed/test
Selector: app=testrc
Labels: app=testrc
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
No volumes.
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------------- -------
1m 1m 1 {replication-controller } Normal SuccessfulCreate Created pod: testrc-g5snq
1m 1m 1 {replication-controller } Normal SuccessfulCreate Created pod: testrc-cws05
1m 1m 1 {replication-controller } Normal SuccessfulCreate Created pod: testrc-ro2bl
Как видно, все три реплики запущены (ожидаемо). Увидеть состояние подов можно с помощью команды:
kubectl get pods
NAME READY STATUS RESTARTS AGE
testrc-cws05 1/1 Running 0 3m
testrc-g5snq 1/1 Running 0 3m
testrc-ro2bl 1/1 Running 0 3m
Перед рассмотрением Replica Sets “убираем” за собой:
kubectl delete rc testrc
Как мы уже ранее говорили, Replica Sets - это более современная версия все того же Replication Controller, которая отличается поддержкой множественного выбора в селекторе. Создадим файл rs.yaml с таким содержимым:
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: testrs
spec:
replicas: 3
selector:
matchLabels:
app: testrs
template:
metadata:
labels:
app: testrs
environment: dev
spec:
containers:
- name: testrs
image: ealebed/test
ports:
- containerPort: 80
Здесь все практически то же самое, что и в описании Replication Controller, за исключением того, что мы используем
matchLabels. Но можно пойти дальше и заменить секцию matchLabels на такую:
matchExpressions:
- {key: app, operator: In, values: [testrs, test]}
- {key: tier, operator: NotIn, values: [production]}
Создаем объект в кластере командой:
kubectl create -f rs.yaml
replicaset "testrs" created
Смотрим описание:
kubectl describe rs testrs
Name: testrs
Namespace: default
Image(s): ealebed/test
Selector: app in (test,testrs),tier notin (production)
Labels: app=testrs
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
No volumes.
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------------- -------
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: testrs-it2hf
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: testrs-kimmm
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: testrs-8i4ra
kubectl get pods
NAME READY STATUS RESTARTS AGE
testrs-8i4ra 1/1 Running 0 1m
testrs-it2hf 1/1 Running 0 1m
testrs-kimmm 1/1 Running 0 1m
Как видим, Replica Sets действительно очень похожа не Replication Controller. Еще одно важное отличие, о котором мы не упомянули - команда rolling-update будет работать для Replication Controller, но не для Replica Sets.
“Убираем” за собой:
kubectl delete rs testrs
replicaset "testrs" deleted
Вариант репликации подов с использованием объекта Deployment - еще более высокий уровень абстракции. На самом деле, под капотом, Deployment будет самостоятельно создавать необходимые Replica Sets (следовательно, предоставлять тот же функционал, но с возможностью rolling-update/rollback).
Создадим файл deployment.yaml следующего содержания:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: test
spec:
replicas: 5
template:
metadata:
labels:
app: test
spec:
containers:
- name: test
image: ealebed/test
ports:
- containerPort: 80
Запускаем объект в кластере:
kubectl create -f deployment.yaml
deployment "test" created
Просмотр деталей:
kubectl describe deployment test
Name: test
Namespace: default
CreationTimestamp: Mon, 03 Sep 2018 13:21:19 +0000
Labels: app=test
Selector: app=test
Replicas: 5 updated | 5 total | 5 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
OldReplicaSets: <none>
NewReplicaSet: test-3914185155 (5/5 replicas created)
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------------- -------
38s 38s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set test-3914185155 to 3
36s 36s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set test-3914185155 to 5
kubectl get pods
NAME READY STATUS RESTARTS AGE
test-3914185155-7gyja 1/1 Running 0 2m
test-3914185155-lrm20 1/1 Running 0 2m
test-3914185155-o28px 1/1 Running 0 2m
test-3914185155-ojzn8 1/1 Running 0 2m
test-3914185155-r2pt7 1/1 Running 0 2m
Чуть больше информации о Replica Sets и Deployment можно найти в предыдущих статьях цикла - здесь и здесь.