Архитектура кластера Kubernetes

KubernetesBeginner
Практиковаться сейчас

Введение

В этом лабораторном занятии мы рассмотрим архитектуру Kubernetes, мощной платформы оркестрации контейнеров. Мы изучим ключевые компоненты, составляющие кластер Kubernetes, и узнаем, как они взаимодействуют для управления контейнеризованными приложениями. Это лабораторное занятие предназначено для начинающих и дает практическое введение в архитектуру Kubernetes.

Исследуйте компоненты управляющей плоскости

Начнем с запуска кластера Kubernetes с использованием Minikube и изучения компонентов управляющей плоскости.

Сначала откройте терминал. По умолчанию вы должны находиться в директории /home/labex/project. Если это не так, перейдите в нее:

cd ~/project

Теперь запустите Minikube с помощью следующей команды:

minikube start

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

После того, как Minikube запустится, давайте изучим компоненты управляющей плоскости. Управляющая плоскость является "мозгом" Kubernetes и отвечает за управление общим состоянием кластера. Чтобы проверить статус этих компонентов, выполните следующую команду:

kubectl get componentstatuses

Вы должны увидеть вывод, похожий на следующий:

NAME                 STATUS    MESSAGE             ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   {"health":"true"}

Разберем, что делает каждый из этих компонентов:

  1. Scheduler (планировщик): Этот компонент отслеживает новые созданные Pods (контейнерные группы), которые не назначены ни на один узел, и выбирает узел для их запуска.
  2. Controller manager (менеджер контроллеров): Он запускает процессы контроллеров, которые регулируют состояние системы. Например, контроллер репликации обеспечивает запуск правильного количества реплик Pods.
  3. etcd: Это распределенное хранилище ключ-значение, которое служит основным хранилищем для всех данных кластера Kubernetes.

Если все компоненты показывают "Healthy" (Здорово), ваша управляющая плоскость работает корректно. Если вы увидите какие-либо ошибки, может быть, стоит перезапустить Minikube с помощью команды minikube delete, а затем minikube start.

Изучение компонентов узла

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

Чтобы увидеть узлы в вашем кластере, выполните следующую команду:

kubectl get nodes

Вы должны увидеть вывод, похожий на следующий:

NAME       STATUS   ROLES    AGE   VERSION
minikube   Ready    control plane   10m   v1.20.0

Этот вывод показывает, что у нас есть один узел с именем "minikube", который является одновременно мастер-узлом (управляющей плоскостью) и рабочим узлом, так как мы используем однодневный кластер. В производственной среде обычно имеется несколько узлов, разделенных на мастер-узлы и рабочие узлы.

Статус "Ready" означает, что узел работает исправно и готов принимать Pods (контейнерные группы).

Чтобы получить более подробную информацию о узле, используйте следующую команду:

kubectl describe node minikube

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

  1. Node Conditions (Состояния узла): Они показывают статус различных состояний узла (например, Ready - готовность, DiskPressure - давление на диск, MemoryPressure - давление на память).
  2. Capacity (Вместимость): Это показывает общие ресурсы, доступные на узле (CPU и память).
  3. Allocatable (Доступные для распределения): Это показывает ресурсы, доступные для использования Pods.
  4. System Info (Информация о системе): Здесь предоставляется информация об операционной системе узла, версии ядра и среде выполнения контейнеров.

Ключевые компоненты узла, которые вы не увидите напрямую, но которые работают на узле, включают:

  1. kubelet: Это основной агент узла. Он отслеживает Pods, которые были назначены его узлу, и обеспечивает их запуск.
  2. kube-proxy: Он поддерживает сетевые правила на узле, позволяя сетевую коммуникацию с вашими Pods изнутри или снаружи кластера.

Создание и изучение Pod

Прежде чем приступить, давайте разберемся, как работает YAML в Kubernetes:

graph TB
    A[YAML Config File] -->|Declares Desired State| B[Kubernetes API]
    B -->|Creates/Manages| C[Running Containers]
    D[kubectl CLI] -->|Reads| A

YAML-файлы в Kubernetes выступают в роли "Инфраструктуры как кода":

  • Представьте их как "меню", которое сообщает Kubernetes, что вы хотите.
  • Описывают желаемое состояние системы в человекочитаемом формате.
  • Можно управлять версиями для совместной работы в команде.

Давайте создадим наш первый YAML-файл. Создайте simple-pod.yaml:

nano ~/project/simple-pod.yaml

Добавьте следующее содержимое:

## --- Beginning of YAML file ---
## 1. Tell Kubernetes which API version to use
apiVersion: v1
## 2. Declare what kind of resource we want to create
kind: Pod
## 3. Set metadata for this resource
metadata:
  name: nginx-pod ## Name of the Pod
  labels: ## Labels help us find and organize Pods
    app: nginx
## 4. Define what the Pod should contain
spec:
  containers: ## Pod can run one or more containers
    - name: nginx ## Name of the container
      image: nginx:latest ## Which container image to use
      ports: ## Which ports to expose
        - containerPort: 80 ## Nginx uses port 80 by default

Структура YAML-файла похожа на дерево:

Pod (root)
├── metadata (branch)
│   ├── name (leaf)
│   └── labels (leaf)
└── spec (branch)
    └── containers (branch)
        └── - name, image, ports (leaves)

Создайте Pod:

kubectl apply -f simple-pod.yaml ## -f means read from file

Эта команда выполнит следующие действия:

  1. Прочитает ваш YAML-файл.
  2. Отправит его в Kubernetes API.
  3. Kubernetes будет работать над достижением описанного вами состояния.

