Katamarina - PaaS-платформа для построения облачных инфраструктур. – Katamarina OS

Docs: Руководство по установке

Mon, 01 Jan 0001 00:00:00 +0000

Требования к минимальной конфигурации:

Управляющий узел (виртуальная машина с Linux) - как минимум 1 шт.:

Любая Linux-подобная ОС, включая российские (РЕД ОС, Альт, Астра Линукс)
Наличие 500 МБ свободного места на диске.
Наличие установленной и работоспособной утилиты kubectl версии 1.33 и выше.
Для установки kubectl можно использовать руководство: https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/

Вычислительный узел (пустая виртуальная машина или физический сервер без установленной операционной системы):

Архитектура: x86_64
vCPU/CPU: 4 ядра
vRAM/RAM: 16 GB
Основной диск: чистый диск, размер от 20ГБ (в формате RAW/IDE для виртуальной машины)
Дополнительный диск (опционально): чистый диск, размер от 200ГБ (в формате RAW/IDE для виртуальной машины)
Сеть: IPv4, обязательно автоматическое получение адреса по DHCP при загрузке

Подготовительные действия для вычислительного узла (выполняются в системе управления виртуальными машинами или management-консоли сервера):

Загрузить ISO-образ по ссылке:

http://files.katamarina.ru/download

Подключить ISO-образ к виртуальной машине (или через виртуальный CD-ROM к серверу).
Выставить порядок загрузки устройств, чтобы он начинался с ISO/CD-ROM.
Включить виртуальную машину/сервер.
Дождаться загрузки с ISO-образа.

Корректно загруженная система должна выглядеть следующим образом:

Убедиться, что в верхней панели статуса присутствует поле KATAMARINA v1.11*, в поле STAGE отображается статус “Maintenance”.

Сохранить/запомнить присвоенный по DHCP управляющий IP-адрес вычислительного узла для следующего шага (в примере - 192.168.122.34).

В случае отличий - произвести полную очистку основного диска (или пересоздать новый (в случае ВМ) и перезагрузить систему с ISO-образа заново).

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

Установка выполняется из под пользователя с правами администратора/root.

1. Установить управляющую утилиту:

curl -sL http://files.katamarina.ru/scripts/install |sh

2. Проверить корректность установки (вывод должен совпадать):

talosctl

Пример корректного вывода команды:

A CLI for out-of-band management of Kubernetes nodes created by Talos
Usage:
talosctl [command]
Available Commands:
apply-config Apply a new configuration to a node
root@demo:~#

3. Установить управляющий IP-адрес вычислительного узла (который был сохранен в предыдущем шаге):

export TALOS_CONTROL_PLANE_IP=192.168.122.34

4. Сгенерировать конфигурацию для будущего кластера:

talosctl gen config katamarina-demo https://$TALOS_CONTROL_PLANE_IP:6443

Пример корректного вывода команды:

generating PKI and tokens
Created /root/controlplane.yaml
Created /root/worker.yaml
Created /root/talosconfig
root@demo:~#

5. Применить конфигурацию вычислительного узла:

talosctl apply-config --insecure -n $TALOS_CONTROL_PLANE_IP --file ./controlplane.yaml

6. Вычислительный узел будет автоматически перезагружен, дождаться перезагрузки.

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

Убедиться, что IP-адрес вычислительного узла остался прежним (в примере - 192.168.122.34).

7. Инициализировать базовую конфигурацию кластера:

Команды далее - по прежнему выполняются в консоли управляющего узла.

talosctl bootstrap --nodes $TALOS_CONTROL_PLANE_IP --endpoints $TALOS_CONTROL_PLANE_IP --talosconfig=./talosconfig

8. Сформировать кластер:

talosctl kubeconfig kubeconf --nodes $TALOS_CONTROL_PLANE_IP --endpoints $TALOS_CONTROL_PLANE_IP --talosconfig ./talosconfig

9. Проверить, что управляющий кластер был сформирован.

./kubectl --kubeconfig ./kubeconf get nodes

