Архитектура Kubernetes: Мастер-Узел (Master-Node) взаимодействия

В этом посте будут описаны пути связи между мастером (на самом деле, apiserver) и кластером Kubernetes. Цель состоит в том, чтобы позволить пользователям настроить свою установку для усиления конфигурации сети, чтобы кластер мог работать в ненадежной сети (или на полностью общедоступных IP-адресах облачного провайдера).

Кластер к Мастеру

Все коммуникационные пути от кластера до мастер устройства заканчиваются на apiserver (ни один из других мастер компонентов не предназначен для предоставления удаленных служб). В типичном развертывании apiserver настроен на прослушивание удаленных подключений через безопасный HTTPS порт (443) с включенной одной или несколькими формами проверки подлинности клиента. Должна быть включена одна или несколько форм авторизации, особенно если разрешены анонимные запросы или токены учетной записи службы.

Узлы должны быть снабжены общедоступным корневым сертификатом для кластера, чтобы они могли безопасно подключаться к apiserver вместе с действительными учетными данными клиента. Например, при развертывании GKE по умолчанию клиентские учетные данные, предоставленные kubelet, имеют форму клиентского сертификата.

Модули (pods), которые хотят подключиться к apiserver, могут сделать это безопасно, используя служебную учетную запись, чтобы Kubernetes автоматически вставлял общедоступный корневой сертификат и действительный токен-носитель в pod при его создании. Служба kubernetes (во всех пространствах имен) настраивается с виртуальным IP-адресом, который перенаправляется (через kube-proxy) на конечную точку HTTPS на apiserver.

Мастер компоненты также обмениваются данными с apiserver кластера через защищенный порт.

В результате режим работы по умолчанию для соединений от кластера (узлы и модули (pods), работающие на узлах) к мастеру защищен по умолчанию и может работать в ненадежных и/или общедоступных сетях.

Мастер к Кластеру

Существует два основных канала связи от мастера (apiserver) к кластеру. Первый - от apiserver до процесса kubelet, который выполняется на каждом узле кластера. Второй - от apiserver до любого узла, модуля (pod) или службы с помощью прокси apiserver'а.

apiserver к kubelet

Соединения от apiserver к kubelet используются для:

  • Получение логов для pod'ов.
  • Прикрепление (через kubectl) к выполняющимся pod'ам.
  • Предоставление функции переадресации портов kubelet.

Эти соединения завершаются в конечной точке HTTPS kubelet. По умолчанию apiserver не проверяет обслуживающий сертификат kubelet, что делает соединение подверженным атакам "человек посередине" (man-in-the-middle) и небезопасным для работы в ненадежных и/или общедоступных сетях.

Чтобы проверить это соединение, используйте флаг --kubelet-certificate-authority, чтобы предоставить apiserver корневой пакет сертификатов, который будет использоваться для проверки обслуживающего сертификата kubelet.

Если это невозможно, используйте SSH-туннелирование между apiserver и kubelet, если необходимо, чтобы избежать подключения по ненадежной или общедоступной сети.

Наконец, аутентификация и/или авторизация Kubelet должны быть включены для защиты kubelet API.

apiserver к узлам, модулям (pods) и службам

Соединения от apiserver к узлу, модулю (pod) или службе по умолчанию равны обычным HTTP-соединениям и поэтому не аутентифицированы и не зашифрованы. Их можно запустить по безопасному HTTPS-соединению, добавив префикс https: к узлу, модулю (pod) или имени службы в URL-адресе API, но они не будут проверять сертификат, предоставленный конечной точкой HTTPS, и не будут предоставлять учетные данные клиента, поэтому соединение будет зашифровано, но это не даст никаких гарантий целостности. Эти соединения в настоящее время небезопасны для работы в ненадежных и/или публичных сетях.

Туннели SSH

Kubernetes поддерживает SSH-туннели для защиты каналов связи Master -> Cluster. В этой конфигурации apiserver инициирует SSH-туннель к каждому узлу в кластере (подключаясь к ssh-серверу, прослушивающему порт 22) и пропускает весь трафик, предназначенный для kubelet, узла, модуля (pod) или службы, через туннель. Этот туннель гарантирует, что трафик не будет открыт за пределами сети, в которой работают узлы.

Туннели SSH в настоящее время устарели, поэтому вы не должны использовать их, если не знаете, что делаете. Разрабатывается замена для этого канала связи.

Читайте также:


Комментарии

Отправить комментарий

Популярные сообщения из этого блога

Контроллеры в Kubernetes: DaemonSet

Изображение
DaemonSet гарантирует, что все (или некоторые) узлы запускают копию Pod. Когда узлы добавляются в кластер, к ним добавляются Pod'ы. Когда узлы удаляются из кластера, эти Pod'ы удаляются. Удаление DaemonSet приведет к очистке созданных им Pod'ов. Некоторые типичные применения DaemonSet : запуск демона кластерного хранилища, такого как glusterd, ceph, на каждом узле. запуск демона сбора журналов на каждом узле, таком как fluentd или logstash. запуск демона мониторинга узла на каждом узле, таком как экспортер узлов Prometheus, агент Sysdig, collectd, Dynatrace OneAgent, агент AppDynamics, агент Datadog, агент New Relic, агент Ganglia gmond или агент Instana. В простом случае один DaemonSet, охватывающий все узлы, будет использоваться для каждого типа демона. Более сложная установка может использовать несколько DaemonSets для одного типа демона, но с разными флагами и/или разными запросами памяти и процессора для разных типов оборудования. Написание спецификации Daemon...
Далее...

Контроллеры в Kubernetes: ReplicaSet

Изображение
Цель контроллера ReplicaSet - поддерживать стабильный набор реплик (экземпляров) Pod'ов, работающих в любой момент времени. Как таковой, он часто используется, чтобы гарантировать наличие определенного количества идентичных Pod'ов. Как работает ReplicaSet ReplicaSet задается полями , включая селектор (selector) , который указывает, как идентифицировать Pod'ы, которые он может приобрести, количество реплик (replicas) , указывающих, сколько Pod'ов он должен поддерживать, и шаблон (template) Pod'ов , указывающий данные новых Pod'ов, которые он должен создать для соответствия критерию количества реплик. Затем ReplicaSet выполняет свое предназначение, создавая и удаляя Pod'ы по мере необходимости для достижения желаемого числа. Когда ReplicaSet нуждается в создании новых Pod'ов, он использует свой шаблон Pod'ов для их создания. Ссылка, которую ReplicaSet имеет на свои Pod'ы, осуществляется через поле metadata.ownerReferences Pod'ов, которое у...
Далее...

Контроллеры в Kubernetes: StatefulSet

Изображение
StatefulSet - это объект workload API, используемый для управления приложениями с отслеживанием состояния. Управляет развертыванием и масштабированием набора Pod'ов, а также предоставляет гарантии относительно порядка и уникальности этих Pod'ов. Подобно Deployment, StatefulSet управляет Pod'ами, основанными на идентичной спецификации контейнера. В отличие от Deployment, StatefulSet поддерживает липкую (sticky) идентификацию для каждого из своих Pod'ов. Эти Pod'ы созданы из одной и той же спецификации, но не являются взаимозаменяемыми: у каждого есть постоянный идентификатор, который он поддерживает при любом перепланировании. StatefulSet работает по тому же шаблону, что и любой другой контроллер. Вы определяете желаемое состояние в объекте StatefulSet, а контроллер StatefulSet делает все необходимые обновления, чтобы получить его из текущего состояния. Использование StatefulSet StatefulSet полезны для приложений, которым требуется одно или несколько из следующ...
Далее...