Введение
Современные приложения часто упаковывают в контейнеры. Контейнер объединяет приложение с необходимыми ему библиотеками и настройками, благодаря чему приложение проще запускать одинаковым образом в разных средах. Запустить один контейнер несложно. А вот надёжно управлять множеством контейнеров гораздо труднее: нужно определить, где их запускать, перезапускать отказавшие контейнеры, обеспечивать взаимодействие приложений и безопасно разворачивать изменения.
Kubernetes — это система оркестрации контейнеров, которая берёт на себя такие задачи на уровне кластера. Вы описываете желаемое состояние — например, «запустить три экземпляра этого веб-приложения», — а Kubernetes постоянно приводит фактическое состояние в соответствие с желаемым.
Кластер Kubernetes состоит из одной или нескольких машин, называемых узлами. Плоскость управления управляет кластером, а узлы предоставляют приложениям процессорные ресурсы, память, сеть и среду выполнения контейнеров. Приложения запускаются в объектах Kubernetes, таких как Pod, Deployment и Service.
В этой первой лабораторной работе вы пока не будете разворачивать приложение. Сначала вы научитесь ориентироваться в работающем кластере:
- Определите доступные инструменты, активный кластер, версию Kubernetes и состояние узлов.
- Найдите компоненты плоскости управления и узлов, обеспечивающие работу Kubernetes.
- Изучите конечные точки кластера и подробную информацию об узлах.
- Исследуйте Pod, Deployment и Service в разных пространствах имён.
Среда уже подготовлена, поэтому вы сможете сосредоточиться на концепциях Kubernetes, а не на установке. Используется Minikube v1.38.1 с профилем labex-v135, в котором запущен Kubernetes v1.35.5. Minikube запускает полноценный кластер Kubernetes внутри контейнера Docker на виртуальной машине LabEx. Это одновузловая учебная среда, однако отрабатываемые команды и концепции Kubernetes применимы и к более крупным кластерам.
Всю работу вы будете выполнять в терминале. Перед запуском каждой команды читайте объяснение, а затем сопоставляйте фактический вывод с описанными признаками. Точный возраст объектов, количество перезапусков и автоматически сгенерированные имена могут отличаться — для работающей системы это нормально.
Проверка предварительно настроенного кластера
Запуск среды: В этой лабораторной работе для вас запускается полноценный кластер Kubernetes. Настройка плоскости управления, узла и сетевых компонентов обычно занимает 2–3 минуты. Дождитесь полной загрузки среды, прежде чем начинать работу.
На этом шаге вы узнаете, как терминальные инструменты подключаются к Kubernetes, проверите версии установленного программного обеспечения и убедитесь, что кластер готов к работе. Перед изменением кластера администратор всегда должен знать, какой кластер активен и исправен ли он.
Знакомство с инструментами
Вы будете использовать два связанных инструмента командной строки:
minikubeсоздаёт и управляет локальными кластерами Kubernetes. Именованная среда Minikube называется профилем. В этой лабораторной работе используется профильlabex-v135.kubectl— стандартный клиент Kubernetes для командной строки. Он отправляет запросы на API-сервер Kubernetes для просмотра, создания, изменения и удаления объектов.
Кластер уже запущен. Не выполняйте minikube start: это не требуется и может привести к ожиданию, пока Minikube повторно проверяет уже существующую среду.
Переход в рабочий каталог
Перейдите в каталог проекта, где в следующих лабораторных работах будут храниться манифесты и другие созданные вами файлы:
cd /home/labex/project
Команда cd изменяет текущий каталог оболочки. При успешном выполнении она обычно ничего не выводит.
Проверка версии Minikube
Выведите установленную версию Minikube. Параметр, начинающийся с --, изменяет поведение команды. В данном случае --short запрашивает только номер версии.
minikube version --short
v1.38.1
Это версия инструмента управления кластером, а не версия Kubernetes. Minikube и Kubernetes — отдельные проекты, поэтому у них разные номера версий.
Проверка версий клиента и сервера
Запросите информацию о версии с помощью kubectl. Команда обращается к кластеру, поэтому проверяет как локальный клиент, так и удалённый API-сервер:
kubectl version
Client Version: v1.35.5
Kustomize Version: ...
Server Version: v1.35.5
Client Version — версия установленного kubectl, а Server Version сообщается API-сервером Kubernetes. Наличие строки с версией сервера подтверждает, что kubectl успешно подключился к кластеру. Kustomize — встроенная возможность настройки манифестов, которая в этой лабораторной работе не понадобится.
Проверка активного контекста
На одном компьютере можно хранить данные доступа к нескольким кластерам в файле kubeconfig. Контекст kubeconfig выбирает кластер, учётные данные пользователя и пространство имён по умолчанию. Проверка контекста помогает избежать случайной работы не в том кластере.
kubectl config current-context
labex-v135
Это соответствует подготовленному профилю Kubernetes v1.35.
Просмотр и выбор контекстов
В реальных файлах kubeconfig часто содержится несколько контекстов. Просмотрите их перед переключением, чтобы не угадывать имя:
kubectl config get-contexts
В столбце NAME указаны имена контекстов, а столбец CURRENT отмечает активный контекст символом *. В остальных столбцах отображаются кластер, данные аутентификации и пространство имён по умолчанию, связанные с каждым контекстом.
Используйте use-context, когда нужно выбрать один из этих контекстов. Повторный выбор labex-v135 безопасен, даже если он уже активен, и позволяет отработать стандартный процесс переключения:
kubectl config use-context labex-v135
Switched to context "labex-v135".
current-context отвечает на вопрос «какой контекст выбран?», get-contexts — «какие варианты доступны?», а use-context NAME изменяет выбор. Эти команды меняют только локальный выбор клиента; они не запускают, не останавливают и не изменяют кластер.
Проверка профиля Minikube
Запросите состояние этого профиля Minikube. Короткий параметр -p означает profile и сопровождается его именем.
minikube status -p labex-v135
labex-v135
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
host означает, что контейнер узла Minikube запущен. kubelet — агент узла. apiserver — конечная точка API Kubernetes. kubeconfig: Configured означает, что локальная конфигурация клиента указывает на этот кластер. Все компоненты должны быть в исправном состоянии.
Просмотр узлов
Большинство команд kubectl имеют форму kubectl <verb> <resource>. Здесь get получает объекты, а nodes обозначает тип ресурса:
kubectl get nodes
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35.5
NAME идентифицирует узел. STATUS=Ready означает, что узел может запускать рабочие нагрузки. ROLES показывает, что на нём размещена плоскость управления. AGE может быть больше продолжительности текущего сеанса, поскольку образ восстанавливается из подготовленного снимка. VERSION — версия kubelet.
В этой лабораторной работе один узел выполняет обязанности как плоскости управления, так и узла рабочих нагрузок. В производственных кластерах эти функции обычно распределены между несколькими машинами.
Контрольная точка шага
Вы убедились, что kubectl подключается к нужному кластеру labex-v135, а его узел имеет состояние Ready и использует Kubernetes v1.35.5. Это полезная процедура первичной проверки при подключении к незнакомому кластеру.
Определение компонентов архитектуры Kubernetes
На этом шаге вы свяжете архитектурную модель Kubernetes с реальными компонентами. Такие названия, как API-сервер, планировщик и kubelet, легче запомнить, когда видишь работающие Pod этих компонентов.
Как запрос проходит через Kubernetes
Представьте, что вы просите Kubernetes запустить веб-приложение. Сначала kubectl отправляет запрос в kube-apiserver, который проверяет его и сохраняет желаемое состояние в etcd.
Затем kube-scheduler выбирает узел для каждого нового Pod. kube-controller-manager наблюдает за кластером и старается привести фактическое состояние в соответствие с желаемым.
Наконец, kubelet на выбранном узле просит среду выполнения контейнеров запустить контейнеры Pod. Компоненты сетевой подсистемы обеспечивают взаимодействие Pod и Service.
Постоянное сопоставление желаемого и фактического состояния называется согласованием. Если Deployment запрашивает три Pod, но существует только два, контроллер создаёт недостающий Pod.
Pod и системные пространства имён
Pod — это наименьшая развёртываемая единица Kubernetes. Он объединяет один или несколько тесно связанных контейнеров и предоставляет им общий сетевой и дисковый контекст.
Пространство имён задаёт логическую область для объектов, использующих пространства имён. В kube-system находятся компоненты инфраструктуры кластера. Параметр -n kube-system сообщает kubectl, что нужно искать объекты там, а не в пространстве имён по умолчанию. Полная эквивалентная форма — --namespace=kube-system; обе формы выбирают одну и ту же область.
Minikube запускает компоненты плоскости управления как статические Pod. Kubelet создаёт их непосредственно на основе файлов узла, благодаря чему плоскость управления может запуститься ещё до того, как станет доступно обычное планирование.
Просмотр плоскости управления
Объекты могут содержать метки — метаданные в формате «ключ-значение», используемые для группировки и выбора. Используйте -l tier=control-plane, чтобы выбрать Pod с такой меткой:
kubectl get pods -n kube-system -l tier=control-plane
NAME READY STATUS RESTARTS AGE
etcd-labex-v135 1/1 Running ... ...
kube-apiserver-labex-v135 1/1 Running ... ...
kube-controller-manager-labex-v135 1/1 Running ... ...
kube-scheduler-labex-v135 1/1 Running ... ...
API-сервер — главный вход в Kubernetes. etcd хранит состояние кластера. Планировщик выбирает место размещения Pod. Менеджер контроллеров запускает контроллеры согласования.
READY=1/1 означает, что единственный контейнер Pod готов. Долго работающие компоненты должны иметь состояние Running. Значение RESTARTS может быть ненулевым после возобновления работы сохранённого кластера. AGE показывает возраст объекта, а не время, проведённое в этой лабораторной работе.
Просмотр меток
Выведите метки в отдельном последнем столбце:
kubectl get pods -n kube-system -l tier=control-plane --show-labels
Найдите component=kube-apiserver и tier=control-plane. Первая метка обозначает конкретный компонент, а вторая объединяет все Pod плоскости управления. Метки идентифицируют объекты, а селекторы находят подходящие объекты.
Просмотр сетевых компонентов узла
Используйте селектор на основе множеств: он означает, что значение k8s-app должно быть kube-proxy или calico-node. Кавычки не дают оболочке интерпретировать круглые скобки.
kubectl get pods -n kube-system -l 'k8s-app in (kube-proxy,calico-node)'
NAME READY STATUS RESTARTS AGE
calico-node-... 1/1 Running ... ...
kube-proxy-... 1/1 Running ... ...
Calico настраивает сеть Pod. kube-proxy поддерживает правила на узле, благодаря которым Service могут направлять трафик к Pod. Kubelet отсутствует в этом списке, поскольку он является агентом хоста, отвечающим за работу Pod, и запускается как системная служба хоста, а не как обычный Pod, управляемый им самим.
Контрольная точка шага
API-сервер принимает запросы, etcd хранит состояние, планировщик выбирает размещение, контроллеры согласуют состояние, kubelet управляет узлом, а Calico и kube-proxy обеспечивают сетевое взаимодействие.
Изучение сведений о кластере и узлах
На этом шаге вы перейдёте от простой проверки состояния к подробному исследованию. Kubernetes предоставляет как компактные списки, так и детальные описания; умение выбирать подходящий вариант — важная привычка при устранении неполадок.
Поиск конечных точек кластера
kubectl cluster-info — специальная команда для первичной ориентации. В отличие от kubectl get, она не выводит объекты одного типа, а запрашивает у активного кластера адреса важных служб, таких как API-сервер и CoreDNS.
kubectl cluster-info
Kubernetes control plane is running at https://...
CoreDNS is running at https://...
URL плоскости управления — это конечная точка API-сервера. CoreDNS предоставляет службу обнаружения через DNS, позволяя рабочим нагрузкам находить Service по имени, а не отслеживать меняющиеся IP-адреса. Адреса могут отличаться, поэтому сосредоточьтесь на фразе is running: она показывает, что API-сервер вернул информацию. Однако это не доказывает исправность каждой рабочей нагрузки.
Расширенный список узлов
Добавьте -o wide, чтобы запросить дополнительные столбцы:
kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP ... OS-IMAGE
labex-v135 Ready control-plane ... v1.35.5 192.168.49.2 ... Debian GNU/Linux 12 (bookworm)
INTERNAL-IP — адрес узла в сети кластера. EXTERNAL-IP=<none> означает, что узлу не назначен общедоступный адрес под управлением Kubernetes. OS-IMAGE, KERNEL-VERSION и CONTAINER-RUNTIME описывают программное обеспечение узла.
Бэкенд LabEx использует Ubuntu 22.04, а Minikube представляет узел Kubernetes в контейнере Docker на базе Debian. Поэтому появление Debian в этом выводе ожидаемо.
Подробное описание узла
Используйте describe, когда строки списка недостаточно. Формат команды: kubectl describe <resource-type> <name>; здесь тип ресурса — node, а имя объекта — labex-v135:
kubectl describe node labex-v135
В верхней части вывода проверьте идентификатор и параметры планирования:
Name: labex-v135
Roles: control-plane
Taints: <none>
Unschedulable: false
Taints могут отталкивать Pod, которые не допускают соответствующие ограничения. <none> означает, что на этом учебном узле таких ограничений нет. Unschedulable: false означает, что Kubernetes может размещать на нём рабочие нагрузки.
Найдите таблицу Conditions:
Type Status ... Reason
NetworkUnavailable False ... CalicoIsUp
MemoryPressure False ... KubeletHasSufficientMemory
DiskPressure False ... KubeletHasNoDiskPressure
PIDPressure False ... KubeletHasSufficientPID
Ready True ... KubeletReady
Для условий, связанных с давлением ресурсов и недоступностью сети, значение False является признаком исправности: проблема отсутствует. Для Ready исправное состояние обозначается значением True. Всегда рассматривайте имя условия вместе с его значением.
Capacity показывает общий объём ресурсов, заявленный узлом. Allocatable — ресурсы, которые Kubernetes может предоставить Pod после вычета системных резервов. В разделе System Info указаны сведения о среде выполнения и kubelet. В следующих разделах перечислены Pod, выделенные запросы и ограничения ресурсов, а также события. Точные значения и временные метки могут отличаться.
Контрольная точка шага
Используйте get для быстрой таблицы, get -o wide — для дополнительных столбцов, а describe — для просмотра условий, доступной ёмкости, сведений о среде выполнения и событий конкретного объекта.
Исследование ресурсов в разных пространствах имён
На этом шаге вы составите начальную карту распространённых объектов Kubernetes: пространства имён организуют ресурсы, Pod запускают контейнеры, Deployment управляют Pod, а Service предоставляют стабильный сетевой доступ.
Взаимосвязи объектов
- Pod — наименьшая развёртываемая единица, содержащая один или несколько контейнеров.
- Deployment описывает, сколько экземпляров stateless-приложения должно работать, и управляет Pod через ReplicaSet.
- Service предоставляет выбранным Pod стабильный виртуальный IP-адрес и DNS-имя, поскольку IP-адреса заменяемых Pod могут меняться.
- Пространство имён объединяет объекты, использующие пространства имён, и позволяет использовать одинаковые имена в разных областях.
Упрощённая схема такова: Deployment управляет Pod, а Service выбирает эти Pod и предоставляет клиентам стабильную конечную точку. Не все объекты относятся к пространствам имён; например, Nodes принадлежат всему кластеру.
Просмотр Pod во всех пространствах имён
Без параметра пространства имён команда kubectl get pods ищет Pod только в текущем пространстве имён. -A означает --all-namespaces:
kubectl get pods -A
NAMESPACE — логическая область. NAME идентифицирует Pod внутри неё. READY показывает количество готовых контейнеров относительно их общего числа. STATUS — текущая фаза жизненного цикла. RESTARTS содержит число перезапусков, а AGE — возраст объекта.
Долго работающая инфраструктура должна иметь состояние Running. Некоторые Pod, связанные с проверкой входящего трафика, могут иметь состояние Completed и готовность 0/1, поскольку они выполняют одноразовые Job и успешно завершаются. Состояние нужно интерпретировать с учётом назначения рабочей нагрузки.
Просмотр Deployment
Использование имени ресурса во множественном числе deployments запрашивает объекты Deployment. Сохраните -A, поскольку системные Deployment находятся за пределами текущего пространства имён default:
kubectl get deployments -A
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
ingress-nginx ingress-nginx-controller 1/1 1 1 ...
kube-system calico-kube-controllers 1/1 1 1 ...
kube-system coredns 1/1 1 1 ...
kube-system metrics-server 1/1 1 1 ...
READY — количество готовых реплик относительно требуемого числа. UP-TO-DATE показывает число реплик, использующих текущий шаблон Pod. AVAILABLE — количество реплик, доступных для выполнения своей задачи. Увиденный ранее Pod coredns-... поддерживается Deployment coredns.
Просмотр Service
Pod могут заменяться, поэтому клиентам не следует зависеть от IP-адреса конкретного Pod. Просмотрите стабильные конечные точки Service:
kubectl get services -A
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default kubernetes ClusterIP 10.96.0.1 <none> 443/TCP ...
kube-system kube-dns ClusterIP 10.96.0.10 <none> ... ...
ingress-nginx ingress-nginx-controller NodePort ... <none> ... ...
TYPE описывает способ публикации Service. ClusterIP доступен внутри кластера, а NodePort дополнительно открывает порт на узле. CLUSTER-IP — стабильный виртуальный адрес. EXTERNAL-IP=<none> означает, что внешний адрес не назначен. PORT(S) перечисляет доступные протоколы и порты.
Service kubernetes предоставляет доступ к API внутри кластера. kube-dns обеспечивает стабильный доступ к CoreDNS. Service Ingress поддерживают входящий трафик HTTP и HTTPS.
Сводное представление
Если вы ещё не знаете, какие распространённые типы рабочих нагрузок существуют, команда kubectl get all предоставляет объединённое представление для первичной ориентации. Добавление -A сохраняет область поиска во всех пространствах имён:
kubectl get all -A
Команда группирует распространённые ресурсы, включая Pod, Service, DaemonSet, Deployment, ReplicaSet и Job. Один компонент может отображаться на нескольких уровнях: Deployment, ReplicaSet и Pod.
Несмотря на название, get all не возвращает вообще все ресурсы. ConfigMap, Secret, NetworkPolicy и многие другие объекты в вывод не входят. Используйте эту команду для ориентации, а затем запрашивайте нужный тип ресурса отдельно.
Контрольная точка шага
Пространства имён задают область видимости, Pod запускают контейнеры, Deployment поддерживают нужное количество реплик Pod, а Service предоставляют стабильный сетевой доступ к изменяющимся Pod.
Итоги
Вы завершили первое пошаговое исследование кластера Kubernetes. Вы узнали, что Kubernetes управляет желаемым состоянием на узлах, а kubectl взаимодействует с API-сервером, используя активный контекст kubeconfig.
Вы научились различать версии Minikube, Kubernetes и kubectl; проверять контекст и готовность узлов; определять компоненты плоскости управления, узлов и сетевой подсистемы; использовать метки и селекторы; выбирать между get, get -o wide и describe; интерпретировать условия и ёмкость узла; а также связывать пространства имён, Pod, Deployment и Service.
Главная привычка начинающего администратора — сначала исследовать, а уже потом что-либо изменять: проверить контекст, оценить состояние узла, определить нужное пространство имён и тип ресурса, внимательно изучить сообщаемое состояние. В следующих лабораторных работах эта модель станет основой для создания собственных рабочих нагрузок.