Пример корректного вывода команды:

NAME STATUS ROLES AGE VERSION
talos-xxq-hug NotReady control-plane 21s v1.34.1
root@demo:~#

Базовая установка завершена, для дальнейшего конфигурирования используйте Руководство Администратора.

Docs: Руководство Администратора платформы

Mon, 01 Jan 0001 00:00:00 +0000

Администрирование и устранение неполадок

Устранение неполадок в Control Plane и других сбоев в кластерах Talos Linux.

В этом руководстве мы предполагаем, что Talos настроен с включенными по умолчанию функциями, такими как Служба обнаружения и KubePrism. Если эти функции отключены, некоторые из шагов по устранению неполадок могут быть неприменимы или потребовать корректировки.

Данное руководство построено таким образом, что его можно выполнять шаг за шагом; пропускайте разделы, не относящиеся к вашей проблеме.

Настройка сети

Поскольку Talos Linux — это операционная система, основанная на API, важно настроить сеть таким образом, чтобы обеспечить доступ к API. Некоторую информацию можно получить с помощью интерактивной панели мониторинга, доступной на консоли машины.

При работе в облаке сетевые настройки должны выполняться автоматически. В то время как при работе на физическом оборудовании может потребоваться более специфичная конфигурация, см. руководство по настройке сети на физическом оборудовании.

API Talos

API Talos работает на порту 50000 (../learn-more/talos-network-connectivity). Узлы Control Plane всегда должны предоставлять доступ к API Talos, в то время как рабочие узлы нуждаются в доступе к узлам Control Plane для выдачи TLS-сертификатов для рабочих узлов.

Проблемы с брандмауэром

Убедитесь, что брандмауэр не блокирует порт 50000 и коммуникацию на портах 50000/50001 внутри кластера.

Проблемы с конфигурацией клиента

Убедитесь, что используете правильный файл конфигурации клиента talosconfig, соответствующий вашему кластеру. Дополнительную информацию см. в разделе начало работы.

Наиболее распространенная проблема заключается в том, что команда talosctl gen config записывает talosconfig в файл в текущем каталоге, в то время как talosctl по умолчанию берет конфигурацию из стандартного расположения (~/.talos/config). Путь к файлу конфигурации можно указать с помощью флага --talosconfig в команде talosctl.

Конфликт в Kubernetes и подсетях хоста

Если talosctl возвращает ошибку, указывающую на то, что IP-адреса сертификатов пусты, это может быть связано с конфликтом между Kubernetes и подсетями хоста. API Talos работает в хост-сети, но автоматически исключает подсети и сети Kubernetes из набора доступных адресов.

В конфигурации машины Talos по умолчанию указаны следующие IPv4 CIDR для подов и сервисов Kubernetes: 10.244.0.0/16 и 10.96.0.0/12. Если в хост-сети используется одна из этих подсетей, измените конфигурацию машины, чтобы использовать другую подсеть.

Неверные конечные точки

Интерфейс командной строки talosctl подключается к API Talos через указанные конечные точки, которые должны представлять собой список адресов машин Control Plane. В случае недоступности каких-либо конечных точек клиент автоматически повторит попытку подключения к другим точкам доступа.

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

Адрес VIP ни в коем случае нельзя использовать в качестве конечной точки API Talos.

TCP-балансировщик нагрузки

При использовании балансировщика нагрузки TCP убедитесь, что конечная точка балансировщика нагрузки включена в список .machine.certSANs в конфигурации машины.

Системные требования

Если минимальные системные требования не соблюдены, это может проявляться различными способами, например, в виде случайных сбоев при запуске служб или сбоев при загрузке образов из реестра контейнеров.

Проведение проверок состояния здоровья

Talos Linux предоставляет набор базовых проверок работоспособности с помощью команды talosctl health, которую можно использовать для проверки состояния кластера.

В режиме по умолчанию команда talosctl health использует информацию из discovery для получения сведений о членах кластера. Это можно переопределить с помощью флагов командной строки --control-plane-nodes и --worker-nodes.

