How do I add a master nodes to a cloud cluster (single-master to a multi-master)? | Как добавить master-узлы в облачном кластере (single-master в multi-master)? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Инструкция в FAQ модуля control-plane-manager… | |||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I reduce the number of master nodes in a cloud cluster (multi-master to single-master)? | Как уменьшить число master-узлов в облачном кластере (multi-master в single-master)? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Инструкция в FAQ модуля control-plane-manager… | |||||||||||||||||||||||||||||||||||||||||||||||||||||
Static nodes | Статические узлы | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
You can add a static node to the cluster manually (an example) or by using Cluster API Provider Static. | Добавить статический узел в кластер можно вручную (пример) или с помощью Cluster API Provider Static. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I add a static node to a cluster (Cluster API Provider Static)? | Как добавить статический узел в кластер (Cluster API Provider Static)? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
To add a static node to a cluster (bare metal server or virtual machine), follow these steps: | Чтобы добавить статический узел в кластер (сервер bare metal или виртуальную машину), выполните следующие шаги: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
An example of adding a static node. | Пример добавления статического узла. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I add a batch of static nodes to a cluster manually? | Как добавить несколько статических узлов в кластер вручную? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Use an existing one or create a new NodeGroup custom resource (example of the | Используйте существующий или создайте новый custom resource NodeGroup (пример | ||||||||||||||||||||||||||||||||||||||||||||||||||||
You can automate the bootstrap process with any automation platform you prefer. The following is an example for Ansible. | Автоматизировать процесс добавления узлов можно с помощью любой платформы автоматизации. Далее приведен пример для Ansible. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell kubectl -n default get ep kubernetes -o json | jq ‘.subsets[0].addresses[0].ip + “:” + (.subsets[0].ports[0].port | tostring)’ -r | shell kubectl -n default get ep kubernetes -o json | jq ‘.subsets[0].addresses[0].ip + “:” + (.subsets[0].ports[0].port | tostring)’ -r | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Check the K8s version. If the version >= 1.25, create | Проверьте версию K8s. Если версия >= 1.25, создайте токен | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell kubectl create token node-group –namespace d8-cloud-instance-manager –duration 1h | shell kubectl create token node-group –namespace d8-cloud-instance-manager –duration 1h | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Save the token you got and add it to the | Сохраните полученный токен, и добавьте в поле | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell
kubectl -n d8-cloud-instance-manager get $(kubectl -n d8-cloud-instance-manager get secret -o name | grep node-group-token) | shell
kubectl -n d8-cloud-instance-manager get $(kubectl -n d8-cloud-instance-manager get secret -o name | grep node-group-token) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml
| yaml
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
text [system] system-0 system-1 | text [system] system-0 system-1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
[system:vars] node_group=system | [system:vars] node_group=system | ||||||||||||||||||||||||||||||||||||||||||||||||||||
[worker] worker-0 worker-1 | [worker] worker-0 worker-1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
[worker:vars] node_group=worker | [worker:vars] node_group=worker | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I clean up a static node manually? | Как вручную очистить статический узел? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
To decommission a node from the cluster and clean up the server (VM), run the following command on the node: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell bash /var/lib/bashible/cleanup_static_node.sh –yes-i-am-sane-and-i-understand-what-i-am-doing | Чтобы вывести из кластера узел и очистить сервер (ВМ), выполните следующую команду на узле: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Can I delete a StaticInstance? | shell bash /var/lib/bashible/cleanup_static_node.sh –yes-i-am-sane-and-i-understand-what-i-am-doing | ||||||||||||||||||||||||||||||||||||||||||||||||||||
A | Можно ли удалить StaticInstance? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
To delete a
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I change the IP address of a StaticInstance? | Чтобы удалить
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
You cannot change the IP address in the | Как изменить IP-адрес StaticInstance? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I migrate a manually configured static node under CAPS control? | Изменить IP-адрес в ресурсе | ||||||||||||||||||||||||||||||||||||||||||||||||||||
You need to clean up the node, then hand over the node under CAPS control. | Как мигрировать статический узел настроенный вручную под управление CAPS? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I change the NodeGroup of a static node? | Необходимо выполнить очистку узла, затем добавить узел под управление CAPS. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Note that if a node is under CAPS control, you cannot change the | Как изменить NodeGroup у статического узла? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
To switch an existing manually created static node to another |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell
kubectl label node –overwrite | Если узел находится под управлением CAPS, то изменить принадлежность к | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Applying the changes will take some time. | Чтобы перенести существующий статический узел созданный вручную из одной | ||||||||||||||||||||||||||||||||||||||||||||||||||||
How to clean up a node for adding to the cluster? | shell
kubectl label node –overwrite | ||||||||||||||||||||||||||||||||||||||||||||||||||||
This is only needed if you have to move a static node from one cluster to another. Be aware these operations remove local storage data. If you just need to change a NodeGroup, follow this instruction. | Применение изменений потребует некоторого времени. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Как зачистить узел для последующего ввода в кластер? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Это необходимо только в том случае, если нужно переместить статический узел из одного кластера в другой. Имейте в виду, что эти операции удаляют данные локального хранилища. Если необходимо просто изменить | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell
kubectl drain |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell bash /var/lib/bashible/cleanup_static_node.sh –yes-i-am-sane-and-i-understand-what-i-am-doing | shell
kubectl drain | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I know if something went wrong? | shell bash /var/lib/bashible/cleanup_static_node.sh –yes-i-am-sane-and-i-understand-what-i-am-doing | ||||||||||||||||||||||||||||||||||||||||||||||||||||
If a node in a nodeGroup is not updated (the value of |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
To view the logs of the | Как понять, что что-то пошло не так? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell journalctl -fu bashible | Если узел в NodeGroup не обновляется (значение | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Example of output when the | Чтобы посмотреть логи сервиса | ||||||||||||||||||||||||||||||||||||||||||||||||||||
console May 25 04:39:16 kube-master-0 systemd[1]: Started Bashible service. May 25 04:39:16 kube-master-0 bashible.sh[1976339]: Configuration is in sync, nothing to do. May 25 04:39:16 kube-master-0 systemd[1]: bashible.service: Succeeded. | shell journalctl -fu bashible | ||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I know what is running on a node while it is being created? | Пример вывода, когда все необходимые действия выполнены: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
You can analyze | console May 25 04:39:16 kube-master-0 systemd[1]: Started Bashible service. May 25 04:39:16 kube-master-0 bashible.sh[1976339]: Configuration is in sync, nothing to do. May 25 04:39:16 kube-master-0 systemd[1]: bashible.service: Succeeded. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Как посмотреть, что в данный момент выполняется на узле при его создании? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell kubectl get instances | grep Pending | Если необходимо узнать, что происходит на узле (к примеру, он долго создается), можно посмотреть логи
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
An example: | shell kubectl get instances | grep Pending | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell $ kubectl get instances | grep Pending dev-worker-2a6158ff-6764d-nrtbj Pending 46s | Пример: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| shell $ kubectl get instances | grep Pending dev-worker-2a6158ff-6764d-nrtbj Pending 46s | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell kubectl get instances dev-worker-2a6158ff-6764d-nrtbj -o yaml | grep ‘bootstrapStatus’ -B0 -A2 |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
An example: | shell kubectl get instances dev-worker-2a6158ff-6764d-nrtbj -o yaml | grep ‘bootstrapStatus’ -B0 -A2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell $ kubectl get instances dev-worker-2a6158ff-6764d-nrtbj -o yaml | grep ‘bootstrapStatus’ -B0 -A2 bootstrapStatus: description: Use ‘nc 192.168.199.178 8000’ to get bootstrap logs. logsEndpoint: 192.168.199.178:8000 | Пример: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| shell $ kubectl get instances dev-worker-2a6158ff-6764d-nrtbj -o yaml | grep ‘bootstrapStatus’ -B0 -A2 bootstrapStatus: description: Use ‘nc 192.168.199.178 8000’ to get bootstrap logs. logsEndpoint: 192.168.199.178:8000 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
The logs of the initial node configuration are located at |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I update kernel on nodes? | Логи первоначальной настройки узла находятся в | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Debian-based distros | Как обновить ядро на узлах? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Create a | Для дистрибутивов, основанных на Debian | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: install-kernel.sh spec: bundles:
| Создайте ресурс | ||||||||||||||||||||||||||||||||||||||||||||||||||||
desired_version=”5.15.0-53-generic” | yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: install-kernel.sh spec: bundles:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
bb-event-on ‘bb-package-installed’ ‘post-install’ post-install() { bb-log-info “Setting reboot flag due to kernel was updated” bb-flag-set reboot } | desired_version=”5.15.0-53-generic” | ||||||||||||||||||||||||||||||||||||||||||||||||||||
version_in_use=”$(uname -r)” | bb-event-on ‘bb-package-installed’ ‘post-install’ post-install() { bb-log-info “Setting reboot flag due to kernel was updated” bb-flag-set reboot } | ||||||||||||||||||||||||||||||||||||||||||||||||||||
if [[ “$version_in_use” == “$desired_version” ]]; then exit 0 fi | version_in_use=”$(uname -r)” | ||||||||||||||||||||||||||||||||||||||||||||||||||||
bb-deckhouse-get-disruptive-update-approval bb-apt-install “linux-image-${desired_version}” | if [[ “$version_in_use” == “$desired_version” ]]; then exit 0 fi | ||||||||||||||||||||||||||||||||||||||||||||||||||||
CentOS-based distros | bb-deckhouse-get-disruptive-update-approval bb-apt-install “linux-image-${desired_version}” | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Create a | Для дистрибутивов, основанных на CentOS | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: install-kernel.sh spec: bundles:
| Создайте ресурс | ||||||||||||||||||||||||||||||||||||||||||||||||||||
desired_version=”3.10.0-1160.42.2.el7.x86_64” | yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: install-kernel.sh spec: bundles:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
bb-event-on ‘bb-package-installed’ ‘post-install’ post-install() { bb-log-info “Setting reboot flag due to kernel was updated” bb-flag-set reboot } | desired_version=”3.10.0-1160.42.2.el7.x86_64” | ||||||||||||||||||||||||||||||||||||||||||||||||||||
version_in_use=”$(uname -r)” | bb-event-on ‘bb-package-installed’ ‘post-install’ post-install() { bb-log-info “Setting reboot flag due to kernel was updated” bb-flag-set reboot } | ||||||||||||||||||||||||||||||||||||||||||||||||||||
if [[ “$version_in_use” == “$desired_version” ]]; then exit 0 fi | version_in_use=”$(uname -r)” | ||||||||||||||||||||||||||||||||||||||||||||||||||||
bb-deckhouse-get-disruptive-update-approval bb-yum-install “kernel-${desired_version}” | if [[ “$version_in_use” == “$desired_version” ]]; then exit 0 fi | ||||||||||||||||||||||||||||||||||||||||||||||||||||
NodeGroup parameters and their result | bb-deckhouse-get-disruptive-update-approval bb-yum-install “kernel-${desired_version}” | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Какие параметры NodeGroup к чему приводят? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Refer to the description of the NodeGroup custom resource for more information about the parameters. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Changing the | Подробно о всех параметрах можно прочитать в описании custom resource NodeGroup. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
During the disruption update, an evict of the pods from the node is performed. If any pod failes to evict, the evict is repeated every 20 seconds until a global timeout of 5 minutes is reached. After that, the pods that failed to evict are removed. | В случае изменения параметров | ||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I redeploy ephemeral machines in the cloud with a new configuration? | При disruption update выполняется evict подов с узла. Если какие-либо поды не удалось evict’нуть, evict повторяется каждые 20 секунд до достижения глобального таймаута в 5 минут. После этого поды, которые не удалось evict’нуть, удаляются. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
If the Deckhouse configuration is changed (both in the node-manager module and in any of the cloud providers), the VMs will not be redeployed. The redeployment is performed only in response to changing | Как пересоздать эфемерные машины в облаке с новой конфигурацией? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
To force the redeployment of all Machines, you need to add/modify the | При изменении конфигурации Deckhouse (как в модуле | ||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I allocate nodes to specific loads? | Чтобы принудительно пересоздать все узлы, связанные с ресурсом | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Как выделить узлы под специфические нагрузки? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
There are two ways to solve this problem: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Для решений данной задачи существуют два механизма: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
How to allocate nodes to system components? |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Frontend | Подробности в статье на Habr. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
For Ingress controllers, use the | Как выделить узлы под системные компоненты? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml nodeTemplate: labels: node-role.deckhouse.io/frontend: “” taints:
| Фронтенд | ||||||||||||||||||||||||||||||||||||||||||||||||||||
System components | Для Ingress-контроллеров используйте | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| yaml nodeTemplate: labels: node-role.deckhouse.io/frontend: “” taints:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml nodeTemplate: labels: node-role.deckhouse.io/system: “” taints:
| Системные | ||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I speed up node provisioning on the cloud when scaling applications horizontally? |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
The most efficient way is to have some extra nodes “ready”. In this case, you can run new application replicas on them almost instantaneously. The obvious disadvantage of this approach is the additional maintenance costs related to these nodes. | yaml nodeTemplate: labels: node-role.deckhouse.io/system: “” taints:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Here is how you should configure the target | Как ускорить заказ узлов в облаке при горизонтальном масштабировании приложений? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Самое действенное — держать в кластере некоторое количество подогретых узлов, которые позволят новым репликам ваших приложений запускаться мгновенно. Очевидным минусом данного решения будут дополнительные расходы на содержание этих узлов. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
An example: | Необходимые настройки целевой | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml cloudInstances: maxPerZone: 10 minPerZone: 1 standby: 10% standbyHolder: overprovisioningRate: 30% |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I disable machine-controller-manager in the case of potentially cluster-damaging changes? | Пример: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| yaml cloudInstances: maxPerZone: 10 minPerZone: 1 standby: 10% standbyHolder: overprovisioningRate: 30% | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Set the | Как выключить machine-controller-manager в случае выполнения потенциально деструктивных изменений в кластере? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml mcmEmergencyBrake: true |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I restore the master node if kubelet cannot load the control plane components? | Установить параметр: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Such a situation may occur if images of the control plane components on the master were deleted in a cluster that has a single master node (e.g., the directory | yaml mcmEmergencyBrake: true | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Below is an instruction on how you can restore the master node. | Как восстановить master-узел, если kubelet не может загрузить компоненты control plane? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
containerd | Подобная ситуация может возникнуть, если в кластере с одним master-узлом на нем были удалены образы
компонентов control plane (например, удалена директория | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Execute the following command to restore the master node in any cluster running under Deckhouse: | Ниже инструкция по восстановлению master-узла. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell kubectl -n d8-system get secrets deckhouse-registry -o json | jq -r ‘.data.”.dockerconfigjson”’ | base64 -d | jq -r ‘.auths.”registry.deckhouse.io”.auth’ | containerd | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Copy the command’s output and use it for setting the AUTH variable on the corrupted master.
Next, you need to pull images of | Для восстановления работоспособности master-узла нужно в любом рабочем кластере под управлением Deckhouse выполнить команду: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell for image in $(grep “image:” /etc/kubernetes/manifests/* | awk ‘{print $3}’); do crictl pull –auth $AUTH $image done | shell kubectl -n d8-system get secrets deckhouse-registry -o json | jq -r ‘.data.”.dockerconfigjson”’ | base64 -d | jq -r ‘.auths.”registry.deckhouse.io”.auth’ | ||||||||||||||||||||||||||||||||||||||||||||||||||||
You need to restart | Вывод команды нужно скопировать и присвоить переменной AUTH на поврежденном master-узле.
Далее на поврежденном master-узле нужно загрузить образы компонентов | ||||||||||||||||||||||||||||||||||||||||||||||||||||
How to change CRI for NodeGroup? | shell for image in $(grep “image:” /etc/kubernetes/manifests/* | awk ‘{print $3}’); do crictl pull –auth $AUTH $image done | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| После загрузки образов необходимо перезапустить kubelet. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Set NodeGroup | Как изменить CRI для NodeGroup? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
NodeGroup YAML example: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: worker spec: nodeType: Static cri: type: Containerd | Установить параметр cri.type в | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Also, this operation can be done with patch: | Пример YAML-манифеста NodeGroup: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: worker spec: nodeType: Static cri: type: Containerd | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell
kubectl patch nodegroup | Также эту операцию можно выполнить с помощью патча: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell
kubectl patch nodegroup | shell kubectl patch nodegroup <имя NodeGroup=""> --type merge -p '{"spec":{"cri":{"type":"Containerd"}}}'имя> | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
After setting up a new CRI for NodeGroup, the node-manager module drains nodes one by one and installs a new CRI on them. Node update
is accompanied by downtime (disruption). Depending on the | shell kubectl patch nodegroup <имя NodeGroup=""> --type merge -p '{"spec":{"cri":{"type":"NotManaged"}}}'имя> | ||||||||||||||||||||||||||||||||||||||||||||||||||||
How to change CRI for the whole cluster? |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
| После настройки нового CRI для NodeGroup модуль | ||||||||||||||||||||||||||||||||||||||||||||||||||||
It is necessary to use the | Как изменить CRI для всего кластера? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Also, this operation can be done with the following patch:
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell data=”$(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)” kubectl -n kube-system patch secret d8-cluster-configuration -p “{"data":{"cluster-configuration.yaml":"$data"}}” | Необходимо с помощью утилиты | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Также возможно выполнить эту операцию с помощью
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell data=”$(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)” kubectl -n kube-system patch secret d8-cluster-configuration -p “{"data":{"cluster-configuration.yaml":"$data"}}” | shell data=”$(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)” kubectl -n kube-system patch secret d8-cluster-configuration -p “{"data":{"cluster-configuration.yaml":"$data"}}” | ||||||||||||||||||||||||||||||||||||||||||||||||||||
If it is necessary to leave some NodeGroup on another CRI, then before changing the |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
| shell data=”$(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)” kubectl -n kube-system patch secret d8-cluster-configuration -p “{"data":{"cluster-configuration.yaml":"$data"}}” | ||||||||||||||||||||||||||||||||||||||||||||||||||||
When changing the CRI in the cluster, additional steps are required for the master nodes: | Если необходимо какую-то NodeGroup оставить на другом CRI, перед изменением | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell kubectl get nodes -l node-role.kubernetes.io/control-plane=”” -o json | jq ‘.items[] | select(.metadata.annotations.”update.node.deckhouse.io/approved”==””) | .metadata.name’ -r | При изменении CRI в кластере для master-узлов необходимо выполнить дополнительные шаги: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell
kubectl annotate node | shell kubectl get nodes -l node-role.kubernetes.io/control-plane=”” -o json | jq ‘.items[] | select(.metadata.annotations.”update.node.deckhouse.io/approved”==””) | .metadata.name’ -r | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
How to add node configuration step? | shell kubectl annotate node <имя master-узла=""> update.node.deckhouse.io/disruption-approved=имя> | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Additional node configuration steps are set via the NodeGroupConfiguration custom resource. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
How to use containerd with Nvidia GPU support? | Как добавить шаг для конфигурации узлов? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Create NodeGroup for GPU-nodes. | Дополнительные шаги для конфигурации узлов задаются с помощью custom resource NodeGroupConfiguration. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: gpu spec: chaos: mode: Disabled disruptions: approvalMode: Automatic nodeType: CloudStatic | Как использовать containerd с поддержкой Nvidia GPU? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Create NodeGroupConfiguration for containerd configuration of NodeGroup | Необходимо создать отдельную NodeGroup для GPU-нод. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: containerd-additional-config.sh spec: bundles:
| yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: gpu spec: chaos: mode: Disabled disruptions: approvalMode: Automatic nodeType: CloudStatic | ||||||||||||||||||||||||||||||||||||||||||||||||||||
mkdir -p /etc/containerd/conf.d bb-sync-file /etc/containerd/conf.d/nvidia_gpu.toml - « “EOF” [plugins] [plugins.”io.containerd.grpc.v1.cri”] [plugins.”io.containerd.grpc.v1.cri”.containerd] default_runtime_name = “nvidia” [plugins.”io.containerd.grpc.v1.cri”.containerd.runtimes] [plugins.”io.containerd.grpc.v1.cri”.containerd.runtimes.runc] [plugins.”io.containerd.grpc.v1.cri”.containerd.runtimes.nvidia] privileged_without_host_devices = false runtime_engine = “” runtime_root = “” runtime_type = “io.containerd.runc.v1” [plugins.”io.containerd.grpc.v1.cri”.containerd.runtimes.nvidia.options] BinaryName = “/usr/bin/nvidia-container-runtime” SystemdCgroup = false EOF nodeGroups:
| Далее необходимо создать NodeGroupConfiguration для NodeGroup | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Create NodeGroupConfiguration for Nvidia drivers setup on NodeGroup | yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: containerd-additional-config.sh spec: bundles:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Ubuntu | mkdir -p /etc/containerd/conf.d bb-sync-file /etc/containerd/conf.d/nvidia_gpu.toml - « “EOF” [plugins] [plugins.”io.containerd.grpc.v1.cri”] [plugins.”io.containerd.grpc.v1.cri”.containerd] default_runtime_name = “nvidia” [plugins.”io.containerd.grpc.v1.cri”.containerd.runtimes] [plugins.”io.containerd.grpc.v1.cri”.containerd.runtimes.runc] [plugins.”io.containerd.grpc.v1.cri”.containerd.runtimes.nvidia] privileged_without_host_devices = false runtime_engine = “” runtime_root = “” runtime_type = “io.containerd.runc.v1” [plugins.”io.containerd.grpc.v1.cri”.containerd.runtimes.nvidia.options] BinaryName = “/usr/bin/nvidia-container-runtime” SystemdCgroup = false EOF nodeGroups:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: install-cuda.sh spec: bundles:
| Далее необходимо добавить NodeGroupConfiguration для установки драйверов Nvidia для NodeGroup | ||||||||||||||||||||||||||||||||||||||||||||||||||||
if [ ! -f “/etc/apt/sources.list.d/nvidia-container-toolkit.list” ]; then distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list fi bb-apt-install nvidia-container-toolkit nvidia-driver-535-server nodeGroups:
| Ubuntu | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Centos | yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: install-cuda.sh spec: bundles:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: install-cuda.sh spec: bundles:
| if [ ! -f “/etc/apt/sources.list.d/nvidia-container-toolkit.list” ]; then distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list fi bb-apt-install nvidia-container-toolkit nvidia-driver-535-server nodeGroups:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
if [ ! -f “/etc/yum.repos.d/nvidia-container-toolkit.repo” ]; then
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
| Centos | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Bootstrap and reboot node. | yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: install-cuda.sh spec: bundles:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
How to check if it was successful? | if [ ! -f “/etc/yum.repos.d/nvidia-container-toolkit.repo” ]; then
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Deploy the Job: | После этого выполните бутстрап и ребут узла. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: batch/v1 kind: Job metadata: name: nvidia-cuda-test namespace: default spec: completions: 1 template: spec: restartPolicy: Never nodeSelector: node.deckhouse.io/group: gpu containers:
| Как проверить, что все прошло успешно? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
And check the logs: | Создайте в кластере Job: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell $ kubectl logs job/nvidia-cuda-test Tue Jan 24 11:36:18 2023 +—————————————————————————–+ | NVIDIA-SMI 525.60.13 Driver Version: 525.60.13 CUDA Version: 12.0 | |——————————-+———————-+———————-+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 Tesla T4 Off | 00000000:8B:00.0 Off | 0 | | N/A 45C P0 25W / 70W | 0MiB / 15360MiB | 0% Default | | | | N/A | +——————————-+———————-+———————-+ | yaml apiVersion: batch/v1 kind: Job metadata: name: nvidia-cuda-test namespace: default spec: completions: 1 template: spec: restartPolicy: Never nodeSelector: node.deckhouse.io/group: gpu containers:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
+—————————————————————————–+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| | No running processes found | +—————————————————————————–+ | И посмотрите логи: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Deploy the Job: | shell $ kubectl logs job/nvidia-cuda-test Tue Jan 24 11:36:18 2023 +—————————————————————————–+ | NVIDIA-SMI 525.60.13 Driver Version: 525.60.13 CUDA Version: 12.0 | |——————————-+———————-+———————-+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 Tesla T4 Off | 00000000:8B:00.0 Off | 0 | | N/A 45C P0 25W / 70W | 0MiB / 15360MiB | 0% Default | | | | N/A | +——————————-+———————-+———————-+ | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: batch/v1 kind: Job metadata: name: gpu-operator-test namespace: default spec: completions: 1 template: spec: restartPolicy: Never nodeSelector: node.deckhouse.io/group: gpu containers:
| +—————————————————————————–+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| | No running processes found | +—————————————————————————–+ | ||||||||||||||||||||||||||||||||||||||||||||||||||||
And check the logs: | Создайте в кластере Job: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell $ kubectl logs job/gpu-operator-test [Vector addition of 50000 elements] Copy input data from the host memory to the CUDA device CUDA kernel launch with 196 blocks of 256 threads Copy output data from the CUDA device to the host memory Test PASSED Done | yaml apiVersion: batch/v1 kind: Job metadata: name: gpu-operator-test namespace: default spec: completions: 1 template: spec: restartPolicy: Never nodeSelector: node.deckhouse.io/group: gpu containers:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
How to deploy custom containerd configuration? | И посмотрите логи: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Bashible on nodes merges main deckhouse containerd config with configs from | shell $ kubectl logs job/gpu-operator-test [Vector addition of 50000 elements] Copy input data from the host memory to the CUDA device CUDA kernel launch with 196 blocks of 256 threads Copy output data from the CUDA device to the host memory Test PASSED Done | ||||||||||||||||||||||||||||||||||||||||||||||||||||
How to add additional registry auth? | Как развернуть кастомный конфиг containerd? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Deploy | Bashible на узлах мержит основной конфиг containerd для Deckhouse с конфигами из | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yamlapiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: containerd-additional-config.sh spec: bundles:
| Как добавить авторизацию в дополнительный registry? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
mkdir -p /etc/containerd/conf.d bb-sync-file /etc/containerd/conf.d/additional_registry.toml - « “EOF” [plugins] [plugins.”io.containerd.grpc.v1.cri”] [plugins.”io.containerd.grpc.v1.cri”.registry] [plugins.”io.containerd.grpc.v1.cri”.registry.mirrors] [plugins.”io.containerd.grpc.v1.cri”.registry.mirrors.”docker.io”] endpoint = [“https://registry-1.docker.io”] [plugins.”io.containerd.grpc.v1.cri”.registry.mirrors.”artifactory.proxy”] endpoint = [“https://artifactory.proxy”] [plugins.”io.containerd.grpc.v1.cri”.registry.configs] [plugins.”io.containerd.grpc.v1.cri”.registry.configs.”artifactory.proxy”.auth] auth = “AAAABBBCCCDDD==” EOF nodeGroups:
| Разверните скрипт | ||||||||||||||||||||||||||||||||||||||||||||||||||||
How to use NodeGroup’s priority feature | yamlapiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: containerd-additional-config.sh spec: bundles:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
The priority field of the | mkdir -p /etc/containerd/conf.d bb-sync-file /etc/containerd/conf.d/additional_registry.toml - « “EOF” [plugins] [plugins.”io.containerd.grpc.v1.cri”] [plugins.”io.containerd.grpc.v1.cri”.registry] [plugins.”io.containerd.grpc.v1.cri”.registry.mirrors] [plugins.”io.containerd.grpc.v1.cri”.registry.mirrors.”docker.io”] endpoint = [“https://registry-1.docker.io”] [plugins.”io.containerd.grpc.v1.cri”.registry.mirrors.”artifactory.proxy”] endpoint = [“https://artifactory.proxy”] [plugins.”io.containerd.grpc.v1.cri”.registry.configs] [plugins.”io.containerd.grpc.v1.cri”.registry.configs.”artifactory.proxy”.auth] auth = “AAAABBBCCCDDD==” EOF nodeGroups:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Here is an example of creating two | Как использовать NodeGroup с приоритетом? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yamlapiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: worker-spot spec: cloudInstances: classReference: kind: AWSInstanceClass name: worker-spot maxPerZone: 5 minPerZone: 0 priority: 50 nodeType: CloudEphemeral — apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: worker spec: cloudInstances: classReference: kind: AWSInstanceClass name: worker maxPerZone: 5 minPerZone: 0 priority: 30 nodeType: CloudEphemeral | С помощью параметра priority custom resource’а | ||||||||||||||||||||||||||||||||||||||||||||||||||||
In the above example, | Пример создания двух | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Once the | yamlapiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: worker-spot spec: cloudInstances: classReference: kind: AWSInstanceClass name: worker-spot maxPerZone: 5 minPerZone: 0 priority: 50 nodeType: CloudEphemeral — apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: worker spec: cloudInstances: classReference: kind: AWSInstanceClass name: worker maxPerZone: 5 minPerZone: 0 priority: 30 nodeType: CloudEphemeral | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Note that node templates (labels/taints) for | В приведенном выше примере | ||||||||||||||||||||||||||||||||||||||||||||||||||||
How to interpret Node Group states? | После того как NodeGroup | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Ready — the node group contains the minimum required number of scheduled nodes with the status Ready for all zones. | Шаблоны узлов (labels/taints) для NodeGroup | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Example 1. A group of nodes in the | Как интерпретировать состояние группы узлов? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: ng1 spec: nodeType: CloudEphemeral cloudInstances: maxPerZone: 5 minPerZone: 1 status: conditions:
| Ready — группа узлов содержит минимально необходимое число запланированных узлов с состоянием Ready для всех зон. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Example 2. A group of nodes in the | Пример 1. Группа узлов в состоянии Ready: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: ng1 spec: nodeType: CloudEphemeral cloudInstances: maxPerZone: 5 minPerZone: 2 status: conditions:
| yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: ng1 spec: nodeType: CloudEphemeral cloudInstances: maxPerZone: 5 minPerZone: 1 status: conditions:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Updating — a node group contains at least one node in which there is an annotation with the prefix update.node.deckhouse.io (for example, update.node.deckhouse.io/waiting-for-approval). | Пример 2. Группа узлов в состоянии Not Ready: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
WaitingForDisruptiveApproval - a node group contains at least one node that has an annotation update.node.deckhouse.io/disruption-required and there is no annotation update.node.deckhouse.io/disruption-approved. | yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: ng1 spec: nodeType: CloudEphemeral cloudInstances: maxPerZone: 5 minPerZone: 2 status: conditions:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Scaling — calculated only for node groups with the type CloudEphemeral. The state True can be in two cases: | 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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
The desired number of nodes is the sum of all replicas in the node group. | Scaling — рассчитывается только для групп узлов с типом CloudEphemeral. Состояние True может быть в двух случаях: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Example. The desired number of nodes is 2: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: ng1 spec: nodeType: CloudEphemeral cloudInstances: maxPerZone: 5 minPerZone: 2 status: … desired: 2 … | Желаемое число узлов — это сумма всех реплик, входящих в группу узлов. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Error — contains the last error that occurred when creating a node in a node group. | Пример. Желаемое число узлов равно 2: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
How do I make werf ignore the Ready conditions in a node group? | yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: ng1 spec: nodeType: CloudEphemeral cloudInstances: maxPerZone: 5 minPerZone: 2 status: … desired: 2 … | ||||||||||||||||||||||||||||||||||||||||||||||||||||
werf checks the Ready status of resources and, if available, waits for the value to become True. | Error — содержит последнюю ошибку, возникшую при создании узла в группе узлов. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Creating (updating) a nodeGroup resource in a cluster can take a significant amount of time to create the required number of nodes. When deploying such a resource in a cluster using werf (e.g., as part of a CI/CD process), deployment may terminate when resource readiness timeout is exceeded. To make werf ignore the nodeGroup status, the following | Как заставить werf игнорировать состояние Ready в группе узлов? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml metadata: annotations: werf.io/fail-mode: IgnoreAndContinueDeployProcess werf.io/track-termination-mode: NonBlocking | werf проверяет состояние Ready у ресурсов и в случае его наличия дожидается, пока значение станет True. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
What is an Instance resource? | Создание (обновление) ресурса nodeGroup в кластере может потребовать значительного времени на развертывание необходимого количества узлов. При развертывании такого ресурса в кластере с помощью werf (например, в рамках процесса CI/CD) развертывание может завершиться по превышении времени ожидания готовности ресурса. Чтобы заставить werf игнорировать состояние | ||||||||||||||||||||||||||||||||||||||||||||||||||||
An Instance resource contains a description of an implementation-independent ephemeral machine resource. For example, machines created by MachineControllerManager or Cluster API Provider Static will have a corresponding Instance resource. | yaml metadata: annotations: werf.io/fail-mode: IgnoreAndContinueDeployProcess werf.io/track-termination-mode: NonBlocking | ||||||||||||||||||||||||||||||||||||||||||||||||||||
The object does not contain a specification. The status contains:
| Что такое ресурс Instance? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
When a machine is created/deleted, the Instance object is created/deleted accordingly. You cannot create an Instance resource yourself, but you can delete it. In this case, the machine will be removed from the cluster (the removal process depends on implementation details. | Ресурс Instance содержит описание объекта эфемерной машины, без учета ее конкретной реализации. Например, машины созданные MachineControllerManager или Cluster API Provider Static будут иметь соответcтвующий ресурс Instance. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Объект не содержит спецификации. Статус содержит:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
When is a node reboot required? | При создании/удалении машины создается/удаляется соответствующий объект Instance. Самостоятельно ресурс Instance создать нельзя, но можно удалить. В таком случае машина будет удалена из кластера (процесс удаления зависит от деталей реализации). | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Node reboots may be required after configuration changes. For example, after changing certain sysctl settings, specifically when modifying the | |||||||||||||||||||||||||||||||||||||||||||||||||||||
Когда требуется перезагрузка узлов? | |||||||||||||||||||||||||||||||||||||||||||||||||||||
Некоторые операции по изменению конфигурации узлов могут потребовать перезагрузки. | |||||||||||||||||||||||||||||||||||||||||||||||||||||
Перезагрузка узла может потребоваться при изменении некоторых настроек sysctl, например, при изменении параметра |