Изучите кластер Kubernetes

Введение

В этом практическом занятии (лабораторной работе) вы будете исследовать локальный кластер Kubernetes с использованием Minikube. Вы запустите кластер, проверите его настройку и изучите основные ресурсы кластера, такие как поды (pods) и развертывания (deployments). Этот практический опыт поможет вам понять основные компоненты и команды среды Kubernetes, заложив основу для дальнейшего исследования и разработки.

Вы начнете с настройки кластера Minikube на своей локальной машине, убедившись, что кластер запущен и готов к использованию. Затем вы проверите конфигурацию и работоспособность кластера с помощью важных команд kubectl, таких как kubectl cluster-info и kubectl get nodes. Наконец, вы изучите основные ресурсы кластера, включая поды и развертывания, чтобы познакомиться с моделью объектов Kubernetes и общим состоянием кластера.

Запустить локальный кластер Kubernetes

На этом этапе вы запустите и проверите локальный кластер Kubernetes с использованием Minikube, который предоставляет простой способ настройки однодневного (одноузлового) кластера Kubernetes для обучения и разработки.

Сначала перейдите в директорию проекта:

cd ~/project

Запустите кластер Minikube:

Примечание: Пользователи бесплатной версии не могут подключаться к интернету, поэтому Minikube уже запущен заранее при запуске практического занятия (лабораторной работы). Вы можете перейти к следующему разделу с кодом, чтобы проверить статус кластера. Перейдите к профессиональной версии, чтобы самостоятельно попрактиковаться в запуске кластера.

minikube start

😄  minikube v1.29.0 on Ubuntu 22.04
✨  Automatically selected the docker driver
📌  Using Docker driver with root permissions
🔥  Creating kubernetes in kubernetes cluster
🔄  Restarting existing kubernetes cluster
🐳  Preparing Kubernetes v1.26.1 on Docker 20.10.23...
🚀  Launching Kubernetes...
🌟  Enabling addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace

Проверьте статус кластера с помощью нескольких команд:

minikube status

Пример вывода:

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Проверьте узлы кластера:

kubectl get nodes

Пример вывода:

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   1m    v1.26.1

Эти команды подтверждают, что:

1. Minikube успешно запущен.
2. Локальный кластер Kubernetes работает.
3. Кластер готов к использованию.
4. У вас есть однодневный (одноузловый) кластер с возможностями управляющего узла (control plane).

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

Обзор архитектуры Kubernetes

Kubernetes работает по клиент-серверной модели, где централизованный управляющий план (Control Plane) управляет состоянием кластера, а набор рабочих узлов (Nodes) выполняет рабочие нагрузки. В общем виде пользователь (чаще всего разработчик) взаимодействует с кластером Kubernetes с помощью инструментов командной строки или API. Управляющий план принимает решения о том, что должно запускаться и где, отслеживает здоровье кластера и обеспечивает достижение желаемого состояния. Рабочие узлы размещают ваши приложения в подах (Pods) — группах из одного или нескольких контейнеров — и предоставляют вычислительные и хранилище ресурсы, необходимые для их запуска.

Управляющий план (Control Plane)

Это «мозг» кластера, состоящий из нескольких компонентов, которые работают вместе для управления всей системой:

• kube-apiserver (API): Является входной точкой кластера. Все административные команды и запросы на ресурсы проходят через него.
• etcd (хранилище ключ-значение): Хранит все конфигурационные данные и текущее состояние кластера. Если вы потеряете данные etcd, вы потеряете состояние кластера.
• kube-scheduler (SCH): Назначает поды узлам на основе требований к ресурсам, ограничений и политик.
• kube-controller-manager (CTLM): Запускает различные контроллеры, которые постоянно корректируют состояние кластера, обеспечивая соответствие фактического состояния желаемому состоянию, определенному вашими развертываниями и конфигурациями.

Узлы (рабочие машины)

На узлах запускаются рабочие нагрузки. Каждый узел имеет:

• kubelet (KLT): Агент на уровне узла, который взаимодействует с управляющим планом. Он обеспечивает запуск подов и сообщает их статус обратно в управляющий план.
• Контейнерный рантайм (CR): Программное обеспечение, которое запускает и управляет контейнерами (например, Docker или containerd). Он создает и управляет контейнеризованными приложениями внутри подов.

Поды (Pods)

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

Сервисы (Services)

Сервис — это абстракция, которая определяет логический набор подов и политику доступа к ним. Сервисы предоставляют стабильные IP-адреса, имена DNS и балансировку нагрузки, обеспечивая, чтобы внешние потребители и другие компоненты кластера могли надежно подключаться к вашим приложениям — даже если поды перемещаются между узлами или заменяются при масштабировании или последовательных обновлениях.

Взаимодействие с кластером

• Разработчики и администраторы взаимодействуют с кластером через kube-apiserver, часто используя kubectl или другие клиенты Kubernetes.
• Когда развертывается новое приложение, компоненты управляющего плана (планировщик, контроллеры) работают над размещением подов на соответствующих узлах.
• Kubelet на каждом узле обеспечивает, чтобы поды были здоровы и работали в соответствии с инструкциями.
• Сервисы маршрутизируют трафик к правильным подам, позволяя клиентам получать доступ к приложениям без необходимости отслеживать изменения местоположения подов.