Журналы сбора

Хотя журналы и состояние системы можно запросить через API Talos, часто бывает полезно собрать журналы со всех узлов кластера и проанализировать их в автономном режиме. Команда talosctl support позволяет собирать журналы и другую информацию с узлов, указанных с помощью флага --nodes (поддерживается несколько узлов).

Обнаружение и членство в кластере

Talos Linux использует службу обнаружения для обнаружения других узлов в кластере.

Список участников на каждой машине должен быть согласованным: talosctl -n <IP> get members.

Некоторые участники отсутствуют

Убедитесь в наличии подключения к службе обнаружения (по умолчанию discovery.talos.dev:443) и в том, что реестр обнаружения не отключен.

Дублирующиеся участники

Не используйте одни и те же базовые секреты для генерации конфигурации машин для нескольких кластеров, поскольку некоторые секреты используются для идентификации членов одного и того же кластера. Таким образом, если одна и та же конфигурация машины (или секреты) используется для многократного создания и уничтожения кластеров, служба обнаружения будет видеть одни и те же узлы как членов разных кластеров.

Удаленные участники все еще присутствуют

Talos Linux удаляет себя из службы обнаружения при перезагрузке. Если устройство не было перезагружено, оно может отображаться как участник кластера в течение максимального времени жизни службы обнаружения (30 минут), после чего будет автоматически удалено.

Проблемы с `etcd`

etcd — это распределенное хранилище типа «ключ-значение», используемое Kubernetes для хранения своего состояния. Talos Linux предоставляет средства автоматизации для управления компонентами etcd, работающими на узлах Control Plane. Если etcd неисправен, сервер API Kubernetes не сможет корректно функционировать.

Всегда рекомендуется запускать нечетное количество участников etcd, поскольку при наличии 3 или более участников обеспечивается отказоустойчивость в случае сбоев меньшего количества участников, чем необходимо для достижения кворума.

Типичные шаги по устранению неполадок:

Проверьте состояние службы etcd с помощью команды talosctl -n IP service etcd для каждого узла Control Plane.
Проверьте принадлежность etcd к каждому узлу Control Plane с помощью команды talosctl -n IP etcd members.
Проверьте логи etcd с помощью команды talosctl -n IP logs etcd
Проверьте наличие оповещений etcd с помощью команды talosctl -n IP etcd alarm list

Все службы `etcd` застряли в состоянии `Pre`

Убедитесь, что хотя бы один участник был запущен.

Убедитесь, что машина может загрузить образ контейнера etcd, проверьте talosctl dmesg на наличие сообщений, начинающихся с префикса retrying:.

Некоторые службы `etcd` застряли в состоянии `Pre`

Убедитесь, что трафик на порту 2380 между узлами Control Plane не заблокирован.

Убедитесь, что кворум etcd не потерян.

Убедитесь, что все узлы Control Plane отображаются в выводе команды talosctl get members.

Отчеты и оповещения `etcd`

См. руководство по обслуживанию etcd.

Кворум `etcd` потерян

См. руководство по аварийному восстановлению.

Другие вопросы

etcd будет запускаться только на узлах Control Plane. Если узел назначен рабочим узлом, не следует ожидать, что на нем будет запущена команда etcd.

При первой загрузке узла каталог данных etcd (/var/lib/etcd) пуст и будет заполнен только при запуске etcd.

Если служба etcd аварийно завершает работу и перезапускается, проверьте ее журналы с помощью команды talosctl -n <IP> logs etcd. Наиболее распространенные причины аварий:

Неверные аргументы, переданные через extraArgs в конфигурации;
При загрузке Talos с непустого диска с уже установленной Talos, /var/lib/etcd содержит данные из старого кластера.

Проблемы с `kubelet` и узлами Kubernetes

Сервис kubelet должен быть запущен на всех узлах Talos и отвечает за запуск подов Kubernetes. статические поды (включая компоненты Control Plane) и регистрация узла на сервере API Kubernetes.

