Getting started

Production environment

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

На требования к кластеру влияют такие проблемы:

• Доступность. Одиночная машина это единая точка отказа. Создание высокодоступного кластера подразумевает:
  • Разделение control plane от worker nodes
  • Реплицирование компонентов control plane на множество узлов
  • Распределение трафика по API Server'ам кластера
  • Наличие достаточного количества доступных worker node, или возможность быстро получить их (в соответствии с требованиями изменяющейся нагрузки)
• Масштабируемость. Если ты ожидаешь что твой куб будет получать стабильную нагрузку, то можешь засетапить его один раз и забыть. Однако если ты ожидаешь рост нагрузки со временем, или изменение нагрузки в связи с сезонностью или другими особыми событиями, то тебе нужно спланировать как масштабировать контрол плейн и дата плейн (и как масштабировать это все вниз чтобы высвобождать ненужные ресурсы (которые были нужны в моменте))
• Безопасность и управление доступом. В учебном кластере ты имеешь полные админские права, но разделяемые кластеры с важной нагрузкой требуют более изысканных подходов к управлению доступом к ресурсам кластера. Ты можешь использовать RBAC и другие механизмы безопасности для обеспечения безопасного доступа к необходимым ресурсам

Чтобы собрать надежный и чинибельный кластер:

• Выбери инструменты деплоя. Есть kubeadm, kops, kubespray и другие, выбери подходящий тебе
• Управляй сертификатами. Безопасная коммуникация между компонентами control plane достигается за счет сертификатов. Сертификаты автоматически генерятся при деплое или ты можешь использовать свой собственный CA
• Настрой балансировщик нагрузки для API Server'ов. Чтобы распределять API запросы на экземпляры API Server'ов запущенных на разных узлах
• Разделяй и бэкапь ETCD. Можно запустить ETCD на тех же машинах что и control plane, а можно унести его на отдельные машины (для дополнительной безопасности и надежности). Поскольку в ETCD хранится полная конфигурация кластера, то он должен бэкапиться регулярно и ты должен мочь восстановить этот бэкап при необходимости (нерабочие бэкапы никому не нужны)
• Делай множественный control plane. Для высокой доступности control plane не должен быть ограничен одной машиной. Если сервисы control plane'a запускаются через систему инициализации (например systemd), то каждый сервис должен запускаться минимум на трех машинах. С другой стороны если запускать компоненты control plane'a как поды, то куб сам постарается сделать так чтобы было доступно необходимое количество экземпляров сервисов
• Охватывай несколько зон. Если сильно критична высокая доступность кластера, то делай кластер который работает в нескольких зонах доступности сразу (или в нескольких датацентрах сразу). Запуская кластер в нескольких зонах, ты повышаешь шанс на то, что, даже при выходе из строя целого датацентра, твой кластер продолжит работать
• Управление приходящими фичами. Если ты планируешь поддерживать свой кластер рабочим долгое время, то нужно быть готовым его обслуживать, обновлять, управлять сертификатами и безопасностью

Продовый кластер должен быть масштабируемым и все на что он полагается тоже должно быть масштабируемым (например CoreDNS)

Установи лимиты на ресурсы. Есть лимиты на уровне неймспейсов и всего кластера

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

Container Runtimes

Нужно установить container runtime на все узлы где должны запускаться поды

Kubernetes 1.30 требует использования такого рантайма, который будет работать по Container Runtime Interface (CRI)

Вот тут есть подробности про доступные рантаймы https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md

Если кратко:
CRI был создан потому что было очень сложно подключать к кубу какие-либо необычные рантаймы
Для этого нужно было сильно шарить за кублет (именно за его внутренности) и закоммитить поддержку своего рантайма в основную репу куба
Это немасштабируемый способ. А куб преследует расширяемость
Поэтому сделали CRI, это понятная спецификация поддержав которую своим рантаймом ты автоматически делаешь его доступным для использования с кубом

До версии 1.24 Kubernetes имел прямую интеграцию с Docker Engine (dockershim). Теперь ее нет

По умолчанию Linux kernel не позволяет роутить IPv4 пакеты между интерфейсами. Многие сетевые драйверы делают такую настройку сами, но некоторые полагаются на то что системный администратор сделает это за них

Чтобы включить это вручную сделай:

# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF

# Apply sysctl params without reboot
sudo sysctl --system

Проверь что net.ipv4.ip_forward возвращает 1

sysctl net.ipv4.ip_forward