Поднимаем кластер для обслуживания веб-приложений без записи состояния (stateless web applications) вместе с ingress, letsencrypt, не используя средства автоматизации вроде kubespray, kubeadm и любых других.
Время на чтение: ~45-60 минут, на воспроизведение действий: от 3-х часов. На написание статьи меня сподвигла потребность в своём собственном кластере kubernetes для экспериментов. Автоматические решения установки и настройки, которые есть в открытом доступе, не работали в моем случае, так как я использовал не-мейнстримовые дистрибутивы Linux. Плотная работа с kubernetes в IPONWEB стимулирует иметь такую площадку, решая свои задачи в комфортном ключе, в том числе и для домашних проектов. В статье будут фигурировать следующие компоненты:  — Ваш любимый Linux — я использовал Gentoo (node-1: systemd / node-2: openrc), Ubuntu 18.04.1.
 — Kubernetes Server — kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, kube-proxy.
 — Containerd + CNI Plugins (0.7.4) — для организации контейнеризации возьмем containerd + CNI вместо docker (хотя изначально вся конфигурация была поднята на docker, так что ничего не помешает использовать его в случае необходимости).
 — CoreDNS — для организации service discovery компонентов, работающих внутри kubernetes кластера. Рекомендована версия не ниже 1.2.5, так как с этой версии появляется вменяемая поддержка работы coredns в качестве процесса, запущенного вне кластера.
 — Flannel — для организации сетевого стека, общения подов и контейнеров между собой.
 — Ваша любимая db.  В ходе работы я пользовался большим количеством источников, но хочу отметить отдельно достаточно подробное руководство Kubernetes the hard way, которое освещает около 90% вопросов базовой конфигурации собственного кластера. Если вы уже ознакомились с этим руководством, можете смело переходить сразу к части Конфигурация Flannel В процессе поднятия кластера я не ставил задачу добиться оптимизации железных ресурсов таким образом, чтобы поместиться в бюджет $20 в месяц. Нужно было просто собрать работающий кластер с как минимум двумя рабочими узлами (nodes). Поэтому изначально кластер выглядел так: После того как первая версия кластера заработала, я решил перестроить его так, чтобы разграничить узлы, ответственные за запуск приложений внутри кластера (рабочие узлы, они же workers), и API мастер-сервера. В результате я получил ответ на вопрос: "Как получить более-менее недорогой, но функционирующий кластер, если я хочу размещать там не самые толстые приложения". 
