K8s Q A Replica Set vs Deployments: различия между версиями

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
(Новая страница: «Категория:K8s Категория:K8s_Вопросы_И_Ответы Категория:Требуется форматирование текс...»)
 
 
(не показана 1 промежуточная версия этого же участника)
Строка 2: Строка 2:
 
[[Категория:K8s_Вопросы_И_Ответы]]
  
[[Категория:K8s_Вопросы_И_Ответы]]
 
[[Категория:Требуется форматирование текста]]
  
[[Категория:Требуется форматирование текста]]
  +
  +
=Различия в Replication Controller, Replica Set и Deployments=
  +
  +
Как инструмент оркестрации контейнеров, Kubernetes предусматривает управление несколькими экземплярами (репликами) контейнеров. На сегодняшний день существует несколько способов организации репликации - в данной статье мы рассмотрим три варианта:
  +
  +
* Replication Controllers
  +
* Replica Sets
  +
* Deployments
  +
  +
Прежде всего, нужно знать зачем нужна репликация контейнеров в кластере Kubernetes.
  +
<BR>
  +
Чаще всего, это нужно для:
  +
  +
* надежности. C несколькими экземплярами приложения вы избавляетесь от проблем в случае отказа одного (или нескольких) из них;
  +
* балансировки. Наличие нескольких экземпляров приложения позволяет распределять траффик между ними, предотвращая перегрузку одного инстанса (под / контейнер) или ноды;
  +
* масштабирования. При возрастающей нагрузке на уже существующие экземпляры приложения Kubernetes позволяет легко увеличивать количество реплик по необходимости.
  +
  +
  +
<BR>
  +
<BR>
  +
Replication Controller - традиционный (изначальный) способ организации репликации в кластере Kubernetes. В данный момент он заменяется более “свежим” вариантом - Replica Sets, но не будет лишним понять, что это и как работает.
  +
<BR>
  +
<BR>
  +
С помощью объекта Replication Controller можно создать несколько экземпляров подов и отслеживать их состояние. Если один (или несколько) подов завершаются с ошибкой, то контроллер создаст и запустит новый экземпляр (чтобы количество подов всегда соответствовало желаемому). Кроме того, Replication Controller предоставляет возможность масштабирования подов.
  +
<BR>
  +
Создадим файл rc.yaml следующего содержания:
  +
<PRE>
  +
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
  +
</PRE>
  +
Далее создадим объект Replication Controller в кластере на основе описания выше:
  +
<PRE>
  +
kubectl create -f rc.yaml
  +
replicationcontroller "testrc" created
  +
</PRE>
  +
Получим детальное описание созданного объекта:
  +
<PRE>
  +
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
  +
<PRE>
  +
Как видно, все три реплики запущены (ожидаемо). Увидеть состояние подов можно с помощью команды:
  +
<PRE>
  +
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
  +
</PRE>
  +
Перед рассмотрением Replica Sets “убираем” за собой:
  +
<PRE>
  +
kubectl delete rc testrc
  +
</PRE>
  +
Как мы уже ранее говорили, Replica Sets - это более современная версия все того же Replication Controller, которая отличается поддержкой множественного выбора в селекторе. Создадим файл rs.yaml с таким содержимым:
  +
  +
<PRE>
  +
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
  +
</PRE>
  +
Здесь все практически то же самое, что и в описании Replication Controller, за исключением того, что мы используем matchLabels. Но можно пойти дальше и заменить секцию matchLabels на такую:
  +
<PRE>
  +
matchExpressions:
  +
- {key: app, operator: In, values: [testrs, test]}
  +
- {key: tier, operator: NotIn, values: [production]}
  +
</PRE>
  +
Создаем объект в кластере командой:
  +
<PRE>
  +
kubectl create -f rs.yaml
  +
replicaset "testrs" created
  +
</PRE>
  +
Смотрим описание:
  +
<PRE>
  +
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
  +
</PRE>
  +
<PRE>
  +
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
  +
</PRE>
  +
Как видим, Replica Sets действительно очень похожа не Replication Controller. Еще одно важное отличие, о котором мы не упомянули - команда rolling-update будет работать для Replication Controller, но не для Replica Sets.
  +
  +
“Убираем” за собой:
  +
<PRE>
  +
kubectl delete rs testrs
  +
replicaset "testrs" deleted
  +
</PRE>
  +
Вариант репликации подов с использованием объекта Deployment - еще более высокий уровень абстракции. На самом деле, под капотом, Deployment будет самостоятельно создавать необходимые Replica Sets (следовательно, предоставлять тот же функционал, но с возможностью rolling-update/rollback).
  +
  +
Создадим файл deployment.yaml следующего содержания:
  +
<PRE>
  +
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
  +
</PRE>
  +
Запускаем объект в кластере:
  +
<PRE>
  +
kubectl create -f deployment.yaml
  +
deployment "test" created
  +
</PRE>
  +
Просмотр деталей:
  +
<PRE>
  +
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
  +
</PRE>
  +
<PRE>
  +
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
  +
</PRE>

Текущая версия на 15:05, 9 января 2024


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

Как инструмент оркестрации контейнеров, Kubernetes предусматривает управление несколькими экземплярами (репликами) контейнеров. На сегодняшний день существует несколько способов организации репликации - в данной статье мы рассмотрим три варианта:

  • Replication Controllers
  • Replica Sets
  • Deployments

Прежде всего, нужно знать зачем нужна репликация контейнеров в кластере Kubernetes.
Чаще всего, это нужно для:

  • надежности. C несколькими экземплярами приложения вы избавляетесь от проблем в случае отказа одного (или нескольких) из них;
  • балансировки. Наличие нескольких экземпляров приложения позволяет распределять траффик между ними, предотвращая перегрузку одного инстанса (под / контейнер) или ноды;
  • масштабирования. При возрастающей нагрузке на уже существующие экземпляры приложения Kubernetes позволяет легко увеличивать количество реплик по необходимости.




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
<PRE>
Как видно, все три реплики запущены (ожидаемо). Увидеть состояние подов можно с помощью команды:
<PRE>
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
Источник — https://noname.com.ua/mediawiki/index.php?title=K8s_Q_A_Replica_Set_vs_Deployments&oldid=12441