Кластеры Kubernetes

Кластеры Kubernetes используются в высоконагруженных информационных системах для управления распределением трафика и автоматического масштабирования узлов. Ключевые особенности:

• Отказоустойчивость.
• Автоматическое масштабирование.
• Эффективное распределение трафика с помощью выделенных балансировщиков нагрузки.

В контейнерах Kubernetes можно быстро запускать и управлять тестовыми средами и, таким образом, автоматизировать и упростить процессы разработки и тестирования. Преимущества:

• Быстрое создание большого количества тестовых сред Kubernetes.
• Развёртывание экземпляров кластеров Kubernetes версии 1.26.5.
• Снижение затрат на хостинг тестовых сред до 3 раз.
• Автоматизация процессов CI/CD.
• Стандартизация разработки в распределённых командах и при работе с аутсорсерами.

Создание и запуск кластера осуществляется при помощи Портала самообслуживания (подробнее — в Руководстве пользователя VK Private Cloud).

Для обеспечения постоянного хранения данных, в Kubernetes существуют следующие виды ресурсов:

• PersistentVolume (PV) — раздел на жёстком диске, доступном из кластера. Взаимодействие кластера с PV осуществляется так же, как с узлами.
• PersistentVolumeClaim (PVC) — пользовательский запрос на использование данного диска. Взаимодействие PV с PVC осуществляется так же, как рабочий узел взаимодействует с подами, то есть PVC запрашивает у PV необходимый размер диска и тип доступа — ReadWriteOnce, ReadOnlyMany или ReadWriteMany.

Подключение PV и PVC выполняется автоматически из кластера на основании Storage class, интегрированного с Cinder.

 
apiVersion: v1kind: PersistentVolumeClaimmetadata:  name: portal-info-data-pvcspec:  volumeMode: Filesystem  accessModes:    - ReadWriteMany  resources:    requests:      storage: 100Gi  volumeName: "portal-info-data-pv"  storageClassName: ""

 
$ kubectl create -f new-pvc.yaml$ kubectl get pvc$ kubectl get pv | grep new-pvc

Подключение NFS-хранилища с помощью Persistent Volume и Persistent Volume Claim приведено в данной инструкции.

Kubernetes Dashboard — графический интерфейс для управления контейнерами Kubernetes.

Локальный клиент для Kubernetes kubectl позволяет выполнять команды для кластеров Kubernetes. Можно использовать kubectl для разворачивания приложений, проверки ресурсов кластера и управления ими, просмотра журналов.

Чтобы проверить актуальность установленной версии kubectl:

1. Узнайте номер последней стабильной версии клиента kubectl: например, по ссылке запроса стабильной версии.

2. Проверьте текущую версию kubectl, чтобы убедиться, что она совместима с версией API сервера кластера:

    
   $ kubectl version

Установка выполняется штатными средствами используемой операционной системы (подробнее — в официальной документации).

Инструкция по подключению kubectl к кластеру Kubernetes приведена в Руководстве пользователя VK Private Cloud в разделе Подключение к кластеру через Kubectl.

Инструкция по настройке доступа к Kubernetes Dashboard приведена в Руководстве пользователя VK Private Cloud в разделе Подключение к Kubernetes Dashboard.

Доступно вертикальное и горизонтальное масштабирование кластера Kubernetes (с настройками автомасштабирования), подробнее — в Руководстве пользователя VK Private Cloud.

Конфигурация позволяет понять, с каким Kubernetes-кластером взаимодействует kubectl. Подробная информация о структуре конфигурационного файла приведена в статье Configure Access to Multiple Clusters.

 
$ kubectl --insecure-skip-tls-verify=true --kubeconfig rk12_kubeconfig.yaml config

 
$ KUBECONFIG=~/.kube/kubconfig1:~/.kube/kubconfig2$ kubectl --insecure-skip-tls-verify=true --kubeconfig rk12_kubeconfig.yaml config view

 
$ kubectl --insecure-skip-tls-verify=true --kubeconfig rk12_kubeconfig.yaml config view -o jsonpath='{.users[?(@.name == "<ЛОГИН_ИНТЕРЕСУЮЩЕГО_ПОЛЬЗОВАТЕЛЯ>")].user.password}'

 
$ kubectl --insecure-skip-tls-verify=true --kubeconfig rk12_kubeconfig.yaml config get-contexts

 
$ kubectl --insecure-skip-tls-verify=true --kubeconfig rk12_kubeconfig.yaml config current-context

 
$ kubectl --insecure-skip-tls-verify=true --kubeconfig rk12_kubeconfig.yaml config use-context <НАЗВАНИЕ_КЛАСТЕРА>