(Планируется быть таким) 
(Скрадено из интернетов, если кто-то вдруг еще не знает или не видел) Первым делом стоило понять, какое количество ресурсов мне нужно, чтобы запустить программные комплексы, которые относятся непосредственно к кластеру. Поиск по запросу "hardware requirements" не дал конкретных результатов, поэтому пришлось подойти к задаче с практической точки зрения. В качестве измерения MEM и CPU я взял статистику от systemd — можно считать, что измерения производились весьма любительским способом, но задачи получения точных значений и не стояло, так как вариантов дешевле $5 за инстанс я все равно не нашёл. Можно было найти VPS/VDS дешевле при размещении серверов на территории России или СНГ, но печальные истории, связанные с РКН и его действиями, создают определенные риски и порождают естественное желание их избежать. Итак: Нет, не нужен. Мастер-узлу не требуется docker или containerd как таковой, хотя в интернете есть большое количество руководств, которые для тех или иных нужд включают использование окружения для контейнеризации. В рассматриваемой конфигурации выключение containerd из списка зависимостей было сделано преднамеренно, однако, каких-то очевидных плюсов такого подхода я не выделяю. Конфигурация, предоставленная выше, является минимальной и достаточной для того, чтобы запустить кластер. Никаких дополнительных действий/компонент не требуется, разве что вы захотите что-то добавить по своему усмотрению. Для построения тестового кластера или кластера для домашних проектов будет вполне достаточно 1vCPU/1G RAM для функционирования мастер-нода. Разумеется, нагрузка на мастер-ноду будет изменяться в зависимости от количества задействованных рабочих узлов (workers), а также наличия и объема сторонних запросов к api-server. Я разнес master и worker конфигурации следующим образом: Для конфигурации мастера необходимо функционирование следующих компонентов: etcd — для хранения данных для api-server'а, а также для flannel; kube-apiserver — собственно, api-server; kube-controller-manager — для генерации и обработки событий; kube-scheduler — для распределения зарегистрированных через api-server ресурсов — например, подов.
Для конфигурации "рабочих лошадок" необходимо функционирование следующих компонентов: kubelet — для запуска подов, обеспечения конфигурирования сетевых настроек; kube-proxy — для организации маршрутизации/балансировки kubernetes сервисов; coredns — для service discovery внутри запущенных контейнеров; flannel — для организации сетевого доступа контейнеров, работающих на разных узлах, а также для динамического распределения сетей по узлам (kubernetes node) кластера. Тут следует сделать маленькое отступление: coredns может быть запущен и на мастер-сервере. Ограничений, которые бы заставили запускать coredns именно на рабочих узлах, нет, кроме нюанса конфигурации coredns.service, который попросту не запустится на стандартном/немодифицированном Ubuntu сервере из-за конфликта с сервисом systemd-resolved. Я и не стремился решить эту проблему, так как меня вполне устраивали 2 ns сервера, расположенные на рабочих узлах. Чтобы сейчас не тратить времени на ознакомление со всеми деталями процесса конфигурирования компонентов, предлагаю самостоятельно ознакомиться с ними в руководстве Kubernetes the hard way. Я же сосредоточусь на отличительных особенностях моего варианта конфигурирования. Все файлы для функционирования компонентов кластера для мастера и рабочих узлов помещены в /var/lib/kubernetes/ для удобства. При необходимости вы можете разместить их иным образом. Основой для генерации сертификатов служит все тот же Kubernetes the hard way, существенных отличий практически нет. Для перегенерации подчиненных сертификатов были написаны простые bash скрипты вокруг cfssl приложений — это очень пригодилось в процессе отладки. Вы можете сгенерировать сертификаты под ваши нужды, пользуясь предложенными ниже скриптами, рецептами из Kubernetes the hard way или другими подходящими инструментами. Взять скрипты можно тут: kubernetes bootstrap. Перед запуском отредактируйте файл certs/env.sh, указав ваши настройки. Пример: Если вы воспользовались env.sh и корректно указали все параметры, то необходимости трогать сгенерированные сертификаты нет. Если вы ошиблись на каком-то этапе, то сертификаты можно перегенерировать по частям. Приведенные bash скрипты тривиальны, разобраться в них не составит сложности. Важное замечание — не стоит часто пересоздавать ca.pem и ca-key.pem сертификаты, так как они являются корневыми для всех последующих, иными словами, вам придется пересоздать все сопутствующие сертификаты и доставить их на все машины и во все нужные директории. Нужные сертификаты для запуска сервисов на мастер-узле следует положить в /var/lib/kubernetes/: kubernetes.pem — необходим для flannel, coredns при подключении к etcd, kube-apiserver.  Данная особенность выполнена по логике конфигурации Kubernetes the hard way.
Исходя из этого, данный файл нужен будет везде — и на мастере, и на рабочих узлах. Я не стал менять подход, предоставленный оригинальным руководством, так как с его помощью можно быстрее и нагляднее организовать работу кластера и понять весь ворох зависимостей. Моё личное мнение состоит в том, что для etcd нужны отдельные сертификаты, никак не пересекающиеся с сертификатами, использующимися для работы kubernetes. Важно! Если у вас больше одного узла, то каждый узел будет включать node-X-key.pem, node-X.pem и node-X.kubeconfig файлы внутри kubelet. Иногда может потребоваться посмотреть, как именно сконфигурирован сертификат, чтобы узнать, какие IP/DNS узлы были использованы при его генерации. В этом нам поможет команда cfssl-certinfo -cert <cert>. Например, узнаем данную информацию для node-1.pem: Все остальные сертификаты для kubelet и kube-proxy вшиты непосредственно в соответствующие kubeconfig'и. Все нужные kubeconfig'и можно сделать с помощью Kubernetes the hard way, однако, здесь и начинаются некоторые отличия. Руководство использует kubedns и cni bridge конфигурацию, здесь же рассматривается coredns и flannel. Эти два сервиса, в свою очередь, используют kubeconfig для авторизации в кластере. Для мастера необходимы следующие kubeconfig файлы (как упомянуто выше, после генерации их можно взять в certs/kubeconfig): Данные файлы потребуются для запуска каждого из компонентов-сервисов. Для рабочих узлов необходимы следующие kubeconfig файлы: Несмотря на то, что на моих рабочих узлах используются разные системы инициализации, в примерах и в репозитории даны варианты с использованием systemd. С их помощью проще всего понять, какой процесс и с какими параметрами необходимо запустить, кроме того, они не должны вызвать больших проблем при изучении сервисов с флагами назначений. Для запуска сервисов необходимо скопировать service-name.service в /lib/systemd/system/ или любой другой каталог, где размещаются сервисы для systemd, и после этого включить и запустить сервис. Пример для kube-apiserver: Разумеется, все сервисы должны быть зелеными (то есть запущенными и функционирующими). Если вдруг вы столкнулись с какой-либо ошибкой, команды journalct -xe или journal -f -t kube-apiserver помогут понять, что именно пошло не так. Не торопитесь запускать все серверы сразу, для начала достаточно будет включить etcd и kube-apiserver. Если все прошло удачно, и у вас сразу заработали все четыре сервиса на мастере, запуск мастера можно считать успешным. Можно воспользоваться systemd настройками или сгенерировать init скрипты для конфигурации, которую вы используете. Как уже было сказано, для мастера вам необходим:  — systemd/etcd
 — systemd/kube-apiserver
 — systemd/kube-controller-manager
 — systemd/kube-scheduler  — systemd/containerd
 — systemd/kubelet
 — systemd/kube-proxy
 — systemd/coredns
 — systemd/flannel Для работы клиента достаточно скопировать certs/kubeconfig/admin.kubeconfig (после того, как вы сгенерируете его или напишете самостоятельно) в ${HOME}/.kube/config Скачайте kubectl и проверьте работу kube-apiserver. Еще раз напомню, что на данном этапе для работы kube-apiserver должен функционировать только etcd. Остальные компоненты понадобятся для полноценной работы кластера несколько позже. Проверяем, что kube-apiserver и kubectl работают: В качестве конфигурации flannel я остановился на vxlan бэкенде. Подробнее о бэкендах можно почитать тут. Сразу скажу, что запуск kubernetes кластера на VPS скорее всего ограничит вас в использовании host-gw бэкенда. Не являясь опытным сетевым инженером, я потратил примерно два дня на отладку, чтобы понять, в чем крылась проблема с его использованием на популярных VDS/VPS провайдерах. Были протестированы linode.com и digitalocean. Суть проблемы заключается в том, что провайдеры не предоставляют честную L2 для частной сети (private networking). Это, в свою очередь, делает невозможным хождение сетевого трафика между узлами в такой конфигурации:  Для того чтобы работал сетевой трафик для подов между нодами, хватит обычной маршрутизации. Не забудьте, что net.ipv4.ip_forward должен быть установлен в 1, а FORWARD цепочка в filter таблице не должна содержать для узлов запрещающих правил. Именно это и не работает на указаных (а, скорее всего, и вообще на всех) VPS/VDS. Поэтому, если вам важна конфигурация решения с высокой сетевой производительностью между узлами, вам все же придется потратить больше $20 на организацию кластера. Для установки нужной конфигурации flannel можно воспользоваться set-flannel-config.sh из etc/flannel. Важно помнить: если вы решите поменять backend, необходимо будет удалить конфигурацию в etcd и перезапустить все flannel демоны на всех узлах, — поэтому выбирайте его с умом. По умолчанию используется vxlan. После того как вы прописали нужную конфигурацию в etcd, необходимо настроить сервис для его запуска на каждом из рабочих узлов. Пример для сервиса можно взять тут: systemd/flannel Как было описано ранее, нам необходимы ca.pem, kubernetes.pem и kubernetes-key.pem файлы для авторизации в etcd. Все остальные параметры не несут в себе какого-то сакрального смысла. Единственное, что действительно важно — это сконфигурировать глобальный ip адрес, через который будут ходить сетевые пакеты между сетями: 
