K8s Q A Services
Services
Общая информация
Поды в кластере Kubernetes смертны - они создаются (рождаются), но когда под по какой-либо причине умирает, то он не воскресает. И хотя каждый под при создании получает свой собственный IP-адрес, этот адрес нельзя назвать постоянным и стабильным вследствие “смертности” подов.
К примеру, ReplicaSet может динамически изменять количество подов в кластере (путем масштабирования), при этом новые поды могут быть запущены на других узлах (нодах) кластера - в этом случае IP-адрес пода наверняка изменится.
Это порождает проблему: если некий набор подов (назовем их backends) предоставляют функционал другому набору подов (назовем их frontends) внутри кластера Kubernetes, то как frontend-поды узнают адреса backend-подов и взаимодействуют с ними?
Сервис в Kubernetes - это абстракция, определяющая логический набор подов и политику доступа к ним (иногда такой набор подов еще называют микросервисом). Как правило, этот набор подов определяется на основе меток (присваиваются в момент создания подов) и селекторов.
Например, backend - это 3 реплики подов, занимающихся обработкой изображений. Все три пода абсолютно идентичны с функциональной точки зрения (так как это реплики), поэтому frontend не должен беспокоиться на какой именно backend-под попадет запрос - это работа сервиса.
Простейший пример сервиса может выглядеть так:
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
Согласно данной спецификации, будет создан объект “сервис” (service) с именем my-service, перенаправляющий запросы на порт 9376 каждого пода, у которого присутствует метка app=MyApp. Этому сервису также будет назначен отдельный IP-адрес.
Согласно указанному селектору, в кластере непрерывно будут проверяться поды на наличие метки app=MyApp, а результат такой проверки будет публиковаться (с помощью POST) в объект Endpoints с таким же именем - my-service.
Стоит отметить, что сервис может сопоставлять входящий порт (port:) с любым портом назначения (targetPort:).
Если параметр targetPort не указан, то по умолчанию будет использоваться тот же порт, что и в параметре port.
Еще одна интересная особенность - targetPort может содержать строку с именем порта в подах (а сам номер порта, присвоенный этому имени, может быть разным для каждого пода).
Сервисы чаще всего используются для доступа к подам в кластере Kubernetes, но их также можно использовать и для доступа к другим типам бэкендов, например:
- внешний кластер баз данных в production-окружении, локальная БД для тестового окружения; (КАК?)
- совершенно иной сервис в другом неймспейсе или кластере;
- часть бекендов, запущенных вне кластера Kubernetes (например, если вы только переносите свою инфраструктуру). (КАК?)
В любом из предложенных вариантов следует создать сервис без селекторов, например:
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9376
и, так как селекторов нет, соотвествующий объект Endpoints не создастся автоматически. Его необходимо создать вручную, тем самым указав связь между сервисом и конечной точкой (бекендом), например так:
kind: Endpoints
apiVersion: v1
metadata:
name: my-service
subsets:
- addresses:
- ip: 1.2.3.4
ports:
- port: 9376
Примечание. IP-адрес в данном случае не может находиться в диапазонах 127.0.0.0/8, 169.254.0.0/16 и 224.0.0.0/24.
Для многих сервисов обычным делом является использование (открытие) нескольких портов. В таком случае, все что необходимо - присвоить имена всем портам, например:
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
- name: https
protocol: TCP
port: 443
targetPort: 9377
В Kubernetes существует несколько вариантов предоставления доступа к сервисам, которые называются типы (ServiceTypes):
Типы Сервисов
(ТУТ НАДО ПОДРОБНЕЕ!!!!!!!)
ClusterIP
предоставляет доступ к сервису на внутреннем IP-адресе кластера (сервис доступен только внутри кластера). Тип ClusterIP используется по умолчанию;
Под капотом для каждого такого сервиса создаются правила в iptables которые и перенаправляют трафик - например (случайный сервис с живого кластера)
kubectl get svc -A -o wide --show-labels | grep tungstenfabric-operator-metrics NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR LABELS tf tungstenfabric-operator-metrics ClusterIP 10.232.100.45 <none> 8383/TCP 222d name=tungstenfabric-operator app.kubernetes.io/managed-by=Helm
Тут видно что
- ClusterIP 10.232.100.45
kubectl -n tf get endpoints tungstenfabric-operator-metrics NAME ENDPOINTS AGE tungstenfabric-operator-metrics 192.168.107.224:8383 222d
- 192.168.107.224 - адрес единственного POD
kubectl get pod -A -o wide | grep 192.168.107.224 tf tungstenfabric-operator-66b776cc76-c5xvt 2/2 Running 2 (24d ago) 37d 192.168.107.224 k8s-control-1 <none> <none>
Этот под запущен на ноде k8s-control-1
На любой произвольной ноде можно видеть (iptables-save показывает правила из всех таблиц, в том числе nat, а не только filter)
iptables-save | grep 10.232.100.45 -A KUBE-SERVICES -d 10.232.100.45/32 -p tcp -m comment --comment "tf/tungstenfabric-operator-metrics cluster IP" -m tcp --dport 8383 -j KUBE-SVC-I663JZWESJMFGRNU -A KUBE-SVC-I663JZWESJMFGRNU ! -s 192.168.104.0/21 -d 10.232.100.45/32 -p tcp -m comment --comment "tf/tungstenfabric-operator-metrics cluster IP" -m tcp --dport 8383 -j KUBE-MARK-MASQ
- -j KUBE-SVC-I663JZWESJMFGRNU - трафик перенаправлен в эту цепочку (-j ==jump)
iptables -t nat -nL KUBE-SVC-I663JZWESJMFGRNU -xv | column -t Chain KUBE-SVC-I663JZWESJMFGRNU (1 references) pkts bytes target prot opt in out source destination 2 120 KUBE-MARK-MASQ tcp -- * * !192.168.104.0/21 10.232.100.45 /* tf/tungstenfabric-operator-metrics cluster IP */ tcp dpt:8383 2 120 KUBE-SEP-NGQNQI7MJHBZTPB6 all -- * * 0.0.0.0/0 0.0.0.0/0 /* tf/tungstenfabric-operator-metrics -> 192.168.107.224:8383 */
(про маркировку пакетов - ctmark = (ctmark AND NOT mask) XOR value )
https://itecnote.com/tecnote/linux-some-questions-about-set-xmark-in-iptables/
Проверить цепочку KUBE-SEP-NGQNQI7MJHBZTPB6
iptables -t nat -nL KUBE-SEP-NGQNQI7MJHBZTPB6 -xv | column -t Chain KUBE-SEP-NGQNQI7MJHBZTPB6 (1 references) pkts bytes target prot opt in out source destination 0 0 KUBE-MARK-MASQ all -- * * 192.168.107.224 0.0.0.0/0 /* tf/tungstenfabric-operator-metrics */ 1 60 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 /* tf/tungstenfabric-operator-metrics */ tcp to:192.168.107.224:8383
В конце видим DNAT на адрес пода 192.168.107.224
NodePort
предоставляет доступ к сервису на IP-адресе каждого узла (ноды) кластера, на статическом порту (из диапазона 30000-32767). Автоматически создастся и сервис типа ClusterIP, на который будут маршрутизироваться запросы с NodePort. Взаимодействовать с сервисом можно также из-за пределов кластера, используя в качестве адреса <NodeIP>:<NodePort>;
LoadBalancer
предоставляет доступ к сервису используя балансировщик (load balancer) облачного провайдера. При этом автоматически создаются сервисы типа NodePort и ClusterIP, на которые будут маршрутизироваться запросы с балансировщика;
ExternalName
особый случай - сопоставляет имя сервиса с содержимым поля externalName (например, foo.bar.example.com), возвращая CNAME запись. Никакого проксирования не происходит. (А через какой резолвер идет резолв?????)
Headless
Headless-сервис: это сервис, который не использует отдельный IP-адрес для маршрутизации запросов (ClusterIP: None). В этом случае под DNS-именем сервиса видны IP всех Pod, которые в этот сервис входят.
Headless-сервисы полезны, когда приложение само должно управлять тем, к какому Pod подключаться, например:
- mongodb-клиент использует IP сервера, с которым он работает, для того, чтобы запросы для одного курсора шли на один хост (курсор «живёт» на mongos). В случае использования ClusterIP могут «теряться» курсоры даже для коротких запросов.
- gRPC-клиенты держат по одному соединению с сервисами и сами управляют запросами, мультиплексируя запросы к одному серверу. В случае использования ClusterIP клиент может создать одно подключение и нагружать ровно один Pod сервера.
О проблемах можно читать тут: https://habr.com/ru/companies/joom/articles/563310/
Service и Endpoint - чуть подробнее
Еще одна интересная заметка которую я утащил сюда https://medium.com/@zzeett694/kubernetes-endpoints-9e3ee398c896
Как взаимодействуют сервисы и поды
Сервисы(services) кубрнетаса не взаимодействуют с Pod напрямую, помимо самого сервиса кубернетес создает так же абстракцию Endpoints которая является промежуточной в цепочке взаимодействия. Цепочка событий выглядит так:
Service -> Endpoints -> Pod
Для наглядности создадим один pod с простым web сервером возвращающим hostname pod-a и сервис с типом ClusterIP который с ним взаимодействует: Создание Deployment и сервиса для общения с ним
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: simple-web-app
image: zet694/simple-web-app
resources:
limits:
memory: "128Mi"
cpu: "500m"
ports:
- name: http
containerPort: 8888
---
apiVersion: v1
kind: Service
metadata:
name: mysvc
spec:
selector:
app: myapp
ports:
- port: 80
targetPort: http
Исследуем наш сервис:
$ kubectl describe svc mysvc Name: mysvc Namespace: default Labels: <none> Annotations: <none> Selector: app=myapp Type: ClusterIP IP Family Policy: SingleStack IP Families: IPv4 IP: 10.101.248.27 IPs: 10.101.248.27 LoadBalancer Ingress: localhost Port: <unset> 80/TCP TargetPort: http/TCP Endpoints: 10.1.1.99:8888 Session Affinity: None Events: <none>
Значение поля endpoints содержит внутренний ip нашего единственного Pod который был выбран через селектор указанный в сервисе. Проверим это путем масштабирования количества Pod-ов до 3 экземпляров для этого используем команду:
$ kubectl scale deployment myapp --replicas=3 deployment.apps/myapp scaled
Теперь убедимся что колличество endpoints изменилось до 3 IP адрессов (ровно столько сколко Pod содержат label соотвествующий указаному в селекторе нашего сервиса):
$ kubectl describe svc mysvc Name: mysvc Namespace: default Labels: <none> Annotations: <none> Selector: app=myapp Type: ClusterIP IP Family Policy: SingleStack IP Families: IPv4 IP: 10.101.248.27 IPs: 10.101.248.27 LoadBalancer Ingress: localhost Port: <unset> 80/TCP TargetPort: http/TCP Endpoints: 10.1.1.102:8888,10.1.1.103:8888,10.1.1.99:8888 Session Affinity: None Events: <none>
Видим что количество Endpoints соответствует количеству Pod-ов, теперь убедимся что это действительно IP наших Pod-ов:
Проверяем внутренний IP наших Pod-ов
Вывод опущен - лень копировать картинку
Из вывода понятно что IP адреса Pod-ов совпадают с теми что указаны в Endpoints.Ресурс Endpoints является списком IP адрессов и портов предоставляющий доступ к службе, взаимодействовать с ним можно посредствам уже знакомых нам команд:
$ kubectl get endpoints NAME ENDPOINTS AGE mysvc 10.1.1.102:8888,10.1.1.103:8888,10.1.1.99:8888 48m
Из всего сказанного можно сделать вывод что при создании сервиса так же создается endpoints который автоматически добавляет и удаляет IP-адреса “подов” по меткам указанным в родительском сервисе.
Service без Selector
В случае если вы создаете сервис без указания селектора(selector) по которому должны будут обнаружены нужные поды, абстракция endpoint не создается так как кубернетес не знает куда направлять ваши запросы из сервиса, вы должны сами создать endpoints указав перечень необходимых IP адресов.
Внимание! Имя сервиса и имя endpoints должны совпадать.
Создадим сервис без указания selectors:
apiVersion: v1
kind: Service
metadata:
name: mysvc-without-selector
spec:
ports:
- port: 80
targetPort: http
Убедимся что сервис создан и не имеет endpoints:
$ kubectl describe svc mysvc-without-selector Name: mysvc-without-selector Namespace: default Labels: <none> Annotations: <none> Selector: <none> Type: ClusterIP IP Family Policy: SingleStack IP Families: IPv4 IP: 10.110.204.181 IPs: 10.110.204.181 Port: <unset> 80/TCP TargetPort: http/TCP Endpoints: <none> Session Affinity: None Events: <none>
Теперь создадим endpoints с тем же именем что и наш сервис:
apiVersion: v1
kind: Endpoints
metadata:
name: mysvc-without-selector
subsets:
- addresses:
- ip: 185.199.110.153
- ip: 77.88.55.80
ports:
- port: 80
Правила создания Endpoint:
- Имя Endpoints и Service должны совпадать.
- Должен быть указан один или более IP.
- Должен быть указан порт.
Таким образом мы можем создать сервис с теми endpoints которые необходимы нам, например для взаимодействия с ресурсами который находятся за пределами кластера.
Все запросы будут балансировать между указанным списком IP.
Если вам необходимо использовать существующий сервис для взаимодействия с ресурсами за пределами кластера — удалите селектор и создайте endpoints с тем же именем.
Если точка назначения находится внутри вашего кластера, просто создайте селектор внутри службы и кубернетес будет автоматически определять IP. Главным преимуществом является то что адрес сервиса внутри приложения остается неизменным, но конечный пункт назначения вынесен на уровень инфрастуктуры.
Использование сервиса для внешних ресурсов
Указанный выше пример для использования сервиса как точку обмена с внешними сервисами имеющими DNS имя не рекомендуется использовать, существует более простой и понятный способ — ExternalName. Для этого достаточно создать сервис с типом ExternalName, указав в его поле DNS имя необходимого внешнего сервиса и порт. Вот небольшой пример:
Пример ExternalName сервиса
apiVersion: v1 kind: Service metadata: name: external-svc spec: type: ExternalName externalName: neverssl.com ports: - port: 80
Обрататите внимание что ExternalName сервис:
- Реализуются исключительно на DNS уровне (создается CNAME запись).
- Не имеет внутреннего IP.
- Подключение к внешней службе происходит в обход внутреннего прокси.
- CNAME указывает на полное имя, вместо IP адреса.
