модули в kubernetes не могут взаимодействовать с другими модулями и внешними узлами кластера

У меня есть 2 основных и 3 рабочих узла и один прокси высокой доступности для controlePlan, У меня есть много микросервисов Java, которые взаимодействуют друг с другом и взаимодействуют с БД или KAFKA за пределами кластера kubernetes. доступ в сеть любой к любому открыт во всех хостах. Я создаю развертывание для каждого микросервиса. Но когда я запускаю контейнер, у меня нет tcp-соединения на портах между модулями и БД или KAFKA за пределами кластера kubernetes.

с хостов у меня есть телнет к БД или KAFKA, но в контейнерах у меня нет доступа.

от хозяев:

[root@master1 ~]# telnet oracle.local 1521
Пытаюсь 192.198.10.30...
Подключен к oracle.local.
Экранирующий символ '^]'.
^C^CСоединение закрыто внешним хостом.
[root@master1 ~]#

из пода, например, busybux:

[root@master1 ~]# kubectl run -i --tty busybox --image=busybox --restart=Никогда -- sh
Если вы не видите командную строку, попробуйте нажать Enter.
/#телнет 192.168.10.30 1521
telnet: не удается подключиться к удаленному хосту (192.168.10.30): время ожидания подключения истекло

состояние кластера:

[root@master1 ~]# kubectl get nodes -o wide
ИМЯ СТАТУС РОЛИ ВОЗРАСТ ВЕРСИЯ ВНУТРЕННИЙ-IP ВНЕШНИЙ-IP ОС-ОБРАЗ ВЕРСИЯ ЯДРА КОНТЕЙНЕР-ВРЕМЯ РАБОТЫ
master1.project.co Готовая плоскость управления, master 11d v1.22.2 192.168.10.1 <нет> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
master2.project.co Готовая плоскость управления, master 11d v1.22.2 192.168.10.2 <нет> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
worker1.project.co Готов <нет> 11d v1.22.2 192.168.10.3 <нет> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
worker2.project.co Готов <нет> 11d v1.22.2 192.168.10.4 <нет> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
worker3.project.co Готов <нет> 11d v1.22.2 192.168.10.5 <нет> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9

опишите pod busybox:

[root@master1 ~]# kubectl описывает модуль busybox
Имя: занятбокс
Пространство имен: по умолчанию
Приоритет: 0
Узел: worker3.project.co/192.168.10.5
Время начала: Сб, 02 Окт 2021 10:27:05 +0330
Ярлыки: run=busybox
Аннотации: cni.projectcalico.org/containerID: 75d7222e8f402c68d9161a7b399df2de6b45e7194b2bb3b0b2730adbdac680c4
              cni.projectcalico.org/podIP: 192.168.205.76/32
              cni.projectcalico.org/podIPs: 192.168.205.76/32
Статус: ожидание
IP:
IP-адреса: <нет>
Контейнеры:
  занятой ящик:
    Идентификатор контейнера:
    Изображение: занятой ящик
    Идентификатор изображения:
    Порт: <нет>
    Хост-порт: <нет>
    Аргументы:
      ш
    Состояние: Ожидание
      Причина: создание контейнера
    Готово: Ложь
    Количество перезапусков: 0
    Среда: <нет>
    Маунты:
      /var/run/secrets/kubernetes.io/serviceaccount из kube-api-access-69snv (ro)
Условия:
  Тип Статус
  Инициализировано Истинно
  Готов Ложь
  ContainersReady False
  PodScheduled True
Объемы:
  куб-апи-доступ-69snv:
    Тип: спроецированный (том, который содержит введенные данные из нескольких источников)
    TokenExpirationSeconds: 3607
    ConfigMapName: kube-root-ca.crt
    ConfigMapOptional: <ноль>
    Нисходящий API: правда
Класс QoS: BestEffort
Селекторы узлов: <нет>
Допуски: node.kubernetes.io/not-ready:NoExecute op=Существует в течение 300 с.
                             node.kubernetes.io/unreachable:NoExecute op=Существует 300 с.
События:
  Тип Причина Возраст от сообщения
  ---- ------ ---- ---- -------
  Обычный Запланировано 21s default-scheduler Успешно назначено default/busybox для worker3.project.co
  Обычный Pulling 20s kubelet Вытягивание изображения "busybox"

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

1. Проверьте, есть ли Сетевые политики применяется путем выполнения kubectl -n <пространство имен> получить netpol. NetworkPolicies может ограничивать обмен данными внутри кластера и за его пределами.
2. Пусть Pod работает с хост-сеть: правда вариант (нет необходимо выполнить в рабочей среде, просто в качестве теста) и снова попробуйте несколько тестов подключения (в обоих направлениях).
3. Проверьте, правильно ли настроена сеть вашего кластера, отследив сетевой вызов. Правильно ли настроены маршрутизаторы и могут ли они использоваться приложениями в кластере?
4. Проверьте, если ваш доступ к сети любой к любому открытый во всех хостах утверждение верно, это может быть проблема с настройками брандмауэра.

Бонус: Кажется, у вас есть только 2 мастер-узла, которые вообще не имеет смысла если etcd работает в кластере Kubernetes (kubectl -n kube-system получить модули | grep и т.д. покажет 2 модуля, если это так). Наличие 2 членов etcd дает вам такую ​​же отказоустойчивость, как и кластер с 1 узлом, но вы тратите ресурсы впустую на наличие другой виртуальной машины, которая занимает память, процессор и т. д.. Рассмотрите возможность увеличения мастер-узлов до 3, чтобы иметь отказоустойчивость на уровне одного. Всегда должно быть большинство работающего кластера etcd. Имейте в виду, что большинство из 2 по-прежнему 2.