K8s Q A Replica Set vs Deployments

Различия в Replication Controller, Replica Set и Deployments

Sep 14, 2018 07:04 · 874 words · 5 minute read KUBERNETES Как инструмент оркестрации контейнеров, 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 можно найти в предыдущих статьях цикла - здесь и здесь.