Rootless kubernetes: различия между версиями

Материал из ALT Linux Wiki
Строка 546: Строка 546:


= Выбор регистратора образов =
= Выбор регистратора образов =
Пакет обеспечивает загрузку <code>kubernet-образов</code> с регистраторов различного уровня. Уровень регистратора определяется переменной среды <code>U7S_REGISTRY</code>. Переменная может принимать нижеописанные основные значения.
 
Во время инициализации <code>master-узла</code> кластера (<code>kubeadm init</code>) или во время подключения узла к кластеру (<code>kubeadm join</code>) команда <code>kubeadm</code> может загружать образы с различных регистраторов образов и с различными префиксами.
 
Выбор регистратора и префикса образов определяет переменная среды <code>U7S_REGISTRY</code>.  
Если переменная не задана регистратор  префикс определяется автоматически на основе конфигурационных файлов <code>/etc/os-release</code> и <code>/etc/hosts</code>.
 
Переменная среды <code>U7S_REGISTRY</code> может принимать следующие основные значения:
* пустое значение;
* <code>registry.altlinux.org/k8s-c10f1</code>;
* <code>registry.altlinux.org/k8s-p10</code>;
* <code>registry.local/k8s-c10f1</code>;
* <code>registry.local/k8s-p10</code>.


== Native kubernetes регистратор ==
== Native kubernetes регистратор ==

Версия от 19:41, 29 июня 2023


Общее описание

Запуск Kubernetes в режиме rootless обеспечивает запуск Podов без системных root-привелегий в рамках user namespace системного пользователя u7s-admin. Работа в этом режиме практически не требует никаких модификаций, но обеспечивает повышенные уровень защищенности kubernetes, так как клиентские приложения даже при использовании уязвимостей не могут получить права пользователя root и нарушить работу узла.

Запуск kubernetes версии 1.26.3 и старше в режиме rootless обеспечивает пакет podsec-k8s версии 1.0.5 или выше.

podsec-k8s - Быстрый старт

Установка master-узла

Инициализация master-узла

Для запуска kubernetes в режиме rootless установите пакет podsec-k8s версии 1.0.5 или выше. 

apt-get install podsec-k8s

Измените переменную PATH: 

export PATH=/usr/libexec/podsec/u7s/bin/:$PATH

В каталоге /usr/libexec/podsec/u7s/bin/ находятся программы, обеспечивающие работы kubernetes в rootless-режиме.

Для разворачивания master-узла запустите команду: 

kubeadm init

По умолчанию уровень отладки устанавливается в 0. Если необходимо увеличить уровень отладки укажите перед подкомандой init флаг -v n. Где n принимает значения от 0 до 9-ти.

После:

  • генерации сертификатов в каталоге /etc/kuarnetes/pki,
  • загрузки образов,
  • генерации conf-файлов в каталоге /etc/kubernetes/manifests/, /etc/kubernetes/manifests/etcd/
  • запуска сервиса kubelet и Pod’ов системных kubernetes-образов

инициализируется kubernet-кластер из одного узла.

По окончании скрипт выводит строки подключения master(Control Plane) и worker-узлов: 

You can now join any number of control-plane nodes by copying certificate authorities
and service account keys on each node and then running the following as root:

kubeadm join xxx.xxx.xxx.xxx:6443 --token ... --discovery-token-ca-cert-hash sha256:.. --control-plane

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join xxx.xxx.xxx.xxx:6443 --token ... --discovery-token-ca-cert-hash sha256:...

Запуск сетевого маршрутизатора для контейенеров kube-flannel

Для перевода узла в состояние Ready, запуска coredns Pod’ов запустите flannel.

На master-узле под пользоваталем root выполните команду: 

# kubectl apply -f /etc/kubernetes/manifests/kube-flannel.yml
Connected to the local host. Press ^] three times within 1s to exit session.
[INFO] Entering RootlessKit namespaces: OK
namespace/kube-flannel created
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.apps/kube-flannel-ds created
Connection to the local host terminated.

