Below are some examples of NodeGroup description, as well as installing the cert-manager plugin for kubectl and setting the sysctl parameter.

Ниже представлены несколько примеров описания NodeGroup, а также установки плагина cert-manager для kubectl и задания параметра sysctl.

Examples of the NodeGroup configuration

Примеры описания NodeGroup

Cloud nodes

Облачные узлы

Static nodes

Статические узлы

Use nodeType: Static for physical servers and VMs on Hypervisors.

Для виртуальных машин на гипервизорах или физических серверов используйте статические узлы, указав nodeType: Static в NodeGroup.

An example:

Пример:

Adding nodes to such a group is done manually using the pre-made scripts.

Узлы в такую группу добавляются вручную с помощью подготовленных скриптов.

You can also use a method that adds static nodes using the Cluster API Provider Static.

Также можно использовать способ добавления статических узлов с помощью Cluster API Provider Static.

System nodes

Системные узлы

Below is an example of a system node group manifest.

Ниже представлен пример манифеста группы системных узлов.

When describing a NodeGroup with Static nodes, specify the value Static in the nodeType field and use the staticInstances field to describe the parameters for provisioning static machines to the cluster.

При описании NodeGroup c узлами типа Static в поле nodeType укажите значение Static и используйте поле staticInstances для описания параметров настройки машин статических узлов.

When describing a NodeGroup with CloudEphemeral type cloud nodes, specify the value CloudEphemeral in the nodeType field and use the cloudInstances field to describe the parameters for provisioning the cloud-based VMs.

При описании NodeGroup c облачными узлами типа CloudEphemeral в поле nodeType укажите значение CloudEphemeral и используйте поле cloudInstances для описания параметров заказа облачных виртуальных машин.

yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: system spec: nodeTemplate: labels: node-role.deckhouse.io/system: “” taints:

• effect: NoExecute key: dedicated.deckhouse.io value: system Example for Static nodes nodeType: Static staticInstances: count: 2 labelSelector: matchLabels: role: system Example for CloudEphemeral nodes nodeType: CloudEphemeral cloudInstances: classReference: kind: YandexInstanceClass name: large maxPerZone: 2 minPerZone: 1 zones:
  • ru-central1-d

yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: system spec: nodeTemplate: labels: node-role.deckhouse.io/system: “” taints:

• effect: NoExecute key: dedicated.deckhouse.io value: system Пример для узлов типа Static nodeType: Static staticInstances: count: 2 labelSelector: matchLabels: role: system Пример для узлов типа CloudEphemeral nodeType: CloudEphemeral cloudInstances: classReference: kind: YandexInstanceClass name: large maxPerZone: 2 minPerZone: 1 zones:
  • ru-central1-d

Nodes with GPU

Узлы с GPU

GPU-node management is available in the Enterprise edition only.

Функциональность управления GPU-узлами доступна только в Enterprise Edition.

GPU nodes require the NVIDIA driver and the NVIDIA Container Toolkit. There are two ways to install the driver:

Для работы узлов с GPU требуются драйвер NVIDIA и NVIDIA Container Toolkit. Возможны два варианта установки драйвера:

1. Manual installation — the administrator installs the driver before the node joins the cluster.
2. Automation via NodeGroupConfiguration (see the Step-by-step procedure for adding a GPU node to the cluster).

1. Ручная установка — администратор устанавливает драйвер до включения узла в кластер.
2. Автоматизация через NodeGroupConfiguration (см. Порядок действий по добавлению GPU-узла в кластер).

After the driver is detected and the NodeGroup includes the spec.gpu section, node-manager enables full GPU support by deploying NFD, GFD, NVIDIA Device Plugin, DCGM Exporter, and, if required, MIG Manager.

После того как драйвер установлен и в NodeGroup добавлен блок spec.gpu, node-manager включает полноценную поддержку GPU: автоматически разворачиваются NFD, GFD, NVIDIA Device Plugin, DCGM Exporter и, при необходимости, MIG Manager.

