Ингресс порт что это

ingress проброс порта

я не самый большой спец по подворотам, но сдается мне, что вот так:

 - path: / backend: - path: / backend: 

делать нельзя и оно завернет на первый по списку, как и есть по факту.

SevikL ★★★★★
( 22.05.19 16:59:38 MSK )
Ответ на: комментарий от SevikL 22.05.19 16:59:38 MSK

Да, это я уже понял. Может есть какие то другие варианты проброса?

Что такое ingress?

Ingress это базовый тип ресурса в кубертенесе. Если просто объявить объект типа Ingress в кубернетисе то ничего не произойдет.

Что бы этот ресурс начал работу в кластере кубернетиса должен быть установлен Ingress Controller, который настроит реверсивный прокси в соответствии с Ingress объектом.

Ingress Controller состоит из 2х компонентов — реверсивного прокси и контроллера который общается с API сервером кубернетеса. Реверсивный прокси слушает входящий трафик на портах которые указаны в настройках (обычно в настройках по умолчанию указан только порт 80). Контроллер может быть как отдельным демоном (как в nginx), так и встроенным в прокси (как в traefik).

Не все клауд провайдеры кубернетеса предустанавливают Ingress Controller по умолчанию.

Контроллеры могут запускаться либо как DaemonSet либо как Deployment. DaemonSet идеально использовать как единственный Ingress Controller, что бы реверсивное прокси слушало на всех IP адресах воркеров. Deployment отлично подходит если перед Ingress контроллером стоит балансировщик — от провайдера кубернетиса (GKE, AKS), MetalLB если онпремис или обычный haproxy/nginx установленный на сервере (требутеся ручная настройка). При этой установке возможно установить несколько Ingress Controller.

Как входящий трафик попадает на Ingress Controller

Во всех случаях реверс прокси в Ingress Controller слушает порты где ожидает http/https соединения.

Трафик на этоти порты может попасть тремя путями:

• NodePort (на случайных портах в диапазоне 30000-32767)
• HostPort (можно повесить на порты 80, 443)
• Host network — Pod повестит свои порты на публичном сетевом интерфейсе (т.е. будут открыты все порты контейнера)

NodePort

Ставить Ingress Controller на NodePort без LoadBalancer имеет мало смысла, так как URL будет включать порт который указан в NodePort http://domain.example.org:32200/.

Для этого варианта лучше использовать Deployments. Это позволит проще скейлить количество подов ответственных за входящий трафик, прописывать им nodeAffinity и запускать несколько ingress controller (например для production и staging).

HostPort

При использовании HostPort порт пробрасывается с хоста где запущен под в этот самый Pod. LoadBalancer на вход не нужен, но для работы сайта в DNS нужно указывать что адрес домена находится на всех узлах.

Пример конфигурации DNS для 3х воркеров:

ingress.example.org A 10.0.0.1 ingress.example.org A 10.0.0.2 ingress.example.org A 10.0.0.3 www.example.org CNAME ingress.example.org

Для этой установки лучше всего использовать DaemonSet т.к. он позволяет запустить не более одного Pod на хосте. Deployment возможен, но имеет мало смысла т.к. надо прописывать affinity что бы не назначилось 2 Pod на один хост, иначе будет конфликт по портам.

Пример конфигурации для traefik

kind: DaemonSet apiVersion: extensions/v1beta1 metadata: name: traefik-ingress-controller namespace: traefik labels: k8s-app: traefik-ingress-lb spec: template: metadata: labels: k8s-app: traefik-ingress-lb name: traefik-ingress-lb namespace: traefik spec: serviceAccountName: traefik-ingress-controller terminationGracePeriodSeconds: 60 containers: - image: traefik:1.7.6 name: traefik-ingress-lb ports: - name: http containerPort: 80 hostPort: 80 - name: https containerPort: 443 hostPort: 443 - name: admin containerPort: 8080 hostPort: 8080 securityContext: capabilities: drop: - ALL add: - NET_BIND_SERVICE args: - --api - --kubernetes - --logLevel=DEBUG - --entrypoints=Name:https Address::443 TLS - --entrypoints=Name:http Address::80 - --defaultentrypoints=http

