Это старая версия документа!
Для доступа к поду (наборам подов) используются сервисы (service). Service - абстракция, определяющая набор подов и политику доступа к ним. Так же берет на себя вопрос распределения нагрузки
При определении сервиса нужно указать селектор, определяющий выбор набора подов. Сервисы без селектора, обычно используются для обращения во вне кластера, там ендпоинт создается вручную
apiVersion: v1 kind Service metadata: name: service-my-pods spec: selector: app: my-pods ports: - protocol: TCP port: 80 targetPort: 8080
Шлет входящие запросы на поды с указанным селектором. В качестве targetPort можно использовать имена портов, если они определены в подах, это дает большую гибкость т.к. могут быть разные
Если targetPort (порт назначения) не указать то по умолчанию используется тот же что и port (входящий)
Создается сервис, присваивается IP и куб добавляет его в DNS, после чего к сервису можно обращаться по имени, к том же NS: «http://service-my-pods», если из другого то нужно указать NS: «service-my-pods.namespace.svc»
В деплойменте должен быть прописан порт, чтобы контейнер мог принимать на нем запросы, в т.ч от сервиса собсна
Стратегия распределения запросов между подами, по умолчанию «round robin»
apiVersion: v1 kind: Service metadata: name: tomcat-main spec: selector: app: tomcat ports: - protocol: TCP port: 80 targetPort: tomcat
apiVersion: apps/v1 kind: Deployment metadata: name: tomcat-deployment spec: replicas: 2 selector: matchLabels: app: tomcat template: metadata: labels: app: tomcat spec: containers: - name: tomcat image: tomcat:10-jdk15 ports: - containerPort: 8080 name: tomcat protocol: TCP
Пару примеров как смотреть в консоли
kubectl get pods -o wide kubectl get svc -o wide # Так виден назначенный IP kubectl get svc <my-service> -o yaml
kubectl get ep
В случае сервисов использующих селекторы, ендпоинты создаются автоматом, система сама находит IP нужных подов и формирует запись в endpoint
Под капотом происходит по сути NAT преобразование, этим заведует kube-proxy
EndpointSlice - это просто разбиение объектов на части, для практичности размеров записей, происходит автоматически
По сути сервис без указания (создания) своего IP, так он напрямую ссылается на IP пода (подов, через запятую). В таком варианте отсутствует NAT преобразование, но так же отсутствует и балансировка. В случае какой то специфики, может пригодится
Для прода не рекомендуется, но для тестов можно чикнуть
apiVersion: v1 kind: Service metadata: name: service-front namespace: my-namespace spec: selector: app: my-front ports: - protocol: TCP port: 3000
На всех нодах открывается рандомный порт, по IP ноды и этому порту, будет доступен сервис. Порт виден в oc describe svc/my-service (NodePort)
Ingress - ресурс k8s где создается описание конфигурации Ingress Controller
Ingress Controller - обрабатывает трафик, его конфигурация формируется из всех Ingress объектов внутри кластера
Вместе создают единую точку входа для трафика и выполняют роль прокси и балансировщика (?)
Ingress Controller можно реализовать на разных платформах, из самых популярных это nginx и haproxy
Ingress работает на 7ом (прикладном) уровне OSI, для работы на третьем (сетевом) можно использовать другие методы публикации приложений:
Внутри Ingress Controller обычный Nginx, поэтому можно настроить распределение запросов по доменам или location
Revers proxy в Ingress Controller слушает порты с HTTP/HTTPS-соединениями, трафик может попадать на порты тремя способами:
NodePort
Непонятно, похоже что нужен «LoadBalancer» т.к. в URL нужно включать порт что пробросился ин ноды
HostPort
Открываются порты (вроде как на всех нодах), надо настраивать DNS, с перечислением всех нод
Host Network
тут вообще борода