GPU nodes are usually tainted (e.g. node-role=gpu:NoSchedule) so that regular workloads don’t land there by accident. A workload that needs a GPU just adds the matching tolerations and nodeSelector.

Узлы с GPU часто помечают отдельным taint-ом (например, node-role=gpu:NoSchedule) — тогда по умолчанию туда не попадают обычные поды. Сервисам, которым нужен GPU, достаточно добавить tolerations и nodeSelector.

See the full field reference in the NodeGroup CR documentation.

Подробная схема параметров находится в описании кастомного ресурса NodeGroup.

Below are examples of NodeGroup manifests for typical GPU operating modes (Exclusive, TimeSlicing, MIG).

Ниже представлены примеры манифестов NodeGroup для типовых режимов работы GPU (Exclusive, TimeSlicing, MIG).

Exclusive mode (one Pod — one GPU)

Эксклюзивный режим (Exclusive)

Each Pod gets an entire physical GPU; the cluster exposes the nvidia.com/gpu resource.

Каждому поду выделяется целый GPU, в кластере публикуется ресурс nvidia.com/gpu.

Time-slicing (4 partitions)

TimeSlicing (4 слота)

The GPU is time-sliced: up to four Pods can share one card sequentially. Suitable for experiments, CI, and light inference workloads.

GPU распределяется по временным слотам: до 4 подов могут последовательно использовать одну карту. Подходит для экспериментов, CI и лёгких inference-задач.

Pods still request the nvidia.com/gpu resource.

Поды по-прежнему запрашивают ресурс nvidia.com/gpu.

MIG (all-1g.5gb profile)

MIG (профиль all-1g.5gb)

A hardware-partitioned GPU (A100, A30, etc.) is split into independent instances. The scheduler exposes resources like nvidia.com/mig-1g.5gb.

Физический GPU (A100, A30 и др.) делится на аппаратные экземпляры. Планировщик увидит ресурсы nvidia.com/mig-1g.5gb.

For a complete list of supported GPUs and their profiles, see the FAQ → How to view available MIG profiles in the cluster?.

Полный список поддерживаемых GPU-устройств и их профили см. в
FAQ → Как посмотреть доступные MIG-профили в кластере?.

Smoke-test Job (CUDA vectoradd)

Проверка работы: тестовая задача (CUDA vectoradd)

This Job runs NVIDIA’s vectoradd CUDA sample. If the Pod finishes with Succeeded, the GPU is present and configured correctly.

Эта задача (Job) запускает демонстрационный пример vectoradd из набора CUDA-samples. Если под завершается успешно (Succeeded), значит GPU-устройство доступно и корректно настроено.

Adding a static node to a cluster

Добавление статического узла в кластер

Adding a static node can be done manually or using the Cluster API Provider Static.

Добавление статического узла можно выполнить вручную или с помощью Cluster API Provider Static.

Manually

Вручную

Follow the steps below to add a new static node (e.g., VM or bare metal server) to the cluster:

Чтобы добавить новый статический узел (выделенная ВМ, bare-metal-сервер и т. п.) в кластер вручную, выполните следующие шаги:

1. For CloudStatic nodes in the following cloud providers, refer to the steps outlined in the documentation:
   • For AWS
   • For GCP
   • For YC
2. Use the existing one or create a new NodeGroup custom resource (see the example for the NodeGroup called worker). The nodeType parameter for static nodes in the NodeGroup must be Static or CloudStatic.
3. Get the Base64-encoded script code to add and configure the node.

1. Для CloudStatic-узлов в облачных провайдерах, перечисленных ниже, выполните описанные в документации шаги:
   • Для AWS
   • Для GCP
   • Для YC
2. Используйте существующий или создайте новый ресурс NodeGroup (пример NodeGroup с именем worker). Параметр nodeType в ресурсе NodeGroup для статических узлов должен быть Static или CloudStatic.
3. Получите код скрипта в кодировке Base64 для добавления и настройки узла.

Here is how you can get Base64-encoded script code to add a node to the worker NodeGroup:

