Введение
В этом лабораторном занятии мы рассмотрим архитектуру 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"}
Разберем, что делает каждый из этих компонентов:
- Scheduler (планировщик): Этот компонент отслеживает новые созданные Pods (контейнерные группы), которые не назначены ни на один узел, и выбирает узел для их запуска.
- Controller manager (менеджер контроллеров): Он запускает процессы контроллеров, которые регулируют состояние системы. Например, контроллер репликации обеспечивает запуск правильного количества реплик Pods.
- 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
Эта команда предоставляет обширную информацию о узле. Не беспокойтесь, если это кажется перегруженным - давайте разберем некоторые ключевые разделы:
- Node Conditions (Состояния узла): Они показывают статус различных состояний узла (например, Ready - готовность, DiskPressure - давление на диск, MemoryPressure - давление на память).
- Capacity (Вместимость): Это показывает общие ресурсы, доступные на узле (CPU и память).
- Allocatable (Доступные для распределения): Это показывает ресурсы, доступные для использования Pods.
- System Info (Информация о системе): Здесь предоставляется информация об операционной системе узла, версии ядра и среде выполнения контейнеров.
Ключевые компоненты узла, которые вы не увидите напрямую, но которые работают на узле, включают:
- kubelet: Это основной агент узла. Он отслеживает Pods, которые были назначены его узлу, и обеспечивает их запуск.
- 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
Эта команда выполнит следующие действия:
- Прочитает ваш YAML-файл.
- Отправит его в Kubernetes API.
- 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>, поздравляем! Вы успешно получили доступ к вашему приложению.
Разберем, что произошло:
- Ваш запрос сначала попал в сервис NodePort, который мы создали.
- Затем сервис перенаправил запрос в Pod, запускающий контейнер Nginx.
- Контейнер 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!


