Работа с Virtual (Shared) IP

Для упрощения создания кластера поддерживается «виртуальный» IP-адрес (VIP) для доступа к API Kubernetes, обеспечивая высокую доступность без необходимости использования дополнительных ресурсов. В этом случае управляющие узлы конкурируют за контроль над общим IP-адресом с помощью выбора в etcd. В любой момент времени IP-адресом может владеть только один управляющий узел. Если предыдущий владелец перестанет быть доступным, будет выбран другой владелец, и он займет IP-адрес.

Требования

Control-plane узлы должны быть доступны в общей подсети на уровне L2. Виртуальный IP-адрес должен быть зарезервированным, неиспользуемым IP-адресом в той же подсети, что и управляющие узлы. VIP не должен назначаться или быть назначаемым вашим DHCP-сервером. На практике это означает, что все управляющие узлы соединены через коммутатор, без какого-либо промежуточного маршрутизатора.

Обратите внимание, что для назначения и управления виртуальным IP-адресом используется etcd, который должен быть в запущенном состоянии. Виртуальный IP-адрес не ограничен портами — вы можете получить доступ к любому порту, на котором работают управляющие узлы, по этому IP-адресу. Таким образом, VIP может быть настроен, как точка доступа Kubernetes API, но доступ к конечной точке API кластера ALT Orchetsra (endpoint) через VIP не рекомендуется, поскольку вы не сможете получить доступ к VIP, когда etcd недоступен, и тогда вы не сможете получить доступ к API для восстановления etcd.

Добавление VIP

Патч для создания VIP:

[
  {
    "op": "add",
    "path": "/machine/network/interfaces",
    "value": [
      {
        "deviceSelector": {
          "physical": true
        },
        "dhcp": true,
        "vip": {
          "ip": "192.168.1.100"
        }
      }
    ]
  }
]

Выполнить патч для всех узлов Controlplane:

talosctl -n 192.168.1.8 patch machineconfig -p '[{"op":"add","path":"/machine/network/interfaces","value":[{"deviceSelector":{"physical":true},"dhcp":true,"vip":{"ip":"192.168.1.100"}}]}]'
talosctl -n 192.168.1.7 patch machineconfig -p '[{"op":"add","path":"/machine/network/interfaces","value":[{"deviceSelector":{"physical":true},"dhcp":true,"vip":{"ip":"192.168.1.100"}}]}]'
talosctl -n 192.168.1.4 patch machineconfig -p '[{"op":"add","path":"/machine/network/interfaces","value":[{"deviceSelector":{"physical":true},"dhcp":true,"vip":{"ip":"192.168.1.100"}}]}]'
talosctl -n 192.168.1.3 patch machineconfig -p '[{"op":"add","path":"/machine/network/interfaces","value":[{"deviceSelector":{"physical":true},"dhcp":true,"vip":{"ip":"192.168.1.100"}}]}]'
talosctl -n 192.168.1.2 patch machineconfig -p '[{"op":"add","path":"/machine/network/interfaces","value":[{"deviceSelector":{"physical":true},"dhcp":true,"vip":{"ip":"192.168.1.100"}}]}]'

Примерный вывод:

patched MachineConfigs.config.talos.dev/v1alpha1 at the node 192.168.1.2
Applied configuration without a reboot

Убедиться, что виртуальный адрес присвоен:

talosctl get addresses 2>/dev/null | grep 192.168.1.100

Примерный вывод:

192.168.1.3   network     AddressStatus   ens19/192.168.1.100/32                     1         192.168.1.100/32               ens19

Проверка Работы VIP

Скопировать конфигурацию k8s:

cp ~/.kube/config ~/vipk8sconfig

Заменить IP-адрес на виртуальный:

sed -i 's|192.168.1.2|192.168.1.100|g' ~/vipk8sconfig

Создать скрипт отслеживания адреса:

echo 'talosctl get addresses -e <Адреса Controlplane, кроме узла с VIP> | grep 192.168.1.100' > get.sh