(Multi-Host Networking Overlay with Flannel) После успешного запуска flannel вы должны обнаружить сетевой интерфейс flannel.N в своей системе: Проверить, что ваши интерфейсы работают корректно на всех узлах, достаточно просто. В моем случае node-1 и node-2 имеют 10.200.8.0/24 и 10.200.12.0/24 сети соответственно, поэтому обычным icmp запросом проверяем их доступность: В случае возникновения каких-либо проблем рекомендуется проверить, нет ли каких-либо режущих правил в iptables по UDP между хостами. Разместите etc/containerd/config.toml в /etc/containerd/config.toml или где вам удобно, главное — не забудьте поменять путь к файлу конфигурации в сервисе (containerd.service, описан ниже). Конфигурация с некоторыми модификациями стандартной. Важно не устанавливайть enable_tls_streaming = true, если вы не понимаете, зачем вы это делаете. В противном случае kubectl exec перестанет работать и будет выдавать ошибку о том, что сертификат был подписан неизвестной стороной. Для проверки, работает ли сервис, можно воспользоваться cri-tools.
Скопируйте etc/crictl.yaml в /etc/crictl.yaml. После этого можно позапускать доступные команды: После того, как у вас что-то появится внутри вашего kubernetes кластера, crictl станет более полезным и начнет отображать поды, контейнеры, образы и так далее. Про CNI уже писали на Хабре, поэтому просто сошлюсь на подходящую статью по теме и, не вдаваясь в подробности, перейду к делу. Для каждого из рабочих узлов скачиваем cni plugins для нужной нам платформы и распаковываем в /opt/cni/bin/ в /etc/cni/net.d кладем следующие файлы с указанным содержанием: Описания проверки этого сетапа перегрузит эту статью, поэтому его я пропущу. Но тем, кто привык рисковать и не боится сложностей, советую к прочтению Red Hat заменяет Docker на Podman, Intro to Podman  Самое важное в установке kubelet сервиса (помимо указания корректных ключей и cni) — корректно указать имя узла. По умолчанию kubelet возьмет значение из hostname. Так как большое количество запросов идет через шифрование сертификатами, то некорректное имя узла может "поломать" вам команды kubectl logs, kubectl exec, kubectl port-forward. Перед тем, как скопировать etc/kubelet-config.yaml в нужное место, необходимо отредактировать его в соответствии с вашими настройками, как и все конфигурационные файлы. Ниже я отмечу данные опции: К сожалению, о них можно прочитать только в декларация GO файлов kubernetes, поэтому гуглите, исходя из собственного опыта и желания разобраться. Конкретно эти опции отвечают за резервирование системных ресурсов. При такой конфигурации из ресурсов вашего реального кластера будет зарезервировано 0.2 vCPU и 600 MB памяти для использования хостовой системой. Это могут быть, к примеру, kubelet, kube-proxy, coredns, flannel или другие системные процессы. Разумеется, данные настройки не являются универсальными и указаны в соответствии с конфигурацией моих рабочих узлов — в моём случае это 2 vCPU / 4G ram, плюс на обоих узлах у меня все еще крутятся старые проекты, которые не переведены в kubernetes + postgresql сервера. В случае использования микро-узлов (micro nodes) я бы вообще удалил данную часть конфигурационного файла. Пример service файла можно взять тут: systemd/kubelet Я не уделял особенного внимания сущностям, которые обслуживают RBAC, поэтому в текущей конфигурации требуется выделение прав для корректного функционирования каждого из узлов под управлением kubelet. Примените etc/kubelet-default-rbac.yaml для того, чтобы kubelet имел необходимые права для манипулирования ресурсами на узле: После того, как ресурсы были созданы, можно приступить к конфигурации и запуску самого сервиса. Если все прошло успешно, то вы должны как минимум увидеть узел через запрос узлов api сервера: Сервис: systemd/kubelet. Тут все просто, особой магии нет, kube-proxy-config.yaml можно взять опять же тут: etc/kube-proxy Так как kube-proxy отвечает за "проделываение" маршрутов внутири iptables, то проверить его работу можно будет только после того, как вы что-то запустите внутри kubernetes кластера (какой-нибудь сервис). Об этом ниже. Corefile можно взять тут: etc/coredns/Corefile, выглядит он следующим образом: Вам необходимо будет скопировать coredns.kubeconfig и pem-сертификаты (процесс их генерации описан выше) на все worker узлы. Вдобавок, coredns сервис я запускал без работающего systemd-resolved. Поэтому, если вы захотите запустить данный конфиг на стоковом Ubuntu сервере, то он, скорее всего, не заработает, как нужно. Но исправить его не так уж и сложно. Проверить, что все ок, можно следующим образом: Как мы видим, coredns вернул нам ip адрес стандартного kubernetes сервиса.
Важно, kubernetes.default сервис будет зарегистрирован работающим kube-controller-manager, поэтому стоит убедиться в его наличии: Чтобы запустить приложение, необходимо определить его ресурсы. А перед этим следует сконфигурировать и установить nginx-ingress и cert-manager.  — nginx kubernetes ingress (master), минимальный сетап:  — cert manager (v0.5.2) После того, как все успешно запустилось, стоит проверить, работают ли процессы приложения: Если cert-manager и nginx-ingress поды находятся в running state, то можно считать, что все успешно запустилось. В ходе различных экспериментов с кластерами приложения могут перестать работать, при этом состояние пода будет продолжать определяться как Running. Обычно в таких ситуациях помогает только исследование логов пода и рестарт подов. Чтобы протестировать конфигурацию, можно воспользоваться уже написанным приложением. Исходники лежат в том же репозитории, вместе с kubernetes resource конфигурацией: app/k8s Следует обратить внимание, что генерация сертификата займет какое-то время. Также важно, чтобы доменное имя (в случае с данным примером это kubernetes-example.w40k.net), для которого вы генерируете сертификат, существовало и было доступно, иначе cert-manager в связке с nginx-ingress не смогут принять участвие в выпуске сертификата и вы не сможете использовать текущую конфигурацию. Тем не менее, вы можете использовать ingress без tls/ssl. Данное приложение в указанной конфигурации создаёт: На текущий момент это вся полезная информация, необходимая для первичной настройки функционирующих мастер- и рабочих узлов. Если у вас что-то не заработало или заработало не до конца, ниже представлена краткая сопроводительная информация, которая поможет в отладке и подгонке компонентов кластера. Информация, которую я использовал для того, чтобы настроить кластер:  — Kubernetes the hard way
 — Multi-Host Networking Overlay with Flannel
 — Intro to Podman
 — Stateless Applications
 — What is ingress Полезно к прочтению:  — Kubernetes Networking: Behind the scenes (перевод)
 — A Guide to the Kubernetes Networking Model
 — Understanding kubernetes networking: services (перевод) <tbd>, позже тут будут размещены ответы на самые популярные вопросы и замечания. Данная секция к прочтению необязательна, особенно, если у вас все работает. Здесь собраны краткие инструкции, куда смотреть и как действовать в ситуации, если что-то не работает, или работает не так, как ожидается. В конфигурации kube-apiserver.service может указываться статический токен, который используется для упрощения отладки работы api-server'а с помощью curl или любого другого http клиента. При его использовании в целях безопасности лучше изменить значение токена на что-то уникальное.