Если kubelet не запущен на узле Control Plane, он заблокирует запуск компонентов Control Plane.

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

`kubelet` не запущен

Убедитесь, что образ kubelet доступен (talosctl image ls --namespace system).

Проверьте логи kubelet с помощью команды talosctl -n IP logs kubelet на наличие ошибок запуска:

Убедитесь, что версия Kubernetes поддерживается в этом релизе Talos.
Убедитесь, что дополнительные аргументы kubelet и дополнительная конфигурация, предоставляемая вместе с конфигурацией машины Talos, являются допустимыми.

Talos выдает ошибку “Узел не найден”

kubelet еще не зарегистрировал узел на сервере API Kubernetes; это ожидаемое поведение на этапе первоначальной загрузки кластера, после чего ошибка исчезнет. Если сообщение не исчезает, проверьте работоспособность API Kubernetes.

Менеджер контроллеров Kubernetes («kube-controller-manager») отвечает за мониторинг сертификата. подписание запросов на подписание сертификатов (CSR) и выдача сертификатов по каждому из них. «Кублетт» отвечает за генерацию и отправку запросов на обслуживание клиентов (CSR) для своего приложения. связанный узел.

Состояние любого запроса на подписание сертификата (CSR) можно проверить с помощью команды kubectl get csr:

$ kubectl get csr
NAME AGE SIGNERNAME REQUESTOR CONDITION
csr-jcn9j 14m kubernetes.io/kube-apiserver-client-kubelet system:bootstrap:q9pyzr Approved,Issued
csr-p6b9q 14m kubernetes.io/kube-apiserver-client-kubelet system:bootstrap:q9pyzr Approved,Issued
csr-sw6rm 14m kubernetes.io/kube-apiserver-client-kubelet system:bootstrap:q9pyzr Approved,Issued
csr-vlghg 14m kubernetes.io/kube-apiserver-client-kubelet system:bootstrap:q9pyzr Approved,Issued

Команда `kubectl get nodes` выдает ошибку “Неверный внутренний IP-адрес”.

Настройте правильный внутренний IP-адрес с помощью .machine.kubelet.nodeIP

Команда `kubectl get nodes` выдает ошибку “Неверный внешний IP-адрес”.

Talos Linux не управляет внешним IP-адресом, это делается с помощью Kubernetes Cloud Controller Manager.

Команда `kubectl get nodes` выдает ошибку “Неверное имя узла”.

По умолчанию имя узла Kubernetes определяется на основе имени хоста. Обновите имя хоста, используя конфигурацию машины, облачную конфигурацию или DHCP-сервер.

Узел не готов

В Kubernetes узел помечается как «готовый» только после того, как его CNI-интерфейс будет активирован. Загрузка изображений CNI и запуск CNI занимают минуту-две. Если узел застрял в этом состоянии слишком долго, проверьте поды CNI и логи с помощью kubectl. Как правило, ресурсы, связанные с CNI, создаются в пространстве имен kube-system.

Например, для стандартного CNI Talos Flannel:

$ kubectl -n kube-system получить модули
NAME READY STATUS RESTARTS AGE
...
kube-flannel-25drx 1/1 Running 0 23m
kube-flannel-8lmb6 1/1 Running 0 23m
kube-flannel-gl7nx 1/1 Running 0 23m
kube-flannel-jknt9 1/1 Running 0 23m
...

Дублирующиеся/Устаревшие узлы

Talos Linux не удаляет узлы Kubernetes автоматически, поэтому, если узел удален из кластера, он все равно останется в Kubernetes. Удалите узел из Kubernetes с помощью команды kubectl delete node <node-name>.

Talos жалуется на ошибки сертификатов в API `kubelet`

Эта ошибка может появиться во время начальной загрузки кластера и исчезнет после запуска сервера API Kubernetes и регистрации узла.

Пример логов Talos:

[talos] controller failed {"component": "controller-runtime", "controller": "k8s.KubeletStaticPodController", "error": "error refreshing pod status: error fetching pod status: Get \"https://127.0.0.1:10250/pods/?timeout=30s\": remote error: tls: internal error"}

По умолчанию kubelet выдает самоподписанный серверный сертификат, но при включении функции rotate-server-certificates, kubelet выдает свой сертификат, используя kube-apiserver. Убедитесь, что запрос на подписание сертификата kubelet одобрен сервером API Kubernetes.

В любом случае, эта ошибка не является критической, поскольку она влияет только на передачу информации о состоянии пода в Talos Linux.

Control Plane Kubernetes

Control Plane Kubernetes состоит из следующих компонентов:

kube-apiserver — API-сервер Kubernetes
kube-controller-manager — менеджер контроллеров Kubernetes
kube-scheduler — планировщик Kubernetes

При желании kube-proxy может запускаться как DaemonSet для обеспечения связи между подом и сервисом.

coredns обеспечивает разрешение имен для кластера.

CNI не является частью Control Plane, но он необходим для подов Kubernetes, использующих сетевое взаимодействие между подами.

Поиск и устранение неисправностей всегда следует начинать с kube-apiserver, а затем переходить к другим компонентам.

В Talos Linux kube-apiserver настроен на взаимодействие с etcd, работающим на том же узле, поэтому etcd должен быть работоспособен, прежде чем kube-apiserver сможет запуститься. Компоненты kube-controller-manager и kube-scheduler настроены на взаимодействие с компонентом kube-apiserver на том же узле, поэтому они не запустятся, пока kube-apiserver не будет работать корректно.

Статические модули Control Plane

Talos должен генерировать статические определения подов для Control Plane Kubernetes. в качестве ресурсов:

$ talosctl -n <IP> get staticpods
NODE NAMESPACE TYPE ID VERSION
172.20.0.2 k8s StaticPod kube-apiserver 1
172.20.0.2 k8s StaticPod kube-controller-manager 1
172.20.0.2 k8s StaticPod kube-scheduler 1

Talos должен сообщить, что статические определения подов отображаются для kubelet:

$ talosctl -n <IP> dmesg | grep 'rendered new'
172.20.0.2: user: warning: [2023-04-26T19:17:52.550527204Z]: [talos] rendered new static pod {"component": "controller-runtime", "controller": "k8s.StaticPodServerController", "id": "kube-apiserver"}
172.20.0.2: user: warning: [2023-04-26T19:17:52.552186204Z]: [talos] rendered new static pod {"component": "controller-runtime", "controller": "k8s.StaticPodServerController", "id": "kube-controller-manager"}
172.20.0.2: user: warning: [2023-04-26T19:17:52.554607204Z]: [talos] rendered new static pod {"component": "controller-runtime", "controller": "k8s.StaticPodServerController", "id": "kube-scheduler"}

Если статические определения подов не отображаются, проверьте состояние служб etcd и kubelet (см. выше). а также журналы выполнения контроллера (talosctl logs controller-runtime).

Состояние модуля управления

Изначально компонент kube-apiserver не будет запущен, и потребуется некоторое время, прежде чем он полностью заработает. во время загрузки Bootstrap (изображение следует брать из интернета и т. д.)

Состояние компонентов Control Plane на каждом из узлов Control Plane можно проверить с помощью команды talosctl containers -k:

$ talosctl -n <IP> containers --kubernetes
NODE NAMESPACE ID IMAGE PID STATUS
172.20.0.2 k8s.io kube-system/kube-apiserver-talos-default-controlplane-1 registry.k8s.io/pause:3.2 2539 SANDBOX_READY
172.20.0.2 k8s.io └─ kube-system/kube-apiserver-talos-default-controlplane-1:kube-apiserver:51c3aad7a271 registry.k8s.io/kube-apiserver:v1.35.0 2572 CONTAINER_RUNNING

Журналы компонентов Control Plane можно проверить с помощью команды talosctl logs --kubernetes (или с помощью -k в качестве сокращенной записи):

