Поиск по сайту:

Как получить доступ к API вашего кластера Kubernetes из ваших модулей


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

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

Зачем обращаться к API Kubernetes внутри модулей?

Существует несколько вариантов использования доступа к API внутри Pod. Этот метод позволяет приложениям динамически проверять свою среду, применять изменения Kubernetes и собирать метрики плоскости управления, которые обеспечивают понимание производительности.

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

Использование клиентских библиотек API

Самый простой и рекомендуемый способ доступа к Kubernetes API из модуля — использование клиентской библиотеки. Полностью поддерживаемые параметры доступны для C, .NET, Go, Haskell, Java, JavaScript, Perl, Python и Ruby. Существуют эквивалентные поддерживаемые сообществом решения для большинства других популярных языков программирования.

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

Вот пример того, как составить список модулей в вашем кластере в приложении Python:

from kubernetes import client, config
 
config.load_incluster_config()
 
api = client.CoreV1Api()
 
# Perform necessary API interactions
# pods = api.list_pod_for_all_namespaces()

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

Выполнение взаимодействий с API вручную

Чтобы вызвать API, вам нужно знать две вещи: имя хоста в кластере, на котором он открыт, и токен служебной учетной записи, который будет аутентифицировать ваш под.

Имя хоста API всегда kubernetes.default.svc. DNS-провайдер Kubernetes разрешит это имя на API-сервер плоскости управления. Кроме того, вы можете использовать переменную среды $KUBERNETES_SERVICE_HOST, чтобы узнать IP-адрес сервера API:

$ echo $KUBERNETES_SERVICE_HOST
10.96.0.1

API доступен только через HTTPS. Вы можете найти файл центра сертификации для вашего кластера по адресу /var/run/secrets/kubernetes.io/serviceaccount/ca.crt в вашем поде. Kubernetes помещает это в файловую систему каждый раз, когда создается новый контейнер.

Вам нужно будет пройти аутентификацию, чтобы получить что-то полезное с API. Kubernetes создает новую учетную запись службы для каждого модуля и предоставляет свой токен по адресу /var/run/secrets/kubernetes.io/serviceaccount/token. Его следует включать в каждый HTTP-запрос в качестве токена-носителя в заголовке Authorization.

Собрав все вместе, вот пример создания базового запроса API Kubernetes в поде с использованием curl:

$ curl \
  --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
  -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
  https://kubernetes.default.svc/api
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "192.168.49.2:8443"
    }
  ]

Сервер Kubernetes ответил доступными версиями API. Это подтверждает успешное подключение с использованием имени хоста kubernetes.default.svc и предоставленной учетной записи службы.

Обработка RBAC

Несмотря на то, что запрос API был успешно выполнен, большинство других будут недоступны, если для вашего кластера включен RBAC. Вновь созданные учетные записи служб не получают роли автоматически, поэтому ваш модуль не сможет запрашивать защищенные конечные точки API.

Вы можете решить эту проблему, создав свои собственные объекты Role и привязав их к учетной записи службы, предоставленной вашим модулям. Сначала создайте новую роль:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: demo-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]

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

$ kubectl apply -f role.yaml

Затем привяжите роль к учетной записи службы:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: demo-role-binding
subjects:
  - kind: ServiceAccount
    name: default
    apiGroup: ""
roleRef:
  kind: Role
  name: demo-role
  apiGroup: ""

Сервисный аккаунт default выбирается в качестве субъекта привязки роли. Поды всегда поставляются с этой учетной записью службы, ограниченной пространством имен, в котором они были созданы. В этом примере используется пространство имен default, но его следует изменить в объектах Role и RoleBinding, если ваш Pod существует. в другом пространстве имен.

Добавьте RoleBinding в свой кластер:

$ kubectl apply -f role-binding.yaml

Теперь вашим подам будет разрешено получать и перечислять другие объекты подов в пространстве имен default. Вы можете убедиться в этом, отправив запрос API к конечной точке подов с пространством имен:

$ curl \
  --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
  -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
  https://kubernetes.default.svc/api/v1/namespaces/default/pods
{
  "kind": "PodList",
  "apiVersion": "v1"
  ...
}

Поды могут определить свое собственное пространство имен, прочитав файл /var/run/secrets/kubernetes.io/serviceaccount/namespace:

$ cat /var/run/secrets/kubernetes.io/serviceaccount/namespace
default

Это обеспечивает удобный метод для интерполяции активного пространства имен в URL-адреса конечных точек:

$ curl \
  --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
  -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
  https://kubernetes.default.svc/api/v1/namespaces/$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)/pods
{
  "kind": "PodList",
  "apiVersion": "v1"
  ...
}

Выбор другой учетной записи службы

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

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  serviceAccountName: demo-sa

В этом примере Pod будет аутентифицироваться как токен demo-sa. Вы можете создать эту учетную запись службы вручную и привязать к ней нужные вам роли.

$ kubernetes create serviceaccount demo-sa

Учетная запись службы должна существовать в том же пространстве имен, что и модуль.

Отказ от подключения сервисной учетной записи

Автоматическая инъекция сервисной учетной записи не всегда желательна. Это может быть угрозой безопасности, поскольку успешная компрометация Pod предлагает немедленный доступ к API вашего кластера Kubernetes. Вы можете отключить монтирование токена сервисной учетной записи с помощью поля манифеста модуля spec.automountServiceAccountToken:

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  automountServiceAccountToken: false

Kubernetes не будет внедрять файл /var/run/secrets/kubernetes.io/serviceaccount/token. Это предотвратит аутентификацию модуля в Kubernetes API, если только вы не предоставите учетные данные вручную, используя другой метод. Это поле также поддерживается в объектах сервисных учетных записей, что делает их неподходящими для автоматического подключения к любому поду.

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

Краткое содержание

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

Официальные клиентские библиотеки упрощают запуск и запуск, если они подходят для вашего случая использования. В других ситуациях вам нужно будет вручную делать запросы к https://kubernetes.default.svc, предоставляя файл центра сертификации и токен учетной записи службы, которые Kubernetes внедряет в ваши контейнеры Pod. Независимо от используемого вами подхода учетная запись службы должна быть правильно настроена с привязками ролей RBAC, чтобы у модуля было разрешение на выполнение запланированных действий.




Все права защищены. © Linux-Console.net • 2019-2024