Ниже представлены несколько примеров описания NodeGroup , а также установки плагина cert-manager для kubectl и задания параметра sysctl.
| Below are some examples of NodeGroup description, as well as installing the cert-manager plugin for kubectl and setting the sysctl parameter.
|
Примеры описания NodeGroup
| Examples of the NodeGroup configuration
|
|
|
Облачные узлы
| Cloud nodes
|
yaml
apiVersion: deckhouse.io/v1
kind: NodeGroup
metadata:
name: test
spec:
nodeType: CloudEphemeral
cloudInstances:
zones:
- eu-west-1a
- eu-west-1b
minPerZone: 1
maxPerZone: 2
classReference:
kind: AWSInstanceClass
name: test
nodeTemplate:
labels:
tier: test
| yaml
apiVersion: deckhouse.io/v1
kind: NodeGroup
metadata:
name: test
spec:
nodeType: CloudEphemeral
cloudInstances:
zones:
- eu-west-1a
- eu-west-1b
minPerZone: 1
maxPerZone: 2
classReference:
kind: AWSInstanceClass
name: test
nodeTemplate:
labels:
tier: test
|
Статические узлы
| Static nodes
|
|
|
Для виртуальных машин на гипервизорах или физических серверов используйте статические узлы, указав nodeType: Static в NodeGroup.
| Use nodeType: Static for physical servers and VMs on Hypervisors.
|
Пример:
| An example:
|
yaml
apiVersion: deckhouse.io/v1
kind: NodeGroup
metadata:
name: worker
spec:
nodeType: Static
| yaml
apiVersion: deckhouse.io/v1
kind: NodeGroup
metadata:
name: worker
spec:
nodeType: Static
|
Узлы в такую группу добавляются вручную с помощью подготовленных скриптов.
| Adding nodes to such a group is done manually using the pre-made scripts.
|
Также можно использовать способ добавления статических узлов с помощью Cluster API Provider Static.
| You can also use a method that adds static nodes using the Cluster API Provider Static.
|
Системные узлы
| System nodes
|
|
|
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
nodeType: Static
| 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
nodeType: Static
|
Добавление статического узла в кластер
| Adding a static node to a cluster
|
|
|
Добавление статического узла можно выполнить вручную или с помощью Cluster API Provider Static.
| Adding a static node can be done manually or using the Cluster API Provider Static.
|
Вручную
| Manually
|
Чтобы добавить новый статический узел (выделенная ВМ, bare-metal-сервер и т. п.) в кластер вручную, выполните следующие шаги:
| Follow the steps below to add a new static node (e.g., VM or bare metal server) to the cluster:
|
- Для CloudStatic-узлов в облачных провайдерах, перечисленных ниже, выполните описанные в документации шаги:
- Используйте существующий или создайте новый custom resource NodeGroup (пример
NodeGroup с именем worker ). Параметр nodeType в custom resource NodeGroup для статических узлов должен быть Static или CloudStatic .
- Получите код скрипта в кодировке Base64 для добавления и настройки узла.
|
- For CloudStatic nodes in the following cloud providers, refer to the steps outlined in the documentation:
- 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 .
- Get the Base64-encoded script code to add and configure the node.
|
Пример получения кода скрипта в кодировке Base64 для добавления узла в NodeGroup worker :
| Here is how you can get Base64-encoded script code to add a node to the worker NodeGroup:
|
shell
NODE_GROUP=worker
kubectl -n d8-cloud-instance-manager get secret manual-bootstrap-for-${NODE_GROUP} -o json | jq ‘.data.”bootstrap.sh”’ -r
| shell
NODE_GROUP=worker
kubectl -n d8-cloud-instance-manager get secret manual-bootstrap-for-${NODE_GROUP} -o json | jq ‘.data.”bootstrap.sh”’ -r
|
- Выполните предварительную настройку нового узла в соответствии с особенностями вашего окружения. Например:
- добавьте необходимые точки монтирования в файл
/etc/fstab (NFS, Ceph и т. д.);
- установите необходимые пакеты (например,
ceph-common );
- настройте сетевую связанность между новым узлом и остальными узлами кластера.
- Зайдите на новый узел по SSH и выполните следующую команду, вставив полученную в п. 2 Base64-строку:
|
- 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 (e.g.,
ceph-common );
- Configure network connectivity between the new node and the other nodes of the cluster.
- Connect to the new node over SSH and run the following command, inserting the Base64 string you got in step 2:
|
shell
echo | base64 -d | bash
| shell
echo | base64 -d | bash
|
С помощью Cluster API Provider Static
| Using the Cluster API Provider Static
|
Простой пример добавления статического узла в кластер с помощью Cluster API Provider Static (CAPS):
| A brief example of adding a static node to a cluster using Cluster API Provider Static (CAPS):
|
- Подготовьте необходимые ресурсы.
|
- Prepare the necessary resources.
|
- Выделите сервер (или виртуальную машину), настройте сетевую связанность и т. п., при необходимости установите специфические пакеты ОС и добавьте точки монтирования которые потребуются на узле.
|
- Allocate a server (or a virtual machine), configure networking, etc. If required, install specific OS packages and add the mount points on the node.
|
- Создайте пользователя (в примере —
caps ) с возможностью выполнять sudo , выполнив на сервере следующую команду:
|
- Create a user (
caps in the example below) and add it to sudoers by running the following command on the server:
|
shell
useradd -m -s /bin/bash caps
usermod -aG sudo caps
| shell
useradd -m -s /bin/bash caps
usermod -aG sudo caps
|
- Разрешите пользователю выполнять команды через sudo без пароля. Для этого на сервере внесите следующую строку в конфигурацию sudo (отредактировав файл
/etc/sudoers , выполнив команду sudo visudo или другим способом):
|
- 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):
|
text
caps ALL=(ALL) NOPASSWD: ALL
| text
caps ALL=(ALL) NOPASSWD: ALL
|
- Сгенерируйте на сервере пару SSH-ключей с пустой парольной фразой:
|
- Generate a pair of SSH keys with an empty passphrase on the server:
|
shell
ssh-keygen -t rsa -f caps-id -C “” -N “”
| shell
ssh-keygen -t rsa -f caps-id -C “” -N “”
|
Публичный и приватный ключи пользователя caps будут сохранены в файлах caps-id.pub и caps-id в текущей папке на сервере.
| 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.
|
- Добавьте полученный публичный ключ в файл
/home/caps/.ssh/authorized_keys пользователя caps , выполнив в директории с ключами на сервере следующие команды:
|
- 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:
|
shell
mkdir -p /home/caps/.ssh
cat caps-id.pub » /home/caps/.ssh/authorized_keys
chmod 700 /home/caps/.ssh
chmod 600 /home/caps/.ssh/authorized_keys
chown -R caps:caps /home/caps/
| shell
mkdir -p /home/caps/.ssh
cat caps-id.pub » /home/caps/.ssh/authorized_keys
chmod 700 /home/caps/.ssh
chmod 600 /home/caps/.ssh/authorized_keys
chown -R caps:caps /home/caps/
|
- Создайте в кластере ресурс SSHCredentials.
|
- Create a SSHCredentials resource in the cluster:
|
В директории с ключами пользователя на сервере выполните следующую команду для получения закрытого ключа в формате Base64:
| Run the following command in the user key directory on the server to encode the private key to Base64:
|
shell
base64 -w0 caps-id
| shell
base64 -w0 caps-id
|
На любом компьютере с kubectl , настроенным на управление кластером, создайте переменную окружения со значением закрытого ключа созданного пользователя в Base64, полученным на предыдущем шаге:
| 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:
|
shell
CAPS_PRIVATE_KEY_BASE64=<ЗАКРЫТЫЙ_КЛЮЧ_В_BASE64>ЗАКРЫТЫЙ_КЛЮЧ_В_BASE64>
| shell
CAPS_PRIVATE_KEY_BASE64=
|
Выполните следующую команду, для создания в кластере ресурса SSHCredentials (здесь и далее также используйте kubectl , настроенный на управление кластером):
| Create a SSHCredentials resource in the cluster (note that from this point on, you have to use kubectl configured to manage the cluster):
|
shell
kubectl create -f - «EOF
apiVersion: deckhouse.io/v1alpha1
kind: SSHCredentials
metadata:
name: credentials
spec:
user: caps
privateSSHKey: “${CAPS_PRIVATE_KEY_BASE64}”
EOF
| shell
kubectl create -f - «EOF
apiVersion: deckhouse.io/v1alpha1
kind: SSHCredentials
metadata:
name: credentials
spec:
user: caps
privateSSHKey: “${CAPS_PRIVATE_KEY_BASE64}”
EOF
|
- Создайте в кластере ресурс StaticInstance, указав IP-адрес сервера статического узла:
|
- Create a StaticInstance resource in the cluster; specify the IP address of the static node server:
|
shell
kubectl create -f - «EOF
apiVersion: deckhouse.io/v1alpha1
kind: StaticInstance
metadata:
name: static-0
spec:
Укажите IP-адрес сервера статического узла.
address: “"
credentialsRef:
kind: SSHCredentials
name: credentials
EOF
| shell
kubectl create -f - «EOF
apiVersion: deckhouse.io/v1alpha1
kind: StaticInstance
metadata:
name: static-0
spec:
Specify the IP address of the static node server.
address: “"
credentialsRef:
kind: SSHCredentials
name: credentials
EOF
|
- Создайте в кластере ресурс NodeGroup:
|
- Create a NodeGroup resource in the cluster:
|
shell
kubectl create -f - «EOF
apiVersion: deckhouse.io/v1
kind: NodeGroup
metadata:
name: worker
spec:
nodeType: Static
staticInstances:
count: 1
EOF
| shell
kubectl create -f - «EOF
apiVersion: deckhouse.io/v1
kind: NodeGroup
metadata:
name: worker
spec:
nodeType: Static
staticInstances:
count: 1
EOF
|
С помощью Cluster API Provider Static и фильтрами в label selector
| Using the Cluster API Provider Static and label selector filters
|
Пример использования фильтров в label selector StaticInstance, для группировки статических узлов и использования их в разных NodeGroup. В примере используются две группы узлов (front и worker ), предназначенные для разных задач, которые должны содержать разные по характеристикам узлы — два сервера для группы front и один для группы worker .
| 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.
|
- Подготовьте необходимые ресурсы (3 сервера или виртуальные машины) и создайте ресурс
SSHCredentials , аналогично п.1 и п.2 примера.
|
- 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.
|
- Создайте в кластере два ресурса NodeGroup (здесь и далее используйте
kubectl , настроенный на управление кластером):
|
- Create two NodeGroup in the cluster (from this point on, use
kubectl configured to manage the cluster):
|
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
| 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
|
- Создайте в кластере ресурсы StaticInstance, указав актуальные IP-адреса серверов:
|
- Create StaticInstance resources in the cluster and specify the valid IP addresses of the servers:
|
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/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
|
Пример описания NodeUser
| An example of the NodeUser configuration
|
yaml
apiVersion: deckhouse.io/v1
kind: NodeUser
metadata:
name: testuser
spec:
uid: 1100
sshPublicKeys:
- “"
passwordHash:
isSudoer: true
| yaml
apiVersion: deckhouse.io/v1
kind: NodeUser
metadata:
name: testuser
spec:
uid: 1100
sshPublicKeys:
- “"
passwordHash:
isSudoer: true
|
Пример описания NodeGroupConfiguration
| An example of the NodeGroupConfiguration configuration
|
Установка плагина cert-manager для kubectl на master-узлах
| Installing the cert-manager plugin for kubectl on master nodes
|
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
| 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
|
Задание параметра sysctl
| Tuning sysctl parameters
|
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: sysctl-tune.sh
spec:
weight: 100
bundles:
- “*”
nodeGroups:
- “*”
content: |
sysctl -w vm.max_map_count=262144
|