Перейти к основному контенту

Kubernetes


Содержание

Kubernetes

Инструкция по работе с kubernetes.

Подготовка

Нужны несколько машин (nodes), одна из которых будет мастером. Системные требования:

    2GB ОЗУ или больше; 2 ядра процессора или больше; Все машины должны быть доступны по сети друг для друга; У всех машин должен быть уникальный hostname; Все машины должны успешно разрешать имена hostname друг друга (через DNS или hosts); Своп должен быть выключен

    Пакеты и сервисы

    1. Нужно установить следующие пакеты: 
      # 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

    2. И запустить сервис crio, также рекомендуется активировать сервис kubelet, чтобы он запускался при перезагрузке хоста: 
      # systemctl enable --now crio
# systemctl enable kubelet

    Разворачивание кластера

    Подготовка

    Отключите подкачку: 

    # swapoff -a

    Разворачивание

    1.  На мастере нужно запустить одну из двух следующих команд для запуска кластера:
      • Для настройки сети с использованием Flannel: 
        # kubeadm init --pod-network-cidr=10.cidr=10.244.0.0/16

        Или для использования control plane образов на базе ALT вместо образов по умолчанию: 

        # kubeadm init --pod-network-cidr=10.cidr=10.244.0.0/16 --kubernetes-version=1.version=1.33.6 --image-repository=repository=registry.altlinux.org/p11
      • Для настройки сети с использованием Calico 
        # kubeadm init --pod-network-cidr=192.cidr=192.168.0.0/16

        Или для использования control plane образов на базе ALT вместо образов по умолчанию: 

        # kubeadm init --pod-network-cidr=192.cidr=192.168.0.0/16 --kubernetes-version=1.version=1.33.6 --image-repository=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:apiVersion: kubeadm.k8s.io/v1beta4
kind:kind: JoinConfiguration
discovery:discovery:
  bootstrapToken:
    bootstrapToken:apiServerEndpoint:     apiServerEndpoint: <CONTROL_PLANE_IP>:6443
    token: token: <TOKEN>
    caCertHashes:
      caCertHashes:-       - sha256:<HASH>
nodeRegistration:nodeRegistration:
  criSocket: criSocket: unix:///var/run/crio/crio.sock
---
apiVersion:apiVersion: kubelet.config.k8s.io/v1beta1
kind:kind: KubeletConfiguration
authentication:authentication:
  anonymous:
    anonymous:enabled: false
  enabled:webhook:
    falseenabled: true
webhook:authorization:
  mode: enabled:Webhook
truecgroupDriver: authorization:systemd
containerRuntimeEndpoint: mode: Webhook
cgroupDriver: systemd
containerRuntimeEndpoint: unix:///var/run/crio/crio.sock
    Настройка kubernetes для работы от пользователя
    1. Создать каталог ~/.kube: 
      $ mkdir ~/.kube
    2. Скопировать конфиг: 
      # 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 <имя-контекста>
    3. Изменить владельца конфига: 
      # chown <пользователь>: /home/<пользователь>/.kube/config
      Примечание: Если предпочитаете работать от root-пользователя: 
      export KUBECONFIG=/etc/kubernetes/admin.conf
    После этого все остальные ноды нужно подключить к мастеру: 
    # 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-100-crio-bridge.conflist.sample 100-100-crio-bridge.conflist
          Запустите POD'ы из calico-манифестов: 
          $ 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:apiVersion: kubeadm.k8s.io/v1beta4
kind:kind: ClusterConfiguration
imageRepository:imageRepository: registry.altlinux.org/p11
kubernetesVersion:kubernetesVersion: 1.35.0
etcd:etcd:
  local:
    local:imageTag:     imageTag: v3.6.6
dns:dns:
  imageTag: imageTag: v1.13.1
networking:networking:
  podSubnet: podSubnet: 10.244.0.0/16

          Все возможные опции конфигурации доступны в официальной документации.

          Путь к созданному файлу указывается через опцию --config для kubeadm.

          Убедиться, что будут использовать указанные образы: 

          # kubeadm config images list --config=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=config=./cluster_configuration.yaml

          Тестовый запуск nginx

          1. Для начала создадим Deployment: 
            $ kubectl apply -f https://k8s.io/examples/application/deployment.yaml
          2. Затем создадим сервис, с помощью которого можно получить доступ к нашему приложению из внешней сети. Сохраним в файл nginx-service.yaml следующую кофигурацию: 
            apiVersion:apiVersion: v1
kind:kind: Service
metadata:metadata:
  name: name:nginx
  labels:
    app: nginx
spec:
  labels:type: NodePort
  app:ports:
  - port: 80
    targetPort: 80
  selector:
    app: nginx
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: nginx
          3. Запустим новый сервис: 
            $ kubectl apply -f nginx-service.yaml
          4. Теперь можно узнать его порт: 
            $ kubectl get svc nginx

            Возможный вывод: 

            NAME      TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
nginx     NodePort   10.108.199.141   <none>        80:32336/TCP   4h
          5. Проверим, что всё работает: 
            $ curl <ip адрес>:<порт>

            где

          ip адрес - это адрес любой из нод (не мастера), а порт - это порт сервиса, полученный с помощью предыдущей команды. Если использовать данные из примеров, то возможная команда: curl 10.10.3.120:32336.

          Обновление

          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

          Смотрите также

            Cilium Kube-bench Cert-manager Kubevirt Trivy-operator Kyverno ОС Альт СП Kubernetes

             

             

            Наверх