После завершения отладки скопируйте admin.kubeconfig в ${HOME}/.kube/config, и тогда kubectl будет работать без авторизации на api-server (kube-apiserver). Если данный запрос (замените токен на свой) возвращает HTTP 200 OK + содержимое, то api-server функционирует корректно: После того, как controller manager соединится с api сервером и начнет работать, он произведет некоторый набор стандартных действий. Для проверки результата достаточно будет убедиться в том, что были созданы service account'ы: Если этот список пуст, убедитесь в том, что kube-controller-manager функционирует корректно. Планировщик отвечает за распределение ресурсов по узлам. Чтобы убедиться, что он работает правильно, можно запустить тестовый debug/job.yaml и просмотреть список событий с помощью команды kubectl describe <type/resource>.
Перед отладкой планировщика важно убедиться в том, что kube controller manager функционирует. Как мы видим, default-scheduler успешно распределил pod на узел w40k.net. Если с планировщиком что-то не так, то об этом можно будет узнать из обработанных или необработанных событий — и принять необходимые меры. При настройке и конфигурациях у меня не возникло большого количества проблем непосредственно с планировщиком. Вот, пожалуй, единственная обнаруженная странность, — планировщик время от времени самопроизвольно "останавливался". Эта проблема разрешилась переходом сервиса на systemd с его встроенными возможностями по перезапуску падающих сервисов. Подробнее про kube scheduler читайте тут или перевод тут Kubelet отвечает за управление kubernetes ресурсами непосредственно на запущенном узле. С kubelet связано множество нюансов в работе и настройке. Внимательное чтение результатов работы kubernetes event (kubectl get events -o wide) поможет быстро понять суть проблем и избавиться от них. Чуть подробнее можно узнать тут (и перевод тут) Само по себе функционирование kube-proxy зависит от двух факторов: Важно, 10.32.0.0/24 адреса явлаются "виртуальными". То есть, их не прослушивает ни один из сетевых интерфейсов. По сути это правила iptables, то есть правила маршрутизации трафика, которые будут применены, как только вы попытаетесь что-то запросить по данному адресу+порту. Вы не можете послать icmp запросы на эти адреса, поэтому стандартный способ проверить сервис ping'ом не сработает. Отсутствие результата не будет свидетельствовать ни о поломке, ни о корректном его функционировании. Для того, чтобы проверить корректную работу kube-proxy, можно отправить запрос на созданный сервис с любого узла и посмотреть на результат его работы: Нас будет интересовать вторая пара src/dst (9 и 10 столбцы). Как мы видим, тут src меняется и имеет два уникальных значения: Это означает, что сервис работает корректно. Если вы видите только один адрес, то какой-то контейнер (скорее всего, расположенный на другом узле) не функционирует. Для отладки этой проблемы можно воспользоваться тестированием непосредственно сети. Если вдруг вы обнаружили, что оба адреса функционируют, но в таблице conntrack у вас все равно указан только один адрес, это означает, что проблема находится на уровне kube-proxy. Проверьте функционирование сервиса, а также содержимое ваших маршрутов в nat таблице: node-1$ iptables -t nat -vnL Также стоит проделать эту операцию на всех узлах вашего кластера.  Во время финальной подгонки я столкнулся с проблемой постоянной задержки при отправке запроса через сервис на другой узел. К сожалению, я не смог найти, с чем это может быть связано. Как ни странно, проявилось это только на одном из узлов. Если кто-то знает возможные причины и решение этой проблемы, пожалуйста, напишите в комментариях. Интересную информацию можно почерпнуть тут и перевод тут Программист