flowchart TB

    %% User interacting with the cluster
    User((Developer))
    User -->|kubectl CLI| API[kube-apiserver]

    %% Control Plane Components
    subgraph ControlPlane[Control Plane]
        API
        ETCD[etcd - Key Value Store]
        SCH[kube-scheduler]
        CTLM[kube-controller-manager]

        API --> ETCD
        API --> SCH
        API --> CTLM
    end

    %% Worker Node 1
    subgraph Node1[Worker Node]
        KLT1[kubelet]
        CR1[Container Runtime]
        subgraph Pods1[Pods]
            P1[Pod]
            P2[Pod]
        end

        KLT1 --> CR1
        CR1 --> P1
        CR1 --> P2
    end

    %% Worker Node 2
    subgraph Node2[Worker Node]
        KLT2[kubelet]
        CR2[Container Runtime]
        subgraph Pods2[Pods]
            P3[Pod]
            P4[Pod]
        end

        KLT2 --> CR2
        CR2 --> P3
        CR2 --> P4
    end

    %% Connections between Control Plane and Nodes
    API --> KLT1
    API --> KLT2

    %% Service connecting to Pods across different Nodes
    Service[Service]
    Service --> P1
    Service --> P2
    Service --> P3
    Service --> P4

На диаграмме:

• Разработчик взаимодействует с kube-apiserver (API) с помощью инструмента командной строки, такого как kubectl.
• Компоненты управляющего плана (API, etcd, Планировщик, Менеджер контроллеров) управляют состоянием кластера и оркестрируют рабочие нагрузки.
• Каждый рабочий узел запускает kubelet и контейнерный рантайм, размещая несколько подов.
• Сервис маршрутизирует внешний или внутренний трафик к правильным подам, предоставляя стабильную конечную точку, которая абстрагирует сложность жизненного цикла подов и изменений IP-адресов.

Эта концептуальная модель поможет вам понять, что вы видите, когда проверяете состояние кластера, состояние узлов, перечисляете поды и запрашиваете сервисы — концепции, которые вы будете применять при дальнейшем изучении Kubernetes с помощью команд kubectl.

Проверить настройку кластера

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

Сначала проверьте информацию о кластере:

kubectl cluster-info

Пример вывода:

Kubernetes control plane is running at https://192.168.49.2:8443
CoreDNS is running at https://192.168.49.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'

Эта команда предоставляет информацию о управляющем плане (control plane) Kubernetes и основных службах, таких как CoreDNS.

Далее получите подробную информацию о узлах кластера:

kubectl get nodes -o wide

Пример вывода:

NAME       STATUS   ROLES           AGE    VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION
minikube   Ready    control-plane   15m    v1.26.1   192.168.49.2   <none>        Ubuntu 22.04 LTS    5.15.0-72-generic

Проведем более подробный анализ информации о узле:

kubectl describe node minikube

Пример вывода (частичный):

Name:               minikube
Roles:              control-plane
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=minikube
                    kubernetes.io/os=linux
                    minikube.k8s.io/commit=86a3b7e45a9a35cdcf8f4c80a4c6a46d20dda00f
Annotations:        node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  [Current Timestamp]
Capacity:
  cpu:                2
  ephemeral-storage:  17784212Ki
  memory:             1947748Ki
  pods:               110
Allocatable:
  cpu:                2
  ephemeral-storage:  16388876Ki
  memory:             1845348Ki
  pods:               110

Основные выводы из этих команд:

1. Проверьте, что управляющий план кластера работает.
2. Проверьте статус узла (Готов/Не готов).
3. Разберитесь с ресурсами и конфигурацией узла.
4. Подтвердите версию Kubernetes и детали узла.

Проверить базовые ресурсы кластера

На этом этапе вы будете проверять базовые ресурсы Kubernetes, такие как поды (Pods), развертывания (Deployments) и сервисы (Services), во всех пространствах имен (Namespaces). Используя флаг -A (или --all-namespaces), вы увидите, как ресурсы организованы в рамках всего кластера. Это отличная возможность познакомиться и понять концепцию пространств имен в Kubernetes.

Пространства имен: изоляция ресурсов

Пространства имен - это логические разделы в кластере Kubernetes, которые помогают организовать и управлять ресурсами. Они предоставляют способ группировать связанные объекты и применять политики, контроль доступа и квоты ресурсов на более детальном уровне. Разделяя ресурсы на разные пространства имен, вы можете:

• Улучшить организацию: Группировать связанные рабочие нагрузки (например, по проекту, команде или среде, такой как разработка, тестирование и производство).
• Усилить безопасность и контроль доступа: Ограничить, какие пользователи или учетные записи сервисов могут просматривать или изменять ресурсы в определенном пространстве имен.
• Упростить управление ресурсами: Более эффективно применять ограничения ресурсов, сетевые политики и другие конфигурации на уровне кластера.