talosctl -n <IP> logs -k kube-system/kube-apiserver-talos-default-controlplane-1:kube-apiserver:51c3aad7a271

Если компонент control plane сообщает об ошибке при запуске, проверьте следующее:

Убедитесь, что версия Kubernetes поддерживается в этом релизе Talos.
Убедитесь, что дополнительные аргументы и дополнительные параметры конфигурации, предоставленные вместе с конфигурацией машины Talos, являются допустимыми.

Манифесты начальной загрузки Kubernetes

В рамках процесса начальной загрузки Talos внедряет манифесты начальной загрузки в API-сервер Kubernetes. Существует два типа таких манифестов: системные манифесты, встроенные в Talos, и дополнительные манифесты, загружаемые извне (пользовательские CNI, дополнительные манифесты в конфигурации машины):

$ talosctl -n <IP> get manifests
NODE NAMESPACE TYPE ID VERSION
172.20.0.2 controlplane Manifest 00-kubelet-bootstrapping-token 1
172.20.0.2 controlplane Manifest 01-csr-approver-role-binding 1
172.20.0.2 controlplane Manifest 01-csr-node-bootstrap 1
172.20.0.2 controlplane Manifest 01-csr-renewal-role-binding 1
172.20.0.2 controlplane Manifest 02-kube-system-sa-role-binding 1
172.20.0.2 controlplane Manifest 03-default-pod-security-policy 1
172.20.0.2 controlplane Manifest 05-https://docs.projectcalico.org/manifests/calico.yaml 1
172.20.0.2 controlplane Manifest 10-kube-proxy 1
172.20.0.2 controlplane Manifest 11-core-dns 1
172.20.0.2 controlplane Manifest 11-core-dns-svc 1
172.20.0.2 controlplane Manifest 11-kube-config-in-cluster 1

Подробную информацию о каждом манифесте можно получить, добавив параметр -o yaml:

$ talosctl -n <IP> get manifests 01-csr-approver-role-binding --namespace=controlplane -o yaml
node: 172.20.0.2
metadata:
namespace: controlplane
type: Manifests.kubernetes.talos.dev
id: 01-csr-approver-role-binding
version: 1
phase: running
spec:
- apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: system-bootstrap-approve-node-client-csr
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:certificates.k8s.io:certificatesigningrequests:nodeclient
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:bootstrappers

Другие компоненты Control Plane

После запуска сервера API Kubernetes проблемы с другими компонентами Control Plane можно устранить с помощью команды kubectl:

kubectl get nodes -o wide
kubectl get pods -o wide --all-namespaces
kubectl describe pod -n NAMESPACE POD
kubectl logs -n NAMESPACE POD

API Kubernetes

Конфигурацию клиента Kubernetes API (kubeconfig) можно получить с помощью Talos API, используя команду talosctl -n <IP> kubeconfig. В Talos Linux кластер в основном не зависит от конечной точки API Kubernetes, но конечную точку API Kubernetes следует настроить. корректно обеспечивается внешний доступ к кластеру.

Конечная точка Control Plane Kubernetes

Конечная точка Control Plane Kubernetes — это единственный канонический URL-адрес, по которому осуществляется доступ к API Kubernetes. В частности, в системах управления с высокой доступностью (HA) эта конечная точка может указывать на балансировщик нагрузки или DNS-имя, которое может имеют несколько записей типа A и AAAA.

Подобно собственному API Talos, API Kubernetes использует взаимный TLS, клиентское соединение. сертификаты и общий центр сертификации (ЦС). В отличие от веб-сайтов общего назначения, здесь нет необходимости в вышестоящем центре сертификации, поэтому инструменты не требуют дополнительных настроек. например, cert-manager, Let’s Encrypt или подобные продукты. поскольку подтвержденные TLS-сертификаты не требуются. Однако шифрование есть, поэтому схема URL всегда будет https://.

