LINUX.ORG.RU

Сообщения vbr

 

Как я кубернетес поднимал

 ,

Точней начал. Может кому интересно будет. Гайдов вроде миллиард в интернете, но почему-то конкретно мои проблемы нигде не описаны были, пришлось курить, хотя там всё просто. А если вдруг корифеи расскажут, чего я сделал не так, будет совсем хорошо.

Вводная - имеется набор виртуальных серверов в одной частной сети 10.206.192.0/24. На них хочется поднять сабж.

Из нестандартного только load balancer. Он у моего провайдера к счастью есть. По сути это реверс прокси. Принимает соединения на 10.206.192.2:6443 и перенаправляет на 10.206.192.90:6443, 10.206.192.91:6443, 10.206.192.92:6443. Помимо прочего мониторит состояние и если какой-то сервер долго не принимает соединения на порту, то выключает его из этого пула.

На самих серверах я поставил ubuntu 20.04. Вообще я написал скрипты terraform и ansible, без них свихнуться можно, тыщу раз пересоздавал узлы.

В идеале надо 3 узла на control cерверы и 3+ worker-а. Конечно желательно, чтобы они крутились на физически разных серверах, иначе какой в этом всём толк. А так - если один сервер умрёт, то остальное вроде продолжит работать. На мастерах надо по 4GB / 2 cores, в крайнем случае до 2GB можно опустить, меньше уже нельзя. На рабочих нодах наверное можно и 1GB по сути сколько уже вашим приложениям нужно.

На всех серверах делается следующая конфигурация (помимо накатывания апдейтов):

echo br_netfilter > /etc/modules-load.d/br_netfilter.conf
modprobe br_netfilter
echo net.ipv4.ip_forward = 1 > /etc/sysctl.conf
sysctl net.ipv4.ip_forward = 1
apt install containerd
mkdir -p /etc/containerd
cat >/etc/containerd/config.toml <<EOF
version = 2
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
runtime_type = "io.containerd.runc.v2"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = false
EOF
systemctl restart containerd
curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" >/etc/apt/sources.list.d/kubernetes.list
apt install kubelet=1.23.7-00 kubeadm=1.23.7-00 kubectl=1.23.7-00
apt-mark hold kubelet kubeadm kubectl

На этом вся подготовка закончилась. containerd из репозитория не очень новый, поэтому 1.24 кажется запустить не получится. Если нужно - там еще надо добавить репозитории докера и ставить последний containerd.

Далее на первом мастере

kubeadm init \
  --kubernetes-version=v1.23.7 \
  --control-plane-endpoint=10.206.192.2:6443 \
  --upload-certs \
  --pod-network-cidr=10.244.0.0/16

если тут какие-то проблемы будут, вероятно неправильно работает load balancer.

Он минут 5 попыхтит и родит кластер. Напечатает команды, их пока выполнять не надо. Еще напечатает команды для копирования admin.conf в ~/.kube, это сделать желательно.

Теперь ставим calico. Это некий плагин для сети. Вот тут я просидел два дня.

kubectl create -f https://projectcalico.docs.tigera.io/manifests/tigera-operator.yaml
curl -O 'https://projectcalico.docs.tigera.io/manifests/custom-resources.yaml'
vim custom-resources.yaml
// spec.calicoNetwork.ipPools[0].cidr: 10.244.0.0/16
// spec.calicoNetwork.ipPools[0].encapsulation: IPIP
kubectl create -f ./custom-resources.yaml
watch kubectl get pods -A

Вся суть в том, чтобы поменять значение поля encapsulation. По умолчанию оно пытается делать что-то странное, что у меня не работало и сеть не поднималась, причем без каких-то индикаторов проблем, на вид все нормально, а пакеты не ходят.

Потом ждем пока все поды запустятся. После этого (а может можно и сразу, но я предпочитаю не торопиться) добавляем все остальные ноды в кластер теми командами, которые написаны в выхлопе kubeadm init.

Альтернативно вмето calico можно поставить flannel. Он типа проще но настроек меньше. Я его пробовал, из коробки заработал без проблем.

