Обнаружение службы Kubernetes с определенной конечной точкой (DNS)

Question

Я использую кластер AKS в Azure. Я пытаюсь обнаружить службу с использованием DNS (http://my -api.default.svc.cluster.local: 3000 / ), но она не работает (недоступен этот сайт). С конечной точкой службы IP все работает нормально.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-api
  labels:
    app: my-api
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-api
  template:
    metadata:
      labels:
    app: my-api
    spec:
      containers:
      - name: my-api
    image: test.azurecr.io/my-api:latest
    ports:
    - containerPort: 3000
      imagePullSecrets:
      - name: testsecret
---
apiVersion: v1
kind: Service
metadata:
  name: my-api
spec:
  selector:
    app: my-api
  ports:
  - protocol: TCP
    port: 3000
    targetPort: 3000

kubectl описать сервисы kube-dns - namespace kube-system

Name:              kube-dns
Namespace:         kube-system
Labels:            addonmanager.kubernetes.io/mode=Reconcile
               k8s-app=kube-dns
               kubernetes.io/cluster-service=true
               kubernetes.io/name=KubeDNS
Annotations:       kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"addonmanager.kubernetes.io/mode":"Reconcile","k8s-app":"kube-dns","kubernet...
Selector:          k8s-app=kube-dns
Type:              ClusterIP
IP:                10.10.110.110
Port:              dns  53/UDP
TargetPort:        53/UDP
Endpoints:         10.10.100.54:53,10.10.100.64:53
Port:              dns-tcp  53/TCP
TargetPort:        53/TCP
Endpoints:         10.10.100.54:53,10.10.100.64:53
Session Affinity:  None
Events:            <none>

kubectl описать svc my-api

Name:              my-api
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"my-api","namespace":"default"},"spec":{"ports":[{"port":3000,"protocol":...
Selector:          app=my-api
Type:              ClusterIP
IP:                10.10.110.104
Port:              <unset>  3000/TCP
TargetPort:        3000/TCP
Endpoints:         10.10.100.42:3000
Session Affinity:  None
Events:            <none>

Из второго POD

kubectl exec -it second-pod /bin/bash
curl my-api.default.svc.cluster.local:3000
Response: {"value":"Hello world2"}

Со второго сайта POD работает веб-сайт, который использует ту же конечную точку, но не подключается к услуге.

Answer 1

Исправив отступ в вашем файле yaml, я смог успешно запустить развертывание и обслуживание. Также разрешение DNS работало нормально.

Отличия:

• Фиксированный отступ
• Используется test1 пространства имен вместо default
• Используется контейнерПорт 80 вместо 3000
• использовал мое изображение

Развертывание:

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  labels:
    app: my-api
  name: my-api
  namespace: test1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-api
  template:
    metadata:
      labels:
        app: my-api
    spec:
      containers:
      - image: leodotcloud/swiss-army-knife
        name: my-api
        ports:
        - containerPort: 80
          protocol: TCP

Услуги:

apiVersion: v1
kind: Service
metadata:
  name: my-api
  namespace: test1
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 80
  selector:
    app: my-api
  type: ClusterIP

Шаги отладки:

• Установите tcpdump внутри обоих контейнеров kube-dns и начните захват трафика DNS (с фильтрами из IP-адреса второго модуля)
• Внутри второго модуля введите команду curl или dig, используя полное доменное имя.
• Проверьте, достигают ли пакеты DNS-запросов контейнеров kube-dns.
• Если нет, проверьте наличие проблем с сетью.
• Если разрешение DNS работает, запустите tcpdump внутри контейнера приложения и проверьте, достигает ли пакет curl пакета.
• Проверьте исходный и целевой IP-адрес пакетов.
• Проверьте правила iptables на хостах.
• Проверьте настройки sysctl.

Answer 2

Из приведенного выше обсуждения я понял, что вы хотите предоставить сервис, но не использовать IP-адрес. Сервис может быть выставлен разными способами. вам следует искать тип сервиса LoadBalancer.

Попробуйте изменить ваш сервис следующим образом:

apiVersion: v1
kind: Service
metadata:
  name: my-api
spec:
  type: LoadBalancer
  selector:
    app: my-api
  ports:
  - protocol: TCP
    port: 3000
    targetPort: 3000

Это создаст балансировщик нагрузки и отобразит ваш сервис на тот же.

Позже вы можете добавить этот loadbalancer в службу сопоставления DNS, предоставляемую Azure, чтобы дать доменное имя, которое вам нравится. например: http:\\my-api.example.com:3000

Также я хотел бы добавить, если вы определите свои порты следующим образом:

ports:
  - name: http
    port: 80
    targetPort: 3000

Это перенаправит трафик, поступающий на порт 80, на 3000, и ваш сервисный вызов будет выглядеть намного чище, например. http:\\my-api.example.com

Answer 3

Если вы используете Deployment для развертывания приложения в кластере, где оно будет использоваться через Service, вам вообще не нужно будет вручную устанавливать Endpoints. Просто положитесь на kubernetes и определите обычный селектор в вашем Service объекте.

Кроме того, когда это имеет смысл (внешняя служба используется внутри кластера), вам необходимо убедиться, что ваше определение портов Endpoints полностью соответствует определению на службе (включая протокол и, возможно, имя). Это неполное сопоставление является наиболее распространенной причиной того, что конечные точки не отображаются как часть службы.