Создание контроллера репликации (ReplicationController) в Kubernetes

Автор Itworkroom

Создание контроллера репликации.

Контроллер репликации (ReplicationController) – это ресурс Kubernetes, который обеспечивает поддержание постоянной работы его модулей. Если модуль исчезает по любой причине, например, в случае исчезновения узла из кластера или потому, что модуль был вытеснен из узла, контроллер репликации замечает отсутствующий модуль и создает сменный модуль.

Контроллер репликации состоит из трех основных частей:

  • селектор меток, определяющий, какие модули находятся в области действия контроллера репликации;
  • количество реплик, указывающее на требуемое количество модулей, которые должны быть запущены;
  • шаблон модуля, используемый при создании новых реплик модуля.

Подобно модулям и другим ресурсам Kubernetes, создается контроллер репликации при помощи отправки дескриптора JSON или YAML на сервер API Kubernetes ($ kubectl create -f kubia-rc.yaml). Содержимое файла kubia-rc.yaml:

apiVersion: v1
kind: ReplicationController
metadata:
 name: kubia
spec:
 replicas: 3
 selector:
   app: kubia
template:
 metadata:
  labels:
   app: kubia
 spec:
  containers:
  – name: kubia
   image: vasya/kubia
   ports:
   – containerPort: 8080

В spec: шаблон модуля для создания новых модулей. При отправке файла kubia-rc.yaml на сервер API Kubernetes создает новый контроллер репликации с именем kubia, который гарантирует, что три экземпляра модуля всегда совпадают с селектором меток app=kubia. Когда не хватает модулей, новые модули будут созданы из предоставленного шаблона модуля.
Вывести список модулей:

$ kubectl get pods

Команда для удаление модуля вручную:

$ kubectl delete pod имя_модуля

Контроллер репликации управляет теми модулями, которые соответствуют его селектору меток. Путем изменения меток модуля он может быть удален или добавлен к области действия контроллера репликации. Его можно перемещать из одного контроллера репликации в другой. Хотя модуль не привязан к контроллеру репликации, модуль все же ссылается на него в поле metadata.ownerReferences, которое можно использовать, чтобы легко найти, к какому контроллеру репликации модуль принадлежит. Если изменить метки модуля, чтобы они больше не совпадали с селектором меток контроллера репликации, то модуль становится похожим на любой другой созданный вручную модуль, т.е он больше ничем не управляется. Если узел модуля аварийно завершает свою работу, то этот модуль не переназначается. Нужно иметь в виду, что при изменении меток модуля контроллер репликации заметит, что один модуль отсутствует, и развернет новый модуль, чтобы его заменить.
Получить информацию о контроллере репликации:

$ kubectl get rc

Отобразить сведения о контроллере репликации:

$ kubectl describe rc kubia

Команды добавления меток в модули управляемые контроллером репликации

kubectl describe
$ kubectl label pod имя_модуля type=special

Вывод списка всех модулей

$ kubectl get pods --show-labels

Изменение меток управляемого модуля

$ kubectl label pod имя_модуля app=foo –overwrite

Вывод списка всех модулей (параметр -L app используется для показа метки app в столбце)

$ kubectl get pods -L app

Изменение шаблона модуля

Изменение шаблона модуля контроллера репликации влияет только на модули, создаваемые впоследствии, и не влияет на существующие модули

$ kubectl edit rc kubia

— команда откроет определение YAML контроллера репликации в текстовом редакторе, установленном по умолчанию. Найдите секцию шаблона модуля (template) и добавьте новую метку в метаданные. После сохранения изменений и выхода из редактора kubectl обновит контроллер репликации и напечатает следующее ниже сообщение. Теперь если вы удалите модули и дождетесь их замены, то увидите новую метку.

Конфигурирование правки для kubectl с целью использования другого текстового редактора

Вы можете поручить kubectl использовать текстовый редактор по вашему выбору путем установки переменной окружения KUBE_EDITOR. Например, если для редактирования ресурсов Kubernetes вы хотите использовать vi, выполните следующую ниже команду (или поместите ее в файл ~/.bashrc либо эквивалентный ему):