По умолчанию сервер API Kubernetes в Talos работает на порту 6443. Таким образом, URL-адреса конечных точек Control Plane для Talos почти всегда будут иметь следующий вид: https://endpoint:6443. (Необходимо указать порт, поскольку он не соответствует порту по умолчанию 443 (https:// … Указанная выше endpoint может быть DNS-именем или IP-адресом, но она должна быть следующей: направлено на множество всех узлов Control Plane, в отличие от один.

Как уже упоминалось выше, этого можно достичь с помощью ряда стратегий, в том числе:

внешний балансировщик нагрузки
DNS-записи
Встроенный в Talos общий IP-адрес ( VIP)
Установление BGP-пиринга для общего IP-адреса (например, с помощью kube-vip)

Использование DNS-имени здесь — хорошая идея, поскольку это позволяет использовать любой другой вариант, одновременно предоставляя… слой абстракции. Это позволяет изменять базовые IP-адреса без влияния на канонический URL.

В отличие от большинства сервисов в Kubernetes, API-сервер работает в рамках сетевой инфраструктуры хоста. Это означает, что он использует то же сетевое пространство имен, что и хост. Это означает, что вы можете использовать IP-адрес(а) хоста для обращения к Kubernetes. API-сервер.

Для обеспечения доступности API важно, чтобы любой балансировщик нагрузки был осведомлен о следующем: проверка работоспособности серверов бэкэнд-API для минимизации сбоев во время работы. Типичные операции с узлами, такие как перезагрузка и обновление.

Прочее

Проверка журналов выполнения контроллера

Talos использует набор контроллеров, которые работают с ресурсами для построения и поддержки операций машины.

Некоторую отладочную информацию можно получить из логов контроллера с помощью команды talosctl logs controller-runtime:

talosctl -n <IP> logs controller-runtime

Контроллеры постоянно работают в цикле согласования, поэтому в любой момент времени они могут запускаться, выходить из строя или перезапускаться. Это ожидаемое поведение.

Если в журнале controller-runtime нет новых сообщений, это означает, что контроллеры успешно завершили согласование, и текущее состояние системы соответствует желаемому состоянию системы.

Docs: Руководство Пользователя платформы

Mon, 01 Jan 0001 00:00:00 +0000

Интерактивная панель управления

Инструмент для проверки состояния работающей системы

Интерактивная панель мониторинга включена для всех платформ, кроме образов SBC. Панель мониторинга можно отключить с помощью параметра ядра talos.dashboard.disabled=1

Панель управления работает только на физической видеоконсоли (не последовательной консоли) на втором виртуальном терминале (TTY). Первый виртуальный терминал отображает журналы ядра. Переключение между виртуальными терминалами осуществляется с помощью клавиш <Alt+F1>и <Alt+F2>

Клавиши <F1>— <Fn>используются для переключения между различными экранами панели управления.

Панель управления использует либо фреймбуфер UEFI, либо фреймбуфер VGA/VESA (для загрузки через устаревший BIOS).

Управление разрешением панели управления

В системах со старым BIOS разрешение экрана можно настроить с помощью vga= kernel parameter.

В современных ядрах и платформах этот параметр часто игнорируется. Для получения надежных результатов рекомендуется загрузка с UEFI .

При работе в режиме UEFI разрешение экрана можно установить через настройки гипервизора или микропрограммы UEFI.

Сводная информация (`F1`)

В заголовке представлена краткая информация об узле:

имя хоста
версия ОС
время безотказной работы
информация об аппаратном обеспечении процессора и памяти
загрузка ЦП и памяти, количество процессов

В табличном представлении отображается сводная информация о машине:

UUID (из данных SMBIOS)
имя кластера (если доступна конфигурация машины)
этап работы машины: Installing, Upgrading, Booting, Maintenance, Running, Rebooting, Shutting down, и т. д.
проверка готовности этапа работы машины: проверяет состояние сервиса Talos, состояние статического модуля и т. д. (для Runningэтапа).
тип машины: плоскость управления/рабочий узел
количество обнаруженных членов в кластере
версия Kubernetes
состояние компонентов Kubernetes kubeletи компонентов плоскости управления Kubernetes (только на controlplaneмашинах)
информация о сети: имя хоста, адреса, шлюз, подключение, DNS и NTP-серверы.

