3. Kubernetes API Server

API-сервер в структуре Kubernetes

API-сервер — это центральный компонент Kubernetes, выполняющий ключевую роль в управлении кластером. Он служит основным интерфейсом взаимодействия для всех компонентов системы и пользователей. Этот сервер принимает входящие запросы (например, на создание, изменение или удаление ресурсов), валидирует их, записывает данные в распределённое хранилище etcd и координирует взаимодействие между другими частями системы.

Основные функции API-сервера:

1. Обработка запросов: API-сервер принимает REST-запросы от пользователей, а также от внутренних компонентов кластера, таких как контроллеры или kubelet.
2. Хранение данных: Все объекты Kubernetes, включая конфигурации, статусы подов, деплойменты и сетевые политики, сохраняются в etcd через API-сервер.
3. Координация: API-сервер отвечает за синхронизацию состояния между желаемым и фактическим состоянием кластера, передавая задачи контроллерам и другим компонентам.

Версионная модель API

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

API-сервер предоставляет два типа API для работы с объектами Kubernetes:

1. Cluster-scoped (глобальные ресурсы):
   • Эти объекты существуют на уровне всего кластера, не привязываясь к конкретному пространству имён (namespace).
   • Примеры: nodes, persistentvolumes (PVs).
   • Запросы:
     • GET /apis/GROUP/VERSION/RESOURCETYPE — возвращает коллекцию объектов.
     • GET /apis/GROUP/VERSION/RESOURCETYPE/NAME — возвращает конкретный объект.
2. Namespaced (локальные ресурсы):
   • Эти объекты изолированы в рамках пространства имён (namespace), что позволяет создавать одинаковые имена ресурсов в разных namespace.
   • Примеры: pods, services, deployments.
   • Запросы:
     • GET /apis/GROUP/VERSION/RESOURCETYPE — возвращает ресурсы из всех namespaces.
     • GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE — ресурсы только из указанного namespace.
     • GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME — конкретный ресурс по имени в указанном namespace.

Декларативный подход

Для взаимодействия с API пользователи, как правило, используют декларативные манифесты — YAML- или JSON-документы, которые описывают желаемое состояние системы. Эти манифесты отправляются на исполнение в API-сервер, который принимает их, валидирует и передаёт другим компонентам для приведения кластера в соответствие с указанным состоянием.

Пример команды для отправки манифеста:

kubectl apply -f deployment.yaml

Общение с API Kubernetes

Существует несколько способов взаимодействия с API Kubernetes:

1. CLI-инструмент kubectl:
   • Наиболее популярный способ управления кластером. Команды автоматически обращаются к API-серверу.
   • Пример: kubectl get pods отправляет запрос GET /api/v1/namespaces/default/pods.
2. Прямые REST-запросы:
   • Использование инструментов вроде curl или библиотек для HTTP-запросов.
   • Пример:

curl -X GET \
-H "Authorization: Bearer <TOKEN>" \
-k https://<API_SERVER>:6443/api/v1/pods

3. Клиентские библиотеки:

• Kubernetes предоставляет SDK для популярных языков программирования: Python, Go, Java, и др.
• Это упрощает разработку приложений, взаимодействующих с API.

4. Пользовательские контроллеры:

• Разработка контроллеров, которые следят за событиями API и выполняют действия, например, создают или удаляют ресурсы.

Утилита kubectl: установка и использование

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

Установка kubectl

Установить kubectl можно несколькими способами. Вот два популярных подхода: загрузка бинарного файла и установка через системный пакетный менеджер.

Установка через загрузку бинарного файла:

curl -LO "https://dl.k8s.io/release/v1.28.1/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

Установка через менеджер пакетов (например, для Ubuntu):

sudo apt-get update && sudo apt-get install -y apt-transport-https
echo "deb [signed-by=/etc/apt/trusted.gpg.d/kubernetes-apt.gpg] https://packages.cloud.google.com/apt/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/kubernetes-apt.gpg
sudo apt-get update
sudo apt-get install -y kubectl

После установки убедитесь, что утилита работает корректно:

kubectl version --client

Базовые команды kubectl

kubectl предоставляет набор команд для управления ресурсами Kubernetes.

Вот основные из них:

Работа с ресурсами и их метками

Многие команды kubectl позволяют работать с метками (labels) для упрощения управления объектами.

Пример: просмотр меток на нодах с помощью флага --show-labels:

kubectl get nodes --show-labels

Для фильтрации объектов по меткам используется флаг -l:

kubectl get pods -l app=my-app

Создание ресурса с манифеста:

apiVersion: v1
kind: Namespace
metadata:
  name: development
  labels:
    environment: dev

Применение манифеста:

kubectl apply -f namespace.yaml

Просмотр текущего состояния ресурса:

kubectl get namespace development -o yaml

Если ресурс уже существует, его можно модифицировать:

kubectl apply -f namespace.yaml

Метки и аннотации