Проверьте создание Pod:

kubectl get pods

Вы должны увидеть:

NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          30s

"1/1" в столбце READY означает, что один контейнер из одного в Pod готов к работе. "Running" в столбце STATUS означает, что ваша первая YAML-конфигурация сработала!

💡 Советы профессионалов:

  • Отступы в YAML имеют решающее значение - используйте пробелы, а не табуляцию.
  • Используйте kubectl explain pod, чтобы посмотреть документацию по полям.
  • Всегда добавляйте комментарии для лучшей поддерживаемости.

Чтобы получить подробную информацию о Pod:

kubectl describe pod nginx-pod

Эта команда предоставляет много информации, в том числе:

  • Узел, на котором запущен Pod.
  • IP-адрес Pod.
  • Контейнеры в Pod.
  • Недавние события, связанные с Pod.

Эта информация имеет решающее значение для отладки и понимания состояния вашего приложения.

Создание сервиса

Теперь, когда у нас есть запущенный Pod, давайте создадим сервис (Service), чтобы сделать его доступным. В Kubernetes сервис представляет собой абстракцию, которая определяет логический набор Pod и политику доступа к ним. Представьте его как способ предоставить доступ к вашему приложению в сети, как внутри кластера, так и извне.

Создайте файл с именем nginx-service.yaml в вашей проектной директории:

nano ~/project/nginx-service.yaml

Добавьте в файл следующее содержимое:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: NodePort

Разберем этот YAML-файл:

  • selector (селектор): Определяет, к каким Pod сервис будет направлять трафик. В данном случае он выберет все Pod с меткой app: nginx.
  • ports (порты): Указывает, какие порты должен использовать сервис.
  • type: NodePort (тип: NodePort): Это означает, что сервис будет доступен по порту на каждом узле вашего кластера.

Сохраните файл и выйдите из редактора.

Теперь создайте сервис, выполнив следующую команду:

kubectl apply -f nginx-service.yaml

Чтобы проверить статус вашего сервиса, используйте:

kubectl get services

Вы должны увидеть вывод, похожий на следующий:

NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP        1h
nginx-service   NodePort    10.110.126.65   <none>        80:30080/TCP   30s

Строка nginx-service показывает, что ваш сервис был создан. 80:30080/TCP в столбце PORT(S) означает, что порт 80 внутри кластера отображается на порт 30080 на узле.

Чтобы получить более подробную информацию о сервисе, используйте:

kubectl describe service nginx-service

Эта команда предоставляет информацию о типе сервиса, IP-адресах, портах и конечных точках (endpoints). Конечные точки - это IP-адреса Pod, к которым сервис направляет трафик.

Доступ к приложению

Теперь, когда у нас есть Pod, запускающий наше приложение, и сервис (Service), предоставляющий доступ к нему, давайте получим доступ к приложению. Этот шаг покажет, как все компоненты, которые мы настроили, работают вместе, чтобы сделать ваше приложение доступным.

Сначала нам нужно узнать URL, который Minikube назначил нашему сервису:

minikube service nginx-service --url

Эта команда выведет URL, который должен выглядеть примерно так: http://192.168.64.2:30080. IP-адрес может отличаться на вашем компьютере.

Для доступа к приложению вы можете использовать команду curl, за которой следует URL:

curl $(minikube service nginx-service --url)

Это должно вернуть HTML-код стандартной приветственной страницы Nginx. Если вы видите HTML-вывод, начинающийся с <!DOCTYPE html>, поздравляем! Вы успешно получили доступ к вашему приложению.

Разберем, что произошло:

  1. Ваш запрос сначала попал в сервис NodePort, который мы создали.
  2. Затем сервис перенаправил запрос в Pod, запускающий контейнер Nginx.
  3. Контейнер Nginx обработал запрос и отправил обратно стандартную приветственную страницу.

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

Резюме

В этом практическом занятии мы изучили архитектуру Kubernetes, рассмотрев его ключевые компоненты и их взаимодействие. Мы запустили кластер Kubernetes с помощью Minikube, изучили компоненты управляющей плоскости и узла, создали Pod для запуска приложения, предоставили доступ к приложению с помощью сервиса (Service) и, наконец, получили доступ к приложению.

graph TB
    subgraph Control Plane
        API[API Server]
        CM[Controller Manager]
        SCH[Scheduler]
        ETCD[etcd]
        API --> ETCD
        API --> CM
        API --> SCH
    end

    subgraph Worker Node
        KL[kubelet]
        KP[kube-proxy]
        CR[Container Runtime]

        subgraph Workloads
            POD1[Pod]
            POD2[Pod]
        end

        SVC[Service]

        KL --> CR
        POD1 --> CR
        POD2 --> CR
        KP --> SVC
        SVC --> POD1
        SVC --> POD2
    end

    API --> KL
    Client[External Client] --> SVC

Мы узнали о:

  • Компонентах управляющей плоскости, таких как API-сервер, планировщик (scheduler) и менеджер контроллеров (controller manager).
  • Компонентах узла, таких как kubelet и kube-proxy.
  • Pod как наименьших развертываемых единицах в Kubernetes.
  • Сервисах (Services) как способе предоставления доступа к приложениям.

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

Следующими шагами в вашем изучении Kubernetes могут стать изучение развертываний (Deployments) для управления несколькими репликами вашего приложения, ConfigMaps и Secrets для управления конфигурацией, а также Persistent Volumes для хранения данных. Продолжайте изучать и удачи в работе с Kubernetes!