Раздражает когда в офф. репозитории используемого дистрибутива linux есть только относительно старые пакеты (не последних версий) (╯°益°)╯彡┻━┻. И приходится устанавливать последние версии вручную.
Именно так обстоят дела с AltLinux, видимо они не поспевают обновлять все пакеты в своих репозиториях...
Для работы k8s нам нужны:
- Kubectl — позволяет создавать и настраивать объекты в кластере.
- Kubelet — занимается запуском контейнеров на хостах.
- Kubeadm — позволит настраивать компоненты, составляющие кластер.
Я ставил по инструкции https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/
Создал файл install.sh с содержимым
CNI_PLUGINS_VERSION="v1.3.0"
CRICTL_VERSION="v1.28.0"
ARCH="amd64"
DEST="/opt/cni/bin"
DOWNLOAD_DIR="/usr/local/bin"
RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
RELEASE_VERSION="v0.15.1"
sudo mkdir -p "$DOWNLOAD_DIR"
sudo mkdir -p "$DEST"
sudo curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_PLUGINS_VERSION}/cni-plugins-linux-${ARCH}-${CNI_PLUGINS_VERSION}.tgz" | sudo tar -C "$DEST" -xz
sudo curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
cd $DOWNLOAD_DIR
sudo curl -L --remote-name-all https://dl.k8s.io/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet}
sudo chmod +x {kubeadm,kubelet}
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service
sudo mkdir -p /etc/systemd/system/kubelet.service.d
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Запустим с правами суперпользователя sudo ./install.sh, будут устанволенны kubeadm,kubelet
Установим kubectl
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/bin/kubectl
Проверим устанволенную весрию
$ kubectl version --client
Client Version: v1.28.1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Устанвоим crio контейнерный движок (вместо постепенно уходящего на второй план docker, или более приятного podma) рекомендуемые k8s. Я так понимаю что можно выбрать и Containerd.
В чем разница междудвумя движками я режил поинтересоваться у нейронки от phind.com:
Выбор между CRI-O и containerd в качестве контейнерного движка для Kubernetes в большей степени зависит от ваших индивидуальных требований и предпочтений, а не от версии Kubernetes. Оба движка поддерживаются Kubernetes и активно развиваются.
CRI-O и containerd оба являются реализациями интерфейса контейнерного среды выполнения (Container Runtime Interface, CRI) для Kubernetes и оба поддерживают стандарты Open Container Initiative (OCI). Они оба предлагают альтернативу Docker в качестве среды выполнения контейнера для Kubernetes.
Вот некоторые особенности каждого из них:
-CRI-O: CRI-O был создан специально для Kubernetes и следует за его циклами выпуска. Это может облегчить совместимость и интеграцию. CRI-O поддерживает как runc, так и crun в качестве OCI совместимых сред выполнения, а также поддерживает различные сетевые плагины через CNI (Container Network Interface)
-containerd: containerd был создан как более универсальная среда выполнения контейнера и используется Docker в качестве его подсистемы. Он поддерживает множество различных плагинов и расширений, что может предложить больше гибкости. Однако, его циклы выпуска не синхронизированы с Kubernetes, что может затруднить совместимость в некоторых случаях
В обоих случаях, вам следует проверить документацию и сообщество каждого проекта, чтобы определить, какой из них лучше подходит для ваших потребностей.
CodeLlama-34b дал такой ответ
Контейнерные движки CRI-O и Containerd являются популярными и широко используемыми в производственных средах. Обе они поддерживаются Kubernetes и могут использоваться с версией 1.28.1. Однако, выбор между ними зависит от ваших конкретных потребностей и предпочтений.Ниже представлены некоторые общие отличия между этими двумя движками:
-Архитектура: CRI-O использует архитектуру "client-server", в которой клиентский процесс (например, Kubernetes) взаимодействует с сервером CRI-O через API. Containerd, с другой стороны, использует более простую архитектуру "daemon", в которой клиентский процесс напрямую взаимодействует с демонским процессом containerd.
-Поддержка функциональности: CRI-O имеет более широкий спектр функциональности, включая поддержку SELinux, AppArmor, seccomp и другие возможности безопасности. Containerd, с другой стороны, имеет меньше функциональных возможностей, но может быть легче настроен и имеет более простой интерфейс.
-Производительность: Containerd обычно быстрее CRI-O из-за своей простой архитектуры и меньшей сложности. Однако, производительность может зависеть от многих факторов, таких как количество контейнеров, размер контейнеров и т.д.
-Поддержка платформы: CRI-O поддерживает большинство платформ, включая x86, ARM, PowerPC и другие. Containerd также поддерживает множество платформ, но может иметь ограничения в зависимости от дистрибутива Linux.
В зависимости от ваших потребностей и предпочтений, вы можете выбрать любой из этих двух движков. Если вам нужна более широкая функциональность и поддержка безопасности, то лучшим выбором будет CRI-O. Если же вам важнее скорость и простота настройки, то Containerd может быть более подходящим выбором.
в репозитории он также не акутально версии, инструкция и архив в офф репозитории:
Скачаем и распакуем архив:
wget https://storage.googleapis.com/cri-o/artifacts/cri-o.amd64.v1.28.1.tar.gz
tar xfz cri-o.amd64.v1.28.1.tar.gz
в распакованной директори запустим install.sh
Скрипт устнаваливает исполняемые файлы в /usr/local/bin
проверим версию
$crio verison
Starting CRI-O, version: 1.28.1, git: eda470f7f503d9f40a9aa2a02e45f0878ed6fc61(dirty)
Version: 1.28.1
Отличненько...
Изменим параметры iptables, создадим файл /etc/sysctl.d/99-kubernetes-cri.con и добавим в него строки:
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1 EOF
Для надежности пропишем в теримнале:
sysctl net.bridge.bridge-nf-call-iptables=1
sysctl net.bridge.bridge-nf-call-ip6tables=1
Выполним
sudo modprobe overlay
sudo modprobe br_netfilter
Применим настройки
sudo sysctl --system
Запустим службы
sudo systemctl daemon-reload
sudo systemctl enable crio --now
sudo systemctl status crio
crio почему то не может создать дирректорию , поэтому сосздал в ручную
mkdir /var/run/crio
sudo systemctl restart crio
Т.к. я хочу попробовать развернуть single node cluster, то нужно разрешить разворачивать Pods на мастер ноде.
sudo kubectl taint nodes --all node-role.kubernetes.io/control-plane-
Пробуем инициализировать кластер:
sudo kubeadm init --pod-network-cidr=10.244.0.0/16
И тут что то у меня всё зависло... долго висело... что то не то....
Полазив в мануалах нашел что нужно скачать системные образы: (－ᴥ－) zzZ
sudo kubeadm config images pull
[config/images] Pulled registry.k8s.io/kube-apiserver:v1.28.2
[config/images] Pulled registry.k8s.io/kube-controller-manager:v1.28.2
[config/images] Pulled registry.k8s.io/kube-scheduler:v1.28.2
[config/images] Pulled registry.k8s.io/kube-proxy:v1.28.2
[config/images] Pulled registry.k8s.io/pause:3.9
[config/images] Pulled registry.k8s.io/etcd:3.5.9-0
[config/images] Pulled registry.k8s.io/coredns/coredns:v1.10.1
Опять чёто задумалось, но через минут 5-10 раздумалось ヽ(*⌒▽⌒*)ﾉ
Повторяем инициализацию кластера:
sudo kubeadm init --pod-network-cidr=10.244.0.0/16
٩(╬ʘ益ʘ╬)۶ падла, опять что то не так
[kubelet-check] It seems like the kubelet isn't running or healthy.
[kubelet-check] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused.
Unfortunately, an error has occurred:
timed out waiting for the condition
This error is likely caused by:
- The kubelet is not running
- The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)
If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'
Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI.
Here is one example how you may list all running Kubernetes containers by using crictl:
- 'crictl --runtime-endpoint unix:///var/run/crio/crio.sock ps -a | grep kube | grep -v pause'
Once you have found the failing container, you can inspect its logs with:
- 'crictl --runtime-endpoint unix:///var/run/crio/crio.sock logs CONTAINERID'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster
To see the stack trace of this error execute with --v=5 or higher
Не знаю что дальше... придумаю продолжу... ٩(ఠ益ఠ)۶
Спустя 2 часа, снёс всё нафиг, на чистую систему установил всё заново
Добавилось:
sudo apt-get install ebtables
udo apt-get install socat
sudo apt-get install ethtool
sudo apt-get install etcd
sudo apt-get install conntrack-tools
Потому что при попытке инициализации кластера, требовались эти пакеты, и всё завелось. Ура Ура °˖✧◝(⁰▿⁰)◜✧˖°
Your Kubernetes control-plane has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Alternatively, if you are the root user, you can run:
export KUBECONFIG=/etc/kubernetes/admin.conf
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/
Then you can join any number of worker nodes by running the following on each as root:
kubeadm join 192.168.100.90:6443 --token ubscx1.eibutsafdgskeuoc \
--discovery-token-ca-cert-hash sha256:105dc16112b78368dced2677f972f12e2a5da9d692ff225594b764092b518e84
На радостях забыл про сетевой плагин
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
Чтобы выполнять комманды от текущего пользователя, скопируем конфиг админа
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Запущенные контейнеры можно посомтреть двумя способами:
kubectl get pods --namespace kube-system
NAME READY STATUS RESTARTS AGE
coredns-5dd5756b68-cfdv4 1/1 Running 0 26m
coredns-5dd5756b68-s8llt 1/1 Running 0 26m
etcd-test-maksimchuk.mfsk.int 1/1 Running 0 27m
kube-apiserver-test-maksimchuk.mfsk.int 1/1 Running 0 27m
kube-controller-manager-test-maksimchuk.mfsk.int 1/1 Running 0 27m
kube-proxy-4vwgx 1/1 Running 0 27m
kube-scheduler-test-maksimchuk.mfsk.int 1/1 Running 0 27m
и
sudo crictl ps
Тепреь нужно придумать как собирать образы и куда их деплоить. crio как я понял сам не умеет собирать образы из Containerfile , и контейнера repository я не вижу....
Всё в одном файле https://github.com/AoAnima/k8s-install