export KUBE_EDITOR="/usr/bin/vi"

Если переменная среды KUBE_EDITOR не задана, то kubectl edit откатит назад к использованию редактора, установленного по умолчанию, который обычно настраивается с помощью переменной среды EDITOR.

Масштабирование контроллера репликации:

Масштабирование контроллера репликации можно командой

$ kubectl scale rc kubia --replicas=10

или путем изменения его определения, редактируя определение контроллера репликации:

Откройте файл командой

$ kubectl edit rc kubia

и найдите поле spec.replicas и поменяйте его значение на необходимое (например 5):

apiVersion: v1
kind: ReplicationController
metadata:
...
spec:
replicas: 3
selector:
app: kubia
...

Далее контроллер репликации обновится и немедленно масштабирует количество модулей до 5, посмотреть результат:

$ kubectl get rc

Удаление контроллера репликации:

При удалении контроллера репликации с помощью команды kubectl delete его модули можно сохранить, передав команде параметр —cascade=false, при этом модули становятся неуправляемыми. Это может быть полезно, когда у вас изначально имеется набор модулей управляемых контроллером репликации, а затем вы приняли решение заменить контроллер репликации на набор реплик (ReplicaSet).

$ kubectl delete rc kubia --cascade=false

Использование набора реплик (ReplicaSet) вместо контроллера репликации

Этот ресурс является новым поколением контроллера репликации и заменяет его полностью (контроллеры репликации в конечном итоге будут объявлены устаревшими).

Определение набора реплик

Создайте новый файл под названием kubia-replicaset.yaml с содержимым:

apiVersion: apps/v1beta2
kind: ReplicaSet
metadata:
name: kubia
spec:
replicas: 3
selector:
matchLabels:
app: kubia
template:
metadata:
labels:
app: kubia
spec:
containers:
– name: kubia
image: vasya/kubia

apiVersion: apps/v1beta2 — наборы реплик принадлежат группе API apps и версии v1beta2. Свойство apiVersion определяет две вещи:

  1. группу API (в данном случае это приложения apps);
  2. актуальную версию API (v1beta2).

matchLabels:  простой селектор matchLabels, подобный селектору контроллера репликации

Создание набора реплик:

Помимо набора реплик replicaset имеется более сложные селекторы меток набора реплик matchExpressions. Секция селектора matchExpressions: kubia-replicaset-matchexpressions.yaml будет выглядеть следующим образом:

selector:
 matchExpressions:
  – key: app
   operator: In
   values:
    – kubia

Этот селектор требует, чтобы модуль содержал метку с ключом «app«, Значение метки – key: должно быть «kubia».

В селекторе могут присутствовать дополнительные выражения. Каждое выражение должно содержать ключ, оператор и, возможно (в зависимости от оператора), список значений. Допустимые операторы:

In – значение метки должно совпадать с одним из указанных значений values;

NotIn – значение метки не должно совпадать с любым из указанных значений values;

Exists – модуль должен содержать метку с указанным ключом (значение не важно). При использовании этого оператора не следует указывать поле values;

DoesNotExist – модуль не должен содержать метку с указанным ключом. Свойство values не должно быть указано.

Если указаны несколько выражений, то, для того чтобы селектор совпал с модулем, все выражения должны оказываться истинными. Если указаны и matchLabels, и matchExpressions, то, чтобы модуль отождествился с селектором, все метки должны совпадать, а все выражения должны оказываться истинными.

Чтобы удалить набор реплик используйте команду

$ kubectl delete rs kubia

при этом, удаление набора реплик должно удалить все модули.

Есть цифровые продукты и необходимо обеспечить их оперативную разработку и вывод на рынок? Нужны готовые Open Source инструменты для работы и it поддержка? Ваши задачи решит ONPLATFORM – Kubernetes-платформа, которую разработала DevOps-команда.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *