Необходимая информация, связанная с сервисом kubernetes

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

$ cat config |grep 6443
сервер: https://ac1poc-20210407164708-kube-api-f5082ea18c7584ad.elb.us-east-1.amazonaws.com:6443

2. И если kubelet должен общаться с конечной точкой API, у него есть аналогичная запись в его файле конфигурации. /etc/кубернетес/кубелет
3. То же самое и для kube-proxy. Таким образом, все эти три внешних API имеют запись Network Load Balancer, настроенную в соответствующих файлах конфигурации. Это означает, что все они отправляют пакеты в NLB всякий раз, когда хотят связаться с серверной частью API.

Но тогда у меня есть эта услуга, как показано ниже. Я хотел спросить, когда эта услуга вступает в игру. Какой API использует этот сервис?

$ kubectl описать svc kubernetes
Имя: Кубернетес
Пространство имен: по умолчанию
Ярлыки: компонент=apserver
                   провайдер = кубернет
Аннотации: <нет>
Селектор: <нет>
Тип: Кластер IP
Семейная политика IP: единый стек
IP-семейства: IPv4
IP: 10.96.0.1
IP-адреса: 10.96.0.1
Порт: https 443/TCP
Целевой порт: 6443/TCP
Конечные точки: 172.36.11.131:6443,172.36.12.131:6443,172.36.13.131:6443
Сходство сеансов: нет
События: <нет>

Мой вопрос в том, что если клиент, скажем, kubectl должен получить доступ к кластеру для различных операций получения/удаления/редактирования

2) И если kubelet нужно поговорить с конечной точкой API

Верно, эти два взаимодействия решают одну и ту же проблему: как процесс, который внешний чтобы кластер kubernetes достиг уровня управления.Можно представить, что он будет ограничен (например) только корпоративным VPN для кубектл операции или только рабочие подсети для кубелет.

кубелет на самом деле нет необходимость для использования NLB (имеется в виду трафик, исходящий из VPC через любой Nat GW/Internet GW в NLB и обратно в VPC), совершенно безопасно и эффективно указать конфигурацию kubelet на «внутренней» стороне этого NLB, поэтому до тех пор, пока сертификаты уровня управления имеют достаточное количество записей альтернативного имени субъекта для выполнения рукопожатия TLS. Обычно именно поэтому люди не утруждают себя разграничением этих двух случаев, но если это касается безопасности (или стоимости!) вашей организации, разделить эти два взаимодействия можно на 100 %.

Какой API использует этот сервис?

CNI Оказание услуг указывает на одну и ту же плоскость управления, но этот трафик проходит внутри кластера, и что kubernetes.default.svc.cluster.local Оказание услуг доступен для всех Пространство именs все время, и именно так любой клиент kubernetes в Pod использует встроенный ServiceAccount токен для доступа к API kubernetes. Таким образом, все, что работает внутри кластера, не нуждается в какой-либо настройке для доступа к API, включая доступ в Интернет, потому что этот внутрикластерный трафик не покидает сеть CNI.