Разрешение IP-адреса модуля по имени

Question

Прежде всего, заявление об отказе от ответственности: я уже некоторое время использую среду Azure Kubernetes, поэтому я извиняюсь за вопрос, что может быть легкой проблемой.

У меня есть две службы Kubernetes, работающие в AKS.Я хочу, чтобы эти службы могли обнаруживать друг друга по имени службы.Каждому из модулей, связанных с этими службами, присваивается IP-адрес из подсети, которую я назначил моему кластеру:

$ kubectl get pods -o wide
NAME      READY   STATUS    RESTARTS   AGE   IP         ...
tom       1/1     Running   0          69m   10.0.2.10  ...
jerry     1/1     Running   5          67m   10.0.2.21  ...

Если я выполняю вызовы REST между этими службами, используя их IP-адреса модулей, вызовы работают должным образом,Я не хочу, конечно, использовать жестко закодированные IP-адреса.При чтении на Kube DNS я понимаю, что записи для зарегистрированных служб создаются в DNS.Тесты, которые я сделал, подтверждают это, но IP-адреса, назначенные записям DNS, не являются IP-адресами модулей.Например:

$ kubectl exec jerry -- ping -c 1 tom.default
PING tom.default (10.1.0.246): 56 data bytes

IP-адрес, связанный с томом службы, представляет собой так называемый «ip кластера»:

$ kubectl get services
NAME   TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
tom    ClusterIP   10.1.0.246   <none>        6010/TCP   21m
jerry  ClusterIP   10.1.0.247   <none>        6040/TCP   20m

То же самое верно и для службы jerry.Проблема с этими IP-адресами состоит в том, что вызовы REST, использующие эти адреса, не работают.Даже простой пинг истекает.Поэтому мой вопрос заключается в том, как связать запись kube-dns, созданную для службы, с IP-адресом модуля вместо IP-адреса кластера?

На основании опубликованного ответа я обновил свой файл yml для "tom" какследует:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: tom
spec:
  template:
    metadata:
      labels:
        app: tom
    spec:
      containers:
      - name: tom
        image: myregistry.azurecr.io/tom:latest
        imagePullPolicy: Always
        ports:
          - containerPort: 6010
---
  apiVersion: v1
  kind: Service
  metadata:
    name: tom
  spec:
    ports:
    - port: 6010
      name: "6010"
    selector:
      app: tom

, а затем повторно применил обновление.Я все еще получаю IP-адрес кластера, хотя при попытке разрешить tom.default, а не IP-адрес модуля.Мне все еще не хватает части головоломки.

Обновление: По запросу, вот выход описания для tom:

$ kubectl describe service tom
Name:              tom
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"tom","namespace":"default"},"spec":{"ports":[{"name":"6010","po...
Selector:          app=tom
Type:              ClusterIP
IP:                10.1.0.139
Port:              6010  6010/TCP
TargetPort:        6010/TCP
Endpoints:         10.0.2.10:6010

Вывод аналогичен для службы jerry.Как вы можете видеть, конечная точка - это то, что я ожидаю - 10.0.2.10 - это IP, назначенный модулю, связанному с сервисом Tom.Однако Kube DNS разрешает имя «tom» в качестве IP-адреса кластера, а не IP-адреса модуля:

$ kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE   IP ...
tom-b4ccbfb97-wfmjp     1/1     Running   0          15h   10.0.2.10
jerry-dd8fbf98f-8jgw7   1/1     Running   0          14h   10.0.2.20

$ kubectl exec jerry-dd8fbf98f-8jgw7 nslookup tom
Name:      tom
Address 1: 10.1.0.139 tom.default.svc.cluster.local

Конечно, это не имеет значения, если вызовы REST направляются на ожидаемый IP-адрес модуля.Сегодня у меня был некоторый успех:

$ kubectl exec jerry-5554b956b-9kpj7 -- wget -O - http://tom:6010/actuator/health
{"status":"UP"}

Это показывает, что, хотя имя "том" разрешает IP-адрес кластера, существует маршрутизация, которая гарантирует, что вызов поступит в модуль.Я попробовал тот же звонок от службы Тома к службе Джерри, и это тоже работает.Любопытно, что время ожидания петли от тома к тому истекает:

$ kubectl exec tom-5c68d66cf9-dxlmf -- wget -O - http://tom:6010/actuator/health
Connecting to tom:6010 (10.1.0.139:6010)
wget: can't connect to remote host (10.1.0.139): Operation timed out
command terminated with exit code 1

Если я использую IP-адрес модуля, вызов работает:

$ kubectl exec tom-5c68d66cf9-dxlmf -- wget -O - http://10.0.2.10:6010/actuator/health
{"status":"UP"}

Так что по какой-то причине маршрутизация нене работает в петлевом деле.Я, вероятно, могу с этим справиться, так как не думаю, что нам нужно будет перезванивать в ту же службу.Хотя это загадочно.

Питер

Answer 1

Это означает, что вы не публиковали порты через свой сервис (или использовали неправильные метки).То, чего вы пытаетесь достичь, должно быть сделано именно с помощью сервисов, вам нужно исправить определение сервиса так, чтобы оно работало должным образом.

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: xxx-name
spec:
  template:
    metadata:
      labels:
        app: xxx-label
    spec:
      containers:
      - name: xxx-container
        image: kmrcr.azurecr.io/image:0.7
        imagePullPolicy: Always
        ports:
          - containerPort: 7003
          - containerPort: 443

---
  apiVersion: v1
  kind: Service
  metadata:
    name: xxx-service
  spec:
    ports:
    - port: 7003
      name: "7003"
    - port: 443
      name: "443"
    selector:
      app: xxx-label < must match your pod label
    type: LoadBalancer

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