После завершения скрипта в течении минуты настраиваются сервисы мастер-узла кластера. По ее истечении проверьте работу usernetes (rootless kuber)


Проверка работы master-узла

На master-узле выполните команду: 

# kubectl get daemonsets.apps -A
NAMESPACE      NAME              DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
kube-flannel   kube-flannel-ds   1         1         1       1            1           <none>                   102s
kube-system    kube-proxy        1         1         1       1            1           kubernetes.io/os=linux   8h

Число READY каждого daemonset должно быть равно числу DESIRED и должно быть равно числу узлов кластера. 

# kubectl get nodes -o wide
NAME       STATUS   ROLES           AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE           KERNEL-VERSION         CONTAINER-RUNTIME
<host>     Ready    control-plane   16m   v1.26.3   10.96.0.1     <none>        ALT SP Server 11100-01   5.15.105-un-def-alt1   cri-o://1.26.2

Проверьте работу usernetes (rootless kuber) 

# kubectl get all -A
NAMESPACE     NAME                                   READY   STATUS    RESTARTS   AGE
kube-system   pod/coredns-c7df5cd6c-5pkkm            1/1     Running   0          19m
kube-system   pod/coredns-c7df5cd6c-cm6vf            1/1     Running   0          19m
kube-system   pod/etcd-host-212                      1/1     Running   0          19m
kube-system   pod/kube-apiserver-host-212            1/1     Running   0          19m
kube-system   pod/kube-controller-manager-host-212   1/1     Running   0          19m
kube-system   pod/kube-proxy-lqf9c                   1/1     Running   0          19m
kube-system   pod/kube-scheduler-host-212            1/1     Running   0          19m

NAMESPACE     NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
default       service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP                  19m
kube-system   service/kube-dns     ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   19m

NAMESPACE     NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
kube-system   daemonset.apps/kube-proxy   1         1         1       1            1           kubernetes.io/os=linux   19m

NAMESPACE     NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/coredns   2/2     2            2           19m

NAMESPACE     NAME                                DESIRED   CURRENT   READY   AGE
kube-system   replicaset.apps/coredns-c7df5cd6c   2         2         2       19m

Состояние всех Pod’ов должны быть в 1/1.

Проверьте состояние дерева процессов: 

# pstree
...
├─systemd─┬─(sd-pam)
│         ├─dbus-daemon
│         ├─nsenter.sh───nsenter───_kubelet.sh───kubelet───11*[{kubelet}]
│         └─rootlesskit.sh───rootlesskit─┬─exe─┬─conmon───kube-controller───7*[{kube-controller}]
│                                        │     ├─conmon───kube-apiserver───8*[{kube-apiserver}]
│                                        │     ├─conmon───kube-scheduler───7*[{kube-scheduler}]
│                                        │     ├─conmon───etcd───8*[{etcd}]
│                                        │     ├─conmon───kube-proxy───4*[{kube-proxy}]
│                                        │     ├─2*[conmon───coredns───8*[{coredns}]]
│                                        │     ├─rootlesskit.sh───crio───10*[{crio}]
│                                        │     └─7*[{exe}]
│                                        ├─slirp4netns
│                                        └─8*[{rootlesskit}]
...

Процесс kubelet запускается как сервис в user namespace процесса rootlesskit.

Все остальные процессы kube-controller, kube-apiserver, kube-scheduler, kube-proxy, etcd, coredns запускаются как контейнеры от соответствующих образов в user namespace процесса rootlesskit.

Обеспечение запуска обычных POD’ов на мастер-узле

По умолчанию на master-узле пользовательские Podы не запускаются. Чтобы снять это ограничение наберите команду: 

# kubectl taint nodes <host> node-role.kubernetes.io/control-plane:NoSchedule-
node/<host> untainted

Инициализация и подключение worker-узла

Установите пакет podsec-k8s: 

