Как добавить master-узлы в облачном кластере (single-master в multi-master)? | How do I add a master nodes to a cloud cluster (single-master to a multi-master)? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Инструкция в FAQ модуля control-plane-manager… | |||||||||||||||||||||||||||||||||||||||||||||||||||||
Как уменьшить число master-узлов в облачном кластере (multi-master в single-master)? | How do I reduce the number of master nodes in a cloud cluster (multi-master to single-master)? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Инструкция в FAQ модуля control-plane-manager… | |||||||||||||||||||||||||||||||||||||||||||||||||||||
Статические узлы | Static nodes | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Добавить статический узел в кластер можно вручную (пример) или с помощью Cluster API Provider Static. | 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)? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Чтобы добавить статический узел в кластер (сервер bare metal или виртуальную машину), выполните следующие шаги: | To add a static node to a cluster (bare metal server or virtual machine), follow these steps: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Пример добавления статического узла. | An example of adding a static node. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как добавить несколько статических узлов в кластер вручную? | How do I add a batch of static nodes to a cluster manually? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Используйте существующий или создайте новый custom resource NodeGroup (пример | Use an existing one or create a new NodeGroup custom resource (example of the | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Автоматизировать процесс добавления узлов можно с помощью любой платформы автоматизации. Далее приведен пример для Ansible. | You can automate the bootstrap process with any automation platform you prefer. The following is an example for 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Проверьте версию K8s. Если версия >= 1.25, создайте токен | Check the K8s version. If the version >= 1.25, create | ||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
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? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Можно ли удалить StaticInstance? | A | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| To delete a | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Чтобы удалить | How do I change the IP address of a StaticInstance? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как изменить IP-адрес StaticInstance? | You cannot change the IP address in the | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Изменить IP-адрес в ресурсе | How do I migrate a manually configured static node under CAPS control? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как мигрировать статический узел настроенный вручную под управление CAPS? | 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? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как изменить NodeGroup у статического узла? | Note that if a node is under CAPS control, you cannot change the | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| To switch an existing manually created static node to another | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Если узел находится под управлением CAPS, то изменить принадлежность к | shell
kubectl label node –overwrite | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Чтобы перенести существующий статический узел созданный вручную из одной | Applying the changes will take some time. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell
kubectl label node –overwrite | How to clean up a node for adding to the cluster? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Применение изменений потребует некоторого времени. | 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
kubectl drain | shell bash /var/lib/bashible/cleanup_static_node.sh –yes-i-am-sane-and-i-understand-what-i-am-doing | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell bash /var/lib/bashible/cleanup_static_node.sh –yes-i-am-sane-and-i-understand-what-i-am-doing | How do I know if something went wrong? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| If a node in a nodeGroup is not updated (the value of | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как понять, что что-то пошло не так? | To view the logs of the | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Если узел в NodeGroup не обновляется (значение | shell journalctl -fu bashible | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Чтобы посмотреть логи сервиса | Example of output when the | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell journalctl -fu bashible | 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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Пример вывода, когда все необходимые действия выполнены: | How do I know what is running on a node while it is being created? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
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. | You can analyze | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как посмотреть, что в данный момент выполняется на узле при его создании? |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Если необходимо узнать, что происходит на узле (к примеру, он долго создается), можно посмотреть логи
| shell kubectl get instances | grep Pending | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell kubectl get instances | grep Pending | An example: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Пример: | 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
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 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Для дистрибутивов, основанных на Debian | Create a | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Создайте ресурс | yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: install-kernel.sh spec: bundles:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: install-kernel.sh spec: bundles:
| desired_version=”5.15.0-53-generic” | ||||||||||||||||||||||||||||||||||||||||||||||||||||
desired_version=”5.15.0-53-generic” | 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 } | ||||||||||||||||||||||||||||||||||||||||||||||||||||
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 } | version_in_use=”$(uname -r)” | ||||||||||||||||||||||||||||||||||||||||||||||||||||
version_in_use=”$(uname -r)” | if [[ “$version_in_use” == “$desired_version” ]]; then exit 0 fi | ||||||||||||||||||||||||||||||||||||||||||||||||||||
if [[ “$version_in_use” == “$desired_version” ]]; then exit 0 fi | bb-deckhouse-get-disruptive-update-approval bb-apt-install “linux-image-${desired_version}” | ||||||||||||||||||||||||||||||||||||||||||||||||||||
bb-deckhouse-get-disruptive-update-approval bb-apt-install “linux-image-${desired_version}” | CentOS-based distros | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Для дистрибутивов, основанных на CentOS | Create a | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Создайте ресурс | yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: install-kernel.sh spec: bundles:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
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” | ||||||||||||||||||||||||||||||||||||||||||||||||||||
desired_version=”3.10.0-1160.42.2.el7.x86_64” | 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 } | ||||||||||||||||||||||||||||||||||||||||||||||||||||
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 } | version_in_use=”$(uname -r)” | ||||||||||||||||||||||||||||||||||||||||||||||||||||
version_in_use=”$(uname -r)” | if [[ “$version_in_use” == “$desired_version” ]]; then exit 0 fi | ||||||||||||||||||||||||||||||||||||||||||||||||||||
if [[ “$version_in_use” == “$desired_version” ]]; then exit 0 fi | bb-deckhouse-get-disruptive-update-approval bb-yum-install “kernel-${desired_version}” | ||||||||||||||||||||||||||||||||||||||||||||||||||||
bb-deckhouse-get-disruptive-update-approval bb-yum-install “kernel-${desired_version}” | NodeGroup parameters and their result | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Какие параметры NodeGroup к чему приводят? |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Refer to the description of the NodeGroup custom resource for more information about the parameters. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Подробно о всех параметрах можно прочитать в описании custom resource NodeGroup. | Changing the | ||||||||||||||||||||||||||||||||||||||||||||||||||||
В случае изменения параметров | 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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
При disruption update выполняется evict подов с узла. Если какие-либо поды не удалось evict’нуть, evict повторяется каждые 20 секунд до достижения глобального таймаута в 5 минут. После этого поды, которые не удалось evict’нуть, удаляются. | How do I redeploy ephemeral machines in the cloud with a new configuration? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как пересоздать эфемерные машины в облаке с новой конфигурацией? | 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
При изменении конфигурации Deckhouse (как в модуле | To force the redeployment of all Machines, you need to add/modify the | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Чтобы принудительно пересоздать все узлы, связанные с ресурсом | How do I allocate nodes to specific loads? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как выделить узлы под специфические нагрузки? |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
| There are two ways to solve this problem: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Для решений данной задачи существуют два механизма: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
| How to allocate nodes to system components? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Подробности в статье на Habr. | Frontend | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как выделить узлы под системные компоненты? | For Ingress controllers, use the | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Фронтенд | yaml nodeTemplate: labels: node-role.deckhouse.io/frontend: “” taints:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Для Ingress-контроллеров используйте | System components | ||||||||||||||||||||||||||||||||||||||||||||||||||||
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? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml nodeTemplate: labels: node-role.deckhouse.io/system: “” taints:
| 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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как ускорить заказ узлов в облаке при горизонтальном масштабировании приложений? | Here is how you should configure the target | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Самое действенное — держать в кластере некоторое количество подогретых узлов, которые позволят новым репликам ваших приложений запускаться мгновенно. Очевидным минусом данного решения будут дополнительные расходы на содержание этих узлов. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Необходимые настройки целевой | An example: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| yaml cloudInstances: maxPerZone: 10 minPerZone: 1 standby: 10% standbyHolder: notHeldResources: cpu: 300m memory: 2Gi | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Пример: | How do I disable machine-controller-manager in the case of potentially cluster-damaging changes? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml cloudInstances: maxPerZone: 10 minPerZone: 1 standby: 10% standbyHolder: notHeldResources: cpu: 300m memory: 2Gi |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как выключить machine-controller-manager в случае выполнения потенциально деструктивных изменений в кластере? | Set the | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| yaml mcmEmergencyBrake: true | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Установить параметр: | How do I restore the master node if kubelet cannot load the control plane components? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml mcmEmergencyBrake: true | 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как восстановить master-узел, если kubelet не может загрузить компоненты control plane? | Below is an instruction on how you can restore the master node. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Подобная ситуация может возникнуть, если в кластере с одним master-узлом на нем были удалены образы
компонентов control plane (например, удалена директория | containerd | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Ниже инструкция по восстановлению master-узла. | Execute the following command to restore the master node in any cluster running under Deckhouse: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
containerd | shell kubectl -n d8-system get secrets deckhouse-registry -o json | jq -r ‘.data.”.dockerconfigjson”’ | base64 -d | jq -r ‘.auths.”registry.deckhouse.io”.auth’ | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Для восстановления работоспособности master-узла нужно в любом рабочем кластере под управлением Deckhouse выполнить команду: | Copy the command’s output and use it for setting the AUTH variable on the corrupted master.
Next, you need to pull images of | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell kubectl -n d8-system get secrets deckhouse-registry -o json | jq -r ‘.data.”.dockerconfigjson”’ | base64 -d | jq -r ‘.auths.”registry.deckhouse.io”.auth’ | shell for image in $(grep “image:” /etc/kubernetes/manifests/* | awk ‘{print $3}’); do crictl pull –auth $AUTH $image done | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Вывод команды нужно скопировать и присвоить переменной AUTH на поврежденном master-узле.
Далее на поврежденном master-узле нужно загрузить образы компонентов | You need to restart | ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell for image in $(grep “image:” /etc/kubernetes/manifests/* | awk ‘{print $3}’); do crictl pull –auth $AUTH $image done | How to change CRI for NodeGroup? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
После загрузки образов необходимо перезапустить kubelet. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как изменить CRI для NodeGroup? | Set NodeGroup | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| NodeGroup YAML example: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Установить параметр cri.type в | yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: worker spec: nodeType: Static cri: type: Containerd | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Пример YAML-манифеста NodeGroup: | Also, this operation can be done with patch: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: worker spec: nodeType: Static cri: type: Containerd |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Также эту операцию можно выполнить с помощью патча: | shell
kubectl patch nodegroup | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell kubectl patch nodegroup <имя NodeGroup=""> --type merge -p '{"spec":{"cri":{"type":"Containerd"}}}'имя> | shell
kubectl patch nodegroup | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell kubectl patch nodegroup <имя NodeGroup=""> --type merge -p '{"spec":{"cri":{"type":"NotManaged"}}}'имя> | 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| How to change CRI for the whole cluster? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
После настройки нового CRI для NodeGroup модуль |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как изменить CRI для всего кластера? | It is necessary to use the | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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/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"}}” | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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"}}” |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Если необходимо какую-то NodeGroup оставить на другом CRI, перед изменением | When changing the CRI in the cluster, additional steps are required for the master nodes: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
При изменении CRI в кластере для master-узлов необходимо выполнить дополнительные шаги: | 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | shell
kubectl annotate node | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
shell kubectl annotate node <имя master-узла=""> update.node.deckhouse.io/disruption-approved=имя> | How to add node configuration step? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Additional node configuration steps are set via the NodeGroupConfiguration custom resource. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как добавить шаг для конфигурации узлов? | How to use containerd with Nvidia GPU support? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Дополнительные шаги для конфигурации узлов задаются с помощью custom resource NodeGroupConfiguration. | Create NodeGroup for GPU-nodes. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как использовать containerd с поддержкой Nvidia GPU? | yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: gpu spec: chaos: mode: Disabled disruptions: approvalMode: Automatic nodeType: CloudStatic | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Необходимо создать отдельную NodeGroup для GPU-нод. | Create NodeGroupConfiguration for containerd configuration of NodeGroup | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: gpu spec: chaos: mode: Disabled disruptions: approvalMode: Automatic nodeType: CloudStatic | yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: containerd-additional-config.sh spec: bundles:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Далее необходимо создать NodeGroupConfiguration для NodeGroup | 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: containerd-additional-config.sh spec: bundles:
| Create NodeGroupConfiguration for Nvidia drivers setup on NodeGroup | ||||||||||||||||||||||||||||||||||||||||||||||||||||
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:
| Ubuntu | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Далее необходимо добавить NodeGroupConfiguration для установки драйверов Nvidia для NodeGroup | yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: install-cuda.sh spec: bundles:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Ubuntu | 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 apt-get update apt-get install -y nvidia-container-toolkit nvidia-driver-525-server nodeGroups:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: install-cuda.sh spec: bundles:
| Centos | ||||||||||||||||||||||||||||||||||||||||||||||||||||
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 apt-get update apt-get install -y nvidia-container-toolkit nvidia-driver-525-server nodeGroups:
| yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: install-cuda.sh spec: bundles:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Centos | distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: install-cuda.sh spec: bundles:
| Bootstrap and reboot node. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
| How to check if it was successful? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
После этого выполните бутстрап и ребут узла. | 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:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Создайте в кластере Job: | And check the logs: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
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:
| 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 | +——————————-+———————-+———————-+ | ||||||||||||||||||||||||||||||||||||||||||||||||||||
И посмотрите логи: | +—————————————————————————–+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| | No running processes found | +—————————————————————————–+ | ||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | +——————————-+———————-+———————-+ | Deploy the Job: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
+—————————————————————————–+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| | No running processes found | +—————————————————————————–+ | 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:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Создайте в кластере Job: | And check the logs: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
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:
| 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 deploy custom containerd configuration? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | Bashible on nodes merges main deckhouse containerd config with configs from | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как развернуть кастомный конфиг containerd? | How to add additional registry auth? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Bashible на узлах мержит основной конфиг containerd для Deckhouse с конфигами из | Deploy | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как добавить авторизацию в дополнительный registry? | yamlapiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: containerd-additional-config.sh spec: bundles:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Разверните скрипт | 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:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
yamlapiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: containerd-additional-config.sh spec: bundles:
| How to use NodeGroup’s priority feature | ||||||||||||||||||||||||||||||||||||||||||||||||||||
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:
| The priority field of the | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как использовать NodeGroup с приоритетом? | Here is an example of creating two | ||||||||||||||||||||||||||||||||||||||||||||||||||||
С помощью параметра priority custom resource’а | 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Пример создания двух | In the above example, | ||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | Once the | ||||||||||||||||||||||||||||||||||||||||||||||||||||
В приведенном выше примере | Note that node templates (labels/taints) for | ||||||||||||||||||||||||||||||||||||||||||||||||||||
После того как NodeGroup | How to interpret Node Group states? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Шаблоны узлов (labels/taints) для NodeGroup | Ready — the node group contains the minimum required number of scheduled nodes with the status Ready for all zones. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как интерпретировать состояние группы узлов? | Example 1. A group of nodes in the | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Ready — группа узлов содержит минимально необходимое число запланированных узлов с состоянием Ready для всех зон. | yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: ng1 spec: nodeType: CloudEphemeral cloudInstances: maxPerZone: 5 minPerZone: 1 status: conditions:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Пример 1. Группа узлов в состоянии Ready: | Example 2. 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:
| yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: ng1 spec: nodeType: CloudEphemeral cloudInstances: maxPerZone: 5 minPerZone: 2 status: conditions:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Пример 2. Группа узлов в состоянии Not Ready: | 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). | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: ng1 spec: nodeType: CloudEphemeral cloudInstances: maxPerZone: 5 minPerZone: 2 status: conditions:
| 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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Updating — группа узлов содержит как минимум один узел, в котором присутствует аннотация с префиксом update.node.deckhouse.io (например, update.node.deckhouse.io/waiting-for-approval). | Scaling — calculated only for node groups with the type CloudEphemeral. The state True can be in two cases: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
WaitingForDisruptiveApproval — группа узлов содержит как минимум один узел, в котором присутствует аннотация update.node.deckhouse.io/disruption-required и отсутствует аннотация update.node.deckhouse.io/disruption-approved. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Scaling — рассчитывается только для групп узлов с типом CloudEphemeral. Состояние True может быть в двух случаях: | The desired number of nodes is the sum of all replicas in the node group. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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 … | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Пример. Желаемое число узлов равно 2: | Error — contains the last error that occurred when creating a node 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 … | How do I make werf ignore the Ready conditions in a node group? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Error — содержит последнюю ошибку, возникшую при создании узла в группе узлов. | werf checks the Ready status of resources and, if available, waits for the value to become True. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Как заставить werf игнорировать состояние Ready в группе узлов? | 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 у ресурсов и в случае его наличия дожидается, пока значение станет True. | yaml metadata: annotations: werf.io/fail-mode: IgnoreAndContinueDeployProcess werf.io/track-termination-mode: NonBlocking | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Создание (обновление) ресурса nodeGroup в кластере может потребовать значительного времени на развертывание необходимого количества узлов. При развертывании такого ресурса в кластере с помощью werf (например, в рамках процесса CI/CD) развертывание может завершиться по превышении времени ожидания готовности ресурса. Чтобы заставить werf игнорировать состояние | What is an Instance resource? | ||||||||||||||||||||||||||||||||||||||||||||||||||||
yaml metadata: annotations: werf.io/fail-mode: IgnoreAndContinueDeployProcess werf.io/track-termination-mode: NonBlocking | 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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Что такое ресурс Instance? | The object does not contain a specification. The status contains:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Ресурс Instance содержит описание объекта эфемерной машины, без учета ее конкретной реализации. Например, машины созданные MachineControllerManager или Cluster API Provider Static будут иметь соответcтвующий ресурс 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. Самостоятельно ресурс Instance создать нельзя, но можно удалить. В таком случае машина будет удалена из кластера (процесс удаления зависит от деталей реализации). | |||||||||||||||||||||||||||||||||||||||||||||||||||||