Kubernetes
Содержание
Kubernetes
Инструкция по работе с kubernetes.
Подготовка
Нужны несколько машин (nodes), одна из которых будет мастером. Системные требования:
- 2GB ОЗУ или больше;
- 2 ядра процессора или больше;
- Все машины должны быть доступны по сети друг для друга;
- У всех машин должен быть уникальный hostname;
- Все машины должны успешно разрешать имена hostname друг друга (через DNS или hosts);
- Своп должен быть выключен
Пакеты и сервисы
-
Нужно установить следующие пакеты:
# apt-get install kubernetes1.33-kubeadm kubernetes1.33-kubelet kubernetes1.33-crio cri-tools1.33Вместо 1.33 можно указать любую доступную в репозитории версию. Список доступных пакетов можно посмотреть на сайте https://packages.altlinux.org/ru/search/?q=kubernetes
-
И запустить сервис crio, также рекомендуется активировать сервис kubelet, чтобы он запускался при перезагрузке хоста:
# systemctl enable --now crio # systemctl enable kubelet
Разворачивание кластера
Подготовка
Отключите подкачку:
# swapoff -a
Разворачивание
- На мастере нужно запустить одну из двух следующих команд для запуска кластера:
-
Для настройки сети с использованием Flannel:
# kubeadm init --pod-network-cidr=10.244.0.0/16
Или для использования control plane образов на базе ALT вместо образов по умолчанию:
# kubeadm init --pod-network-cidr=10.244.0.0/16 --kubernetes-version=1.33.6 --image-repository=registry.altlinux.org/p11
-
Для настройки сети с использованием Calico
# kubeadm init --pod-network-cidr=192.168.0.0/16
Или для использования control plane образов на базе ALT вместо образов по умолчанию:
# kubeadm init --pod-network-cidr=192.168.0.0/16 --kubernetes-version=1.33.6 --image-repository=registry.altlinux.org/p11
Пояснение флагов:
--pod-network-cidr=10.244.0.0/16— внутренняя (разворачиваемая Kubernetes) сеть, данное значение рекомендуется оставить для правильной работыFlannel;
--image-repository=registry.altlinux.org/p11— переопределение реестра, откуда будут скачиваться control plane образы.
--kubernetes-version=1.33.6— использовать версию kubernetes 1.33.6 для компонентов control plane.
В конце вывода будет строка вида:
kubeadm join <ip адрес>:<порт> --token <токен> --discovery-token-ca-cert-hash sha256:<хэш>Примечание: Упрощённый запуск с помощью `kubeadm init ...` и `kubeadm join ...` без config-файла подходит только для базового ознакомления. Для предсказуемой настройки kubelet, запущенного на нодах, рекомендуется использовать флаг `--config` для использования конфигурационного файла таким образом:# Предварительно вы должны самостоятельно подготовить конфигурационный файл kubeadm init --config kubeadm-config.yaml
Это явно определит схему аутентификации и авторизации kubelet.
Пример файла kubeadm-config.yaml:
apiVersion: kubeadm.k8s.io/v1beta4 kind: JoinConfiguration discovery: bootstrapToken: apiServerEndpoint: <CONTROL_PLANE_IP>:6443 token: <TOKEN> caCertHashes: - sha256:<HASH> nodeRegistration: criSocket: unix:///var/run/crio/crio.sock --- apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration authentication: anonymous: enabled: false webhook: enabled: true authorization: mode: Webhook cgroupDriver: systemd containerRuntimeEndpoint: unix:///var/run/crio/crio.sock
-
Для настройки сети с использованием Flannel:
-
Настройка
kubernetesдля работы от пользователя-
Создать каталог ~/.kube:
$ mkdir ~/.kube -
Скопировать конфиг:
# cp /etc/kubernetes/admin.conf /home/<пользователь>/.kube/configПримечание: Команда для копирования конфигурации с удалённого сервера через `scp` на ваш компьютер, где установлен `kubectl`:scp <пользователь>@<сервер>:/etc/kubernetes/admin.conf ~/.kube/remote-configПосле этого вы можете или переименовать `remote-config` в `config`, или, если локально у вас уже есть сконфигурированные через `kubectl` кластеры, объедините конфигурацию удалённого кластера с уже существующими:
# делаем бекап старой конфигурации mv ~/.kube/config ~/.kube/config_backup # объединяем конфигурацию KUBECONFIG=~/.kube/config:remote-config kubectl config view --flatten > config
Затем переключитесь на нужный вам кластер следующим образом:
kubectl config use-context <имя-контекста> -
Изменить владельца конфига:
# chown <пользователь>: /home/<пользователь>/.kube/configПримечание: Если предпочитаете работать от root-пользователя:export KUBECONFIG=/etc/kubernetes/admin.conf
-
Создать каталог ~/.kube:
-
После этого все остальные ноды нужно подключить к мастеру:
# kubeadm join <ip адрес>:<порт> --token <токен> --discovery-token-ca-cert-hash sha256:<хэш>- Проверить наличие нод можно так:
$ kubectl get nodes -o wide- Вывод примерно следующий:
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME master NotReady control-plane 19m v1.24.8 172.16.0.8 <none> ALT Regular 5.15.90-std-def-alt1 cri-o://1.24.3 node NotReady <none> 19m v1.24.8 172.16.0.9 <none> ALT Regular 5.15.90-std-def-alt1 cri-o://1.24.3
Обратите внисание, что ноды находятся в состоянии
NotReady. Они перейдут в состояниеReadyпосле настройки сети. -
Далее следует развернуть сеть. Для этого на мастер-ноде (control-plane) запустите команды:
- Для Flannel:
$ kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml- Для Flannel с использованием образов на базе ALT:
- Манифесты находятся по адресу
https://altlinux.space/cloud/manifests/src/branch/master/flannel/<платформа>. - Где <платформа> на текущий момент (12.12.2025):
sisyphus,p11,c10f. - Каждый каталог платформы содержит каталоги
├── <major> │ ├── <minor> │ │ └── <patch> │ │ └── kube-flannel.yml ... └── latest └── kube-flannel.yml
- Выберите для Вашей платформы (например
sisyphus) установленной версииkubernetesнеобходимую версиюflannel(например0.27.3) и наберите команду разворачивания: $ kubectl apply -f https://altlinux.space/cloud/manifests/raw/branch/master/flannel/sisyphus/0/27/3/kube-flannel.yml- Для последних версий
kubernetesможно использовать последнюю версиюflannel(тегlatest): $ kubectl apply -f https://altlinux.space/cloud/manifests/raw/branch/master/flannel/sisyphus/latest/kube-flannel.yml
- Для Calico:
- Перед запуском
calico-манифестовперейдите в каталог/etc/cni/net.d/:
# cd /etc/cni/net.d/
- и создайте файл
100-crio-bridge.conflist
- и создайте файл
# cp 100-crio-bridge.conflist.sample 100-crio-bridge.conflist
- Запустите POD'ы из
calico-манифестов:
- Запустите POD'ы из
$ kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/master/manifests/tigera-operator.yaml$ kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/master/manifests/custom-resources.yaml- Проверить, что всё работает можно так:
$ kubectl get pods --namespace kube-system- Вывод должен быть примерно таким:
NAME READY STATUS RESTARTS AGE coredns-78fcdf6894-6trk7 1/1 Running 0 2h coredns-78fcdf6894-nwt5l 1/1 Running 0 2h etcd-k8s 1/1 Running 0 2h kube-apiserver-k8s 1/1 Running 0 2h kube-controller-manager-k8s 1/1 Running 0 2h kube-flannel-ds-894bt 1/1 Running 0 2h kube-flannel-ds-kbngw 1/1 Running 0 2h kube-flannel-ds-n7h45 1/1 Running 0 2h kube-flannel-ds-tz2rc 1/1 Running 0 2h kube-proxy-6f4lm 1/1 Running 0 2h kube-proxy-f92js 1/1 Running 0 2h kube-proxy-qkh54 1/1 Running 0 2h kube-proxy-szvlt 1/1 Running 0 2h kube-scheduler-k8s 1/1 Running 0 2h
Следует обратить внимание, что coredns находятся в состоянии Running.
Количество kube-flannel и kube-proxy зависит от общего числа нод (в данном случае их четыре).
Если coredns находится в состоянии "crashloopbackoff", то проверьте содержимое файла /etc/resolv.conf. Для каждой ноды в резолвере должны быть указаны реальные адреса (например 192.168.3.30, при развертывании в локальной сети на виртуальных машинах)
Использование конфигурационного файла вместо опций kubeadm
Для более глубокой кастомизации рекомендуется использовать конфигурационный файл, а не CLI опции программы kubeadm.
Пример конфигурационного файла cluster_configuration.yaml:
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
imageRepository: registry.altlinux.org/p11
kubernetesVersion: 1.35.0
etcd:
local:
imageTag: v3.6.6
dns:
imageTag: v1.13.1
networking:
podSubnet: 10.244.0.0/16
Все возможные опции конфигурации доступны в официальной документации.
Путь к созданному файлу указывается через опцию --config для kubeadm.
Убедиться, что будут использовать указанные образы:
# kubeadm config images list --config=./config.yaml
registry.altlinux.org/p11/kube-apiserver:v1.35.0
registry.altlinux.org/p11/kube-controller-manager:v1.35.0
registry.altlinux.org/p11/kube-scheduler:v1.35.0
registry.altlinux.org/p11/kube-proxy:v1.35.0
registry.altlinux.org/p11/coredns:v1.13.1
registry.altlinux.org/p11/pause:3.10.1
registry.altlinux.org/p11/etcd:v3.6.6
Если по какой-то причине необходимо изменить версию образа pause, то это делается в конфигурационном файле CRI. Для cri-o необходимо изменить файл /etc/crio/crio.conf:
[crio.image]
pause_image = "registry.altlinux.org/p11/pause:3.10.1"
Создание кластера:
# kubeadm init --config=./cluster_configuration.yaml
Тестовый запуск nginx
-
Для начала создадим Deployment:
$ kubectl apply -f https://k8s.io/examples/application/deployment.yaml -
Затем создадим сервис, с помощью которого можно получить доступ к нашему приложению из внешней сети.
Сохраним в файл nginx-service.yaml следующую кофигурацию:
apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: type: NodePort ports: - port: 80 targetPort: 80 selector: app: nginx
-
Запустим новый сервис:
$ kubectl apply -f nginx-service.yaml -
Теперь можно узнать его порт:
$ kubectl get svc nginxВозможный вывод:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx NodePort 10.108.199.141 <none> 80:32336/TCP 4h
-
Проверим, что всё работает:
$ curl <ip адрес>:<порт>где
- ip адрес - это адрес любой из нод (не мастера), а порт - это порт сервиса, полученный с помощью предыдущей команды. Если использовать данные из примеров, то возможная команда:
curl 10.10.3.120:32336.
- ip адрес - это адрес любой из нод (не мастера), а порт - это порт сервиса, полученный с помощью предыдущей команды. Если использовать данные из примеров, то возможная команда:
Обновление
CRI-O
При использовании cri-o следует обратить внимание на то, что до версии cri-o 1.30 по умолчанию использовался runc в качестве рантайма. В версии cri-o 1.31 апстрим сменил рантайм по умолчанию на crun.
Если конфигурационный файл /etc/crio/crio.conf не менялся после установки пакета версий до 1.30, то по умолчанию используется runc, и данные рантайма хранятся в /run/runc, а после обновления с 1.30 до 1.31 теперь по умолчанию используется crun и данные ожидаются в /run/crun.
Для избежания проблем с запуском сервиса cri-o следует перед обновлением зафиксировать желаемый райнтайм в конфигурационном файле /etc/crio/crio.conf. Достаточно раскомментировать строку с установкой рантайма по умолчанию.
...
default_runtime = "runc"
...см. altbug #53963