Kubernetes и Docker: как позволить двум сервисам правильно общаться

Для доступа к службам в Kubernetes вы должны использовать этот DNS:

• http: //caller-loadbalancer.default.svc.cluster.local: 8080
[ 113] http: //called-loadbalancer.default.svc.cluster.local: 8081

Краткий ответ: вам не нужно показывать их в Dockerfile. Вы можете установить любые переменные окружения, которые захотите, при запуске контейнера, и их не нужно указывать заранее в Dockerfile.

Вы можете убедиться в этом, запустив контейнер, используя 'docker run' с '-e' для установки env vars и '-it' для получения интерактивного сеанса. Выведите значение вашего env var, и вы увидите, что оно установлено.

Вы также можете получить терминальную сессию с одним из контейнеров в вашем запущенном модуле kubernetes с помощью «kubectl exec» ( https://kubernetes.io/docs/tasks/debug-application-cluster/ получить скорлупе выполняющихся-контейнер / ). Оттуда вы можете отобразить переменные окружения, чтобы увидеть, что они установлены. Вы можете увидеть их быстрее с помощью «kubectl description pod» после получения имени модуля с помощью «kubectl get pods».

Поскольку у вас возникли проблемы, вы также хотите проверить, правильно ли работают ваши службы. Поскольку вы используете миникуб, вы можете воспользоваться «сервисом миникуб», чтобы проверить, что к ним можно получить доступ извне. Вы также захотите проверить внутренний доступ - см. Доступ к конечной точке контроллера весенней загрузки в модуле kubernetes

. Ваш подход к использованию имен служб и портов действителен. Немного отладки, и вы сможете заставить его работать. Ваша настройка аналогична иллюстрации, которую я сделал в https://dzone.com/articles/kubernetes-namespaces-explained , поэтому ссылка на это может помочь (за исключением того, что вы используете env vars напрямую, а не через карту конфигурации). но это равносильно тому же).

Я думаю, что в вызывающей стороне вы вводите неправильный порт в env var - вы вводите собственный порт вызывающей стороны, а не порт того, что он пытается вызвать.

Мы можем установить ...

Мы должны установить ...

Никто здесь не знает, что вы хотите сделать, и было бы гораздо полезнее увидеть какое-то определение того, что вы ожидаете.

Сказав это сейчас, я должен перейти к вашему основному вопросу ...

  env:
    - name: CALLERPORT
      value: "8080"
    - name: CALLEDADDRESS
      value: called-loadbalancer  # WHAT TO PUT HERE?!
    ports:
    - containerPort: 8080
      name: caller

Эти вещи будут автоматически экспортированы k8s. Например, у меня есть служба kibana с port:80 в определении службы:

svc/kibana                                 ClusterIP      10.222.81.249    <none>                              80/TCP              1y        app=kibana

, вот как я могу получить это в другом модуле, который находится в том же пространстве имен:

[112 ]

Двигаясь вперед, почему вы используете LoadBalancer? Без какого-либо облака это будет похоже на NodePort, но, похоже, ClusterIP - это все, что вам нужно. Далее, сервисные порты могут быть одинаковыми, и не будет никаких конфликтов портов, просто потому, что ClusterIP каждый раз уникален и, следовательно, сокет будет уникальным для каждого сервиса. Ваши сервисы можно описать так:

apiVersion: v1
kind: Service              
metadata:
  name: caller-loadbalancer
spec:
  type: LoadBalancer       
  ports:
  - port: 80 <--------------------           
    targetPort: 8080        
  selector:            
    app: caller  

apiVersion: v1
kind: Service              
metadata:
  name: called-loadbalancer
spec:
  type: LoadBalancer       
  ports:
  - port: 80 <------------------             
    targetPort: 8081        
  selector:            
    app: called

Это упростит использование имен сервисов только по именам без указания портов:

http://caller-loadbalancer.default.svc.cluster.local
http://called-loadbalancer.default.svc.cluster.local

или

http://caller-loadbalancer.default
http://called-loadbalancer.default

или (в аналогичном пространстве имен):

http://caller-loadbalancer
http://called-loadbalancer

или (в зависимости от библиотеки)

caller-loadbalancer
called-loadbalancer

То же самое в containerPort / targetPort! Почему вы используете 8081 и 8080? Кто заботится о внутренних портах контейнера? Я согласен, что бывают разные случаи, но в этом случае у вас внутри один процесс, и вы определенно не собираетесь запускать еще несколько процессов, не так ли? Так что они тоже могут быть одинаковыми.

Я хотел бы посоветовать вам использовать стекопоток другим способом. Не спрашивайте, как сделать что-то по-своему, гораздо лучше спросить, как сделать что-то наилучшим образом