apt-get install podsec-k8s

Подключение worker-узлов

Скопируйте команду подключения worker-узла, полученную на этапе установки начального master-узла. Запустите ее: 

kubeadm join xxx.xxx.xxx.xxx:6443 --token ... --discovery-token-ca-cert-hash sha256:...

По умолчанию уровень отладки устанавливается в 0. Если необходимо увеличить уровень отладки укажите перед подкомандой join флаг -v n. Где n принимает значения от 0 до 9-ти.

По окончании скрипт выводит текст: 

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

Проверка состояния процессов

Проверьте состояние дерева процессов: 

# pstree
...
├─systemd─┬─(sd-pam)
│         ├─dbus-daemon
│         ├─nsenter.sh───nsenter───_kubelet.sh───kubelet───10*[{kubelet}]
│         └─rootlesskit.sh───rootlesskit─┬─exe─┬─conmon───kube-proxy───4*[{kube-proxy}]
│                                        │     ├─rootlesskit.sh───crio───9*[{crio}]
│                                        │     └─6*[{exe}]
│                                        ├─slirp4netns
│                                        └─8*[{rootlesskit}]
...

Процесс kubelet запускается как сервис в user namespace процесса rootlesskit.

Все остальные процессы kube-proxy, kube-flannel запускаются как контейнеры от соответствующих образов в user namespace процесса rootlesskit.

Проверка готовности master и worker узлов kubernets

Зайдите на master-узел и проверьте подключение worker-узла: 

# kubectl get nodes -o wide
NAME       STATUS   ROLES           AGE     VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                 KERNEL-VERSION         CONTAINER-RUNTIME
<host1>   Ready    control-plane   7h54m   v1.26.3   10.96.0.1     <none>  ALT   cri-o://1.26.2
<host2>   Ready    <none>          8m30s   v1.26.3   10.96.0.1     <none>  ALT   cri-o://1.26.2
...

Инициализация и подключение дополнительных master-узлов

Установите пакет podsec-k8s: 

apt-get install podsec-k8s

Подключение master-узлов

Скопируйте команду подключения master-узла, полученную на этапе установки начального master-узла. Она отличается от команды подключения worker-узлов наличием дополнительных параметров --control-plane, --certificate-key.

Запустите ее: 

kubeadm join xxx.xxx.xxx.xxx:6443 --token ... --discovery-token-ca-cert-hash sha256:...
  --control-plane --certificate-key ...

По умолчанию уровень отладки устанавливается в 0. Если необходимо увеличить уровень отладки укажите перед подкомандой join флаг -v n. Где n принимает значения от 0 до 9-ти.

По окончании скрипт выводит текст: 

This node has joined the cluster and a new control plane instance was created:

* Certificate signing request was sent to apiserver and approval was received.
* The Kubelet was informed of the new secure connection details.
* Control plane label and taint were applied to the new node.
* The Kubernetes control plane instances scaled up.
* A new etcd member was added to the local/stacked etcd cluster.

Проверка состояния процессов

Проверьте состояние дерева процессов: 

# pstree
...
        ├─systemd─┬─(sd-pam)
        │         ├─dbus-daemon
        │         ├─kubelet.sh───nsenter_u7s───nsenter───_kubelet.sh───kubelet───11*[{kubelet}]
        │         └─rootlesskit.sh───rootlesskit─┬─exe─┬─conmon───kube-controller───4*[{kube-controller}]
        │                                        │     ├─conmon───kube-scheduler───8*[{kube-scheduler}]
        │                                        │     ├─conmon───etcd───9*[{etcd}]
        │                                        │     ├─conmon───kube-proxy───4*[{kube-proxy}]
        │                                        │     ├─conmon───kube-apiserver───8*[{kube-apiserver}]
        │                                        │     ├─rootlesskit.sh───crio───8*[{crio}]
        │                                        │     └─7*[{exe}]
        │                                        ├─slirp4netns
        │                                        └─8*[{rootlesskit}]