• Метки (labels): используются для группировки, фильтрации и поиска объектов. Формат: ключ=значение.
  Пример:

kubectl get pods -l app=myapp

Аннотации (annotations): содержат метаинформацию для других инструментов. Формат аналогичен меткам, но используется для хранения дополнительных данных (например, о мониторинге или логировании).

Просмотр доступных ресурсов

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

kubectl api-resources

[***ДОБАВИТЬ КОД ВЫВОДА]

Подробное описание колонок:

• NAME: имя ресурса (например, pods).
• SHORTNAMES: сокращения для команды (например, po вместо pods).
• APIVERSION: версия API.
• NAMESPACED: указывает, существует ли ресурс в рамках namespace.
• KIND: тип ресурса (например, Pod, Service).
• VERBS: доступные операции (create, get, list, и т.д.).

Практический пример: работа с нодами

• Получить список всех нод:

kubectl get nodes

• Посмотреть подробную информацию о конкретной ноде:

kubectl describe node <node-name>

• Фильтровать ноды по меткам:

kubectl get nodes -l node-role.kubernetes.io/control-plane=

Альтернативные способы взаимодействия с API Kubernetes

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

1. Официальные библиотеки

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

• Go: client-go — официальная библиотека для работы с Kubernetes.
• Python: библиотека kubernetes из PyPI.
• Java: библиотека kubernetes-client.
• JavaScript/TypeScript: клиент @kubernetes/client-node.

Эти библиотеки позволяют разрабатывать сложные приложения, используя удобные абстракции для работы с объектами Kubernetes.

Список всех официальных и неофициальных библиотек можно найти в официальной документации.

2. Использование curl

Прямые HTTP-запросы к API Kubernetes возможны с помощью таких инструментов, как curl или Postman. Это полезно для автоматизации, отладки или глубокой интеграции.

Пример запроса:

curl -k -X GET \
  -H "Accept: application/json" \
  -H "Authorization: Bearer <TOKEN>" \
  'https://<API_SERVER>:6443/api/v1/namespaces/development'

Обратите внимание:

• Флаг -k отключает проверку SSL-сертификатов (в тестовых средах это допустимо, но в продакшене нежелательно).
• Токен (<TOKEN>) — это ключ доступа, который можно найти в секрете Kubernetes или в kubeconfig.

3. Подсмотрим запросы kubectl

Иногда хочется понять, как kubectl формирует свои запросы к API-серверу.

Это можно сделать, добавив флаг -v для включения детализированного лога:

kubectl get pods -v=8

Пример вывода фрагмента лога:

I0218 19:47:51.589217   13865 loader.go:395] Config loaded from file:  /home/user/.kube/config

Лог указывает, что файл конфигурации для подключения к API находится по умолчанию в ~/.kube/config.

Этот файл, называемый kubeconfig, содержит данные для аутентификации, такие как:

• Адрес API-сервера.
• Токены или сертификаты доступа.
• Настройки пространств имён.

4. Проблемы доступа: ошибка 403

Если попытаться выполнить запрос к API-серверу без корректной аутентификации, как в примере ниже:

curl -k -X GET -H "Accept: application/json" 'https://192.168.0.199:6443/api/v1/namespaces/development'

Вы можете получить ответ:

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "namespaces \"development\" is forbidden: User \"system:anonymous\" cannot get resource \"namespaces\"...",
  "reason": "Forbidden",
  "code": 403
}

Причина:
Запрос отправляется от имени анонимного пользователя (system:anonymous), у которого нет прав на выполнение действий. Это связано с системой управления доступом RBAC (Role-Based Access Control).

Для выполнения успешного запроса вам нужно передать корректные учетные данные (например, токен аутентификации из kubeconfig).

5. Использование файла kubeconfig

Файл kubeconfig — это конфигурационный файл, который kubectl и клиентские библиотеки используют для подключения к Kubernetes. Он содержит:

• URL API-сервера.
• Сертификаты и ключи для аутентификации.
• Настройки пространств имён и контекстов.

Пример kubeconfig:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /path/to/ca.crt
    server: https://192.168.0.199:6443
  name: my-cluster
contexts:
- context:
    cluster: my-cluster
    user: my-user
  name: my-context
current-context: my-context
users:
- name: my-user
  user:
    token: <TOKEN>

по умолчанию файл находится в ~/.kube/config.

Переменная окружения KUBECONFIG позволяет указать другой путь:

export KUBECONFIG=/path/to/custom-config

Способы расширения API Kubernetes

Kubernetes предлагает гибкие возможности для расширения стандартного API, что делает его подходящим для множества специфичных сценариев. Например, компании, такие как Zalando, разрабатывают собственные операторы для управления сложными системами, адаптируя их под Kubernetes. Один из таких примеров — postgres-operator, который позволяет развёртывать и управлять кластерами PostgreSQL «под ключ».

