kubernetes. ReplicaSet - теория. часть2

Thank you for reading this post, don't forget to subscribe!

ReplicaSet гарантирует, что определенное количество экземпляров подов (Pods) будет запущено в кластере Kubernetes в любой момент времени. Давайте разберемся!

Сразу стоит сказать, что деплоймент (Deployment), который мы рассмотрим в следующей статье, представляет собой абстракцию более высокого уровня, которая управляет ReplicaSets и предоставляет расширенный функционал управления контейнерами. Разработчики Kubernetesсоветуют использовать именно Deployments, если не нужна специфическая настройка оркестрации (или если вообще не требуется обновление подов). При использовании Deployments, вам не нужно беспокоиться об управлении создаваемыми ReplicaSets - деплоймент все сделает за вас.

Фактически это значит, что вам (возможно) и не придется манипулировать объектами ReplicaSet: достаточно будет деплоймента с описанием свойств приложения в разделе spec.

ReplicaSet - это следующее поколение Replication Controller. Единственная разница между ReplicaSet и Replication Controller - это поддержка селектора. ReplicaSet поддерживает множественный выбор в селекторе, тогда как Replication Controller поддерживает в селекторе только выбор на основе равенства.

Как и для всех других API-объектов Kubernetes, для определения ReplicaSet в yaml-файле нужны поля apiVersion, kind и metadata. Кроме того, в ReplicaSet также должна присутствовать секция .spec.

Далее, в секции .spec обязательно должна присутствовать вложенная секция .spec.template - шаблон пода (Pod). Он имеет точно такой же формат, как описание пода (Pod) без секций apiVersion и kind. Кроме обязательных полей, в секции .spec.template при описании ReplicaSetнужно указывать соответствующие метки (.spec.template.metadata.labels) и политику перезапуска (единственным допустимым значением для .spec.template.spec.restartPolicy является Always, которое соответствует значению по умолчанию).

Секция .spec.selector описывает селектор меток. ReplicaSet управляет всеми подами (Pods) с метками, которые соответствуют описанному селектору - неважно, создавались ли эти поды самим ReplicaSet, другим процессом (например, деплойментом) или администратором вручную. Такой подход позволяет изменять ReplicaSet, не затрагивая запущенные поды в кластере.

При описании ReplicaSet стоит указать, сколько экземпляров подов должно работать одновременно (а иначе какой смысл в использовании ReplicaSet), установив параметр .spec.replicas. Если этого не сделать, то будет запущен только один экземпляр пода -.spec.replicas по умолчанию равно единице.

ReplicaSet может сам иметь метки - они должны быть установлены в разделе .metadata.labels. Как правило, их нужно устанавливать по аналогии с установкой меток в секции .spec.template.metadata.labels, но сами метки могут быть разными, потому что .metadata.labels не влияют на поведение ReplicaSet.

Пример описания ReplicaSet:

<span style="font-family: 'times new roman', times, serif; font-size: 12pt;"><code class="language-yaml">apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
    matchExpressions:
      - {key: tier, operator: In, values: [frontend]}
  template:
    metadata:
      labels:
        app: guestbook
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        env:
        - name: GET_HOSTS_FROM
          value: env
        ports:
        - containerPort: 80
</code></span>

<code class="language-yaml">apiVersion: apps/v1

kind: ReplicaSet

metadata:

labels:

app: guestbook

tier: frontend

spec:

replicas: 3

selector:

matchLabels:

tier: frontend

matchExpressions:

- {key: tier, operator: In, values: [frontend]}

template:

metadata:

labels:

app: guestbook

tier: frontend

spec:

containers:

- name: php-redis

image: gcr.io/google_samples/gb-frontend:v3

resources:

requests:

cpu: 100m

memory: 100Mi

env:

- name: GET_HOSTS_FROM

value: env

ports:

- containerPort: 80

</code>

Предложенный манифест можно сохранить в файл frontend.yaml и запустить в кластере Kubernetes с помощью утилиты командной строки:

<span style="font-size: 12pt;"><strong><span style="font-family: 'times new roman', times, serif;"><code class="language-bash hljs">kubectl create <span class="hljs-_">-f</span> frontend.yaml
</code></span></strong></span>

1 2	<span style="font-size: 12pt;"><strong><span style="font-family: 'times new roman', times, serif;"><code class="language-bash hljs">kubectl create <span class="hljs-_">-f</span> frontend.yaml </code></span></strong></span>

Просмотреть детальное состояние запущенного выше ReplicaSet можно с помощью команды kubectl describe rs/frontend, результат выполнения команды будет примерно следующим:

<span style="font-family: 'times new roman', times, serif; font-size: 12pt;"><code class="language-bash hljs">Name:		frontend
Namespace:	default
Selector:	tier=frontend,tier <span class="hljs-keyword">in</span> (frontend)
Labels:		app=guestbook
		tier=frontend
Annotations:	&lt;none&gt;
Replicas:	3 current / 3 desired
Pods Status:	3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:       app=guestbook
                tier=frontend
  Containers:
   php-redis:
    Image:      gcr.io/google_samples/gb-frontend:v3
    Port:       80/TCP
    Requests:
      cpu:      100m
      memory:   100Mi
    Environment:
      GET_HOSTS_FROM:   env
    Mounts:             &lt;none&gt;
  Volumes:              &lt;none&gt;
Events:
  FirstSeen    LastSeen    Count    From                SubobjectPath    Type        Reason            Message
  ---------    --------    -----    ----                -------------    --------    ------            -------
  1m           1m          1        {replicaset-controller }             Normal      SuccessfulCreate  Created pod: frontend-qhloh
  1m           1m          1        {replicaset-controller }             Normal      SuccessfulCreate  Created pod: frontend-dnjpy
  1m           1m          1        {replicaset-controller }             Normal      SuccessfulCreate  Created pod: frontend-9si5l
</code></span>

<code class="language-bash hljs">Name: frontend

Namespace: default

Selector: tier=frontend,tier in (frontend)

Labels: app=guestbook

tier=frontend

Annotations: <none>

Replicas: 3 current / 3 desired

Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed

Pod Template:

Labels: app=guestbook

tier=frontend

Containers:

php-redis:

Image: gcr.io/google_samples/gb-frontend:v3

Port: 80/TCP

Requests:

cpu: 100m

memory: 100Mi

Environment:

GET_HOSTS_FROM: env

Mounts: <none>

Volumes: <none>

Events:

FirstSeen LastSeen Count From SubobjectPath Type Reason Message

--------- -------- ----- ---- ------------- -------- ------ -------

1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh

1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy

1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l

</code>

Для удаления ReplicaSet и всех его подов, нужно использовать команду kubectl delete .... При этом утилита kubectl выполнит масштабирование количества реплик до нуля, дождется удаления каждого пода и удалит сам ReplicaSet. При использовании REST API все три шага нужно выполнять отдельно и в правильной очередности.

Есть возможность удалить ReplicaSet, не затрагивая ни один из его подов, для этого следует использовать kubectl delete с дополнительным параметром --cascade=false.

Поды (Pods) могут быть удалены из набора ReplicaSet путем изменения их меток - этот вариант может пригодиться при отладке, восстановлении данных и т. д. Поды, которые удаляются таким образом, будут автоматически заменены (при условии, что количество реплик в наборе ReplicaSet также не изменяется).

ReplicaSet можно легко масштабировать (вверх или вниз), просто меняя значение поля .spec.replicas.

Стоит отметить, что наборы ReplicaSet могут использоваться для горизонтального масштабирования подов (автоскейлинга, HPA). Пример настройки такого масштабирования (в зависимости от использования CPU) для созданного ранее ReplicaSet будет выглядеть так:

<span style="font-family: 'times new roman', times, serif; font-size: 12pt;"><code class="language-yaml">apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: frontend-scaler
spec:
  scaleTargetRef:
    kind: ReplicaSet
    name: frontend
  minReplicas: 3
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50
</code></span>

<code class="language-yaml">apiVersion: autoscaling/v1

kind: HorizontalPodAutoscaler

metadata:

spec:

scaleTargetRef:

kind: ReplicaSet

minReplicas: 3

maxReplicas: 10

targetCPUUtilizationPercentage: 50

</code>

Сохраняем предложенный манифест в файл hpa-rs.yaml и запускаем его в кластере Kubernetes:

<span style="font-size: 12pt;"><strong><span style="font-family: 'times new roman', times, serif;"><code class="language-bash hljs">kubectl create <span class="hljs-_">-f</span> hpa-rs.yaml
</code></span></strong></span>

1 2	<span style="font-size: 12pt;"><strong><span style="font-family: 'times new roman', times, serif;"><code class="language-bash hljs">kubectl create <span class="hljs-_">-f</span> hpa-rs.yaml </code></span></strong></span>

Альтернативы использования ReplicaSet:

Deployment (рекомендуемый);
Job (для подов, которые должны “завершаться” самостоятельно после выполнения определенной задачи);
DaemonSet (для запуска подов на каждой ноде кластера)..

Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

Centos

kubernetes. ReplicaSet - теория. часть2

https://github.com/midnight47/