K8S Hard Way Bare Metal

Предисловие

Всем привет :)
Не хочу и не буду заниматься в тупую перепечаткой мануала - это бесполезное занятие, всего лишь освещу несколько аспектов
А так же для тех, кто понятия не имеет, что такое контейнеризация, k8s, ни разу в k8s не лазали даже на миникубе, а уж тем более и через kubespray не развертывали и вообще зачем оно нужно - к сожалению с большой долей вероятности вы просто потратите своё время, читая тут многа букаф

Развертывание

сам мануал вот
небольшим подспорьем еще может послужить эта статья
https://habr.com/ru/post/462473/
без kubeadm и docker'а можно обойтись

из инструментов - ваши лучшие друзья:
- kubectl
- k9s (удобно и быстро)
- journalctl -u $service_name --since час:минуты
- kubectl autocomplete - желателен, но не обязателен

За основу (лично у меня) был взят Debian 11.0 ввиду того, что убунта с некоторыми пакетами, подразумевающими только терминальное использование вдруг начала тащить "лишнее", например пакеты для х11 (внезапно) - от нее было принято решение отказаться

Для минимального понимания "как всё работает" необходимо минимум 2-3 ноды (воркеры и мастера на 2х нодах + желательно HA на отдельной), в идеале штук 5-7 (все ноды разные со своими ролями)
с мануала развертывается почти всё без проблем кроме некоторых аспектов, а именно - cgroups - маунтить их можно легко и непринужденно, но желательно в kubelet добавлять вот эти строки

--runtime-cgroups=/systemd/system.slice \
 --kubelet-cgroups=/systemd/system.slice

Отдельное внимание нужно обратить на генерацию сертификатов - в них можно легко запутаться и логи на одном из воркеров у вас будут на это ругаться - придется либо их перегенеривать, либо подложить правильные, а после рестартовать службы куба

Последующее развертывание пройдет по мануалу выше без каких либо загвоздок, но скорее всего запнетесь об calico или иные варианты сети для кубера

Calico нужен для того, чтоб роутить траффик между нодами и их подами, т.е. если под1 на воркер1 и под2 на воркер2 - друг друга они не увидят, хотя находятся в одной сети (ippool опустим)
с момента попытки развертывания calico, я дошел аж до calico hard way https://projectcalico.docs.tigera.io/getting-started/kubernetes/hardway/overview (кстати можно обойтись без kubeadm) но проблема оказалась в другом - неправильный конфиг containerd и cni плагина

calico ругалось, сеть наружу из под была, между подами - нет

Пришлось дописывать конфиг и в containerd и в cni

cat /etc/containerd/config.toml
[plugins]
 [plugins.cri.containerd]
   snapshotter = "overlayfs"
   [plugins.cri.containerd.default_runtime]
     runtime_type = "io.containerd.runtime.v1.linux"
     runtime_engine = "/usr/local/bin/runc"
     runtime_root = ""
 [plugins.cri.cni]
   conf_template="/etc/cni/net.d/10-calico.conflist"

для плагина (bridge кстати оказался не нужен)

cat /etc/cni/net.d/10-calico.conflist  
{
 "name": "k8s-pod-network",
 "cniVersion": "0.3.1",
 "plugins": [
   {
     "type": "calico",
     "log_level": "info",
     "log_file_path": "/var/log/calico/cni/cni.log",
     "etcd_endpoints": "https://192.168.6.1:2379,https://192.168.6.2:2379",
     "etcd_key_file": "/etc/cni/net.d/calico-tls/etcd-key",
     "etcd_cert_file": "/etc/cni/net.d/calico-tls/etcd-cert",
     "etcd_ca_cert_file": "/etc/cni/net.d/calico-tls/etcd-ca",
     "mtu": 0,
     "ipam": {
         "type": "calico-ipam"
     },
     "policy": {
         "type": "k8s"
     },
     "kubernetes": {
         "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
     }
   },
   {
     "type": "portmap",
     "snat": true,
     "capabilities": {"portMappings": true}
   },
   {
     "type": "bandwidth",
     "capabilities": {"bandwidth": true}
   }
 ]
}

рестартим кубелет и контейнерд - видим в kubectl get nodes status Ready
разворачиваем pingtest с calico hard way - должен работать

coredns добавится почти без проблем, если с сетью всё решили и служба systemd-resolved.service запущена, для комплекта я бы еще добавил node-local-dns

А теперь вишенка на торте - кубспреем всё это делается практически за одну команду, лишь бы были забиты хосты

ansible-playbook -i inventory/mycluster/hosts.yaml --become --become-user=root cluster.yml

зачем нужен тогда k8s hard way в таком случае? для более широкого понимания работы куберовских служб, etcd, containerd, т.к. ансибл кубспрея не отображает всего, что делает (конечно можно заморочиться и расковырять плейбуки, но зачем?)
в дальнейшем это вам очень поможет в траблшутинге кубера

всем, кто осилил - спасибо :)