В принципе всё, кластер работает. Я пока до этого этапа дошел. busybox запускается, пинги идут. Дальше буду со storage разбираться. Пока что всё довольно просто выглядит, не знаю, чего там этим кубернетесом все пугают. Какой-нибудь Оракл ставить было куда сложней.

vbr
()

Вопросы по кубернетесу

 

Стоит задача поднять кубернетес кластер. Пока для гитлаба, в перспективе для кучи другого, что сейчас в колхозном docker-compose крутится.

Поигрался немного, в целом вроде понятно, как устанавливать через kubeadm, но хочется по некоторым вопросам подтверждения.

Работать оно будет на виртуальных серверах, запущенных в openstack.

  1. ОС для виртуального сервера. Пробовал Ubuntu 20.04 и 22.04, в принципе оба варианта работают, больше склоняюсь к 20.04, 22.04 всё же только вышла.

  2. Версия кубернетеса. Тут вообще понимания нет. LTS у них нет, в каждом облаке своя версия, причём они даже патч-версии последние не используют в стабильных каналах, что меня особенно удивляет. Пока планирую использовать 1.22.10 (последняя версия в ветке 1.22), т.е. 1.21 уже почти снят с поддержки. Хотя в gke/stable именно 1.21 доступна как последняя версия.

  3. Хранилище. Как я понимаю, для кубернетеса надо обеспечить сервис, где он сможет сохранять данные (вроде называется persistent volumes). Пока планирую использовать NFS-сервер, запущенный на отдельном сервере, но в целом хотелось бы что-то более легко реплицирующееся, т.к. будет единая точка отказа, что не очень нравится. Не очень понятно, есть ли тут какой-то «стандарт-де факто».

  4. СУБД. Для сервисов нужен постгрес. Планирую его тоже запускать на отдельном сервере, т.к. много слышал, что в кубернетесе СУБД запускать неправильно. Правда не понял, почему. В перспективе сделать репликацию для устойчивости.

  5. Сеть. Как я понял, два основных варианта это Flannel и Calico. С Flannel у меня всё заработало сразу, с Calico возникли проблемы (dashboard не открывается). Как я понимаю, Calico даёт возможность условно говоря делать фаервол на каждый сервис. Пока не уверен, надо ли это, т.е. понятно, что иметь это хорошо, но ценой большого усложнения - не уверен, и так есть с чем разбираться. Нормально ли будет остановиться на Flannel? Не приведёт ли к проблемам в будущем?

  6. Всё в одном кластере. Т.к. накладные расходы на сам кубернетес не так уж малы, хочется ограничиться одним кластером на: вспомогательные инструменты (гитлаб), мониторинг/логи, production, staging. Я так понимаю, есть namespaces, которые вроде должны позволять полностью разграничить все сервисы. Можно ли это считать приемлемым подходом? В основном волнует то, чтобы сервисы из других пространств имён не влияли на production. Я так понимаю, в кубере для этого есть все инструменты по ограничению ресурсов.

vbr
()

kubeadm init: [WARNING SystemVerification]: missing optional cgroups: blkio

 

Пытаюсь установить kubernetes по официальной инструкции. При запуске kubeadm init вылезло предупреждение

[WARNING SystemVerification]: missing optional cgroups: blkio

Пытался нагуглить, не нагуглил. В целом вроде заработало. Но хочется понять, насколько это важно.

ОС - Ubuntu Server 22.04.

ls /sys/fs/cgroup/
cgroup.controllers      cgroup.threads         dev-mqueue.mount  io.stat                        sys-kernel-config.mount
cgroup.max.depth        cpu.pressure           init.scope        memory.numa_stat               sys-kernel-debug.mount
cgroup.max.descendants  cpuset.cpus.effective  io.cost.model     memory.pressure                sys-kernel-tracing.mount
cgroup.procs            cpuset.mems.effective  io.cost.qos       memory.stat                    system.slice
cgroup.stat             cpu.stat               io.pressure       misc.capacity                  user.slice
cgroup.subtree_control  dev-hugepages.mount    io.prio.class     sys-fs-fuse-connections.mount

Как я понял, должен быть файл /sys/fs/cgroup/blkio, у меня его нет.

Ничего особенно не настраивал, всё из коробки.

vbr
()

RSS подписка на новые темы