Deployment — это объект Kubernetes, представляющий набор множества идентичных контейнеров без уникальных номеров. Deployment позволяет запускать несколько реплик приложений и автоматически заменять экземпляры приложений в случае сбоя.

 
$ kubectl --insecure-skip-tls-verify=true --kubeconfig rk12_kubeconfig.yaml create deployment <НАЗВАНИЕ> --image=<НАЗВАНИЕ_ОБРАЗА_КОНТЕЙНЕРА>

 
$ kubectl --insecure-skip-tls-verify=true --kubeconfig rk12_kubeconfig.yaml describe deployment <НАЗВАНИЕ_DEPLOYMENT>

 
apiVersion: apps/v1kind: Deploymentmetadata:  name: nginxspec:  replicas: 3  selector:    matchLabels:      app: nginx  template:    metadata:      labels:        app: nginx    spec:      containers:      - name: nginx        image: nginx:1.7.9        ports:        - containerPort: 80

В данном примере создаётся три идентичных контейнера с именем nginx на базе образа NGINX версии 1.7.9. Доступ к контейнерам осуществляется по 80-му порту.

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

 
$ kubectl --insecure-skip-tls-verify=true --kubeconfig rk12_kubeconfig.yaml apply -f <НАЗВАНИЕ_DEPLOYMENT>

1. Получите список текущих контейнеров:

    
   $ kubectl --insecure-skip-tls-verify=true --kubeconfig rk12_kubeconfig.yaml get po -n <НАЗВАНИЕ_ПРОСТРАНСТВА_ИМЁН>

2. Получите список журналов конкретного контейнера:

    
   $ kubectl --insecure-skip-tls-verify=true --kubeconfig rk12_kubeconfig.yaml -n <НАЗВАНИЕ_ПРОСТРАНСТВА_ИМЁН> logs <ИМЯ_КОНТЕЙНЕРА>

   Системные контейнеры расположены в пространстве имён kube-system. Наиболее востребованные контейнеры:

   • cluster-autoscaler-* — журнал событий масштабирования контейнеров.

   • openstack-cloud-controller-* — журнал взаимодействия всех компонентов платформы виртуализации (например, с Cinder для создания дисков, с Nova для создания ВМ, Octavia для балансировщиков и так далее).

     Пример просмотра журнала cluster-autoscaler-*

      
     $ kubectl --insecure-skip-tls-verify=true --kubeconfig rk12_kubeconfig.yaml -n kube-system logs cluster-autoscaler-7f754489f8-qxsqf...I1230 08:33:58.952822       1 filter_out_schedulable.go:90] No schedulable podsI1230 08:33:58.952850       1 static_autoscaler.go:334] No unschedulable podsI1230 08:33:58.952877       1 static_autoscaler.go:381] Calculating unneeded nodes....84c14039e967,Unschedulable:false,Taints:[]Taint{Taint{Key:CriticalAddonsOnly,Value:True,Effect:NoSchedule,TimeAdded:<nil>,},Taint{Key:dedicated,Value:master,Effect:NoSchedule,TimeAdded:<nil>,},},ConfigSource:nil,PodCIDRs:[],}...

     Пример просмотра журнала openstack-cloud-controller-*

      
     $ kubectl  --insecure-skip-tls-verify=true --kubeconfig rk12_kubeconfig.yaml -n kube-system logs openstack-cloud-controller-manager-nnrlx...Ensuring load balancer for service ingress-nginx/nginx-ingress-controllerE1222 08:23:53.451038       1 service_controller.go:255] error processing service ingress-nginx/nginx-ingress-controller (will retry): failed to ensure load balancer: there are no available nodes for LoadBalancer service ingress-nginx/nginx-ingress-controllerI1222 08:23:53.451162       1 event.go:255] Event(v1.ObjectReference{Kind:"Service", Namespace:"ingress-nginx", Name:"nginx-ingress-controller", UID:"68bb8ac5-b7f4-4404-94b2-943e7e55ddc9", APIVersion:"v1", ResourceVersion:"953", FieldPath:""}): type: 'Normal' reason: 'EnsuringLoadBalancer' Ensuring load balancer...

Helm — менеджер пакетов для Kubernetes, который используется для быстрой установки сложных приложений, таких как CRM, e-commerce, БД и прочие.

Helm доступен в созданных кластерах по умолчанию.

StatefulSet — это удобный способ работы со Stateful-приложениями, которым требуется обрабатывать события об остановке работы Pod и осуществления Graceful Shutdown. Обычно, такие приложения — это базы данных и очереди сообщений, которые работают в нескольких экземплярах, синхронизируемых друг с другом посредством репликации или кластеризации.

Существует несколько способов организации таких схем: с использованием общих Persistent Volumes (RWX) и с помощью индивидуальных Persistent Volumes (RWO). Подробности приведены в данной инструкции.