Kubernetes 1.4 и kubeadm: ставим кластер на bare-metal CentOS 7 за 30 минут

Kubernetes 1.4 вышел несколько дней назад, и главная новость - не очередной раунд API-стабилизации, а kubeadm. Это утилита для начальной загрузки кластера: она берёт на себя генерацию сертификатов, настройку etcd, kube-apiserver, controller-manager и прочей компании. Раньше это делалось либо руками по документации (занимало день-два, если первый раз), либо через Ansible-роли чужого производства (занимало день разобраться в чужих ролях). Решили проверить, насколько «30 минут» - это маркетинг, а насколько - правда.

Стенд: три железных сервера, CentOS 7.2, один мастер и две рабочие ноды. Без облаков, без виртуализации - честный bare-metal, потому что у заказчика именно такой.

Что kubeadm делает

Схема простая: на будущем мастере запускаешь kubeadm init, получаешь токен и команду для присоединения нод. На каждой рабочей ноде запускаешь kubeadm join --token <token> <master-ip>. После этого кластер технически работает, но без сети между подами - нужно поставить CNI-плагин отдельно.

Что берёт на себя kubeadm:

• Генерация PKI - CA, сертификаты для всех компонентов, kubeconfig для kubectl.
• Запуск системных компонентов - kube-apiserver, controller-manager, scheduler и etcd поднимаются как статические поды через kubelet на мастере.
• Настройка RBAC - базовые роли прописываются автоматически.
• TLS Bootstrapping для нод - рабочие ноды автоматически получают сертификаты при join, не надо генерировать их вручную для каждой.

Где начались приключения

До kubeadm у нас был накопленный Ansible-плейбук для подъёма кластера - примерно 400 строк yaml с учётом всех нюансов версионирования и конфигурации. Сейчас kubeadm init отрабатывает за несколько минут. Разрыв существенный.

Первый камень: SELinux и firewalld. CentOS 7 из коробки имеет оба включёнными. kubeadm не выдаёт внятной ошибки, если firewalld блокирует нужные порты - просто компоненты не поднимаются, а в логах kubelet сообщения про таймауты. Нужно открыть порты 6443 (API), 2379-2380 (etcd), 10250-10255 (kubelet), или временно отключить firewalld чтобы убедиться что дело в нём. Мы открыли конкретные порты через firewall-cmd - не хотелось полностью отключать на проде.

SELinux пришлось перевести в permissive для kubelet - в enforcing режиме он жалуется на доступ к cgroup-файлам. Это известная проблема, обходится добавлением политик, но на старте проще permissive, потом разберёмся.

Второй камень: flannel и аргументы kubelet. Flannel - самый простой CNI для начала, документация к kubeadm его рекомендует для тестов. Но чтобы flannel работал корректно, kubelet должен стартовать с --pod-network-cidr=10.244.0.0/16. Этот параметр передаётся в kubeadm init, но если запустить init без него, а потом попробовать поставить flannel - поды будут получать адреса, но трафик между нодами не пойдёт. Симптом: ping между подами на разных нодах падает, на одной ноде работает. Потерял на диагностике около часа.

Решение: сбросить кластер (kubeadm reset на всех нодах, это тоже новинка 1.4), и переинициализировать с правильным CIDR.

Третий камень: swap. kubelet в 1.4 стартует, но при включённом swap в логах появляются предупреждения и поведение с памятью непредсказуемо. Логика понятна - Kubernetes управляет памятью контейнеров через cgroups и swap ломает эту картину. На наших серверах swap был включён по старой привычке. swapoff -a и убрать строку из /etc/fstab - минута работы, но нужно об этом знать заранее.

Что получилось в итоге

Чистая установка от kubeadm init до рабочего кластера с flannel и kubectl get nodes в статусе Ready - около 25 минут при первой попытке (минус час на диагностику flannel, который я уже учёл). Если знать подводные камни - укладывается в 15.

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

При этом kubeadm в 1.4 - инструмент именно для начальной загрузки. Обновление кластера, добавление мастер-нод для HA, ротация сертификатов - этого пока нет. Текущий кластер с одним мастером не переживёт падения мастер-ноды: etcd один, apiserver один. Для тестового стенда и разработки это нормально, для продакшна - вопрос открытый.

Где это применимо сейчас

Нам kubeadm уже пригодился для быстрого разворачивания тестовых окружений. Раньше тестовый кластер жил долго, потому что его жалко было сносить - пересоздать дорого. Теперь kubeadm reset + kubeadm init - и через 20 минут свежий кластер. Это меняет подход к работе.

Для заказчиков, которым нужна managed-инфраструктура на Kubernetes - пока используем старый подход с Ansible и более детальной настройкой. kubeadm хорош для старта, но продакшн-кластер требует большего контроля над конфигурацией каждого компонента. Возможно это изменится в следующих версиях, когда kubeadm прикроет больше операционных сценариев.

Пока фиксируем: установка кластера перестала быть квестом. Это уже ценно.