Как k8 traffi c протекает внутри? - PullRequest
Новая
       31

Как k8 traffi c протекает внутри?

1 голос
/ 09 марта 2020

У меня есть вход и обслуживание с LB. Когда traffi c, приходящий извне, он сначала попадает на вход, а затем идет ли он на модули напрямую, используя входной LB, или он отправляется на обслуживание и получает IP-адрес модуля через селектор, а затем идет на модули? Если это первый способ, что такое использование услуг? И какой тип, сервисы или входы используют готовностьProbe в развертывании?

Все настройки в GCP

Я новичок в сетях K8.

Ответы [ 2 ]

2 голосов
/ 09 марта 2020

Зависит от того, предоставляет ли ваша служба LoadBalancer контроллер Ingress или блоки вашего приложения (первый подход - правильный).

Обычный способ использования служб и входов такой: 

LoadBalancer Service -> Ingress -> ClusterIP Service -> Pods

В этом случае трафик c от Inte rnet сначала попадает на балансировщик нагрузки вашего облачного провайдера (созданного службой LoadBalancer), который перенаправляет его в контроллер Ingress (который работает с одним или несколькими модулями *) 1014 * в вашем кластере), который, в свою очередь, перенаправляет его в модули вашего приложения (получая IP-адреса модулей из службы ClusterIP).

Я не уверен, что у вас в данный момент есть это созвездие: 

Ingress -> LoadBalancer Service -> Pods

В этом случае вам не нужна служба LoadBalancer. Вам нужна только служба ClusterIP за входом, а затем вы обычно предоставляете вход с помощью службы LoadBalancer.

2 голосов
/ 09 марта 2020

Тип сервиса LoadBalancer - это внешний источник, предоставляемый вашим облаком и НЕ входящий в кластер Kubernetes. Они могут переадресовать запрос на ваши модули, используя селектор узлов, но вы не можете, например, создать правила пути или перенаправить, переписать, потому что это обеспечивается Ingress.

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

        Internet
            |
     [ LoadBalancer ]
       --|-----|--
       [ Services ]
       --|      |--
    [ Pod1 ]  [ Pod2 ]

Когда вы используете Ingress , является компонентным контроллером входного контроллера, который в основном является модулем, настроенным для обработки определенных вами правил. Чтобы использовать вход, вам нужно настроить службу для вашего пути, и тогда эта служба достигнет модулей с селекторами конфигурации. Вы можете настроить некоторые правила на основе пути, имени хоста и их перенаправления для нужной вам службы. Например: 

        Internet
            |
       [ Ingress ]
       --|-----|--
       [ Services ]
       --|      |--
    [ Pod1 ]  [ Pod2 ]

Вход предоставляет маршруты HTTP и HTTPS извне кластера для служб внутри кластера. Маршрутизация Traffi c контролируется правилами, определенными на ресурсе Ingress.

В этой статье есть хорошее объяснение всех способов предоставления вашего сервиса.

readnessProbe настроен в ваших спецификациях модуля / развертывания, а kubelet отвечает за оценку работоспособности вашего контейнера.

Kubelet использует датчики готовности, чтобы узнать, когда Контейнер готов начать принимать трафик c. Стручок считается готовым, когда все его контейнеры готовы. Одним из применений этого сигнала является управление тем, какие Бобы используются в качестве бэкэндов для Сервисов. Когда модуль не готов, он удаляется из сервисных балансировщиков нагрузки.

kube-proxy отвечает за выполнение запроса на модули.

Например, если у вас есть 2 модуля в разных узлах, kube-proxy будет обрабатывать правила брандмауэра (iptables) и распределять трафик c между вашими узлами. На каждом узле в вашем кластере запущен kube-proxy.

kube-proxy можно настроить тремя способами: режим пользовательского пространства , режим iptables и ipvs mode .

Если kube-proxy работает в режиме iptables, а первый выбранный Pod не отвечает, соединение не устанавливается. Это отличается от режима пользовательского пространства: в этом случае kube-proxy обнаружит, что соединение с первым модулем не удалось, и автоматически выполнит попытку с другим модулем внутреннего интерфейса.

Ссылки:

https://kubernetes.io/docs/concepts/services-networking/service/

https://kubernetes.io/docs/concepts/services-networking/ingress/

...