В нижней части экрана отображаются журналы ядра, как и на виртуальном терминале TTY 1.

Экран монитора (`F2`)

На экране монитора отображается информация об использовании ресурсов машины в режиме реального времени: ЦП, память, дисковое пространство, сеть и процессы.

Экран настройки сети (`F3`)

Примечание: экран настройки сети доступен только для metal платформ.

Экран настройки сети предоставляет возможности редактирования metal конфигурации сети платформы.

Экран разделён на три секции:

В самом левом разделе можно ввести параметры сетевой конфигурации: имя хоста, DNS и NTP-серверы, настроить сетевой интерфейс (через DHCP или статический IP-адрес) и т.д.
В средней части отображается текущая конфигурация сети.
В самой правой части отображается конфигурация сети, которая будет применена после нажатия кнопки «Сохранить».

После сохранения конфигурации сетевой конфигурации платформы она немедленно применяется к машине.

Katamarina - PaaS-платформа для построения облачных инфраструктур. – Katamarina OS

Docs: Руководство по установке

Требования к минимальной конфигурации:

Управляющий узел (виртуальная машина с Linux) - как минимум 1 шт.:

Вычислительный узел (пустая виртуальная машина или физический сервер без установленной операционной системы):

Подготовительные действия для вычислительного узла (выполняются в системе управления виртуальными машинами или management-консоли сервера):

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

Docs: Руководство Администратора платформы

Администрирование и устранение неполадок

Настройка сети

API Talos

Проблемы с брандмауэром

Проблемы с конфигурацией клиента

Конфликт в Kubernetes и подсетях хоста

Неверные конечные точки

TCP-балансировщик нагрузки

Системные требования

Проведение проверок состояния здоровья

Журналы сбора

Обнаружение и членство в кластере

Некоторые участники отсутствуют

Дублирующиеся участники

Удаленные участники все еще присутствуют

Проблемы с etcd

Все службы etcd застряли в состоянии Pre

Некоторые службы etcd застряли в состоянии Pre

Отчеты и оповещения etcd

Кворум etcd потерян

Другие вопросы

Проблемы с kubelet и узлами Kubernetes

kubelet не запущен

Talos выдает ошибку “Узел не найден”

Команда kubectl get nodes выдает ошибку “Неверный внутренний IP-адрес”.

Команда kubectl get nodes выдает ошибку “Неверный внешний IP-адрес”.

Команда kubectl get nodes выдает ошибку “Неверное имя узла”.

Узел не готов

Дублирующиеся/Устаревшие узлы

Talos жалуется на ошибки сертификатов в API kubelet

Control Plane Kubernetes

Статические модули Control Plane

Состояние модуля управления

Манифесты начальной загрузки Kubernetes

Другие компоненты Control Plane

API Kubernetes

Конечная точка Control Plane Kubernetes

Прочее

Проверка журналов выполнения контроллера

Docs: Руководство Пользователя платформы

Интерактивная панель управления

Управление разрешением панели управления

Сводная информация (F1)

Экран монитора (F2)

Экран настройки сети (F3)

Проблемы с `etcd`

Все службы `etcd` застряли в состоянии `Pre`

Некоторые службы `etcd` застряли в состоянии `Pre`

Отчеты и оповещения `etcd`

Кворум `etcd` потерян

Проблемы с `kubelet` и узлами Kubernetes

`kubelet` не запущен

Команда `kubectl get nodes` выдает ошибку “Неверный внутренний IP-адрес”.

Команда `kubectl get nodes` выдает ошибку “Неверный внешний IP-адрес”.

Команда `kubectl get nodes` выдает ошибку “Неверное имя узла”.

Talos жалуется на ошибки сертификатов в API `kubelet`

Сводная информация (`F1`)

Экран монитора (`F2`)

Экран настройки сети (`F3`)