Какова цель kubectl прокси?

Question

Чтобы получить доступ к панели управления Kubernetes, вы должны запустить прокси-сервер kubectl на своем локальном компьютере, а затем направить веб-браузер на прокси-сервер.Точно так же, если вы хотите отправить задание Spark, вы снова запускаете прокси-сервер kubectl на своем локальном компьютере, а затем запускаете spark-submit для адреса localhost.

Мой вопрос: почему у Kubernetes такая особая схема?Служба панели мониторинга работает в кластере Kubernetes, так почему я не указываю своему веб-браузеру на кластер напрямую?Зачем нужен прокси?В некоторых случаях необходимость в прокси неудобна.Например, с моего веб-сервера я хочу отправить задание Spark.Я не могу этого сделать - сначала мне нужно запустить прокси, но это привязывает меня к определенному кластеру.У меня может быть много кластеров Kubernetes.

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

Answer 1

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

Проще говоря, для безопасности и удобство .

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

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

Как отмечалось в ваших примерах, вам не нужно было проходить аутентификацию в кластере, чтобы общаться, kubectl сделал всю работу за вас, и для каждого вызова API Server будет установлена ​​защита от вашего имени.

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

Answer 2

Вы можете получить доступ к своему приложению в кластере различными способами:

1. , используя apiserver в качестве прокси , но вам необходимо пройти этап аутентификации и авторизации.
2. с использованием hostNetwork .Когда модуль сконфигурирован с hostNetwork: true, приложения, работающие в таком модуле, могут напрямую видеть сетевые интерфейсы хост-машины, на которой был запущен модуль.
3. с помощью hostPort .Порт контейнера будет открыт для внешней сети на hostIP:hostPort, где hostIP - это IP-адрес узла Kubernetes, на котором работает контейнер, а hostPort - это порт, запрошенный пользователем.
4. с использованием Сервисов с типом: ClusterIP .Службы ClusterIP доступны только для модулей в кластере и узлах кластера.
5. с помощью служб с типом: NodePort .В дополнение к ClusterIP эта служба получает случайный или указанный пользователем порт из диапазона 30000-32767.Все узлы кластера прослушивают этот порт и перенаправляют весь трафик в соответствующую службу.
6. , используя службы типа: LoadBalancer .Он работает только с поддерживаемыми облачными провайдерами и с Metallb для локальных кластеров.В дополнение к открытию NodePort, Kubernetes создает балансировщик нагрузки облака, который перенаправляет трафик к NodeIP:Nodeport для этой службы.

Итак, в основном: [[[ Kubernetes Service type:ClusterIP] + NodePort ] + LoadBalancer ]

с использованием Ingress (ingress-controller + Ingress object).Ingress-controller предоставляется службой Nodeport или LoadBalancer и работает как L7 обратный прокси-сервер / LB для служб кластера.Он имеет доступ к Сервисам ClusterIP, поэтому вам не нужно предоставлять Сервисы, если вы используете Ingress.Вы можете использовать его для терминации SSL и для пересылки трафика на основе URL-пути.Самые популярные входные контроллеры:

• kubernetes / nginx-ingress ,
• nginxinc / kubernetes-ingress ,
• HAProxy-ingress ,
• Traefik .

Теперь о kubectl proxy.Он использует первый способ подключения к кластеру.По сути, он считывает конфигурацию кластера в .kube / config и использует оттуда учетные данные для прохождения этапа проверки подлинности и авторизации API сервера кластера.Затем он создает канал связи от локального компьютера до интерфейса API-сервера, поэтому вы можете использовать локальный порт для отправки запросов в API кластера Kubernetes без необходимости указывать учетные данные для каждого запроса.