Роль Кубернетес, чтобы скрыть мастера

Question

Я строю кластер kubernetes, и мне было интересно, есть ли способ скрыть главный (ие) узел (ы) от "kubectl get node". Как они делают с eks, aks et c. Цель состоит в том, чтобы предоставить полный административный контроль пользователю, кроме как на главных узлах / компонентах. Я предполагаю, что с k8s RBA C есть какой-то способ, но пока что не могу найти что-либо релевантное.

Я также попытался отключить kubelet на мастере, как предложено здесь ( Как управляемые провайдеры Kubernetes скрывают главные узлы? ), но узел просто отображается как "Не готов"

Answer 1

После того, как вы создали кластер, вы можете запустить следующую команду, чтобы удалить главные узлы

kubectl delete node master-node-name

После этого вы больше не сможете видеть этот главный узел в kubectl get nodes, но вы все равно сможете нормально взаимодействовать с кластером. Здесь запись узлов в ETCD только удаляется.

Другой способ добиться того же - настроить Kubelet таким образом, чтобы он не регистрировал узел с помощью флага --register-node=false и управлял им вручную

Я считаю, что это то, чем управляют kubernetes поставщики услуг делают внутренне.

Answer 2

Ключ действительно является kubelet компонентом Kubernetes.
Я подозреваю, что управляемые версии Kubernetes вообще не запускаются kubelet .
Вы можете сделать то же самое на своем кластере DIY. чтобы доказать.

Основная цель kubelet - запускать Pod.
Если вам не нужно запускать Pod на хосте, вы не запускаете kubelet.
Компоненты Control Plane могут работать в качестве системных служб или stati c контейнеров.

Существует функция Alpha для самостоятельного размещения компонентов Control Plane (ie запускает их в виде модулей): https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/self-hosting/
Так что в будущем они могут запустить kubelet на главные хосты, но пока не нужны.

Кублет - это основной «агент узла», который работает на каждом узле. Он может зарегистрировать узел с помощью apiserver, используя одно из: имя хоста; флаг для переопределения имени хоста; или укажите c logi c для облачного провайдера.

https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/

Когда флаг кубета --register-node Значение true (по умолчанию), kubelet попытается зарегистрировать на сервере API. Это предпочтительный шаблон, используемый большинством дистрибутивов.

https://kubernetes.io/docs/concepts/architecture/nodes/#self -registration-of-hosts

Answer 3

Как бы вы отключили kubelet "вообще"? Я имею в виду, я устанавливаю свой мастер k8s с помощью "kubeadm init", я не устанавливаю и не запускаю "systemctl kubelet start", но мой узел все еще регистрируется и остается как узел "Не готов", поэтому регистрирующая часть все еще здесь.

Если вы настроили кластер kubernetes с использованием kubeadm , необходимо установить kubelets на всех узлах, включая главный поскольку он развертывает подавляющее большинство ключевых компонентов кластера, таких как kube-apiserver, kube-controller-manager или kube-scheduler как Pods в kube-system пространстве имен (вы можете перечислить их по kubectl get pods -n kube-system). Другими словами: вы не можете запустить кластер с kubeadm, не запустив kubelet на своем главном узле. Без него невозможно развернуть систему Pods, формирующую ваш кластер kubernetes . См. Также этот раздел в официальной документации kubernetes.

Что касается Самостоятельное размещение плоскости управления Kubernetes , упомянутой @Ivan, лучше внимательно прочтите ее в официальных документах, чтобы понять как это действительно работает:

kubeadm позволяет экспериментально создать самодостаточный управляющий уровень Kubernetes. Это означает, что ключевые компоненты, такие как сервер API, диспетчер контроллеров и планировщик, работают как модули DaemonSet, настроенные с помощью API Kubernetes, вместо модулей stati c, настроенных в кубеле через файлы stati c.

Это нигде не написано, что вам не нужно kubelet на master-node в настоящее время. Напротив, в нем говорится, что в случае использования автономного самолета управления Kubernetes (в настоящее время эксперимент) подход в kubeadm:

ключевые компоненты, такие как API server, controller manager и scheduler, выполняются как DaemonSet Pods, настроенный через API Kubernetes, вместо stati c Pods, настроенного в kubelet через статические файлы.

Итак, еще раз: в обоих подходах ключевые компоненты кластера выполняются как Pods, только DaemonSets настроены через API Kubernetes, но эти все еще Pods и да, stati c Pods, сконфигурированные с помощью файлов stati c (что является текущим подходом kubeadm), все еще нуждаются в kubelet , который может читать эти файлы stati c на мастер-узел и создайте соответствующие Pods заявленные в них.