Дерево процессов должно совпадать с деревом процессов основного master-узла.

Проверка готовности master и worker узлов kubernets

На одном из master-узлов наберите команду: 

# kubectl get nodes -o wide
NAME       STATUS   ROLES           AGE     VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                 KERNEL-VERSION         CONTAINER-RUNTIME
<host1>   Ready    control-plane   7h54m   v1.26.3   10.96.0.1     <none>        ALT    cri-o://1.26.2
<host2>   Ready    <none>          8m30s   v1.26.3   10.96.0.1     <none>  ALT   cri-o://1.26.2
...
<hostN>   Ready    control-plane   55m     v1.26.3   10.96.122.<N> <none>        ALT      cri-o://1.26.2
...

Использование REST-интерефейсов подключенных master-узлов

По умолчанию на подключенных master-узлах в файле /etc/kubernetes/admin.conf указан адрес API-интерфейса основного master-узла: 

apiVersion: v1
clusters:
- cluster:
    ...
    server: https://<master1>:6443
...

Для балансировки нагрузки в файлах конфигурации ~user/.kube/config есть смысл указать адреса API-интерфейсов дополнительгных master-узла: 

apiVersion: v1
clusters:
- cluster:
    ...
    server: https://<masterN>:6443
...

Системный пользователь u7s-admin

Все контейнеры в rootless kubernetes. включая системные работают от имени системного пользователя u7s-admin. Вы можете для мониторинга работы системы или запуска дополнительного функционала работать в системе от имени этого пользователя.

Для входа в терминальный режим этого пользователя достаточно в пользователе с правами root набрать команду: 

# machinectl shell u7s-admin@ /bin/bash

или задав пароль пользователя: 

# passwd u7s-admin

зайти в него через ssh.

Для входа в namespace пользователя наберите команду : 

$ nsenter_u7s
#

В рамках своего namespace пользователь u7s-admin имеет права root, оставаясь в рамках системы с правам пользователя u7s-admin.

Наличие прав root позволает использовать системные команды,требующих root-привелегий для работы с сетевым, файловым окружением (эти окружения отличаются от системных): ip, iptables, crictl, ...

С помощью команды crictl можно

  • посмотреть наличие образов в системном кэше,
  • удалить, загрузить образы
  • посмотреть состояние контейнеров, pod'ов
  • и т.п.

Кроме этого namespace пользователя u7s-admin присутствуют файлы и каталоге созданные в рамках данного namespace и отсутствующие в основной системе. Например Вы можете посмотреть логи контейнеров в каталоге /var/log/pods и т.п.

Разворачивание rootless kubernetes кластера с балансировщиком REST-запросов haproxy

Ручная балансировка запросов к API-интерфейсам master-узлов путем указания у клиентов адресов различных master-узлов довольно неудобна, так как не обеспечивает равномерного распределения запросов по узлам кластера и не обеспечивает автоматической отказоустойчивости при выходе из строя master-узлов.

Решает данную проблему установка балансировщика нагрузки haproxy.

Перевод кластера в режим балансировки запросов через haproxy возможен. Подробности описаны в статье How to convert a Kubernetes non-HA control plane into an HA control plane?, но данная процедура не гарантирует корректный перевод на всех версиях kubernetes и ее не рекомендуют применять на production кластерах.

Так что наиболее надежным способом создания кластера с балансировкой запросов является создание нового кластера.

Настройка балансировщика REST-запросов haproxy

Балансировщик REST-запросов haproxy можно устанавливать как на отдельный сервер, так на один из серверов кластера.

Если балансировщик устанавливается на rootless сервер кластера, но для балансировщика необходимо выделить отдельный IP-адрес. Если на этом же сервере функционируют локальный регистратор (registry.local) и сервер подписей (sigstore.local), то IP-адрес балансировщика может совпадать c IP-адресами этих сервисов.

Если планируется создание отказоустойчивого решения на основе нескольких серверов haproxy, то для них кроме собственного IP-адреса необходимо будет для всех серверов haproxy выделить один общий IP-адрес, который будет иметь master-балансировщик.


Полная настройка отказоустойчивого кластера haproxy из 3-х узлов описана в документе ALT Container OS подветка K8S. Создание HA кластера.

Здесь же мы рассмотрим создание и настройка с одним сервером haproxy с балансировкой запросов на master-узлы.

Установите пакет haproxy: 

# apt-get install haproxy

Отредактируйте конфигурационный файл /etc/haproxy/haproxy.cfg:

  • добавьте в него описание frontend’a main, принимающего запросы по порту 8443: 
     frontend main
  bind *:8443
  mode tcp
  option tcplog
  default_backend apiserver
  • добавьте описание backend’а apiserver: 
    backend apiserver
  option httpchk GET /healthz
  http-check expect status 200
  mode tcp
  option ssl-hello-chk
  balance     roundrobin
      server master01 <IP_или_DNS_начального_мастер_узла>:6443 check
  • запустите haproxy:
# systemctl enable haproxy
# systemctl start haproxy

Инициализация master-узла

Инициализация мастер-узла при работа с балансировщиков haproxy

При установке начального master-узла необходимо параметром control-plane-endpoint указать URL балансировщика haproxy: 

# kubeadm init --apiserver-advertise-address 192.168.122.80 --control-plane-endpoint <IP_адрес_haproxy>:8443

При запуске в параметре --apiserver-advertise-address укажите IP-адрес API-интерфейса kube-apiserver.

IP-адреса в параметрах --apiserver-advertise-address и --control-plane-endpoint должны отличаться. Если Вы развернули haproxy на том же мастер-узле, поднимите на сетевом нтерфейсе дополнительный IP-адрес и укажите его в параметре --control-plane-endpoint.

В результате инициализации kubeadm выведет команды подключения дополнительных control-plane и worker узлов: 

...
You can now join any number of the control-plane node running the following command on each as root:

kubeadm join <IP_адрес_haproxy>:8443 --token ... \
        --discovery-token-ca-cert-hash sha256:... \
        --control-plane --certificate-key ...

Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use
"kubeadm init phase upload-certs --upload-certs" to reload certs afterward.

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join <IP_адрес_haproxy>:8443 --token ... \
        --discovery-token-ca-cert-hash sha256:...
...

Обратите внимание - в командах присоединения узлов указывается не URL созданного начального master-узла (<IP_или_DNS_начального_мастер_узла>:6443), а URL haproxy.

В сформированных файлах конфигурации /etc/kubernetes/admin.conf, ~/.kube/config также указывается URL haproxy: 

apiVersion: v1
clusters:
- cluster:
...
    server: https://<IP_адрес_haproxy>:8443

То есть вся работа с кластеров в дальнейшем идет через балансировщик запросов haproxy.

Для перевода узла в состояние Ready, запуска coredns Pod’ов запустите flannel

Запуск сетевого маршрутизатора для контейнеров kube-flannel

На master-узле под пользоваталем root выполните команду: 

# kubectl apply -f /etc/kubernetes/manifests/kube-flannel.yml
Connected to the local host. Press ^] three times within 1s to exit session.
[INFO] Entering RootlessKit namespaces: OK
namespace/kube-flannel created
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.apps/kube-flannel-ds created
Connection to the local host terminated.

После завершения скрипта в течении минуты настраиваются сервисы мастер-узла кластера. По ее истечении проверьте работу usernetes (rootless kuber)

Подключение дополнительных master-узлов

Установка тропы PATH поиска исполняемых команд

Измените переменную PATH: 

export PATH=/usr/libexec/podsec/u7s/bin/:$PATH

Подключение master (control plane) узла

Скопируйте строку подключения control-plane узла и вызовите ее: 

# kubeadm join <IP_адрес_haproxy>:8443 --token ... \
        --discovery-token-ca-cert-hash sha256:... \
        --control-plane --certificate-key ...

В результате работы команда kubeadm выведет строки: 

 This node has joined the cluster and a new control plane instance was created:

* Certificate signing request was sent to apiserver and approval was received.
* The Kubelet was informed of the new secure connection details.
* Control plane label and taint were applied to the new node.
* The Kubernetes control plane instances scaled up.
* A new etcd member was added to the local/stacked etcd cluster.
...
Run 'kubectl get nodes' to see this node join the cluster.

Наберите на вновь созданном (или начальном)control-plane узле команду: 

# kubectl  get nodes
NAME       STATUS   ROLES           AGE     VERSION
<host1>   Ready    control-plane   4m31s   v1.26.3
<host2>   Ready    control-plane   26s     v1.26.3

Обратите внимание, что роль (ROLES) обоих узлов - control-plane.

Наберите команду: 

# kubectl get all -A
NAMESPACE      NAME                                   READY   STATUS    RESTARTS       AGE    IP             NODE       NOMINATED NODE   READINESS GATES
kube-flannel   pod/kube-flannel-ds-2mhqg              1/1     Running   0              153m   10.96.0.1      <host1>   <none>           <none>
kube-flannel   pod/kube-flannel-ds-95ht2              1/1     Running   0              153m   10.96.122.68   <host2>    <none>           <none>
...
kube-system    pod/etcd-<host1>                       1/1     Running   0              174m   10.96.0.1      <host1>   <none>           <none>
kube-system    pod/etcd-<host2>                       1/1     Running   0              170m   10.96.122.68   <host2>    <none>           <none>

kube-system    pod/kube-apiserver-<host1>             1/1     Running   0              174m   10.96.0.1      <host1>   <none>           <none>
kube-system    pod/kube-apiserver-<host2>             1/1     Running   0              170m   10.96.122.68   <host2>    <none>           <none>

kube-system    pod/kube-controller-manager-<host1>    1/1     Running   1 (170m ago)   174m   10.96.0.1      <host1>   <none>           <none>
kube-system    pod/kube-controller-manager-<host2>    1/1     Running   0              170m   10.96.122.68   <host2>    <none>           <none>

kube-system    pod/kube-proxy-9nbxz                   1/1     Running   0              174m   10.96.0.1      <host1>   <none>           <none>
kube-system    pod/kube-proxy-bnmd7                   1/1     Running   0              170m   10.96.122.68   <host2>    <none>           <none>

kube-system    pod/kube-scheduler-<host1>             1/1     Running   1 (170m ago)   174m   10.96.0.1      <host1>   <none>           <none>
kube-system    pod/kube-scheduler-<host2>             1/1     Running   0              170m   10.96.122.68   <host2>    <none>           <none>
...

NAMESPACE      NAME                             DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE    CONTAINERS     IMAGES                                      SELECTOR
kube-flannel   daemonset.apps/kube-flannel-ds   2         2         2       3            3           <none>                   153m   kube-flannel   registry.local/k8s-c10f1/flannel:v0.19.2      app=flannel
kube-system    daemonset.apps/kube-proxy        2         2         2       2            2           kubernetes.io/os=linux   174m   kube-proxy     registry.local/k8s-c10f1/kube-proxy:v1.26.3   k8s-app=kube-proxy
...

Убедитесь, что сервисы pod/etcd, kube-apiserver, kube-controller-manager, kube-scheduler, kube-proxy, kube-flannel запустились на обоих control-plane узлах.

Добавление master_узла в балансироващик haproxy

Для балансировки запросов по двум серверам добавьте URL подключенного control-plane узла в файл конфигурации /etc/haproxy/haproxy.cfg: 

backend apiserver
    option httpchk GET /healthz
    http-check expect status 200
    mode tcp
    option ssl-hello-chk
    balance     roundrobin
        server master01 <IP_или_DNS_начального_мастер_узла>:6443 check
        server master02 <IP_или_DNS_подключенного_мастер_узла>:6443 check

и перезапустите haproxy: 

# systemctl restart haproxy

Логи обращений и балансировку запросов между узлами можно посмотреть командой: 

# tail -f /var/log/haproxy.log

Подключение worker-узлов

Подключение дополнительных worker-узлов происходит аналогично описанному выше в главе Инициализация и подключение worker-узла.

Настройка отказоустойчивого кластера серверов haproxy, keepalived

Особенности разворачивания приложений kubernetes

При использовании сервисов типа NodePort поднятые в рамках кластера порты в диапазоне 30000-32767 остаются в namespace пользователя u7s-admin. Для их проброса наружу необходимо в пользователе u7s-admin запустить команду: 

$ nsenter_u7s rootlessctl add-ports 0.0.0.0:<port>:<port>/tcp

Сервисы типа NodePort из за их небольшого диапазона и "нестабильности" портов при переносе решения в другой кластер довольно редко используются. Рекомендуется вместо них использовать сервисы типа ClusterIP c доступом к ним через Ingress-контроллеры.

Установка и настройка ingress-контролера

Выбор регистратора образов

Во время инициализации master-узла кластера (kubeadm init) или во время подключения узла к кластеру (kubeadm join) команда kubeadm может загружать образы с различных регистраторов образов и с различными префиксами.

Выбор регистратора и префикса образов определяет переменная среды U7S_REGISTRY. Если переменная не задана регистратор префикс определяется автоматически на основе конфигурационных файлов /etc/os-release и /etc/hosts.

Переменная среды U7S_REGISTRY может принимать следующие основные значения:

  • пустое значение;
  • registry.altlinux.org/k8s-c10f1;
  • registry.altlinux.org/k8s-p10;
  • registry.local/k8s-c10f1;
  • registry.local/k8s-p10.

Native kubernetes регистратор

export U7S_REGISTRY=

Если переменная U7S_REGISTRY установлена в пустое значение образы загружаются со стандартного регистратора образов kubernetes.

Регистратор altlinux

С регистратора altlinux устанавливаются образы для которых не требуются ограничения политики доступа для различных категория пользователей:

  • export U7S_REGISTRY=registry.altlinux.org/k8s-c10f1 - образы для сертфицированного дистрибутива c10;
  • export U7S_REGISTRY=registry.altlinux.org/k8s-p10 - образы для несертфицированного дистрибутива p10.

podsec - Локальный регистратор

C локального регистраторе, как правило, устанавливается подписанные образы с ограничением политики доступа для различных категория пользователей, устанавливаемые скриптами пакета podsec. cjplf.ncz Эти образы создаются (копируются с регистраторов с созданием алиаса в домене registry.local, строятся на основе Dockerfile и т.п.) пользователями группы podsec_dev, подписываются и загружаются в локальный регистратор registry.local.

Подробности по установке rootless kubernetes в этом режиме описаны в документе Установка и настройка U7S (rootless kuber).


  • export U7S_REGISTRY=registry.local/k8s-c10f1 - образы для сертифицированного дистрибутива c10;
  • export U7S_REGISTRY=registry.local/k8s-p10 - образы для несертифицированного дистрибутива p10.

Настройка политики доступа к образам различным категориям пользователей

Поддержка электронной подписи образов

Автоматический выбор регистратора образов

Если переменная U7S_REGISTRY не установлена, ее значения вычисляется автоматически по следующему алгоритму:

  • Если файл /etc/hosts содержит описание хоста registry.local префикс переменной U7S_REGISTRY принимает значение registry.local/, иначе registry.altlinux.org/.
  • Если переменная CPE_NAME файла /etc/os-release содержит значение spserver суффикс переменной U7S_REGISTRY принимает значение k8s-c10f1, иначе k8s-p10.

podsec-k8s-rbac - Поддержка управление доступом на основе ролей (RBAC)

podsec-inotify - Мониторинг безопасности системы