Когда вы перечисляете ресурсы с флагом -A (или --all-namespaces), вы заметите, что компоненты, относящиеся к системе Kubernetes, находятся в пространстве имен kube-system, которое предназначено для инфраструктуры на уровне кластера. Пользовательские приложения обычно находятся в пространстве имен default или других настраиваемых пространствах имен, которые вы определяете.

Пространства имен и ресурсы

flowchart LR

    %% User interacts with the cluster via kube-apiserver
    User((Developer))
    User -->|kubectl get pods -A| API[kube-apiserver]

    %% Control Plane Subgraph
    subgraph ControlPlane[Control Plane]
        API
        ETCD[etcd]
        SCH[kube-scheduler]
        CTLM[kube-controller-manager]
    end

    API --> ETCD
    API --> SCH
    API --> CTLM

    %% kube-system namespace
    subgraph kube-system[Namespace: kube-system]
        SysDeployment[Deployment: coredns]
        SysPod1[Pod: coredns-xxx]
        SysService[Service: kube-dns]

        SysDeployment --> SysPod1
        SysService --> SysPod1
    end

    %% default namespace (renamed to avoid parse issues)
    subgraph defaultNs[Namespace: default]
        DefDeployment[Deployment: my-app]
        DefPod1[Pod: my-app-pod1]
        DefPod2[Pod: my-app-pod2]
        DefService[Service: my-app-service]

        DefDeployment --> DefPod1
        DefDeployment --> DefPod2
        DefService --> DefPod1
        DefService --> DefPod2
    end

    %% dev namespace
    subgraph dev[Namespace: dev]
        DevDeployment[Deployment: dev-app]
        DevPod[Pod: dev-app-pod]
        DevService[Service: dev-app-service]

        DevDeployment --> DevPod
        DevService --> DevPod
    end

    %% Demonstration of communication
    API --> kube-system
    API --> defaultNs
    API --> dev

На диаграмме:

• Управляющий план (Control Plane) управляет всем кластером, взаимодействуя с узлами и контролируя рабочие нагрузки.
• Пространства имен (такие как kube-system, default и dev) логически разделяют ресурсы в рамках кластера.
  • kube-system содержит компоненты на уровне системы, такие как CoreDNS и kube-dns.
  • default обычно используется для общих рабочих нагрузок, здесь представлено развертыванием my-app.
  • dev может представлять среду разработки, изолированную от рабочих нагрузок в производственной среде.

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

Примеры:

Перечислить все поды во всех пространствах имен:

kubectl get pods -A

Пример вывода:

NAMESPACE     NAME                               READY   STATUS    RESTARTS      AGE
kube-system   coredns-787d4945fb-j8rhx           1/1     Running   0             20m
kube-system   etcd-minikube                      1/1     Running   0             20m
kube-system   kube-apiserver-minikube            1/1     Running   0             20m
kube-system   kube-controller-manager-minikube   1/1     Running   0             20m
kube-system   kube-proxy-xb9rz                   1/1     Running   0             20m
kube-system   kube-scheduler-minikube            1/1     Running   0             20m
kube-system   storage-provisioner                1/1     Running   1 (20m ago)   20m

Здесь вы видите все поды, связанные с системой, запущенные в пространстве имен kube-system. Если бы у вас были другие развертывания или сервисы в разных пространствах имен, они также появились бы в этом списке, каждый четко обозначенный своим пространством имен.

Перечислить все развертывания во всех пространствах имен:

kubectl get deployments -A

Пример вывода:

NAMESPACE     NAME      READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   coredns   1/1     1            1           20m

Развертывание coredns находится в пространстве имен kube-system.

Получить полное представление о всех ресурсах во всех пространствах имен:

kubectl get all -A

Эта команда отображает обзор подов, сервисов и развертываний в разных пространствах имен, помогая вам понять, как эти ресурсы распределены по всему кластеру.

Основные выводы:

• Пространства имен обеспечивают логическую изоляцию и организацию в рамках кластера Kubernetes.
• Различные компоненты и ресурсы Kubernetes организованы в определенные пространства имен (например, kube-system для основных служб, default для общих рабочих нагрузок и дополнительные пространства имен, которые вы создаете).
• Используя -A для просмотра ресурсов во всех пространствах имен, вы получаете представление о структуре вашего кластера и о том, как пространства имен служат границами для организации ресурсов и контроля доступа.

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

Резюме

В рамках этого практического занятия (лабораторной работы) вы запустили и проверили локальный кластер Kubernetes с использованием Minikube, который предоставляет простой способ настройки однодневного (одноузлового) кластера Kubernetes для обучения и разработки. Вы подтвердили, что кластер Minikube успешно запущен, локальный кластер Kubernetes работает, кластер готов к использованию и у вас есть однодневный (одноузловый) кластер с возможностями управляющего узла (control plane). Вы также научились проверять конфигурацию и работоспособность кластера Kubernetes с помощью важных команд kubectl, таких как kubectl cluster-info и kubectl get nodes, которые помогли вам понять текущее состояние и связность кластера.