Как добавить master-узлы в облачном кластере?
Как конвертировать кластер с одним master-узлом в мультикластерный описано в FAQ модуля control-plane-manager.
Как уменьшить число master-узлов в облачном кластере?
Как конвертировать мультимастерный кластер в кластер с одним master-узлом описано в FAQ модуля control-plane-manager.
Статические узлы
Добавить статический узел в кластер можно вручную (пример) или с помощью Cluster API Provider Static.
Как добавить статический узел в кластер (Cluster API Provider Static)?
Чтобы добавить статический узел в кластер (сервер bare-metal или виртуальную машину), выполните следующие шаги:
-
Подготовьте необходимые ресурсы:
-
Выделите сервер или виртуальную машину и убедитесь, что узел имеет необходимую сетевую связанность с кластером.
-
При необходимости установите дополнительные пакеты ОС и настройте точки монтирования, которые будут использоваться на узле.
-
-
Создайте пользователя с правами
sudo
:-
Добавьте нового пользователя (в данном примере —
caps
) с правами выполнения команд черезsudo
:1useradd -m -s /bin/bash caps 2usermod -aG sudo caps
-
Разрешите пользователю выполнять команды через
sudo
без ввода пароля. Для этого отредактируйте конфигурациюsudo
(отредактировав файл/etc/sudoers
, выполнив командуsudo visudo
или другим способом):1caps ALL=(ALL) NOPASSWD: ALL
-
-
На сервере откройте файл
/etc/ssh/sshd_config
и убедитесь, что параметрUsePAM
установлен в значениеyes
. Затем перезапустите службуsshd
:1sudo systemctl restart sshd
-
Сгенерируйте на сервере пару SSH-ключей с пустой парольной фразой:
1ssh-keygen -t rsa -f caps-id -C "" -N ""
Приватный и публичный ключи будут сохранены в файлах
caps-id
иcaps-id.pub
соответственно в текущей директории. -
Добавьте полученный публичный ключ в файл
/home/caps/.ssh/authorized_keys
пользователяcaps
, выполнив в директории с ключами на сервере следующие команды:1mkdir -p /home/caps/.ssh 2cat caps-id.pub >> /home/caps/.ssh/authorized_keys 3chmod 700 /home/caps/.ssh 4chmod 600 /home/caps/.ssh/authorized_keys 5chown -R caps:caps /home/caps/
- Создайте ресурс SSHCredentials.
- Создайте ресурс StaticInstance.
- Создайте ресурс NodeGroup с nodeType
Static
, указав желаемое количество узлов в группе и, при необходимости, фильтр выбораStaticInstance
.
Пример добавления статического узла.
Как добавить несколько статических узлов в кластер вручную?
Используйте существующий или создайте новый кастомный ресурс (Custom Resource) NodeGroup (пример NodeGroup
с именем worker
).
Автоматизировать процесс добавления узлов можно с помощью любой платформы автоматизации. Далее приведен пример для Ansible.
-
Получите один из адресов Kubernetes API-сервера. Обратите внимание, что IP-адрес должен быть доступен с узлов, которые добавляются в кластер:
1kubectl -n default get ep kubernetes -o json | jq '.subsets[0].addresses[0].ip + ":" + (.subsets[0].ports[0].port | tostring)' -r
Проверьте версию K8s. Если версия >= 1.25, создайте токен
node-group
:1kubectl create token node-group --namespace d8-cloud-instance-manager --duration 1h
Сохраните полученный токен, и добавьте в поле
token:
playbook’а Ansible на дальнейших шагах. -
Если версия Kubernetes меньше 1.25, получите Kubernetes API-токен для специального ServiceAccount’а, которым управляет Deckhouse:
1kubectl -n d8-cloud-instance-manager get $(kubectl -n d8-cloud-instance-manager get secret -o name | grep node-group-token) \ 2 -o json | jq '.data.token' -r | base64 -d && echo ""
-
Создайте Ansible playbook с
vars
, которые заменены на полученные на предыдущих шагах значения:1- hosts: all 2 become: yes 3 gather_facts: no 4 vars: 5 kube_apiserver: <KUBE_APISERVER> 6 token: <TOKEN> 7 tasks: 8 - name: Check if node is already bootsrapped 9 stat: 10 path: /var/lib/bashible 11 register: bootstrapped 12 - name: Get bootstrap secret 13 uri: 14 url: "https://{{ kube_apiserver }}/api/v1/namespaces/d8-cloud-instance-manager/secrets/manual-bootstrap-for-{{ node_group }}" 15 return_content: yes 16 method: GET 17 status_code: 200 18 body_format: json 19 headers: 20 Authorization: "Bearer {{ token }}" 21 validate_certs: no 22 register: bootstrap_secret 23 when: bootstrapped.stat.exists == False 24 - name: Run bootstrap.sh 25 shell: "{{ bootstrap_secret.json.data['bootstrap.sh'] | b64decode }}" 26 args: 27 executable: /bin/bash 28 ignore_errors: yes 29 when: bootstrapped.stat.exists == False 30 - name: wait 31 wait_for_connection: 32 delay: 30 33 when: bootstrapped.stat.exists == False
-
Определите дополнительную переменную
node_group
. Значение переменной должно совпадать с именемNodeGroup
, которой будет принадлежать узел. Переменную можно передать различными способами, например с использованием inventory-файла:1[system] 2system-0 3system-1 4[system:vars] 5node_group=system 6[worker] 7worker-0 8worker-1 9[worker:vars] 10node_group=worker
-
Запустите выполнение playbook’а с использованием inventory-файла.
Как вручную очистить статический узел?
Инструкция справедлива как для узла, настроенного вручную (с помощью бутстрап-скрипта), так и для узла, настроенного с помощью CAPS.
Чтобы вывести из кластера узел и очистить сервер (ВМ), выполните следующую команду на узле:
1bash /var/lib/bashible/cleanup_static_node.sh --yes-i-am-sane-and-i-understand-what-i-am-doing
Можно ли удалить StaticInstance?
StaticInstance
, находящийся в состоянии Pending
можно удалять без каких-либо проблем.
Чтобы удалить StaticInstance
находящийся в любом состоянии, отличном от Pending
(Running
, Cleaning
, Bootstrapping
), выполните следующие шаги:
- Добавьте метку
"node.deckhouse.io/allow-bootstrap": "false"
вStaticInstance
. - Дождитесь, пока
StaticInstance
перейдет в статусPending
. - Удалите
StaticInstance
. - Уменьшите значение параметра
NodeGroup.spec.staticInstances.count
на 1.
Как изменить IP-адрес StaticInstance?
Изменить IP-адрес в ресурсе StaticInstance
нельзя. Если в StaticInstance
указан ошибочный адрес, то нужно удалить StaticInstance и создать новый.
Как мигрировать статический узел настроенный вручную под управление CAPS?
Необходимо выполнить очистку узла, затем добавить узел под управление CAPS.
Как изменить NodeGroup у статического узла?
Если узел находится под управлением CAPS, то изменить принадлежность к NodeGroup
у такого узла нельзя. Единственный вариант — удалить StaticInstance и создать новый.
Чтобы перенести существующий статический узел созданный вручную из одной NodeGroup
в другую, необходимо изменить у узла лейбл группы:
1kubectl label node --overwrite <node_name> node.deckhouse.io/group=<new_node_group_name>
2kubectl label node <node_name> node-role.kubernetes.io/<old_node_group_name>-
Применение изменений потребует некоторого времени.
Как зачистить узел для последующего ввода в кластер?
Это необходимо только в том случае, если нужно переместить статический узел из одного кластера в другой. Имейте в виду, что эти операции удаляют данные локального хранилища. Если необходимо просто изменить NodeGroup
, следуйте этой инструкции.
Если на зачищаемом узле есть пулы хранения LINSTOR/DRBD, то предварительно перенесите ресурсы с узла и удалите узел LINSTOR/DRBD, следуя инструкции.
-
Удалите узел из кластера Kubernetes:
1kubectl drain <node> --ignore-daemonsets --delete-local-data 2kubectl delete node <node>
-
Запустите на узле скрипт очистки:
1bash /var/lib/bashible/cleanup_static_node.sh --yes-i-am-sane-and-i-understand-what-i-am-doing
-
После перезагрузки узла запустите скрипт
bootstrap.sh
.
Как понять, что что-то пошло не так?
Если узел в NodeGroup не обновляется (значение UPTODATE
при выполнении команды kubectl get nodegroup
меньше значения NODES
) или вы предполагаете какие-то другие проблемы, которые могут быть связаны с модулем node-manager
, нужно проверить логи сервиса bashible
. Сервис bashible
запускается на каждом узле, управляемом модулем node-manager
.
Чтобы проверить логи сервиса bashible
, выполните на узле следующую команду:
1journalctl -fu bashible
Пример вывода, когда все необходимые действия выполнены:
1May 25 04:39:16 kube-master-0 systemd[1]: Started Bashible service.
2May 25 04:39:16 kube-master-0 bashible.sh[1976339]: Configuration is in sync, nothing to do.
3May 25 04:39:16 kube-master-0 systemd[1]: bashible.service: Succeeded.
Как посмотреть, что в данный момент выполняется на узле при его создании?
Если необходимо узнать, что происходит на узле (например, узел долго создается), можно проверить логи cloud-init
. Для этого выполните следующие шаги:
-
Найдите узел, который находится в стадии бутстрапа:
1kubectl get instances | grep Pending
Пример:
1$ kubectl get instances | grep Pending 2dev-worker-2a6158ff-6764d-nrtbj Pending 46s
-
Получите информацию о параметрах подключения для просмотра логов:
1kubectl get instances dev-worker-2a6158ff-6764d-nrtbj -o yaml | grep 'bootstrapStatus' -B0 -A2
Пример:
1$ kubectl get instances dev-worker-2a6158ff-6764d-nrtbj -o yaml | grep 'bootstrapStatus' -B0 -A2 2bootstrapStatus: 3 description: Use 'nc 192.168.199.178 8000' to get bootstrap logs. 4 logsEndpoint: 192.168.199.178:8000
-
Выполните полученную команду (в примере выше —
nc 192.168.199.178 8000
), чтобы просмотреть логиcloud-init
и определить, на каком этапе остановилась настройка узла.
Логи первоначальной настройки узла находятся в /var/log/cloud-init-output.log
.
Как обновить ядро на узлах?
Для дистрибутивов, основанных на Debian
Создайте ресурс NodeGroupConfiguration
, указав в переменной desired_version
shell-скрипта (параметр spec.content
ресурса) желаемую версию ядра:
1apiVersion: deckhouse.io/v1alpha1
2kind: NodeGroupConfiguration
3metadata:
4 name: install-kernel.sh
5spec:
6 bundles:
7 - '*'
8 nodeGroups:
9 - '*'
10 weight: 32
11 content: |
12 # Copyright 2022 Flant JSC
13 #
14 # Licensed under the Apache License, Version 2.0 (the "License");
15 # you may not use this file except in compliance with the License.
16 # You may obtain a copy of the License at
17 #
18 # http://www.apache.org/licenses/LICENSE-2.0
19 #
20 # Unless required by applicable law or agreed to in writing, software
21 # distributed under the License is distributed on an "AS IS" BASIS,
22 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
23 # See the License for the specific language governing permissions and
24 # limitations under the License.
25 desired_version="5.15.0-53-generic"
26 bb-event-on 'bb-package-installed' 'post-install'
27 post-install() {
28 bb-log-info "Setting reboot flag due to kernel was updated"
29 bb-flag-set reboot
30 }
31 version_in_use="$(uname -r)"
32 if [[ "$version_in_use" == "$desired_version" ]]; then
33 exit 0
34 fi
35 bb-deckhouse-get-disruptive-update-approval
36 bb-apt-install "linux-image-${desired_version}"
Для дистрибутивов, основанных на CentOS
Создайте ресурс NodeGroupConfiguration
, указав в переменной desired_version
shell-скрипта (параметр spec.content
ресурса) желаемую версию ядра:
1apiVersion: deckhouse.io/v1alpha1
2kind: NodeGroupConfiguration
3metadata:
4 name: install-kernel.sh
5spec:
6 bundles:
7 - '*'
8 nodeGroups:
9 - '*'
10 weight: 32
11 content: |
12 # Copyright 2022 Flant JSC
13 #
14 # Licensed under the Apache License, Version 2.0 (the "License");
15 # you may not use this file except in compliance with the License.
16 # You may obtain a copy of the License at
17 #
18 # http://www.apache.org/licenses/LICENSE-2.0
19 #
20 # Unless required by applicable law or agreed to in writing, software
21 # distributed under the License is distributed on an "AS IS" BASIS,
22 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
23 # See the License for the specific language governing permissions and
24 # limitations under the License.
25 desired_version="3.10.0-1160.42.2.el7.x86_64"
26 bb-event-on 'bb-package-installed' 'post-install'
27 post-install() {
28 bb-log-info "Setting reboot flag due to kernel was updated"
29 bb-flag-set reboot
30 }
31 version_in_use="$(uname -r)"
32 if [[ "$version_in_use" == "$desired_version" ]]; then
33 exit 0
34 fi
35 bb-deckhouse-get-disruptive-update-approval
36 bb-yum-install "kernel-${desired_version}"
Какие параметры NodeGroup к чему приводят?
Параметр NG | Disruption update | Перезаказ узлов | Рестарт kubelet |
---|---|---|---|
chaos | - | - | - |
cloudInstances.classReference | - | + | - |
cloudInstances.maxSurgePerZone | - | - | - |
cri.containerd.maxConcurrentDownloads | - | - | + |
cri.type | - (NotManaged) / + (other) | - | - |
disruptions | - | - | - |
kubelet.maxPods | - | - | + |
kubelet.rootDir | - | - | + |
kubernetesVersion | - | - | + |
nodeTemplate | - | - | - |
static | - | - | + |
update.maxConcurrent | - | - | - |
Подробно о всех параметрах можно прочитать в описании кастомного ресурса NodeGroup.
В случае изменения параметров InstanceClass
или instancePrefix
в конфигурации Deckhouse не будет происходить RollingUpdate
. Deckhouse создаст новые MachineDeployment
, а старые удалит. Количество заказываемых одновременно MachineDeployment
определяется параметром cloudInstances.maxSurgePerZone
.
При обновлении, которое требует прерывания работы узла (disruption update), выполняется процесс вытеснения подов с узла. Если какой-либо под не может быть вытеснен, попытка повторяется каждые 20 секунд до достижения глобального таймаута в 5 минут. После истечения этого времени, поды, которые не удалось вытеснить, удаляются принудительно.
Как пересоздать эфемерные машины в облаке с новой конфигурацией?
При изменении конфигурации Deckhouse (как в модуле node-manager
, так и в любом из облачных провайдеров) виртуальные машины не будут перезаказаны. Пересоздание происходит только после изменения ресурсов InstanceClass
или NodeGroup
.
Чтобы принудительно пересоздать все узлы, связанные с ресурсом Machines
, следует добавить/изменить аннотацию manual-rollout-id
в NodeGroup
: kubectl annotate NodeGroup имя_ng "manual-rollout-id=$(uuidgen)" --overwrite
.
Как выделить узлы под специфические нагрузки?
Запрещено использование домена deckhouse.io
в ключах labels
и taints
у NodeGroup
. Он зарезервирован для компонентов Deckhouse. Следует отдавать предпочтение в пользу ключей dedicated
или dedicated.client.com
.
Для решений данной задачи существуют два механизма:
- Установка меток в
NodeGroup
spec.nodeTemplate.labels
для последующего использования их вPod
spec.nodeSelector или spec.affinity.nodeAffinity. Указывает, какие именно узлы будут выбраны планировщиком для запуска целевого приложения. - Установка ограничений в
NodeGroup
spec.nodeTemplate.taints
с дальнейшим снятием их вPod
spec.tolerations. Запрещает исполнение не разрешенных явно приложений на этих узлах.
Deckhouse по умолчанию поддерживает использование taint’а с ключом dedicated
, поэтому рекомендуется применять этот ключ с любым значением для taints на ваших выделенных узлах.
Если требуется использовать другие ключи для taints (например, dedicated.client.com
), необходимо добавить соответствующее значение ключа в параметр modules.placement.customTolerationKeys. Это обеспечит разрешение системным компонентам, таким как cni-flannel
, использовать эти узлы.
Подробности в статье на Habr.
Как выделить узлы под системные компоненты?
Фронтенд
Для Ingress-контроллеров используйте NodeGroup
со следующей конфигурацией:
1nodeTemplate:
2 labels:
3 node-role.deckhouse.io/frontend: ""
4 taints:
5 - effect: NoExecute
6 key: dedicated.deckhouse.io
7 value: frontend
Системные
Для компонентов подсистем Deckhouse параметр NodeGroup
будет настроен с параметрами:
1nodeTemplate:
2 labels:
3 node-role.deckhouse.io/system: ""
4 taints:
5 - effect: NoExecute
6 key: dedicated.deckhouse.io
7 value: system
Как ускорить заказ узлов в облаке при горизонтальном масштабировании приложений?
Самое действенное — держать в кластере некоторое количество предварительно подготовленных узлов, которые позволят новым репликам ваших приложений запускаться мгновенно. Очевидным минусом данного решения будут дополнительные расходы на содержание этих узлов.
Необходимые настройки целевой NodeGroup
будут следующие:
- Указать абсолютное количество предварительно подготовленных узлов (или процент от максимального количества узлов в этой группе) в параметре
cloudInstances.standby
. - При наличии на узлах дополнительных служебных компонентов, не обслуживаемых Deckhouse (например, DaemonSet
filebeat
), задать их процентное потребление ресурсов узла можно в параметреstandbyHolder.overprovisioningRate
. - Для работы этой функции требуется, чтобы как минимум один узел из группы уже был запущен в кластере. Иными словами, либо должна быть доступна одна реплика приложения, либо количество узлов для этой группы
cloudInstances.minPerZone
должно быть1
.
Пример:
1cloudInstances:
2 maxPerZone: 10
3 minPerZone: 1
4 standby: 10%
5 standbyHolder:
6 overprovisioningRate: 30%
Как выключить machine-controller-manager в случае выполнения потенциально деструктивных изменений в кластере?
Использовать эту настройку допустимо только тогда, когда вы четко понимаете, зачем это необходимо.
Для того чтобы временно отключить machine-controller-manager (MCM) и предотвратить его автоматические действия, которые могут повлиять на инфраструктуру кластера (например, удаление или пересоздание узлов), установите следующий параметр в конфигурации:
1mcmEmergencyBrake: true
Как восстановить master-узел, если kubelet не может загрузить компоненты control plane?
Подобная ситуация может возникнуть, если в кластере с одним master-узлом на нем были удалены образы компонентов control plane (например, удалена директория /var/lib/containerd
).
В этом случае kubelet при рестарте не сможет скачать образы компонентов control plane
, поскольку на master-узле нет параметров авторизации в registry.deckhouse.io
.
Далее приведена инструкция по восстановлению master-узла.
containerd
Для восстановления работоспособности master-узла нужно в любом рабочем кластере под управлением Deckhouse выполнить команду:
1kubectl -n d8-system get secrets deckhouse-registry -o json |
2jq -r '.data.".dockerconfigjson"' | base64 -d |
3jq -r '.auths."registry.deckhouse.io".auth'
Вывод команды нужно скопировать и присвоить переменной AUTH
на поврежденном master-узле.
Далее на поврежденном master-узле нужно загрузить образы компонентов control-plane
:
1for image in $(grep "image:" /etc/kubernetes/manifests/* | awk '{print $3}'); do
2 crictl pull --auth $AUTH $image
3done
После загрузки образов необходимо перезапустить kubelet
.
Как изменить CRI для NodeGroup?
Смена CRI возможна только между Containerd
на NotManaged
и обратно (параметр cri.type).
Для изменения CRI для NodeGroup, установите параметр cri.type в Containerd
или в NotManaged
.
Пример YAML-манифеста NodeGroup:
1apiVersion: deckhouse.io/v1
2kind: NodeGroup
3metadata:
4 name: worker
5spec:
6 nodeType: Static
7 cri:
8 type: Containerd
Также эту операцию можно выполнить с помощью патча:
-
Для
Containerd
:1kubectl patch nodegroup <имя NodeGroup> --type merge -p '{"spec":{"cri":{"type":"Containerd"}}}'
-
Для
NotManaged
:1kubectl patch nodegroup <имя NodeGroup> --type merge -p '{"spec":{"cri":{"type":"NotManaged"}}}'
При изменении cri.type
для NodeGroup, созданных с помощью dhctl
, необходимо обновить это значение в dhctl config edit provider-cluster-configuration
и настройках объекта NodeGroup.
После изменения CRI для NodeGroup модуль node-manager
будет поочередно перезагружать узлы, применяя новый CRI. Обновление узла сопровождается простоем (disruption). В зависимости от настройки disruption
для NodeGroup, модуль node-manager
либо автоматически выполнит обновление узлов, либо потребует подтверждения вручную.
Как изменить CRI для всего кластера?
Смена CRI возможна только между Containerd
на NotManaged
и обратно (параметр cri.type).
Для изменения CRI для всего кластера, необходимо с помощью утилиты dhctl
отредактировать параметр defaultCRI
в конфигурационном файле cluster-configuration
.
Также возможно выполнить эту операцию с помощью kubectl patch
.
-
Для
Containerd
:1data="$(kubectl -n kube-system get secret d8-cluster-configuration -o json | jq -r '.data."cluster-configuration.yaml"' | base64 -d | sed "s/NotManaged/Containerd/" | base64 -w0)" 2kubectl -n kube-system patch secret d8-cluster-configuration -p "{\"data\":{\"cluster-configuration.yaml\":\"$data\"}}"
-
Для
NotManaged
:1data="$(kubectl -n kube-system get secret d8-cluster-configuration -o json | jq -r '.data."cluster-configuration.yaml"' | base64 -d | sed "s/Containerd/NotManaged/" | base64 -w0)" 2kubectl -n kube-system patch secret d8-cluster-configuration -p "{\"data\":{\"cluster-configuration.yaml\":\"$data\"}}"
Если необходимо, чтобы отдельные NodeGroup использовали другой CRI, перед изменением defaultCRI
необходимо установить CRI для этой NodeGroup,
как описано в документации.
Изменение defaultCRI
влечет за собой изменение CRI на всех узлах, включая master-узлы.
Если master-узел один, данная операция является опасной и может привести к полной неработоспособности кластера.
Рекомендуется использовать multimaster-конфигурацию и менять тип CRI только после этого.
При изменении CRI в кластере для master-узлов необходимо выполнить дополнительные шаги:
-
Чтобы определить, какой узел в текущий момент обновляется в master NodeGroup, используйте следующую команду:
1kubectl get nodes -l node-role.kubernetes.io/control-plane="" -o json | jq '.items[] | select(.metadata.annotations."update.node.deckhouse.io/approved"=="") | .metadata.name' -r
-
Подтвердите остановку (disruption) для master-узла, полученного на предыдущем шаге:
1kubectl annotate node <имя master-узла> update.node.deckhouse.io/disruption-approved=
-
Дождаитесь перехода обновленного master-узла в
Ready
. Выполните итерацию для следующего master-узла.
Как добавить шаг для конфигурации узлов?
Дополнительные шаги для конфигурации узлов задаются с помощью кастомного ресурса NodeGroupConfiguration.
Как автоматически проставить на узел кастомные лейблы?
-
На узле создайте каталог
/var/lib/node_labels
. -
Создайте в нём файл или файлы, содержащие необходимые лейблы. Количество файлов может быть любым, как и вложенность подкаталогов, их содержащих.
-
Добавьте в файлы нужные лейблы в формате
key=value
. Например:1example-label=test
-
Сохраните файлы.
При добавлении узла в кластер указанные в файлах лейблы будут автоматически проставлены на узел.
Обратите внимание, что добавить таким образом лейблы, использующиеся в DKP, невозможно. Работать такой метод будет только с кастомными лейблами, не пересекающимися с зарезервированными для Deckhouse.
Как использовать containerd с поддержкой Nvidia GPU?
Необходимо создать отдельную NodeGroup для GPU-узлов:
1apiVersion: deckhouse.io/v1
2kind: NodeGroup
3metadata:
4 name: gpu
5spec:
6 chaos:
7 mode: Disabled
8 disruptions:
9 approvalMode: Automatic
10 nodeType: CloudStatic
Далее создайте NodeGroupConfiguration для NodeGroup gpu
для конфигурации containerd:
1apiVersion: deckhouse.io/v1alpha1
2kind: NodeGroupConfiguration
3metadata:
4 name: containerd-additional-config.sh
5spec:
6 bundles:
7 - '*'
8 content: |
9 # Copyright 2023 Flant JSC
10 #
11 # Licensed under the Apache License, Version 2.0 (the "License");
12 # you may not use this file except in compliance with the License.
13 # You may obtain a copy of the License at
14 #
15 # http://www.apache.org/licenses/LICENSE-2.0
16 #
17 # Unless required by applicable law or agreed to in writing, software
18 # distributed under the License is distributed on an "AS IS" BASIS,
19 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
20 # See the License for the specific language governing permissions and
21 # limitations under the License.
22 mkdir -p /etc/containerd/conf.d
23 bb-sync-file /etc/containerd/conf.d/nvidia_gpu.toml - << "EOF"
24 [plugins]
25 [plugins."io.containerd.grpc.v1.cri"]
26 [plugins."io.containerd.grpc.v1.cri".containerd]
27 default_runtime_name = "nvidia"
28 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
29 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
30 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia]
31 privileged_without_host_devices = false
32 runtime_engine = ""
33 runtime_root = ""
34 runtime_type = "io.containerd.runc.v1"
35 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia.options]
36 BinaryName = "/usr/bin/nvidia-container-runtime"
37 SystemdCgroup = false
38 EOF
39 nodeGroups:
40 - gpu
41 weight: 31
Добавьте NodeGroupConfiguration для установки драйверов Nvidia для NodeGroup gpu
.
Ubuntu
1apiVersion: deckhouse.io/v1alpha1
2kind: NodeGroupConfiguration
3metadata:
4 name: install-cuda.sh
5spec:
6 bundles:
7 - ubuntu-lts
8 content: |
9 # Copyright 2023 Flant JSC
10 #
11 # Licensed under the Apache License, Version 2.0 (the "License");
12 # you may not use this file except in compliance with the License.
13 # You may obtain a copy of the License at
14 #
15 # http://www.apache.org/licenses/LICENSE-2.0
16 #
17 # Unless required by applicable law or agreed to in writing, software
18 # distributed under the License is distributed on an "AS IS" BASIS,
19 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
20 # See the License for the specific language governing permissions and
21 # limitations under the License.
22 if [ ! -f "/etc/apt/sources.list.d/nvidia-container-toolkit.list" ]; then
23 distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
24 curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add -
25 curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
26 fi
27 bb-apt-install nvidia-container-toolkit nvidia-driver-535-server
28 nvidia-ctk config --set nvidia-container-runtime.log-level=error --in-place
29 nodeGroups:
30 - gpu
31 weight: 30
Centos
1apiVersion: deckhouse.io/v1alpha1
2kind: NodeGroupConfiguration
3metadata:
4 name: install-cuda.sh
5spec:
6 bundles:
7 - centos
8 content: |
9 # Copyright 2023 Flant JSC
10 #
11 # Licensed under the Apache License, Version 2.0 (the "License");
12 # you may not use this file except in compliance with the License.
13 # You may obtain a copy of the License at
14 #
15 # http://www.apache.org/licenses/LICENSE-2.0
16 #
17 # Unless required by applicable law or agreed to in writing, software
18 # distributed under the License is distributed on an "AS IS" BASIS,
19 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
20 # See the License for the specific language governing permissions and
21 # limitations under the License.
22 if [ ! -f "/etc/yum.repos.d/nvidia-container-toolkit.repo" ]; then
23 distribution=$(. /etc/os-release;echo $ID$VERSION_ID) \
24 curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.repo | sudo tee /etc/yum.repos.d/nvidia-container-toolkit.repo
25 fi
26 bb-yum-install nvidia-container-toolkit nvidia-driver
27 nvidia-ctk config --set nvidia-container-runtime.log-level=error --in-place
28 nodeGroups:
29 - gpu
30 weight: 30
После того как конфигурации будут применены, необходимо провести бутстрап и перезагрузить узлы, чтобы применить настройки и установить драйвера.
Как проверить, что все прошло успешно?
Создайте в кластере Job:
1apiVersion: batch/v1
2kind: Job
3metadata:
4 name: nvidia-cuda-test
5 namespace: default
6spec:
7 completions: 1
8 template:
9 spec:
10 restartPolicy: Never
11 nodeSelector:
12 node.deckhouse.io/group: gpu
13 containers:
14 - name: nvidia-cuda-test
15 image: nvidia/cuda:11.6.2-base-ubuntu20.04
16 imagePullPolicy: "IfNotPresent"
17 command:
18 - nvidia-smi
Проверьте логи командой:
1$ kubectl logs job/nvidia-cuda-test
2Tue Jan 24 11:36:18 2023
3+-----------------------------------------------------------------------------+
4| NVIDIA-SMI 525.60.13 Driver Version: 525.60.13 CUDA Version: 12.0 |
5|-------------------------------+----------------------+----------------------+
6| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
7| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
8| | | MIG M. |
9|===============================+======================+======================|
10| 0 Tesla T4 Off | 00000000:8B:00.0 Off | 0 |
11| N/A 45C P0 25W / 70W | 0MiB / 15360MiB | 0% Default |
12| | | N/A |
13+-------------------------------+----------------------+----------------------+
14+-----------------------------------------------------------------------------+
15| Processes: |
16| GPU GI CI PID Type Process name GPU Memory |
17| ID ID Usage |
18|=============================================================================|
19| No running processes found |
20+-----------------------------------------------------------------------------+
Создайте в кластере Job:
1apiVersion: batch/v1
2kind: Job
3metadata:
4 name: gpu-operator-test
5 namespace: default
6spec:
7 completions: 1
8 template:
9 spec:
10 restartPolicy: Never
11 nodeSelector:
12 node.deckhouse.io/group: gpu
13 containers:
14 - name: gpu-operator-test
15 image: nvidia/samples:vectoradd-cuda10.2
16 imagePullPolicy: "IfNotPresent"
Проверьте логи командой:
1$ kubectl logs job/gpu-operator-test
2[Vector addition of 50000 elements]
3Copy input data from the host memory to the CUDA device
4CUDA kernel launch with 196 blocks of 256 threads
5Copy output data from the CUDA device to the host memory
6Test PASSED
7Done
Как развернуть кастомный конфигурационный файл containerd?
Пример NodeGroupConfiguration
основан на функциях, заложенных в скрипте 032_configure_containerd.sh.
Добавление кастомных настроек вызывает перезапуск сервиса containerd
.
Bashible на узлах объединяет конфигурацию containerd для Deckhouse с конфигурацией из файла /etc/containerd/conf.d/*.toml
.
Вы можете переопределять значения параметров, которые заданы в файле /etc/containerd/deckhouse.toml
, но их работу придётся обеспечивать самостоятельно. Также, лучше изменением конфигурации не затрагивать master-узлы (nodeGroup master
).
1apiVersion: deckhouse.io/v1alpha1
2kind: NodeGroupConfiguration
3metadata:
4 name: containerd-option-config.sh
5spec:
6 bundles:
7 - '*'
8 content: |
9 # Copyright 2024 Flant JSC
10 #
11 # Licensed under the Apache License, Version 2.0 (the "License");
12 # you may not use this file except in compliance with the License.
13 # You may obtain a copy of the License at
14 #
15 # http://www.apache.org/licenses/LICENSE-2.0
16 #
17 # Unless required by applicable law or agreed to in writing, software
18 # distributed under the License is distributed on an "AS IS" BASIS,
19 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
20 # See the License for the specific language governing permissions and
21 # limitations under the License.
22 mkdir -p /etc/containerd/conf.d
23 bb-sync-file /etc/containerd/conf.d/additional_option.toml - << EOF
24 oom_score = 500
25 [metrics]
26 address = "127.0.0.1"
27 grpc_histogram = true
28 EOF
29 nodeGroups:
30 - "worker"
31 weight: 31
Как добавить авторизацию в дополнительный registry?
Разверните скрипт NodeGroupConfiguration
:
1apiVersion: deckhouse.io/v1alpha1
2kind: NodeGroupConfiguration
3metadata:
4 name: containerd-additional-config.sh
5spec:
6 bundles:
7 - '*'
8 content: |
9 # Copyright 2023 Flant JSC
10 #
11 # Licensed under the Apache License, Version 2.0 (the "License");
12 # you may not use this file except in compliance with the License.
13 # You may obtain a copy of the License at
14 #
15 # http://www.apache.org/licenses/LICENSE-2.0
16 #
17 # Unless required by applicable law or agreed to in writing, software
18 # distributed under the License is distributed on an "AS IS" BASIS,
19 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
20 # See the License for the specific language governing permissions and
21 # limitations under the License.
22 REGISTRY_URL=private.registry.example
23 mkdir -p /etc/containerd/conf.d
24 bb-sync-file /etc/containerd/conf.d/additional_registry.toml - << EOF
25 [plugins]
26 [plugins."io.containerd.grpc.v1.cri"]
27 [plugins."io.containerd.grpc.v1.cri".registry]
28 [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
29 [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
30 endpoint = ["https://registry-1.docker.io"]
31 [plugins."io.containerd.grpc.v1.cri".registry.mirrors."${REGISTRY_URL}"]
32 endpoint = ["https://${REGISTRY_URL}"]
33 [plugins."io.containerd.grpc.v1.cri".registry.configs]
34 [plugins."io.containerd.grpc.v1.cri".registry.configs."${REGISTRY_URL}".auth]
35 auth = "AAAABBBCCCDDD=="
36 EOF
37 nodeGroups:
38 - "*"
39 weight: 31
Как настроить сертификат для дополнительного registry?
Помимо containerd, сертификат можно одновременно добавить и в операционной системе.
Пример NodeGroupConfiguration
для настройки сертификата для дополнительного registry:
1apiVersion: deckhouse.io/v1alpha1
2kind: NodeGroupConfiguration
3metadata:
4 name: configure-cert-containerd.sh
5spec:
6 bundles:
7 - '*'
8 content: |-
9 # Copyright 2024 Flant JSC
10 #
11 # Licensed under the Apache License, Version 2.0 (the "License");
12 # you may not use this file except in compliance with the License.
13 # You may obtain a copy of the License at
14 #
15 # http://www.apache.org/licenses/LICENSE-2.0
16 #
17 # Unless required by applicable law or agreed to in writing, software
18 # distributed under the License is distributed on an "AS IS" BASIS,
19 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
20 # See the License for the specific language governing permissions and
21 # limitations under the License.
22 REGISTRY_URL=private.registry.example
23 CERT_FILE_NAME=${REGISTRY_URL}
24 CERTS_FOLDER="/var/lib/containerd/certs/"
25 CERT_CONTENT=$(cat <<"EOF"
26 -----BEGIN CERTIFICATE-----
27 MIIDSjCCAjKgAwIBAgIRAJ4RR/WDuAym7M11JA8W7D0wDQYJKoZIhvcNAQELBQAw
28 JTEjMCEGA1UEAxMabmV4dXMuNTEuMjUwLjQxLjIuc3NsaXAuaW8wHhcNMjQwODAx
29 MTAzMjA4WhcNMjQxMDMwMTAzMjA4WjAlMSMwIQYDVQQDExpuZXh1cy41MS4yNTAu
30 NDEuMi5zc2xpcC5pbzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL1p
31 WLPr2c4SZX/i4IS59Ly1USPjRE21G4pMYewUjkSXnYv7hUkHvbNL/P9dmGBm2Jsl
32 WFlRZbzCv7+5/J+9mPVL2TdTbWuAcTUyaG5GZ/1w64AmAWxqGMFx4eyD1zo9eSmN
33 G2jis8VofL9dWDfUYhRzJ90qKxgK6k7tfhL0pv7IHDbqf28fCEnkvxsA98lGkq3H
34 fUfvHV6Oi8pcyPZ/c8ayIf4+JOnf7oW/TgWqI7x6R1CkdzwepJ8oU7PGc0ySUWaP
35 G5bH3ofBavL0bNEsyScz4TFCJ9b4aO5GFAOmgjFMMUi9qXDH72sBSrgi08Dxmimg
36 Hfs198SZr3br5GTJoAkCAwEAAaN1MHMwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB
37 /wQCMAAwUwYDVR0RBEwwSoIPbmV4dXMuc3ZjLmxvY2FsghpuZXh1cy41MS4yNTAu
38 NDEuMi5zc2xpcC5pb4IbZG9ja2VyLjUxLjI1MC40MS4yLnNzbGlwLmlvMA0GCSqG
39 SIb3DQEBCwUAA4IBAQBvTjTTXWeWtfaUDrcp1YW1pKgZ7lTb27f3QCxukXpbC+wL
40 dcb4EP/vDf+UqCogKl6rCEA0i23Dtn85KAE9PQZFfI5hLulptdOgUhO3Udluoy36
41 D4WvUoCfgPgx12FrdanQBBja+oDsT1QeOpKwQJuwjpZcGfB2YZqhO0UcJpC8kxtU
42 by3uoxJoveHPRlbM2+ACPBPlHu/yH7st24sr1CodJHNt6P8ugIBAZxi3/Hq0wj4K
43 aaQzdGXeFckWaxIny7F1M3cIWEXWzhAFnoTgrwlklf7N7VWHPIvlIh1EYASsVYKn
44 iATq8C7qhUOGsknDh3QSpOJeJmpcBwln11/9BGRP
45 -----END CERTIFICATE-----
46 EOF
47 )
48 CONFIG_CONTENT=$(cat <<EOF
49 [plugins]
50 [plugins."io.containerd.grpc.v1.cri".registry.configs."${REGISTRY_URL}".tls]
51 ca_file = "${CERTS_FOLDER}/${CERT_FILE_NAME}.crt"
52 EOF
53 )
54 mkdir -p ${CERTS_FOLDER}
55 mkdir -p /etc/containerd/conf.d
56 # bb-tmp-file - Create temp file function. More information: http://www.bashbooster.net/#tmp
57 CERT_TMP_FILE="$( bb-tmp-file )"
58 echo -e "${CERT_CONTENT}" > "${CERT_TMP_FILE}"
59 CONFIG_TMP_FILE="$( bb-tmp-file )"
60 echo -e "${CONFIG_CONTENT}" > "${CONFIG_TMP_FILE}"
61 # bb-sync-file - File synchronization function. More information: http://www.bashbooster.net/#sync
62 ## "${CERTS_FOLDER}/${CERT_FILE_NAME}.crt" - Destination file
63 ## ${CERT_TMP_FILE} - Source file
64 bb-sync-file \
65 "${CERTS_FOLDER}/${CERT_FILE_NAME}.crt" \
66 ${CERT_TMP_FILE}
67 bb-sync-file \
68 "/etc/containerd/conf.d/${REGISTRY_URL}.toml" \
69 ${CONFIG_TMP_FILE}
70 nodeGroups:
71 - '*'
72 weight: 31
Как использовать NodeGroup с приоритетом?
С помощью параметра priority кастомного ресурса NodeGroup
можно задавать порядок заказа узлов в кластере.
Например, можно сделать так, чтобы сначала заказывались узлы типа spot-node, а если они закончились — обычные узлы. Или чтобы при наличии ресурсов в облаке заказывались узлы большего размера, а при их исчерпании — узлы меньшего размера.
Пример создания двух NodeGroup
с использованием узлов типа spot-node:
1---
2apiVersion: deckhouse.io/v1
3kind: NodeGroup
4metadata:
5 name: worker-spot
6spec:
7 cloudInstances:
8 classReference:
9 kind: AWSInstanceClass
10 name: worker-spot
11 maxPerZone: 5
12 minPerZone: 0
13 priority: 50
14 nodeType: CloudEphemeral
15---
16apiVersion: deckhouse.io/v1
17kind: NodeGroup
18metadata:
19 name: worker
20spec:
21 cloudInstances:
22 classReference:
23 kind: AWSInstanceClass
24 name: worker
25 maxPerZone: 5
26 minPerZone: 0
27 priority: 30
28 nodeType: CloudEphemeral
В приведенном выше примере, cluster-autoscaler
сначала попытается заказать узел типа _spot-node. Если в течение 15 минут его не получится добавить в кластер, NodeGroup worker-spot
будет поставлен на паузу (на 20 минут) и cluster-autoscaler
начнет заказывать узлы из NodeGroup worker
.
Если через 30 минут в кластере возникнет необходимость развернуть еще один узел, cluster-autoscaler
сначала попытается заказать узел из NodeGroup worker-spot
и только потом — из NodeGroup worker
.
После того как NodeGroup worker-spot
достигнет своего максимума (5 узлов в примере выше), узлы будут заказываться из NodeGroup worker
.
Шаблоны узлов (labels/taints) для NodeGroup worker
и worker-spot
должны быть одинаковыми, или как минимум подходить для той нагрузки, которая запускает процесс увеличения кластера.
Как интерпретировать состояние группы узлов?
Ready — группа узлов содержит минимально необходимое число запланированных узлов с состоянием Ready
для всех зон.
Пример 1. Группа узлов в состоянии Ready
:
1apiVersion: deckhouse.io/v1
2kind: NodeGroup
3metadata:
4 name: ng1
5spec:
6 nodeType: CloudEphemeral
7 cloudInstances:
8 maxPerZone: 5
9 minPerZone: 1
10status:
11 conditions:
12 - status: "True"
13 type: Ready
14---
15apiVersion: v1
16kind: Node
17metadata:
18 name: node1
19 labels:
20 node.deckhouse.io/group: ng1
21status:
22 conditions:
23 - status: "True"
24 type: Ready
Пример 2. Группа узлов в состоянии Not Ready
:
1apiVersion: deckhouse.io/v1
2kind: NodeGroup
3metadata:
4 name: ng1
5spec:
6 nodeType: CloudEphemeral
7 cloudInstances:
8 maxPerZone: 5
9 minPerZone: 2
10status:
11 conditions:
12 - status: "False"
13 type: Ready
14---
15apiVersion: v1
16kind: Node
17metadata:
18 name: node1
19 labels:
20 node.deckhouse.io/group: ng1
21status:
22 conditions:
23 - status: "True"
24 type: Ready
Updating — группа узлов содержит как минимум один узел, в котором присутствует аннотация с префиксом update.node.deckhouse.io
(например, update.node.deckhouse.io/waiting-for-approval
).
WaitingForDisruptiveApproval — группа узлов содержит как минимум один узел, в котором присутствует аннотация update.node.deckhouse.io/disruption-required
и
отсутствует аннотация update.node.deckhouse.io/disruption-approved
.
Scaling — рассчитывается только для групп узлов с типом CloudEphemeral
. Состояние True
может быть в двух случаях:
- Когда число узлов меньше желаемого числа узлов в группе, то есть когда нужно увеличить число узлов в группе.
- Когда какой-то узел помечается к удалению или число узлов больше желаемого числа узлов, то есть когда нужно уменьшить число узлов в группе.
Желаемое число узлов — это сумма всех реплик, входящих в группу узлов.
Пример. Желаемое число узлов равно 2:
1apiVersion: deckhouse.io/v1
2kind: NodeGroup
3metadata:
4 name: ng1
5spec:
6 nodeType: CloudEphemeral
7 cloudInstances:
8 maxPerZone: 5
9 minPerZone: 2
10status:
11...
12 desired: 2
13...
Error — содержит последнюю ошибку, возникшую при создании узла в группе узлов.
Как заставить werf игнорировать состояние Ready в группе узлов?
werf проверяет состояние Ready
у ресурсов и в случае его наличия дожидается, пока значение станет True
.
Создание (обновление) ресурса nodeGroup в кластере может потребовать значительного времени на развертывание необходимого количества узлов. При развертывании такого ресурса в кластере с помощью werf (например, в рамках процесса CI/CD) развертывание может завершиться по превышении времени ожидания готовности ресурса. Чтобы заставить werf игнорировать состояние nodeGroup
, необходимо добавить к nodeGroup
следующие аннотации:
1metadata:
2 annotations:
3 werf.io/fail-mode: IgnoreAndContinueDeployProcess
4 werf.io/track-termination-mode: NonBlocking
Что такое ресурс Instance?
Ресурс Instance
в Kubernetes представляет собой описание объекта эфемерной виртуальной машины, но без конкретной реализации. Это абстракция, которая используется для управления машинами, созданными с помощью таких инструментов, как MachineControllerManager или Cluster API Provider Static.
Объект не содержит спецификации. Статус содержит:
- Ссылку на
InstanceClass
, если он существует для данной реализации. - Ссылку на объект Node Kubernetes.
- Текущий статус машины.
- Информацию о том, как проверить логи создания машины (появляется на этапе создания машины).
При создании или удалении машины создается или удаляется соответствующий объект Instance.
Самостоятельно ресурс Instance
создать нельзя, но можно удалить. В таком случае машина будет удалена из кластера (процесс удаления зависит от деталей реализации).
Когда требуется перезагрузка узлов?
Некоторые операции по изменению конфигурации узлов могут потребовать перезагрузки.
Перезагрузка узла может потребоваться при изменении некоторых настроек sysctl, например, при изменении параметра kernel.yama.ptrace_scope
(изменяется при использовании команды astra-ptrace-lock enable/disable
в Astra Linux).