Пример получения кода скрипта в кодировке Base64 для добавления узла в NodeGroup worker:

1. Pre-configure the new node according to the specifics of your environment. For example:
   • Add all the necessary mount points to the /etc/fstab file (NFS, Ceph, etc.).
   • Install the necessary packages.
   • Configure network connectivity between the new node and the other nodes of the cluster.
2. Connect to the new node over SSH and run the following command, inserting the Base64 string you got in step 3:

1. Выполните предварительную настройку нового узла в соответствии с особенностями вашего окружения. Например:
   • добавьте необходимые точки монтирования в файл /etc/fstab (NFS, Ceph и т. д.);
   • установите необходимые пакеты;
   • настройте сетевую связность между новым узлом и остальными узлами кластера.
2. Зайдите на новый узел по SSH и выполните следующую команду, вставив полученную в п. 3 Base64-строку:

shell echo | base64 -d | bash

shell echo | base64 -d | bash

Using the Cluster API Provider Static

С помощью Cluster API Provider Static

A brief example of adding a static node to a cluster using Cluster API Provider Static (CAPS):

Простой пример добавления статического узла в кластер с помощью Cluster API Provider Static (CAPS):

1. Prepare the necessary resources.

1. Подготовьте необходимые ресурсы.

• Allocate a server (or a virtual machine), configure networking, etc. If required, install specific OS packages and add the mount points on the node.

• Выделите сервер (или виртуальную машину), настройте сетевую связность и т. п., при необходимости установите специфические пакеты ОС и добавьте точки монтирования которые потребуются на узле.

• Create a user (caps in the example below) and add it to sudoers by running the following command on the server:

• Создайте пользователя (в примере — caps) с возможностью выполнять sudo, выполнив на сервере следующую команду:

• Allow the user to run sudo commands without having to enter a password. For this, add the following line to the sudo configuration on the server (you can either edit the /etc/sudoers file, or run the sudo visudo command, or use some other method):

• Разрешите пользователю выполнять команды через sudo без пароля. Для этого на сервере внесите следующую строку в конфигурацию sudo (отредактировав файл /etc/sudoers, выполнив команду sudo visudo или другим способом):

• Generate a pair of SSH keys with an empty passphrase on the server:

• Сгенерируйте на сервере пару SSH-ключей с пустой парольной фразой:

The public and private keys of the caps user will be stored in the caps-id.pub and caps-id files in the current directory on the server.

Публичный и приватный ключи пользователя caps будут сохранены в файлах caps-id.pub и caps-id в текущей директории на сервере.

• Add the generated public key to the /home/caps/.ssh/authorized_keys file of the caps user by executing the following commands in the keys directory on the server:

• Добавьте полученный публичный ключ в файл /home/caps/.ssh/authorized_keys пользователя caps, выполнив в директории с ключами на сервере следующие команды:

1. Create a SSHCredentials resource in the cluster:

В операционных системах семейства Astra Linux, при использовании модуля мандатного контроля целостности Parsec, сконфигурируйте максимальный уровень целостности для пользователя caps:

Run the following command in the user key directory on the server to encode the private key to Base64:

shell pdpl-user -i 63 caps

shell base64 -w0 caps-id

1. Создайте в кластере ресурс SSHCredentials.

On any computer with kubectl configured to manage the cluster, create an environment variable with the value of the Base64-encoded private key you generated in the previous step:

В директории с ключами пользователя на сервере выполните следующую команду для получения закрытого ключа в формате Base64:

shell CAPS_PRIVATE_KEY_BASE64=

shell base64 -w0 caps-id

Create a SSHCredentials resource in the cluster (note that from this point on, you have to use kubectl configured to manage the cluster):

На любом компьютере с kubectl, настроенным на управление кластером, создайте переменную окружения со значением закрытого ключа созданного пользователя в Base64, полученным на предыдущем шаге:

shell kubectl create -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: SSHCredentials metadata: name: credentials spec: user: caps privateSSHKey: “${CAPS_PRIVATE_KEY_BASE64}” EOF