Существуют два основных механизма расширения API Kubernetes: Custom Resource Definitions (CRD) и API Aggregation Layer. Рассмотрим их подробнее.

1. Custom Resource Definitions (CRD)

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

Как это работает:

1. Пользователь создаёт Custom Resource Definition (CRD) — описание нового типа ресурса.
2. Kubernetes берёт на себя хранение и валидацию объектов, созданных на основе CRD.
3. Пользовательский контроллер или оператор подписывается на события, связанные с этими объектами, и выполняет необходимые действия (например, развёртывание PostgreSQL-кластера).

Пример манифеста CR (Custom Resource):

apiVersion: databases.example.com/v1
kind: Postgresql
metadata:
  name: example-database
spec:
  replicas: 3
  storageSize: 20Gi

После создания CRD можно использовать команду kubectl для работы с этими объектами:

kubectl get customresourcedefinitions

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

2. Kubernetes API Aggregation Layer

API Aggregation Layer — это способ интеграции сторонних API-сервисов в Kubernetes. Он позволяет расширять функциональность API без добавления собственных CRD, путём регистрации новых API-групп и проксирования запросов к внешним сервисам.

Как это работает:

1. Вы создаёте объект APIService, который описывает новую API-группу.
2. Указываете, какой сервис будет обрабатывать запросы (например, metrics-server).
3. API-сервер Kubernetes перенаправляет запросы, адресованные зарегистрированной группе, на указанный сервис.

Пример манифеста APIService:

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta1.metrics.k8s.io
spec:
  service:
    name: metrics-server
    namespace: kube-system
  group: metrics.k8s.io
  version: v1beta1
  insecureSkipTLSVerify: true
  groupPriorityMinimum: 100
  versionPriority: 100

После регистрации новая API-группа становится доступной через kubectl:

kubectl get apiservices

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

Сравнение CRD и API Aggregation Layer

Заключение

Подведём итоги:

1. Работа с Kubernetes сводится к написанию манифестов — декларативных описаний инфраструктуры, которые передаются на обработку API-серверу Kubernetes (kube-apiserver).
2. Типы объектов в API:
   • Cluster-объекты (глобальные) существуют на уровне всего кластера и не зависят от namespace.
   • Namespaced-объекты локализованы внутри определённого namespace, обеспечивая изоляцию и уникальность ресурсов.
3. Namespace — это средство логической изоляции, позволяющее создавать отдельные пространства для групп объектов, что удобно для разграничения окружений (например, dev, staging, prod).
4. Общение с API:
   • Через утилиту kubectl, которая упрощает выполнение запросов к API.
   • Напрямую с помощью инструментов, таких как curl, для более низкоуровневого взаимодействия.
5. Расширение стандартного API:
   • CRD (Custom Resource Definitions) позволяет создавать пользовательские ресурсы и контроллеры для них.
   • API Aggregation Layer предоставляет возможность интеграции внешних сервисов с API Kubernetes.
6. Система контроля доступа: Kubernetes имеет мощный механизм управления доступом на основе ролей (RBAC), который мы рассмотрим в следующем блоке.

  
  
  
Чем отличаются метки (labels) от аннотаций (annotations)?
  
Метки добавляются автоматически, аннотации — вручную
Аннотации всегда обязательны, метки — нет
Метки используются для логирования, аннотации 
Метки используются для группировки и фильтрации объектов, аннотации — для дополнительной информации
  
Что предоставляет namespace в Kubernetes?
  
Логическое разделение ресурсов 
птимизацию сетевых подключений
Управление доступом к кластеру
Резервное копирование данных
  
Что делает API Aggregation Layer?
  
Расширяет доступ к стандартным объектам API
Позволяет подключать внешние API к Kubernetes 
Управляет внутренним состоянием API Kubernetes
Добавляет новые типы ресурсов через CRD
  
Какой флаг используется в kubectl для изменения формата вывода команды?
  
--verbose
--format
--show-labels
 --output
  
Что делает команда kubectl get nodes?
  
Получает список всех нод
Создаёт новую ноду
Удаляет ноду
Получает список всех подов
  
Что такое CRD (Custom Resource Definition)?
  
Система хранения конфигураций в Kubernetes
Функция для развертывания стандартных подов
Описание нового типа ресурса в API Kubernetes
Тип аутентификации в Kubernetes
  
Как называется компонент Kubernetes, который обрабатывает запросы и координирует работу компонентов?
  
kube-scheduler
kube-apiserver 
etcd
kube-controller
  
Какие типы объектов существуют в API Kubernetes?
  
Public и Private
Static и Dynamic
Глобальные и локальные
Cluster-scoped и Namespaced 
  
Какая команда используется для создания объекта из манифеста?
  
kubectl create
kubectl get
kubectl describe
kubectl apply
  
Как называется механизм управления доступом в Kubernetes?
  
IAM
RBAC
ACL
OAuth
  
Подготавливаем результат...
  
    
      
        Назад      
      
        Дальше        
Нажмите ↵