Host network

При запуске Ingress Controller в общей сети с хостом не требуется никаких пробросов портов, но в этом случае все порты которые открыты в Pod будут доступны из интернета. Для запуска лучше использовать DaemonSet. Причины такие же как и с HostPort — что бы избежать конфликта портов.

Что выбрать

Если есть LoadBalancer на входе — NodePort, если нет — HostPort + DNS Round Robin. Для экспериментов можно попробовать Host network, но это не безопасно.

Сети Kubernetes: Ingress

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

Маршрутизация — это не балансировка нагрузки

В предыдущем материале этой серии была рассмотрена конфигурация, состоящая из пары подов и сервиса, которому был назначен IP-адрес, называемый «IP кластера». Именно на этот адрес отправлялись запросы, предназначенные для подов. Здесь мы продолжим работу над нашей учебной системой, начав там, где закончили в прошлый раз. Вспомним о том, что кластерный IP-адрес сервиса, 10.3.241.152 , принадлежит диапазону IP-адресов, отличному от того, который используется в сети подов, и от того, который используется в сети, в которой находятся узлы. Я назвал сеть, заданную этим адресным пространством, «сервисной сетью», хотя она вряд ли достойна особого названия, так как к этой сети не подключено никаких устройств, и её адресное пространство, фактически, полностью состоит из правил маршрутизации. Ранее было продемонстрировано то, как эта сеть реализована на основе компонента Kubernetes, который называется kube-proxy и взаимодействует с модулем ядра Linux netfilter для перехвата и перенаправления трафика, отправленного на IP кластера, на работающий под.

До сих пор мы говорили о «соединениях» и «запросах» и даже использовали сложное для толкования понятие «трафик», но для того, чтобы понять особенности работы механизма Kubernetes Ingress, нам нужно использовать более точные термины. Так, соединения и запросы работают на 4 уровне модели OSI (tcp) или на 7 уровне (http, rpc, и так далее). Правила netfilter представляют собой правила маршрутизации, они работают с IP-пакетами на третьем уровне. Все маршрутизаторы, включая netfilter, принимают решения, более или менее основываясь только на информации, содержащейся в пакете. В целом, их интересует то, откуда идёт пакет и куда он направляется. Поэтому для того чтобы описать это поведение в терминах третьего уровня модели OSI, нужно сказать, что каждый пакет, предназначенный для сервиса, находящегося по адресу 10.3.241.152:80 , который прибывает на интерфейс узла eth0 , обрабатывается средствами netfilter, и, в соответствии с правилами, заданными для нашего сервиса, перенаправляется на IP-адрес работоспособного пода.

Кажется совершенно очевидным то, что любой механизм, который мы используем для того, чтобы позволить внешним клиентам обращаться к подам, должен использовать эту же инфраструктуру маршрутизации. В результате эти внешние клиенты будут обращаться к IP-адресу и порту кластера, так как они являются «точкой доступа» ко всем тем механизмам, о которых мы до сих пор говорили. Они позволяют нам не беспокоиться о том, где именно выполняется под в некий определённый момент времени. Однако совсем неочевидно то, как сделать так, чтобы всё это работало.

Кластерный IP сервиса достижим лишь с Ethernet-интерфейса узла. Ничто за пределами кластера не знает о том, что делать с адресами из диапазона, к которому принадлежит этот адрес. Как можно перенаправить трафик с общедоступного IP-адреса на адрес, который достижим только в том случае, если пакет уже пришёл в узел?

Если мы попытаемся найти решение этой проблемы, то одним из дел, которые можно сделать в процессе поиска решения, будет исследование правил netfilter с использованием утилиты iptables. Если это сделать, можно будет обнаружить нечто такое, что, на первый взгляд, может показаться необычным: правила для сервиса не ограничены конкретной сетью-источником. Это значит, что любые пакеты, сгенерированные где угодно, которые прибывают на Ethernet-интерфейс узла и имеют адрес назначения 10.3.241.152:80 , будут признаны как соответствующие правилу и будут перенаправлены поду. Можем ли мы просто дать клиентам IP кластера, возможно, привязав его к подходящему доменному имени, и затем настроить маршрут, позволяющий организовать доставку этих пакетов одному из узлов?

