K8s Q A ReplicaSets: различия между версиями
Sirmax (обсуждение | вклад) (Новая страница: «Категория:K8s =<code>ReplicaSet</code>= <code>ReplicaSet</code> гарантирует, что определенное количество экзе...») |
Sirmax (обсуждение | вклад) |
||
(не показано 5 промежуточных версий этого же участника) | |||
Строка 1: | Строка 1: | ||
[[Категория:K8s]] |
[[Категория:K8s]] |
||
+ | [[Категория:K8s]] |
||
+ | [[Категория:K8s_Вопросы_И_Ответы]] |
||
+ | |||
=<code>ReplicaSet</code>= |
=<code>ReplicaSet</code>= |
||
⚫ | |||
+ | ==Свойства <code>ReplicaSet</code>== |
||
+ | |||
⚫ | |||
+ | будет запущено в кластере Kubernetes в любой момент времени. |
||
+ | <BR> |
||
Сразу стоит сказать, что <code>Deployment</code> представляет собой абстракцию более высокого уровня, |
Сразу стоит сказать, что <code>Deployment</code> представляет собой абстракцию более высокого уровня, |
||
которая управляет <code>ReplicaSets</code> и предоставляет |
которая управляет <code>ReplicaSets</code> и предоставляет |
||
расширенный функционал управления контейнерами. |
расширенный функционал управления контейнерами. |
||
+ | <BR> |
||
− | |||
+ | <code>ReplicaSet</code> - это следующее поколение <code>Replication Controller</code>. |
||
+ | Единственная разница между <code>ReplicaSet</code> и <code>Replication Controller</code> - это поддержка селектора. |
||
+ | <BR> |
||
⚫ | |||
<BR> |
<BR> |
||
⚫ | |||
⚫ | |||
− | Различия между Replication Controller, ReplicaSet и Deployment рассмотрены в отдельной статье. |
||
+ | * <code>apiVersion</code> |
||
+ | * <code>kind</code> |
||
+ | * <code>metadata</code> |
||
+ | * Кроме того, в <code>ReplicaSet</code> также должна присутствовать секция <code>.spec.</code> |
||
+ | <BR> |
||
+ | Далее, в секции <code>.spec</code> обязательно должна присутствовать вложенная секция <code>.spec.template</code> - шаблон пода (Pod). <BR> |
||
+ | Он имеет точно такой же формат, как описание пода (Pod) без секций apiVersion и kind. <BR> |
||
+ | Кроме обязательных полей, в секции <code>.spec.template</code> при описании <code>ReplicaSet</code> нужно указывать соответствующие метки (<code>.spec.template.metadata.labels</code>) и |
||
⚫ | |||
+ | политику перезапуска (единственным допустимым значением для .spec.template.spec.restartPolicy является Always, которое соответствует значению по умолчанию). |
||
− | |||
+ | <BR> |
||
− | Далее, в секции .spec обязательно должна присутствовать вложенная секция .spec.template - шаблон пода (Pod). Он имеет точно такой же формат, как описание пода (Pod) без секций apiVersion и kind. Кроме обязательных полей, в секции .spec.template при описании ReplicaSet нужно указывать соответствующие метки (.spec.template.metadata.labels) и политику перезапуска (единственным допустимым значением для .spec.template.spec.restartPolicy является Always, которое соответствует значению по умолчанию). |
||
+ | Секция <code>.spec.selector</code> описывает селектор меток. |
||
+ | <code>ReplicaSet</code> управляет всеми подами (Pods) с метками, |
||
+ | которые соответствуют описанному селектору - неважно, создавались ли эти поды самим ReplicaSet, |
||
+ | другим процессом (например, деплойментом) или администратором вручную. |
||
+ | Такой подход позволяет изменять ReplicaSet, не затрагивая запущенные поды в кластере. |
||
+ | <BR> |
||
+ | При описании ReplicaSet стоит указать, сколько экземпляров подов должно работать одновременно |
||
+ | (а иначе какой смысл в использовании ReplicaSet), установив параметр <code>.spec.replicas</code>. |
||
+ | Если этого не сделать, то будет запущен только один экземпляр пода - <code>.spec.replicas</code> по |
||
+ | умолчанию равно единице. |
||
+ | <BR> |
||
+ | <code>ReplicaSet</code> может сам иметь метки - они должны быть установлены в разделе |
||
+ | <code>.metadata.labels</code> |
||
+ | Как правило, их нужно устанавливать по аналогии с установкой меток в секции <code>.spec.template.metadata.labels</code>, |
||
− | Секция .spec.selector описывает селектор меток. ReplicaSet управляет всеми подами (Pods) с метками, которые соответствуют описанному селектору - неважно, создавались ли эти поды самим ReplicaSet, другим процессом (например, деплойментом) или администратором вручную. Такой подход позволяет изменять ReplicaSet, не затрагивая запущенные поды в кластере. |
||
+ | но сами метки могут быть разными, потому что <code>.metadata.labels</code> не влияют на поведение ReplicaSet. |
||
− | |||
− | При описании ReplicaSet стоит указать, сколько экземпляров подов должно работать одновременно (а иначе какой смысл в использовании ReplicaSet), установив параметр .spec.replicas. Если этого не сделать, то будет запущен только один экземпляр пода - .spec.replicas по умолчанию равно единице. |
||
− | |||
− | ReplicaSet может сам иметь метки - они должны быть установлены в разделе .metadata.labels. Как правило, их нужно устанавливать по аналогии с установкой меток в секции .spec.template.metadata.labels, но сами метки могут быть разными, потому что .metadata.labels не влияют на поведение ReplicaSet. |
||
Пример описания ReplicaSet: |
Пример описания ReplicaSet: |
||
+ | <PRE> |
||
− | |||
apiVersion: apps/v1 |
apiVersion: apps/v1 |
||
kind: ReplicaSet |
kind: ReplicaSet |
||
Строка 57: | Строка 84: | ||
ports: |
ports: |
||
- containerPort: 80 |
- containerPort: 80 |
||
+ | </PRE> |
||
+ | |||
Предложенный манифест можно сохранить в файл frontend.yaml и запустить в кластере Kubernetes с помощью утилиты командной строки: |
Предложенный манифест можно сохранить в файл frontend.yaml и запустить в кластере Kubernetes с помощью утилиты командной строки: |
||
+ | <BR> |
||
⚫ | |||
⚫ | |||
Просмотреть детальное состояние запущенного выше ReplicaSet можно с помощью команды kubectl describe rs/frontend, результат выполнения команды будет примерно следующим: |
Просмотреть детальное состояние запущенного выше ReplicaSet можно с помощью команды kubectl describe rs/frontend, результат выполнения команды будет примерно следующим: |
||
+ | <PRE> |
||
− | |||
Name: frontend |
Name: frontend |
||
Namespace: default |
Namespace: default |
||
Selector: tier=frontend,tier in (frontend) |
Selector: tier=frontend,tier in (frontend) |
||
Labels: app=guestbook |
Labels: app=guestbook |
||
− | tier=frontend |
+ | tier=frontend |
Annotations: <none> |
Annotations: <none> |
||
Replicas: 3 current / 3 desired |
Replicas: 3 current / 3 desired |
||
Строка 90: | Строка 120: | ||
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy |
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy |
||
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l |
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l |
||
+ | </PRE > |
||
⚫ | Для удаления ReplicaSet и всех его подов, нужно использовать команду kubectl delete .... При этом утилита kubectl выполнит масштабирование количества реплик до нуля, дождется удаления каждого пода и удалит сам ReplicaSet. При использовании REST API все три шага нужно выполнять отдельно и в правильной очередности. |
||
⚫ | Для удаления ReplicaSet и всех его подов, нужно использовать команду kubectl delete .... При этом утилита kubectl выполнит масштабирование количества реплик до нуля, дождется удаления каждого пода и удалит сам ReplicaSet. При использовании REST API все три шага нужно выполнять отдельно и в правильной очередности. |
||
+ | <BR> |
||
Есть возможность удалить ReplicaSet, не затрагивая ни один из его подов, для этого следует использовать kubectl delete с дополнительным параметром --cascade=false. |
Есть возможность удалить ReplicaSet, не затрагивая ни один из его подов, для этого следует использовать kubectl delete с дополнительным параметром --cascade=false. |
||
+ | <BR> |
||
− | |||
− | Поды (Pods) могут быть удалены из набора ReplicaSet путем изменения их меток - этот вариант может пригодиться при отладке, |
+ | Поды (Pods) могут быть удалены из набора ReplicaSet путем изменения их меток - этот вариант может пригодиться при отладке, |
+ | восстановлении данных и т. д. Поды, которые удаляются таким образом, будут автоматически заменены (при условии, что количество реплик в наборе ReplicaSet также не изменяется). |
||
ReplicaSet можно легко масштабировать (вверх или вниз), просто меняя значение поля .spec.replicas. |
ReplicaSet можно легко масштабировать (вверх или вниз), просто меняя значение поля .spec.replicas. |
||
Стоит отметить, что наборы ReplicaSet могут использоваться для горизонтального масштабирования подов (автоскейлинга, HPA). Пример настройки такого масштабирования (в зависимости от использования CPU) для созданного ранее ReplicaSet будет выглядеть так: |
Стоит отметить, что наборы ReplicaSet могут использоваться для горизонтального масштабирования подов (автоскейлинга, HPA). Пример настройки такого масштабирования (в зависимости от использования CPU) для созданного ранее ReplicaSet будет выглядеть так: |
||
+ | <PRE> |
||
− | |||
apiVersion: autoscaling/v1 |
apiVersion: autoscaling/v1 |
||
kind: HorizontalPodAutoscaler |
kind: HorizontalPodAutoscaler |
||
Строка 111: | Строка 144: | ||
maxReplicas: 10 |
maxReplicas: 10 |
||
targetCPUUtilizationPercentage: 50 |
targetCPUUtilizationPercentage: 50 |
||
+ | </PRE> |
||
Сохраняем предложенный манифест в файл hpa-rs.yaml и запускаем его в кластере Kubernetes: |
Сохраняем предложенный манифест в файл hpa-rs.yaml и запускаем его в кластере Kubernetes: |
||
kubectl create -f hpa-rs.yaml |
kubectl create -f hpa-rs.yaml |
||
+ | |||
Альтернативы использования ReplicaSet: |
Альтернативы использования ReplicaSet: |
||
− | Deployment (рекомендуемый); |
+ | * <code>Deployment</code> (рекомендуемый); |
− | Job (для подов, которые должны “завершаться” самостоятельно после выполнения определенной задачи); |
+ | * <code>Job</code> (для подов, которые должны “завершаться” самостоятельно после выполнения определенной задачи); |
− | DaemonSet (для запуска подов на каждой ноде кластера). |
+ | * <code>DaemonSet</code> (для запуска подов на каждой ноде кластера). |
Текущая версия на 10:22, 8 января 2024
ReplicaSet
Свойства ReplicaSet
ReplicaSet
гарантирует, что определенное количество экземпляров подов (Pods)
будет запущено в кластере Kubernetes в любой момент времени.
Сразу стоит сказать, что Deployment
представляет собой абстракцию более высокого уровня,
которая управляет ReplicaSets
и предоставляет
расширенный функционал управления контейнерами.
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:
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
Предложенный манифест можно сохранить в файл frontend.yaml и запустить в кластере Kubernetes с помощью утилиты командной строки:
kubectl create -f frontend.yaml
Просмотреть детальное состояние запущенного выше ReplicaSet можно с помощью команды kubectl describe rs/frontend, результат выполнения команды будет примерно следующим:
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
Для удаления ReplicaSet и всех его подов, нужно использовать команду kubectl delete .... При этом утилита kubectl выполнит масштабирование количества реплик до нуля, дождется удаления каждого пода и удалит сам ReplicaSet. При использовании REST API все три шага нужно выполнять отдельно и в правильной очередности.
Есть возможность удалить ReplicaSet, не затрагивая ни один из его подов, для этого следует использовать kubectl delete с дополнительным параметром --cascade=false.
Поды (Pods) могут быть удалены из набора ReplicaSet путем изменения их меток - этот вариант может пригодиться при отладке,
восстановлении данных и т. д. Поды, которые удаляются таким образом, будут автоматически заменены (при условии, что количество реплик в наборе ReplicaSet также не изменяется).
ReplicaSet можно легко масштабировать (вверх или вниз), просто меняя значение поля .spec.replicas.
Стоит отметить, что наборы ReplicaSet могут использоваться для горизонтального масштабирования подов (автоскейлинга, HPA). Пример настройки такого масштабирования (в зависимости от использования CPU) для созданного ранее ReplicaSet будет выглядеть так:
apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: frontend-scaler spec: scaleTargetRef: kind: ReplicaSet name: frontend minReplicas: 3 maxReplicas: 10 targetCPUUtilizationPercentage: 50
Сохраняем предложенный манифест в файл hpa-rs.yaml и запускаем его в кластере Kubernetes:
kubectl create -f hpa-rs.yaml
Альтернативы использования ReplicaSet:
Deployment
(рекомендуемый);Job
(для подов, которые должны “завершаться” самостоятельно после выполнения определенной задачи);DaemonSet
(для запуска подов на каждой ноде кластера).