shell CAPS_PRIVATE_KEY_BASE64=<ЗАКРЫТЫЙ_КЛЮЧ_В_BASE64>

1. Create a StaticInstance resource in the cluster; specify the IP address of the static node server:

Выполните следующую команду, для создания в кластере ресурса SSHCredentials (здесь и далее также используйте kubectl, настроенный на управление кластером):

shell kubectl create -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: StaticInstance metadata: name: static-worker-1 labels: role: worker spec: Specify the IP address of the static node server. address: “" credentialsRef: kind: SSHCredentials name: credentials EOF

shell kubectl create -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: SSHCredentials metadata: name: credentials spec: user: caps privateSSHKey: “${CAPS_PRIVATE_KEY_BASE64}” EOF

1. Create a NodeGroup resource in the cluster. Value of count defines number of staticInstances which fall under the labelSelector that will be bootstrapped and joined into the nodeGroup, in this example this is 1:

1. Создайте в кластере ресурс StaticInstance, указав IP-адрес сервера статического узла:

The labelSelector field in the NodeGroup resource is immutable. To update the labelSelector, you need to create a new NodeGroup and move the static nodes into it by changing their labels.

shell kubectl create -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: StaticInstance metadata: name: static-worker-1 labels: role: worker spec: Укажите IP-адрес сервера статического узла. address: “" credentialsRef: kind: SSHCredentials name: credentials EOF

shell kubectl create -f - «EOF apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: worker spec: nodeType: Static staticInstances: count: 1 labelSelector: matchLabels: role: worker EOF

1. Создайте в кластере ресурс NodeGroup. Параметр count обозначает количество staticInstances, подпадающих под labelSelector, которые будут добавлены в кластер, в данном случае 1:

If it is necessary to add nodes to an existing node group, specify the desired number in the .spec.count field of the NodeGroup.

Поле labelSelector в ресурсе NodeGroup является неизменным. Чтобы обновить labelSelector, нужно создать новую NodeGroup и перенести в неё статические узлы, изменив их лейблы (labels).

Using Cluster API Provider Static for multiple node groups

shell kubectl create -f - «EOF apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: worker spec: nodeType: Static staticInstances: count: 1 labelSelector: matchLabels: role: worker EOF

This example shows how you can use filters in the StaticInstance label selector to group static nodes and use them in different NodeGroups. Here, two node groups (front and worker) are used for different tasks. Each group includes nodes with different characteristics — the front group has two servers and the worker group has one.

Если необходимо добавить узлы в уже существующую группу узлов, укажите их желаемое количество в поле .spec.count NodeGroup.

1. Prepare the required resources (3 servers or virtual machines) and create the SSHCredentials resource in the same way as step 1 and step 2 of the example.

С помощью Cluster API Provider Static для нескольких групп узлов

1. Create two NodeGroup in the cluster (from this point on, use kubectl configured to manage the cluster):

Пример использования фильтров в label selector StaticInstance, для группировки статических узлов и использования их в разных NodeGroup. В примере используются две группы узлов (front и worker), предназначенные для разных задач, которые должны содержать разные по характеристикам узлы — два сервера для группы front и один для группы worker.

The labelSelector field in the NodeGroup resource is immutable. To update the labelSelector, you need to create a new NodeGroup and move the static nodes into it by changing their labels.

1. Подготовьте необходимые ресурсы (3 сервера или виртуальные машины) и создайте ресурс SSHCredentials, аналогично п.1 и п.2 примера.

shell kubectl create -f - «EOF apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: front spec: nodeType: Static staticInstances: count: 2 labelSelector: matchLabels: role: front — apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: worker spec: nodeType: Static staticInstances: count: 1 labelSelector: matchLabels: role: worker EOF

1. Создайте в кластере два ресурса NodeGroup (здесь и далее используйте kubectl, настроенный на управление кластером):

1. Create StaticInstance resources in the cluster and specify the valid IP addresses of the servers:

Поле labelSelector в ресурсе NodeGroup является неизменным. Чтобы обновить labelSelector, нужно создать новую NodeGroup и перенести в неё статические узлы, изменив их лейблы (labels).

shell kubectl create -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: StaticInstance metadata: name: static-front-1 labels: role: front spec: address: “" credentialsRef: kind: SSHCredentials name: credentials --- apiVersion: deckhouse.io/v1alpha1 kind: StaticInstance metadata: name: static-front-2 labels: role: front spec: address: "" credentialsRef: kind: SSHCredentials name: credentials --- apiVersion: deckhouse.io/v1alpha1 kind: StaticInstance metadata: name: static-worker-1 labels: role: worker spec: address: "" credentialsRef: kind: SSHCredentials name: credentials EOF

shell kubectl create -f - «EOF apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: front spec: nodeType: Static staticInstances: count: 2 labelSelector: matchLabels: role: front — apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: worker spec: nodeType: Static staticInstances: count: 1 labelSelector: matchLabels: role: worker EOF

Cluster API Provider Static: Moving Instances Between Node Groups

1. Создайте в кластере ресурсы StaticInstance, указав актуальные IP-адреса серверов:

During the process of transferring instances between node groups, the instance will be cleaned and re-bootstrapped, and the Node object will be recreated.

shell kubectl create -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: StaticInstance metadata: name: static-front-1 labels: role: front spec: address: “" credentialsRef: kind: SSHCredentials name: credentials --- apiVersion: deckhouse.io/v1alpha1 kind: StaticInstance metadata: name: static-front-2 labels: role: front spec: address: "" credentialsRef: kind: SSHCredentials name: credentials --- apiVersion: deckhouse.io/v1alpha1 kind: StaticInstance metadata: name: static-worker-1 labels: role: worker spec: address: "" credentialsRef: kind: SSHCredentials name: credentials EOF

This section describes the process of moving static instances between different node groups (NodeGroup) using the Cluster API Provider Static (CAPS). The process involves modifying the NodeGroup configuration and updating the labels of the corresponding StaticInstance.

Cluster API Provider Static: перемещение узлов между NodeGroup

Initial Configuration

В данном разделе описывается процесс перемещения статических узлов между различными NodeGroup с использованием Cluster API Provider Static (CAPS). Процесс включает изменение конфигурации NodeGroup и обновление лейблов у соответствующих StaticInstance.

Assume that there is already a NodeGroup named worker in the cluster, configured to manage one static instance with the label role: worker.

Исходная конфигурация

NodeGroup worker:

Предположим, что в кластере уже существует NodeGroup с именем worker, настроенный для управления одним статическим узлом с лейблом role: worker.

yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: worker spec: nodeType: Static staticInstances: count: 1 labelSelector: matchLabels: role: worker

NodeGroup worker:

StaticInstance static-worker-1:

yaml apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: worker spec: nodeType: Static staticInstances: count: 1 labelSelector: matchLabels: role: worker

yaml apiVersion: deckhouse.io/v1alpha2 kind: StaticInstance metadata: name: static-worker-1 labels: role: worker spec: address: “192.168.1.100” credentialsRef: kind: SSHCredentials name: credentials

StaticInstance static-0:

Steps to Move an Instance Between Node Groups

yaml apiVersion: deckhouse.io/v1alpha2 kind: StaticInstance metadata: name: static-worker-1 labels: role: worker spec: address: “192.168.1.100” credentialsRef: kind: SSHCredentials name: credentials

1. Create a New NodeGroup for the Target Node Group

Шаги по перемещению узла между NodeGroup

Create a new NodeGroup resource, for example, named front, which will manage a static instance with the label role: front.

В процессе переноса узлов между NodeGroup будет выполнена очистка и повторный бутстрап узла, объект Node будет пересоздан.

shell kubectl create -f - «EOF apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: front spec: nodeType: Static staticInstances: count: 1 labelSelector: matchLabels: role: front EOF

1. Создание новой NodeGroup для целевой группы узлов

2. Update the Label on the StaticInstance