Внешний клиент и кластер

Если настроить всё именно так, то такая конструкция окажется рабочей. Клиенты обращаются к кластерному IP, пакеты следуют по маршруту, ведущему их к узлу, а затем перенаправляются поду. В этот момент вам может показаться, что таким решением можно и ограничиться, но оно страдает некоторыми серьёзными проблемами. Первая заключается в том, что узлы, вообще-то, понятие эфемерное, они не особенно отличаются в этом плане от подов. Они, конечно, немного ближе к материальному миру, чем поды, но они могут мигрировать на новые виртуальные машины, кластеры могут масштабироваться вверх или вниз, и так далее. Маршрутизаторы работают на третьем уровне модели OSI и пакеты не могут отличить нормально работающие сервисы от тех, что работают неправильно. Они ожидают, что следующий переход в маршруте будет доступен и окажется стабильным. Если узел оказывается недостижимым, маршрут станет нерабочим и будет таким оставаться, в большинстве случаев, немало времени. Если даже маршрут окажется устойчивым к сбоям, то такая схема приведёт к тому, что весь внешний трафик пойдёт через единственный узел, что, вероятно, оптимальным не является.

Как бы мы ни приводили клиентский трафик в систему, нам надо это делать так, чтобы это не зависело бы от состояния любого отдельно взятого узла кластера. И, на самом деле, нет надёжного способа сделать это, используя лишь маршрутизацию, без неких средств активного управления маршрутизатором. Собственно говоря, именно подобную роль, роль системы управления, kube-proxy играет по отношению к netfilter. Расширение сферы ответственности Kubernetes до управления внешним маршрутизатором, вероятно, не имело особого смысла для архитекторов системы, особенно учитывая то, что у нас уже есть доказавшие свою полезность инструменты для распределения клиентского трафика между множеством серверов. Они называются балансировщиками нагрузки, и неудивительно то, что именно они являются действительно надёжно работающим решением для Kubernetes Ingress. Для того чтобы понять то, как в точности это происходит, нам нужно подняться с третьего уровня OSI и снова поговорить о соединениях.

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

Среди других адресов, с которыми можно работать, можно отметить лишь адреса сети, к которой подключены Ethernet-интерфейсы узлов, то есть, в этом примере, 10.100.0.0/24 . Маршрутизатор уже знает о том, как направлять пакеты на эти интерфейсы, и соединения, отправленные с балансировщика нагрузки на маршрутизатор, попадут туда, куда должны попасть. Но если клиент хочет подключиться к нашему сервису по порту 80, то мы не можем просто отправить пакеты на этот порт сетевых интерфейсов узлов.

Балансировщик нагрузки, неудачная попытка обращения к порту 80 сетевого интерфейса узла

Причина, по которой сделать этого нельзя, совершенно очевидна. А именно, речь идёт о том, что нет процесса, ожидающего соединений по адресу 10.100.0.3:80 (а если и есть, то это, точно, не тот процесс), и правила netfilter, которые, как мы надеялись, перехватят запрос и направят его поду, не сработают при таком адресе назначения. Они реагируют лишь на кластерный IP сети, основанной на сервисах, то есть на адрес 10.3.241.152:80 . В результате эти пакеты, при их прибытии, не могут быть доставлены по адресу назначения, и ядро выдаст ответ ECONNREFUSED . Это ставит нас в запутанное положение: с сетью, на перенаправление пакетов в которую настроен netfilter, непросто работать при перенаправлении данных со шлюза на узлы, а сеть, для которой легко настроить маршрутизацию, это не та сеть, в которую netfilter перенаправляет пакеты. Для того чтобы решить эту проблему, можно создать между этими сетями мост. Именно это и делается в Kubernetes с использованием сервиса типа NodePort.

Сервисы типа NodePort

Тому сервису, который мы, для примера, создали в предыдущем материале, не назначен тип, поэтому он принял тип, назначаемый по умолчанию — ClusterIP . Есть ещё два типа сервисов, которые отличаются дополнительными возможностями, и тот из них, который нас сейчас интересует — это NodePort . Вот пример описания сервиса такого типа:

kind: Service apiVersion: v1 metadata: name: service-test spec: type: NodePort selector: app: service_test_pod ports: - port: 80 targetPort: http

Сервисы типа NodePort — это сервисы типа ClusterIP , обладающие дополнительной возможностью: доступ к ним можно получить как по IP-адресу, назначенному узлу, так и по адресу, назначенному кластеру в сети сервисов. Достигается это довольно простым способом: когда Kubernetes создаёт сервис NodePort , kube-proxy выделяет порт в диапазоне 30000-32767 и открывает этот порт на интерфейсе eth0 каждого узла (отсюда и название типа сервиса — NodePort ). Соединения, выполняемые к этому порту (мы будем называть такие порты NodePort ), перенаправляются на кластерный IP сервиса. Если мы создадим сервис, описанный выше, и выполним команду kubectl get svc service-test , мы сможем увидеть порт, назначенный ему.

$ kubectl get svc service-test NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE service-test 10.3.241.152 80:32213/TCP 1m

В данном случае сервису назначен NodePort 32213 . Это означает, что мы теперь можем подключаться к сервису через любой узел в нашем экспериментальном кластере по адресу 10.100.0.2:32213 или по адресу 10.100.0.3:32213 . При этом трафик будет перенаправляться сервису.

После того, как эта часть системы заняла своё место, у нас есть все фрагменты конвейера для балансировки нагрузки, создаваемой запросами клиентов ко всем узлам кластера.

Сервис NodePort

На предыдущем рисунке клиент подключается к балансировщику нагрузки через общедоступный IP-адрес, балансировщик нагрузки выбирает узел и подключается к нему по адресу 10.100.0.3:32213 , kube-proxy принимает это соединение и перенаправляет его сервису, доступному по кластерному IP 10.3.241.152:80 . Здесь запрос успешно обрабатывается по правилам, заданным netfilter, и перенаправляется серверному поду на адрес 10.0.2.2:8080 . Возможно, всё это может выглядеть немного сложным, и, в некоторой степени, так оно и есть, но нелегко придумать более простое решение, которое поддерживает все те замечательные возможности, которые дают нам поды и сети, основанные на сервисах.

Этот механизм, однако, не лишён собственных проблем. Использование сервисов типа NodePort даёт клиентам доступ к сервисам с использованием нестандартного порта. Часто проблемой это не является, так как балансировщик нагрузки может предоставить им обычный порт и скрыть NodePort от конечных пользователей. Но в некоторых сценариях, например, тогда, когда используется внешний балансировщик нагрузки платформы Google Cloud, может быть необходимым раскрыть NodePort клиентам. Надо отметить, что такие порты, кроме того, представляют собой ограниченные ресурсы, хотя 2768 портов, вероятно, достаточно даже для самых больших кластеров. В большинстве случаев можно позволить Kubernetes выбирать номера портов случайным образом, но при необходимости их можно задавать самостоятельно. Ещё одна проблема заключается в некоторых ограничениях, касающихся сохранения IP-адресов источников в запросах. Для того чтобы выяснить способы решения этих проблем, вы можете обратиться к этому материалу из документации Kubernetes.

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

Архитекторы платформы, понимая это, предоставили два способа задания конфигурации балансировщика нагрузки из самой платформы Kubernetes. Давайте это обсудим.

Сервисы типа LoadBalancer и ресурсы вида Ingress

Сервисы типа LoadBalancer и ресурсы вида Ingress представляют собой одни из наиболее сложно устроенных механизмов Kubernetes. Мы, однако, не будем тратить на них слишком много времени, так как их использование не приводит к коренным изменениям во всём том, о чём мы до сих пор говорили. Весь внешний трафик, как и прежде, входит в кластер через NodePort .

Архитекторы могли бы здесь и остановиться, позволив тем, кто создаёт кластеры, заботиться лишь об общедоступных IP-адресах и балансировщиках нагрузки. На самом деле, в определённых ситуациях, в таких, как запуск кластера на обычных серверах или в домашних условиях, именно так и поступают. Но в окружениях, которые поддерживают конфигурации сетевых ресурсов, управляемые через API, Kubernetes позволяет настроить всё, что нужно, в одном месте.

