Блог

Главная - Вопросы по программированию - Как управляемые поставщики Kubernetes скрывают главные узлы?

Как управляемые поставщики Kubernetes скрывают главные узлы?

#kubernetes #digital-ocean #google-kubernetes-engine

# #kubernetes #digital-ocean #google-kubernetes-engine

Вопрос:

Если я запускаю kubectl get nodes GKE, EKS или DigitalOcean Kubernetes, я вижу только рабочие узлы. Как эти системы спроектированы на сетевом или прикладном уровне, чтобы создать такое разделение между рабочими и главными узлами?

Ответ №1:

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

Комментарии:

1. кто создает Node объекты в API kubernetes? контроллер узла? Как он узнает, когда он должен создать Node объект или нет, чтобы он выглядел kubectl get nodes выдающимся?

2. Node Объект создается, когда новый процесс kubelet подключается к кластеру. Теоретически вы можете запустить несколько kubelets или узлов на одной виртуальной машине.

3. Kubelet тоже работает на главном, верно? Так разве они не появляются на бегу kubectl get nodes ?

4. @fiunchinho Обычной практикой является запуск главного сервера на определенных узлах кластера, но для этого нет никаких требований. Главные компоненты могут находиться где угодно и без kubelet, если существует сетевое соединение между сервером api и kubelets рабочего узла.

5. Все руководства, которые я нашел для начальной загрузки кластера, включают запуск kubelet на главных узлах. Теперь я вижу, что этого не требуется. Было бы неплохо, если бы эта установка «без мастера» была где-нибудь задокументирована. Может быть, я напишу об этом пост в блоге. Спасибо за ответ и обсуждение.

Ответ №2:

Кластер контейнерных движков — это группа экземпляров вычислительных движков, работающих под управлением Kubernetes. Он состоит из одного или нескольких экземпляров узла и управляемой главной конечной точки Kubernetes. Каждый контейнерный кластер имеет единственную главную конечную точку, которая управляется механизмом контейнеров. Мастер обеспечивает унифицированное представление кластера и через свою общедоступную конечную точку является дверью для взаимодействия с кластером.

Управляемый мастер также запускает сервер API Kubernetes, который обслуживает запросы REST, планирует создание и удаление pod на рабочих узлах и синхронизирует информацию pod (например, открытые порты и местоположение) со служебной информацией.

Более подробную информацию можно найти здесь

Метки: