Чтобы лучше разобраться в этом вопросе, стоит напомнить основные Кубернетес-компоненты.
В основном мы можем разделить кластер на:
- Главный узел: плоскость управления, отвечающая за принятие глобальных решений о кластере.
- Рабочие узлы — отвечают за запуск модулей, предоставляя среду выполнения Kubernetes.
Рассмотрим компоненты раздела «Узел» (рабочий):
кубелет
Агент, работающий на каждом узел в кластере. Это гарантирует, что контейнеры работают в Стручок.
kubelet принимает набор PodSpec, предоставляемых с помощью различных механизмов, и обеспечивает работоспособность контейнеров, описанных в этих PodSpec. Kubelet не управляет контейнерами, которые не были созданы Kubernetes.
kube-прокси
kube-proxy — это сетевой прокси, который работает на каждом узел в вашем кластере, реализуя часть Kubernetes Оказание услуг концепция.
kube-прокси поддерживает сетевые правила на узлах. Эти сетевые правила разрешают сетевое взаимодействие с вашими модулями из сетевых сеансов внутри или за пределами вашего кластера.
kube-proxy использует уровень фильтрации пакетов операционной системы, если он есть и доступен. В противном случае kube-proxy сам пересылает трафик.
Время выполнения контейнера
Среда выполнения контейнера — это программное обеспечение, отвечающее за запуск контейнеров.
Kubernetes поддерживает несколько сред выполнения контейнеров: Докер, контейнерd, ЦРИ-Ои любая реализация Kubernetes CRI (интерфейс времени выполнения контейнера).
Как кубелет и среда выполнения контейнера — это два основных компонента, которые отвечают за запуск модуля и установление соединения с Control Plane, они должны быть установлены непосредственно в ОС узла. значит и для кубелет он должен иметь сертификаты TLS, которые вы упомянули в своем вопросе, для обеспечения безопасного подключения к плоскости управления. Как насчет kube-прокси?
Его можно было установить двумя способами при подготовке кластера — непосредственно на ОС узла (например, этот способ используется в Kubernetes: трудный путь) или как DaemonSet (кубадм).
Когда kube-прокси является установлен напрямую это будет также отдельно сгенерированные сертификаты TLS, как кубелет.
Второй способ - это «DamonSet», упомянутый в вашем вопросе. Это означает, что вместо того, чтобы работать в качестве демона ОС непосредственно на узле, он будет настроен через ДемонСет развертывание, и он будет работать как модуль на каждом узле. Преимущества перед запуском непосредственно в ОС:
- Используя функции DeamonSet, мы гарантируем, что в случае сбоя этот модуль будет автоматически воссоздан на узле.
- меньше вмешательства непосредственно в ОС узла — вместо генерации новых парных TLS-сертификатов мы будем просто использовать ServiceAccount
Отвечая на ваш вопрос:
Что особенного в демонсетах относительно аутентификации?
Чтобы лучше понять это, мы можем более глубоко взглянуть на kube-прокси настроен через DaemonSets с использованием кластера, подготовленного с помощью кубадм. На основе Документы Kubernetes:
Сервисный аккаунт для kube-прокси создается в kube-система пространство имен; затем kube-proxy развертывается как DaemonSet:
- Учетные данные (
ca.crt и жетон) в плоскость управления поступают из ServiceAccount
- Расположение (URL) сервера API берется из ConfigMap
-
kube-прокси ServiceAccount привязан к привилегиям в система: узел-прокси КластерРоле
Есть три точки. Сначала проверим первое:
Учетные данные - секрет
Получите имя учетной записи службы из определения модуля:
kubectl получить daemonset kube-proxy -n kube-system -o yaml
...
serviceAccount: kube-proxy
serviceAccountName: кубе-прокси
...
Как видите, имеет назначен сервисный аккаунт называется kube-прокси:
Давайте проверим это:
kubectl получить sa kube-proxy -n kube-system -o yaml
Вывод:
апиВерсия: v1
тип: ServiceAccount
метаданные:
Отметка времени создания: "2021-08-16T14:14:56Z"
имя: kube-прокси
пространство имен: kube-система
РесурсВерсия: "259"
идентификатор: (UID)
секреты:
- имя: kube-proxy-token-2qhph
Как видите, речь идет о секрете с именем куб-прокси-токен-2qhph:
kubectl получить секрет kube-proxy-token-2qhph -n kube-system -o yaml
Вывод:
апиВерсия: v1
данные:
ca.crt: (КОДИРОВАНИЕ BASE64 CA APISERVER)
пространство имен: (ПРОСТРАНСТВО ИМЕН В КОДИРОВАНИИ BASE64)
токен: (ТОКЕН-НОСИТЕЛЬ BASE64, ЗАКОДИРОВАННЫЙ)
вид: Секрет
метаданные:
аннотации:
kubernetes.io/service-account.name: kube-proxy
kubernetes.io/service-account.uid: ...
Отметка времени создания: "2021-08-16T14:14:56Z"
имя: kube-proxy-token-2qhph
пространство имен: kube-система
РесурсВерсия: "256"
идентификатор: (UID)
тип: kubernetes.io/service-account-token
Этот секрет содержит:
Созданный секрет содержит общедоступный ЦС сервера API и подписанный веб-токен JSON (JWT).
Мы используем этот токен носителя «JSON Web Token» для проверки запросов:
Учетная запись службы — это автоматически включенный аутентификатор, который использует подписанные токены носителя для проверки запросов.
Подписанный JWT можно использовать в качестве маркера носителя для аутентификации в качестве данной учетной записи службы. Видеть выше для того, как токен включается в запрос. Обычно эти секреты монтируются в модули для внутрикластерного доступа к серверу API, но их можно использовать и за пределами кластера.
Для получения дополнительной информации о токенах начальной загрузки я бы рекомендовал прочитать следующие документы Kubernetes: Аутентификация с помощью токенов Bootstrap, токен kubeadm и Kubernetes RBAC 101: аутентификация.
Карта конфигурации
Выполнив те же шаги, что и для получения имени ServiceAccount, мы получим имя ConfigMap, которое смонтировано на kube-прокси стручок:
kubectl получить daemonset kube-proxy -n kube-system -o yaml
...
тома:
- карта конфигурации:
дефолтмоде: 420
имя: kube-прокси
...
Теперь давайте получим определение ConfigMap:
kubectl получить cm kube-proxy -n kube-system -o yaml
kubeconfig.conf: |-
апиВерсия: v1
вид: Конфигурация
кластеры:
- кластер:
центр сертификации: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
сервер: https://10.230.0.12:6443
имя: по умолчанию
контексты:
- контекст:
кластер: по умолчанию
пространство имен: по умолчанию
пользователь: по умолчанию
имя: по умолчанию
текущий контекст: по умолчанию
пользователи:
- имя: по умолчанию
пользователь:
tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
Этот IP-адрес в сервер: это адрес API, поэтому kube-прокси знает его и может с ним общаться.
Имеются также ссылки на ca.rt и жетон которые монтируются из куб-прокси-токен-2qhph секрет.
КластерРоле
Давайте проверим ранее упомянутую ClusterRole — система: узел-прокси:
kubectl описывает систему кластерных ролей: узел-прокси
Имя: система: узел-прокси
Ярлыки: kubernetes.io/bootstrapping=rbac-defaults
Аннотации: rbac.authorization.kubernetes.io/autoupdate: true
Правило политики:
Ресурсы URL-адреса, не относящиеся к ресурсам Имена ресурсов Глаголы
------------------------ ------------------ -------------- -----
события [] [] [создать обновление патча]
events.events.k8s.io [] [] [создать обновление патча]
узлы [] [] [получить список просмотра]
конечные точки [] [] [список просмотра]
услуги [] [] [список просмотра]
endpointslices.discovery.k8s.io [] [] [список просмотра]
Мы можем, чтобы эта роль могла перечислять и отслеживать конечные точки узла, конечные точки, службы и т. д.
Описывая ClusterRoleBinding kubeadm:узел-прокси мы можем подтвердить эту роль система: узел-прокси используется kube-прокси Сервисный аккаунт:
kubectl описывает привязку кластерной роли kubeadm:node-proxyer
Имя: kubeadm: узел-прокси
Ярлыки: <нет>
Аннотации: <нет>
Роль:
Вид: ClusterRole
Имя: система: узел-прокси
Предметы:
Пространство имен видов
---- ---- ---------
ServiceAccount kube-proxy kube-system
Для получения более подробной информации я бы рекомендовал прочитать кубадм детали реализации.
Отвечая на ваш второй вопрос:
В чем смысл "Так как сам kubelet загружается на каждую ноду, и этого достаточно для запуска базовых сервисов" ?
Это просто означает, что узел установил соединение с Control Plane (как кубелет компонент, отвечающий за это), так что Control Plane может начать планировать kube-прокси pod на узле с помощью предопределенной среды выполнения контейнера.