Первый подход к решению этой задачи, самый простой, заключается в использовании сервисов Kubernetes типа LoadBalancer . Такие сервисы имеют все возможности сервисов типа NodePort , и, в дополнение к этому, обладают возможностью создавать полные пути для входящего трафика, исходя из предположения о том, что кластер запущен в окружениях наподобие GCP или AWS, поддерживающих конфигурирование сетевых ресурсов через API.

kind: Service apiVersion: v1 metadata: name: service-test spec: type: LoadBalancer selector: app: service_test_pod ports: - port: 80 targetPort: http

Если мы удалим и повторно создадим сервис из нашего примера в Google Kubernetes Engine, то мы, вскоре после этого, используя команду kubectl get svc service-test , сможем удостовериться в факте назначения внешнего IP.

$ kubectl get svc service-test NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE openvpn 10.3.241.52 35.184.97.156 80:32213/TCP 5m

Выше сказано, что удостовериться в факте назначения внешнего IP-адреса мы сможем «вскоре», несмотря на то, что назначение внешнего IP может занять несколько минут, что неудивительно, учитывая количество ресурсов, которые нужно привести в работоспособное состояние. На платформе GCP, например, для этого нужно, чтобы система создала внешний IP-адрес, правила перенаправления трафика, целевой прокси-сервер, бэкенд-сервис, и, возможно, экземпляр группы. После выделения внешнего IP-адреса к сервису можно подключиться через этот адрес, назначить ему доменное имя и сообщить клиентам. До тех пор, пока сервис не будет уничтожен и создан повторно (для того, чтобы это сделать, редко когда находится достойный повод), IP-адрес меняться не будет.

У сервисов типа LoadBalancer есть некоторые ограничения. Такой сервис нельзя настроить на расшифровку HTTPS-трафика. Нельзя создавать виртуальные хосты или настраивать маршрутизацию, основанную на путях, поэтому нельзя, строя конфигурации, применимые на практике, использовать единственный балансировщик нагрузки со множеством сервисов. Эти ограничения привели к появлению в Kubernetes 1.1. особого ресурса, предназначенного для конфигурирования балансировщиков нагрузки. Речь идёт о ресурсе вида Ingress. Сервисы типа LoadBalancer нацелены на расширение возможностей отдельно взятого сервиса по поддержке внешних клиентов. В отличие от них, ресурсы Ingress — это особые ресурсы, которые позволяют гибко настраивать балансировщики нагрузки. API Ingress поддерживает расшифровку TLS-трафика, виртуальные хосты, маршрутизацию, основанную на путях. С помощью этого API балансировщик нагрузки легко можно настроить на работу с несколькими бэкенд-сервисами.

API ресурсов вида Ingress слишком велико для того, чтобы обсуждать тут его особенности, оно, кроме того, не особенно влияет на то, как Ingress-ресурсы работают на сетевом уровне. Реализация этого ресурса следует обычному шаблону Kubernetes: имеется тип ресурса и контроллер для управления этим типом. Ресурсом в данном случае является ресурс Ingress , описывающий запросы к сетевым ресурсам. Вот как может выглядеть описание ресурса Ingress .

apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test-ingress annotations: kubernetes.io/ingress.class: "gce" spec: tls: - secretName: my-ssl-secret rules: - host: testhost.com http: paths: - path: /* backend: serviceName: service-test servicePort: 80

Контроллер Ingress ответственен за выполнение этих запросов путём приведения в нужное состояние других ресурсов. При использовании Ingress создаются сервисы типа NodePort , после чего контроллеру Ingress позволяют принимать решения о том, как направить трафик к узлам. Существует реализация контроллера Ingress для балансировщиков нагрузки GCE, для балансировщиков AWS, для популярных прокси-серверов, таких как nginx и haproxy. Обратите внимание на то, что смешивание ресурсов Ingress и сервисов типа LoadBalancer может привести к небольшим проблемам в некоторых окружениях. С ними несложно справиться, но, в целом, лучше всего просто использовать Ingress даже для простых сервисов.

HostPort и HostNetwork

То о чём сейчас пойдёт речь, а именно, HostPort и HostNetwork , можно отнести скорее к разряду интересных редкостей, а не к полезным инструментам. На самом деле, я берусь утверждать, что в 99.99% случаев их использование можно считать анти-паттерном, и любая система, в которой они используются, должна в обязательном порядке подвергаться проверке её архитектуры.

Я думал, что о них и вовсе не стоит говорить, но они представляют собой нечто вроде тех средств, которые используются ресурсами Ingress для обработки входящего трафика, поэтому я решил, что о них стоит, хотя бы кратко, упомянуть.

Для начала поговорим о HostPort . Это — свойство контейнера (объявленное в структуре ContainerPort ). Когда в него записан некий номер порта, это приводит к открытию этого порта на узле и к его перенаправлению прямо к контейнеру. Тут нет механизмов проксирования, и порт открывается лишь на узлах, на которых выполняется контейнер. В ранние дни платформы, до появления в ней механизмов DaemonSet и StatefulSet, HostPort представлял собой хитрость, позволяющую обеспечить запуск лишь одного контейнера некоего типа на любом узле. Например, я однажды использовал это для создания Elasticsearch-кластера, установив HostPort в значение 9200 и указав столько реплик, сколько было узлов. Теперь подобный ход воспринимается как жуткий хак, и если только вы не занимаетесь реализацией системного компонента Kubernetes, вам вряд ли когда-нибудь понадобится пользоваться свойством контейнера HostPort .

Свойство пода NostNetwork , пожалуй, в контексте Kubernetes выглядит ещё более странно, чем HostPort . Если это свойство установлено в значение true , оно работает так же как аргумент — network=host команды docker run . Оно приводит к тому, что все контейнеры в поде будут использовать сетевое пространство имён узла. То есть у всех из них будет прямой доступ к интерфейсу eth0 и к открытым портам. Не думаю, что перебором будет совет никогда и ни при каких обстоятельствах этим не пользоваться. Если же вам эта возможность понадобится, то вы, весьма вероятно, занимаетесь разработкой платформы Kubernetes, и не нуждаетесь в каких-либо советах.

Итоги

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

Уважаемые читатели! Пользуетесь ли вы ресурсами Ingress?

Kubernetes: ClusterIP, NodePort или Ingress? Когда использовать каждый

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

Основы

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

Служба — это абстрактный механизм для предоставления модулей в сети. Каждой службе назначается тип — ClusterIP, NodePort или LoadBalancer. Они определяют, как внешний трафик достигает службы.

IP кластера

ClusterIP — это служба Kubernetes по умолчанию. Ваша служба будет отображаться на ClusterIP, если вы вручную не определите другой тип.

ClusterIP обеспечивает сетевое подключение внутри вашего кластера. Обычно к нему нельзя получить доступ извне. Вы используете эти службы для внутреннего сетевого взаимодействия между вашими рабочими нагрузками.

Этот пример манифеста определяет службу ClusterIP. Трафик на порт 80 на ClusterIP будет перенаправлен на порт 80 ваших модулей ( targetPort ). В сервис будут добавлены модули с полем метаданных app: my-app .

Вы можете увидеть назначенный IP-адрес, запустив kubectl get services . Другие рабочие нагрузки в вашем кластере могут использовать этот IP-адрес для взаимодействия с вашей службой.

Вы можете вручную установить ClusterIP на определенный IP-адрес, используя поле spec.clusterIp :

Значение clusterIp должно быть действительным IP-адресом в пределах диапазона, настроенного для вашего кластера. Это определяется настройкой service-cluster-ip-range на сервере API Kubernetes.

NodePort

NodePort публично предоставляет услугу на фиксированном номере порта. Это позволяет вам получить доступ к сервису из-за пределов вашего кластера. Вам потребуется использовать IP-адрес кластера и номер NodePort , например 123.123.123.123:30000 .

Создание NodePort откроет этот порт на каждом узле в вашем кластере. Kubernetes автоматически направит трафик порта на службу, с которой он связан.

Вот пример манифеста службы NodePort:

Определения NodePort имеют те же обязательные свойства, что и службы ClusterIP. Единственное отличие заключается в изменении на type: NodePort . Поле targetPort по-прежнему необходимо, так как порты NodePort поддерживаются службой ClusterIP.

Применение приведенного выше манифеста назначит вашему NodePort случайный номер порта из диапазона, доступного для Kubernetes. Обычно по умолчанию это порты 30000-32767. Вы можете указать порт вручную, задав поле ports.nodePort :

Это направит трафик с порта 32000 на порт 80 в ваших модулях.

NodePorts не всегда идеально подходят для общедоступных сервисов. Они используют нестандартные порты, которые не подходят для большей части HTTP-трафика. Вы можете использовать NodePort для быстрой настройки службы для разработки или предоставления службы TCP или UDP на ее собственном порту. При обслуживании пользователей в производственной среде вместо этого вы захотите использовать альтернативу.

Вход

Ingress на самом деле является совершенно другим ресурсом для службы. Обычно вы используете входы перед вашими службами для обеспечения конфигурации маршрутизации HTTP. Они позволяют настраивать внешние URL-адреса, виртуальные хосты на основе домена, SSL и балансировку нагрузки.

Для настройки Ingress требуется, чтобы в вашем кластере существовал Ingress Controller. Доступен широкий выбор контроллеров. У большинства крупных облачных провайдеров есть собственный Ingress Controller, который интегрируется с их инфраструктурой балансировки нагрузки. nginx-ingress — это популярный автономный вариант, использующий веб-сервер NGINX в качестве обратного прокси-сервера для получения трафика к вашим службам.

Вы создаете Ingress, используя тип ресурса Ingress . Аннотация kubernetes.io/ingress.class позволяет указать, какой тип Ingress вы создаете. Это полезно, если вы используете несколько контроллеров кластера.

Этот манифест определяет две конечные точки Ingress. Первое правило host направляет трафик example.com на порт 80 в службе my-service . Второе правило настраивает another-example.com для сопоставления с модулями, которые являются частью second-service .

Вы можете настроить SSL, задав поле tls в spec Ingress:

Для этого вам понадобится эмитент, например Cert Manager, в вашем кластере. Эмитент получит SSL-сертификаты для ваших доменов при создании Ingress.

Входы следует использовать, когда вы хотите обрабатывать трафик из нескольких доменов и URL-адресов. Вы настраиваете свои конечные точки с помощью декларативных операторов. Контроллер Ingress предоставит ваши маршруты и сопоставит их с сервисами.

Балансировщики нагрузки

Последний тип службы — LoadBalancer. Эти сервисы автоматически интегрируются с балансировщиками нагрузки, предоставляемыми общедоступными облачными средами. Вам нужно будет настроить собственный балансировщик нагрузки, если вы самостоятельно размещаете свой кластер.

Балансировщики нагрузки используются для сопоставления внешних IP-адресов со службами в вашем кластере. В отличие от Ingress, здесь нет автоматической фильтрации или маршрутизации. Трафик на внешний IP и порт будет направляться прямо на ваш сервис. Это означает, что они подходят для всех типов трафика.

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

Манифесты балансировщика нагрузки похожи на другие типы служб. Трафик на указанный вами port балансировщика нагрузки будет приниматься через targetPort в ваших модулях.

Ваша облачная среда создаст новый балансировщик нагрузки для обработки вашего трафика. Некоторые провайдеры позволяют запрашивать определенный внешний IP-адрес с помощью поля spec.loadBalancerIP . Вы получите случайный IP-адрес, если он не поддерживается.

Заключение

ClusterIPs, NodePorts, Ingresses и Load Balancers направляют внешний трафик к службам в вашем кластере. Каждый из них предназначен для различных вариантов использования. Некоторые из ваших сервисов будут иметь наибольший смысл с NodePort, в то время как другим потребуется Ingress, обычно когда вы хотите предоставить URL-адрес.

Все четыре варианта работают в тандеме с более широкой концепцией «сервис». Они являются привратниками, которые обеспечивают сетевой доступ к вашим услугам. Затем эти сервисы выполняют последний прыжок в ваши модули. Два уровня абстракции полностью отделяют маршрутизацию от ваших рабочих нагрузок: ваши модули просто предоставляют порты, которые сервисы делают общедоступными.

Все права защищены. © Linux-Console.net • 2019-2023