Создайте новый ресурс NodeGroup, например, с именем front, который будет управлять статическим узлом с лейблом role: front.

Change the role label of the existing StaticInstance from worker to front. This will allow the new NodeGroup front to manage this instance.

shell kubectl create -f - «EOF apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: front spec: nodeType: Static staticInstances: count: 1 labelSelector: matchLabels: role: front EOF

shell kubectl label staticinstance static-worker-1 role=front –overwrite

2. Обновление лейбла у StaticInstance

3. Decrease the Number of Static Instances in the Original NodeGroup

Измените лейбл role у существующего StaticInstance с worker на front. Это позволит новой NodeGroup front начать управлять этим узлом.

Update the NodeGroup resource worker by reducing the count parameter from 1 to 0.

shell kubectl label staticinstance static-worker-1 role=front –overwrite

shell kubectl patch nodegroup worker -p ‘{“spec”: {“staticInstances”: {“count”: 0}}}’ –type=merge

3. Уменьшение количества статических узлов в исходной NodeGroup

An example of the NodeUser configuration

Обновите ресурс NodeGroup worker, уменьшив значение параметра count с 1 до 0.

yaml apiVersion: deckhouse.io/v1 kind: NodeUser metadata: name: testuser spec: uid: 1100 sshPublicKeys:

• “" passwordHash: isSudoer: true

shell kubectl patch nodegroup worker -p ‘{“spec”: {“staticInstances”: {“count”: 0}}}’ –type=merge

An example of the NodeGroupConfiguration configuration

Пример описания NodeUser

Installing the cert-manager plugin for kubectl on master nodes

yaml apiVersion: deckhouse.io/v1 kind: NodeUser metadata: name: testuser spec: uid: 1100 sshPublicKeys:

• “" passwordHash: isSudoer: true

yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: add-cert-manager-plugin.sh spec: weight: 100 bundles:

• “*” nodeGroups:
• “master” content: | if [ -x /usr/local/bin/kubectl-cert_manager ]; then exit 0 fi curl -L https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/kubectl-cert_manager-linux-amd64.tar.gz -o - | tar -zxvf - kubectl-cert_manager mv kubectl-cert_manager /usr/local/bin

Пример описания NodeGroupConfiguration

Tuning sysctl parameters

Установка плагина cert-manager для kubectl на master-узлах

yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: sysctl-tune.sh spec: weight: 100 bundles:

• “*” nodeGroups:
• “*” content: | sysctl -w vm.max_map_count=262144

yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: add-cert-manager-plugin.sh spec: weight: 100 bundles:

• “*” nodeGroups:
• “master” content: | if [ -x /usr/local/bin/kubectl-cert_manager ]; then exit 0 fi curl -L https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/kubectl-cert_manager-linux-amd64.tar.gz -o - | tar -zxvf - kubectl-cert_manager mv kubectl-cert_manager /usr/local/bin

Adding a root certificate to the host

Задание параметра sysctl

Example is given for Ubuntu OS.
The method of adding certificates to the store may differ depending on the OS.

yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: sysctl-tune.sh spec: weight: 100 bundles:

• “*” nodeGroups:
• “*” content: | sysctl -w vm.max_map_count=262144

Change the bundles and content parameters to adapt the script to a different OS.

Добавление корневого сертификата в хост

To use the certificate in containerd (including pulling containers from a private repository), a restart of the service is required after adding the certificate.

Данный пример приведен для ОС Ubuntu.
Способ добавления сертификатов в хранилище может отличаться в зависимости от ОС. При адаптации скрипта под другую ОС измените параметры bundles и content.

yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: add-custom-ca.sh spec: weight: 31 nodeGroups:

• ‘*’
  bundles:
• ‘ubuntu-lts’ content: |- CERT_FILE_NAME=example_ca CERTS_FOLDER=”/usr/local/share/ca-certificates” CERT_CONTENT=$(cat «EOF —–BEGIN CERTIFICATE—– MIIDSjCCAjKgAwIBAgIRAJ4RR/WDuAym7M11JA8W7D0wDQYJKoZIhvcNAQELBQAw JTEjMCEGA1UEAxMabmV4dXMuNTEuMjUwLjQxLjIuc3NsaXAuaW8wHhcNMjQwODAx MTAzMjA4WhcNMjQxMDMwMTAzMjA4WjAlMSMwIQYDVQQDExpuZXh1cy41MS4yNTAu NDEuMi5zc2xpcC5pbzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL1p WLPr2c4SZX/i4IS59Ly1USPjRE21G4pMYewUjkSXnYv7hUkHvbNL/P9dmGBm2Jsl WFlRZbzCv7+5/J+9mPVL2TdTbWuAcTUyaG5GZ/1w64AmAWxqGMFx4eyD1zo9eSmN G2jis8VofL9dWDfUYhRzJ90qKxgK6k7tfhL0pv7IHDbqf28fCEnkvxsA98lGkq3H fUfvHV6Oi8pcyPZ/c8ayIf4+JOnf7oW/TgWqI7x6R1CkdzwepJ8oU7PGc0ySUWaP G5bH3ofBavL0bNEsyScz4TFCJ9b4aO5GFAOmgjFMMUi9qXDH72sBSrgi08Dxmimg Hfs198SZr3br5GTJoAkCAwEAAaN1MHMwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB /wQCMAAwUwYDVR0RBEwwSoIPbmV4dXMuc3ZjLmxvY2FsghpuZXh1cy41MS4yNTAu NDEuMi5zc2xpcC5pb4IbZG9ja2VyLjUxLjI1MC40MS4yLnNzbGlwLmlvMA0GCSqG SIb3DQEBCwUAA4IBAQBvTjTTXWeWtfaUDrcp1YW1pKgZ7lTb27f3QCxukXpbC+wL dcb4EP/vDf+UqCogKl6rCEA0i23Dtn85KAE9PQZFfI5hLulptdOgUhO3Udluoy36 D4WvUoCfgPgx12FrdanQBBja+oDsT1QeOpKwQJuwjpZcGfB2YZqhO0UcJpC8kxtU by3uoxJoveHPRlbM2+ACPBPlHu/yH7st24sr1CodJHNt6P8ugIBAZxi3/Hq0wj4K aaQzdGXeFckWaxIny7F1M3cIWEXWzhAFnoTgrwlklf7N7VWHPIvlIh1EYASsVYKn iATq8C7qhUOGsknDh3QSpOJeJmpcBwln11/9BGRP —–END CERTIFICATE—– EOF )

Для использования сертификата в containerd (в т.ч. pull контейнеров из приватного репозитория) после добавления сертификата требуется произвести рестарт сервиса.

bb-event - Creating subscription for event function. More information: http://www.bashbooster.net/#event ca-file-updated - Event name update-certs - The function name that the event will call bb-event-on “ca-file-updated” “update-certs” update-certs() { # Function with commands for adding a certificate to the store update-ca-certificates }

yaml apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: add-custom-ca.sh spec: weight: 31 nodeGroups:

• ‘*’
  bundles:
• ‘ubuntu-lts’ content: |- CERT_FILE_NAME=example_ca CERTS_FOLDER=”/usr/local/share/ca-certificates” CERT_CONTENT=$(cat «EOF —–BEGIN CERTIFICATE—– MIIDSjCCAjKgAwIBAgIRAJ4RR/WDuAym7M11JA8W7D0wDQYJKoZIhvcNAQELBQAw JTEjMCEGA1UEAxMabmV4dXMuNTEuMjUwLjQxLjIuc3NsaXAuaW8wHhcNMjQwODAx MTAzMjA4WhcNMjQxMDMwMTAzMjA4WjAlMSMwIQYDVQQDExpuZXh1cy41MS4yNTAu NDEuMi5zc2xpcC5pbzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL1p WLPr2c4SZX/i4IS59Ly1USPjRE21G4pMYewUjkSXnYv7hUkHvbNL/P9dmGBm2Jsl WFlRZbzCv7+5/J+9mPVL2TdTbWuAcTUyaG5GZ/1w64AmAWxqGMFx4eyD1zo9eSmN G2jis8VofL9dWDfUYhRzJ90qKxgK6k7tfhL0pv7IHDbqf28fCEnkvxsA98lGkq3H fUfvHV6Oi8pcyPZ/c8ayIf4+JOnf7oW/TgWqI7x6R1CkdzwepJ8oU7PGc0ySUWaP G5bH3ofBavL0bNEsyScz4TFCJ9b4aO5GFAOmgjFMMUi9qXDH72sBSrgi08Dxmimg Hfs198SZr3br5GTJoAkCAwEAAaN1MHMwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB /wQCMAAwUwYDVR0RBEwwSoIPbmV4dXMuc3ZjLmxvY2FsghpuZXh1cy41MS4yNTAu NDEuMi5zc2xpcC5pb4IbZG9ja2VyLjUxLjI1MC40MS4yLnNzbGlwLmlvMA0GCSqG SIb3DQEBCwUAA4IBAQBvTjTTXWeWtfaUDrcp1YW1pKgZ7lTb27f3QCxukXpbC+wL dcb4EP/vDf+UqCogKl6rCEA0i23Dtn85KAE9PQZFfI5hLulptdOgUhO3Udluoy36 D4WvUoCfgPgx12FrdanQBBja+oDsT1QeOpKwQJuwjpZcGfB2YZqhO0UcJpC8kxtU by3uoxJoveHPRlbM2+ACPBPlHu/yH7st24sr1CodJHNt6P8ugIBAZxi3/Hq0wj4K aaQzdGXeFckWaxIny7F1M3cIWEXWzhAFnoTgrwlklf7N7VWHPIvlIh1EYASsVYKn iATq8C7qhUOGsknDh3QSpOJeJmpcBwln11/9BGRP —–END CERTIFICATE—– EOF )

bb-tmp-file - Creating temp file function. More information: http://www.bashbooster.net/#tmp CERT_TMP_FILE=”$( bb-tmp-file )” echo -e “${CERT_CONTENT}” > “${CERT_TMP_FILE}”
bb-sync-file - File synchronization function. More information: http://www.bashbooster.net/#sync “${CERTS_FOLDER}/${CERT_FILE_NAME}.crt” - Destination file ${CERT_TMP_FILE} - Source file ca-file-updated - Name of event that will be called if the file changes.

bb-event - Creating subscription for event function. More information: http://www.bashbooster.net/#event ca-file-updated - Event name update-certs - The function name that the event will call bb-event-on “ca-file-updated” “update-certs” update-certs() { # Function with commands for adding a certificate to the store update-ca-certificates }

bb-sync-file
“${CERTS_FOLDER}/${CERT_FILE_NAME}.crt”
${CERT_TMP_FILE}
ca-file-updated

bb-tmp-file - Creating temp file function. More information: http://www.bashbooster.net/#tmp CERT_TMP_FILE=”$( bb-tmp-file )” echo -e “${CERT_CONTENT}” > “${CERT_TMP_FILE}”
bb-sync-file - File synchronization function. More information: http://www.bashbooster.net/#sync “${CERTS_FOLDER}/${CERT_FILE_NAME}.crt” - Destination file ${CERT_TMP_FILE} - Source file ca-file-updated - Name of event that will be called if the file changes.

Adding the ability to download images from insecure container registry to containerd

bb-sync-file
“${CERTS_FOLDER}/${CERT_FILE_NAME}.crt”
${CERT_TMP_FILE}
ca-file-updated

The ability to download images from an insecure container registry is enabled using the insecure_skip_verify parameter in the containerd configuration file. For more information, see the section “How to add configuration for an additional registry”

Добавление в containerd возможности скачивать образы из insecure container registry

Возможность скачивания образов из insecure container registry включается с помощью параметра insecure_skip_verify в конфигурационном файле containerd. Подробнее — в разделе «Как добавить конфигурацию для дополнительного registry».