Контейнеры docker/kubernetes с Ubuntu введение часть #1 (подготовка).

[D2]

Собственно, простыми словами отличие виртуалки от контейнера в том, что, при запуске приложения на контейнере как правило не требуется ядро операционной системы(на примере никсов).Далее подробно.
Контейнеры очень удобны при работе с микросервисами(архитектура приложения).
Не всегда, контейнер/ы развернуть проще чем развернуть виртуалу, но выгоднее в силу того, что это снижает портабельность, востребованность в железе и увеличивает быстродействие.
Начнем с виртуалки - это система действует точно так же как компьютер. Виртуалка ведет себя как полноценный отдельный компьютер, можно использовать для работы с различными операционными системами, запускать приложения которые не могут работать на вашей основной операционной системе.

Контейниризация началась с Docker’а 13 марта 2013 года на никсах.
Docker - контейнерная технология, позволяющая разрабатывать(упрощает процесс) микросервисы/распределенные приложения.

Если дело доходит до облачной инфраструктуры, виртуальная машина является стандартом перехода по многим своим преимуществам.
Если есть альтернатива виртуальной машине, которая была бы более легкой, экономичной и масштабируемой. То это Docker. Если говорить про Kubernetes(кубер), то это pod’ы.


Про Docker писать не буду, уже всем давно все извесно. Выяснилось что с ним удобнее, ну и типо идем в ногу со временем, точнее отстаем, кубер знаменит, лет n, назад.
Сразу хочу озвучить, что, если мы касаемся kubernetes(кубер), то определенно, речь зайдет о docker’е.

--------------------------------------------------------------------
Начнем..
Я буду извращаться и делать все это из под mac m1, поэтому немного brew(но можно и с port’ами).

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

Ставим multipass:
brew install —cask multipass

Полетели!

Пока выполняем код ниже, потом напишу зачем.

Запускаем виртуалку - мастер ноду с минимальными требованиями - Ubuntu 24.04 LTS:
multipass launch —name k8s.master1.local —cpus 2 —memory 2G —disk 5G 24.04

Запускаем виртуалку - воркер ноду1 с минимальными требованиями - Ubuntu 24.04 LTS:
multipass launch —name k8s.worker1.local —cpus 2 —memory 2G —disk 5G 24.04

Запускаем виртуалку - воркер ноду2 с минимальными требованиями - Ubuntu 24.04 LTS:
multipass launch —name k8s.worker2.local —cpus 2 —memory 2G —disk 5G 24.04

Минимальный кластер кубера состоит из трех под/узлов(мастер и два воркера).
Master - отвечает за управление кластером.
Worker’ы - на них выполняются приложения.

Проверим какие присовились IP адреса нашим нодам:
multipass list | grep -e '^Name' -e k8s-
Спойлер: Вывод
Name State IPv4 Image
k8s.master1.local Running 192.168.27.3 Ubuntu 24.04 LTS
k8s.worker1.local Running 192.168.27.4 Ubuntu 24.04 LTS
k8s.worker2.local Running 192.168.27.5 Ubuntu 24.04 LTS

Ansible'а нет, и playbook не настроишь, хотя можно было бы поставить, поэтому писать про это нет смысла(виртуалок мало) логинимся на каждой виртуалке и прописываем следующее(некоторое распишу, все расписывать нет смысла) делать буду на основе master’а(иначе топик получится нечитабельным):
multipass shell k8s.master1.local
sudo nano /etc/hosts
Спойлер: Ввод
k8s.master1.local 192.168.27.3
k8s.worker1.local 192.168.27.4
k8s.worker2.local 192.168.27.5

Объяснять не нужно, третья строчка понадобится позже(ввести сейчас/рекомендуется по нескольким причинам: деградация производительности(требуется значительное количество памяти, так-же помогает предотвратить риск вызова процесса OOM killer, исчерпывание свободной памяти в связи с этим кубер может завершать приоритетные/критические компоненты)):
Код: Скопировать в буфер обмена

sudo apt update && apt upgrade
sudo apt install curl apt-transport-https git iptables-persistent
swapoff -a

Закомментировать строчку swap.img в fstab, для этого:
sudo nano /etc/fstab

Загружаем дополнительные модули ядра:
sudo nano /etc/modules-load.d/k8s.conf
Спойлер: Ввод
br_netfilter
overlay

overlay потребуется для загрузки мостового трафика в iptables и объединенной файловой системы для контейнеров.

Загружаем модули в ядро:
Код: Скопировать в буфер обмена

modprobe br_netfilter
modprobe overlay

Проверка модулей:
lsmod | grep -E 'br_netfilter|overlay'
Спойлер: Вывод
overlay 204800 0
br_netfilter 32768 0
bridge 401408 1 br_netfilter
Создаем конфигурационный файл, в котором разрешаем обработку трафика через bridge в netfilter:
sudo nano /etc/sysctl.d/k8s.conf
Спойлер: Ввод
net.bridge.bridge-nf-call.iptables = 1
net.bridge.bridge-nf-call.ip6tables = 1

Применение параметров:
sudo sysctl —system

Для master’a и worker’а создаем разные правила iptables.

На master/Control-plane разрешим следующие порты:
Спойлер: Надо
6443(подключение для управления(Kubernetes API),
2379:2380(порты для взаимодействия master’а с worker’ами(etcd server client API),
10250:10252(работа с kublete(API, Scheduller, controller-manager))))
sudo iptables -I INPUT 1 -p tcp --match multiport —dports 6443,2379:2380,10250:10252 -j ACCEPT

Для сохранения:
sudo netfilter-persistent save

На worker’е разрешаем следующие порты:
Спойлер: Надо
10250(подключение к kublete API),
30000:32767(рабочие порты по умолчанию для подключения к pod’ам(NodePort Services))
sudo iptables -I INPUT 1 -p tcp —match multiport —dports 10250,30000:32767 -j ACCEPT

Для сохранения:
sudo netfilter-persistent save


Таким образом мы создали виртуалки(или на железе) задали имена узлов, установили компоненты для этой статьи, отключили файл подкачки, загрузили дополнительные модули ядра, изменили параметры ядра, на master и worker нодазх прописали правила.


Понравилось? Плюсуй, кидай мелочь, в любом случае пишу еще.