Service, Endpoints і DNS

Після модуля ви зможете пояснити стабільну адресацію Service поверх змінних Pod IP, пов’язати selector з EndpointSlice, використовувати кластерний DNS і діагностувати ситуацію, коли ім’я вирішується, але трафік не доходить до backend.

• Service та його типи
• selector і EndpointSlice
• DNS-імена між namespaces
• діагностика від клієнта до Pod

Кожен Pod отримує власний IP і доступний через кластерну мережу, але Pod є одноразовим: після заміни IP може змінитися. Service відокремлює клієнтів від змінного набору backend Pods і надає стабільний virtual IP та DNS name.

Контейнери одного Pod використовують localhost. Між Pods трафік іде через pod network, а звернення до Service обробляє service proxy — kube-proxy або реалізація мережевого плагіна.

Selector Service обирає Pods за labels. port — порт Service для клієнта, targetPort — порт або ім’я порту контейнера. Іменований targetPort дає змогу змінити номер порту backend без зміни клієнта.

• ClusterIP доступний усередині кластера та є типовим
• NodePort публікує порт на Nodes і зазвичай є будівельним блоком
• LoadBalancer запитує зовнішній балансувальник у підтримуваної інфраструктури
• ExternalName повертає DNS CNAME і не створює proxy backend
• headless Service з clusterIP: None повертає адреси endpoints напряму

Control Plane створює EndpointSlices для Service з selector і включає відповідні backend endpoints. Використовуйте EndpointSlice API: застарілий Endpoints API має обмеження й не є правильною основою для нових інструментів.

CoreDNS створює записи Service. У тому самому namespace достатньо web; з іншого використовуйте web.lab-network, повне ім’я — web.lab-network.svc.cluster.local. Успішний DNS lookup не гарантує наявності готових endpoints.

• Діагностуйте з Pod-клієнта, а не з хоста
• Розділяйте DNS resolution, Service VIP, EndpointSlice і доступність Pod
• Порівнюйте Service selector з фактичними Pod labels
• Перевіряйте port, targetPort, protocol та readiness endpoints
• Не використовуйте Pod IP як постійну адресу застосунку
• Для доступу ззовні обирайте LoadBalancer, Gateway або Ingress усвідомлено

Збережіть багатооб’єктний маніфест як service-lab.yaml. Він створює namespace, три nginx Pods і ClusterIP Service з коректним selector.

apiVersion: v1
kind: Namespace
metadata:
  name: lab-network
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: lab-network
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: web
  template:
    metadata:
      labels:
        app.kubernetes.io/name: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.29-alpine
          ports:
            - name: http
              containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 3
---
apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: lab-network
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: web
  ports:
    - name: http
      port: 80
      targetPort: http

Застосуйте маніфест, дослідіть EndpointSlice та виконайте запити з окремого клієнтського Pod за коротким і повним DNS-іменем.

kubectl apply -f service-lab.yaml
kubectl rollout status deployment/web -n lab-network --timeout=120s
kubectl get service web -n lab-network
kubectl get endpointslices -n lab-network -l kubernetes.io/service-name=web -o wide
kubectl run client -n lab-network --image=busybox:1.37.0 --restart=Never -- sleep 3600
kubectl wait -n lab-network --for=condition=Ready pod/client --timeout=120s
kubectl exec -n lab-network client -- nslookup web
kubectl exec -n lab-network client -- nslookup web.lab-network.svc.cluster.local
kubectl exec -n lab-network client -- wget -qO- http://web
kubectl exec -n lab-network client -- cat /etc/resolv.conf

Критерій: Service має ClusterIP, EndpointSlice містить три ready endpoint, обидва DNS-імені вирішуються, HTTP повертає сторінку nginx.

Навмисно зламайте selector Service. DNS продовжить вирішувати ім’я і ClusterIP збережеться, але EndpointSlice не матиме відповідних endpoints, тому HTTP-запит не виконається.

kubectl patch service web -n lab-network --type=merge -p '{"spec":{"selector":{"app.kubernetes.io/name":"missing"}}}'
kubectl get service web -n lab-network -o yaml
kubectl get pods -n lab-network --show-labels
kubectl get endpointslices -n lab-network -l kubernetes.io/service-name=web -o yaml
kubectl exec -n lab-network client -- nslookup web
kubectl exec -n lab-network client -- wget -T 3 -qO- http://web
kubectl patch service web -n lab-network --type=merge -p '{"spec":{"selector":{"app.kubernetes.io/name":"web"}}}'
kubectl wait -n lab-network --for=jsonpath='{.endpoints[0].conditions.ready}'=true endpointslice -l kubernetes.io/service-name=web --timeout=60s
kubectl exec -n lab-network client -- wget -qO- http://web
kubectl delete namespace lab-network

Алгоритм: перевірити Service і ports → зіставити selector з Pod labels → дослідити EndpointSlices і readiness → за потреби звернутися до Pod IP → виправити мінімальне поле.

Якщо не вирішується навіть kubernetes.default, дослідіть resolv.conf клієнта, Service та EndpointSlices kube-dns, потім Pods і логи CoreDNS.

kubectl exec -n lab-network client -- nslookup kubernetes.default
kubectl get service kube-dns -n kube-system
kubectl get endpointslices -n kube-system -l kubernetes.io/service-name=kube-dns
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=50

Якщо kubernetes.default вирішується, а web ні, проблема зазвичай в імені, namespace або об’єкті Service, а не в роботі CoreDNS загалом.

• Чому Service переживає заміну Pod?
• Чим port відрізняється від targetPort?
• Чому DNS може працювати за порожнього EndpointSlice?
• Коли headless Service корисніший за ClusterIP?
• З якого шару починати діагностику з іншого namespace?

Модуль засвоєно, якщо ви простежуєте шлях DNS → ClusterIP → EndpointSlice → ready Pod, знаходите невідповідність selector і labels та відновлюєте доступ без повторного створення workload.