Запустить отслеживание в разных терминалах:

watch -n 5 ./get.sh
watch KUBECONFIG=~/vipk8sconfig kubectl get nodes -o wide

Остановить узел, где запущен VIP.

Проверить, что виртуальный IP-адрес сменился с текущего узла на другой (например, с 192.168.1.3 на 192.168.1.4).

С отслеживанием kubectl с виртуальным IP происходит следующее:

1. После отключения доступ на какое-то время недоступен: Unable to connect to the server: dial tcp 192.168.1.100:6443: i/o timeout
2. Через какое время доступ получен.
3. Отключенный узел в статусе NotReady.

Включить отключенный узел, убедиться, что статус в узлах Kubernetes стал Ready.

Удаление VIP

Патч для удаления VIP:

[
  {
    "op": "remove",
    "path": "/machine/network/interfaces"
  }
]

[{"op":"remove","path":"/machine/network/interfaces"}]

Выполнить патч для всех узлов Controlplane:

talosctl -n 192.168.1.8 patch machineconfig -p '[{"op":"remove","path":"/machine/network/interfaces"}]'
talosctl -n 192.168.1.7 patch machineconfig -p '[{"op":"remove","path":"/machine/network/interfaces"}]'
talosctl -n 192.168.1.4 patch machineconfig -p '[{"op":"remove","path":"/machine/network/interfaces"}]'
talosctl -n 192.168.1.3 patch machineconfig -p '[{"op":"remove","path":"/machine/network/interfaces"}]'
talosctl -n 192.168.1.2 patch machineconfig -p '[{"op":"remove","path":"/machine/network/interfaces"}]'

Убедиться, что виртуальный адрес отсутствует:

talosctl get addresses 2>/dev/null | grep 192.168.1.100

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

talosctl -n 192.168.1.8 health
talosctl -n 192.168.1.7 health
talosctl -n 192.168.1.4 health
talosctl -n 192.168.1.3 health
talosctl -n 192.168.1.2 health
kubectl get nodes

Предостережения

Так как VIP зависит от etcd, его функциональность будет недоступна до тех пор, пока вы не запустите Kubernetes. Не используйте VIP в качестве конечной точки API в talosconfig, поскольку для управления VIP требуются запущенные etcd и kube-apiserver, и в случае сбоя одного из этих компонентов не будет возможности восстановиться посредством API.

Поведение при отказоустойчивости VIP-клиентов

Когда управляющий узел, владелец VIP-адреса, корректно завершает работу, адрес переназначается практически мгновенно, обеспечивая бесперебойный доступ. Однако, если узел неожиданно выходит из строя, например, из-за отключения питания или сбоя, процесс переключения на резервный узел занимает больше времени, обычно до минуты. Такая более медленная реакция является запланированной, поскольку ALT Orchestra координирует владение VIP-адресом посредством процесса выборов в etcd, который должен обеспечивать баланс между скоростью и безопасностью. Задержка гарантирует, что временный сбой в сети или кратковременная пауза в сети не приведут к тому, что несколько узлов одновременно будут считать, что владеют VIP-адресом (что является опасным сценарием «split-brain»). Ожидая истечения таймаута выборов перед переназначением VIP-адреса, ALT Orchestra гарантирует, что только один узел будет объявлять общий IP-адрес, даже если это означает более медленное переключение на резервный узел в сценариях внезапных сбоев.

Влияние на рабочую нагрузку

Переключение VIP-адреса на резервный сервер влияет только на внешний доступ к кластеру, например, при выполнении команд kubectl к API-серверу. Внутри кластера рабочие нагрузки продолжают нормально функционировать. Однако для внешних клиентов переключение на резервный сервер может на короткое время прервать соединение. Длительные соединения, такие как сессии HTTP/2, могут быть разорваны при перемещении виртуального IP-адреса на новый узел, и клиенты должны быть готовы к повторному подключению после завершения переключения на резервный сервер.