Может ли модуль Kubernetes связать несколько IP-адресов?

Question

КРАТКИЙ ВОПРОС:

Есть ли способ для модуля Kubernetes связать несколько IP-адресов?

Даже если только петлевые?

ДОПОЛНИТЕЛЬНОЕ ОБЪЯСНЕНИЕ:

У меня есть приложение, которое необходимо развернуть в модуле Kubernetes и которое использует Cassandra. Сама Cassandra расположена за брандмауэром, который по административным причинам не может быть открыт для прямого IP-доступа из внешнего облака, в котором размещен ландшафт K8S. Вместо этого мне нужно разработать реле, которое проходит через настраиваемый туннель.

Драйвер Cassandra внутри приложения будет указывать не на настоящий кластер Cassandra, а на реле, которое затем будет туннелировать соединение.

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

Проблема, однако, в том, что Cassandra драйвер подключается к каждому узлу в кластере Cassandra по IP-адресу узла, например, если кластер Cassandra состоит из трех узлов, то драйвер подключается к node1: 9042, node2: 9042 и node3: 9042. Номер порта принудительно используется всеми подключениями. Драйвер не позволяет указывать, скажем, node1: 9042, node2: 9043 и node3: 9044. Таким образом, я не могу подключить драйвер к thispod: 9042, thispod: 9043 и thispod: 9044. Если бы это было возможно, я мог бы запустить реле внутри контейнера, прослушивать три порта, а затем перенаправлять соединения. Однако из-за ограничений драйвера Cassandra конечные точки прослушивания ретрансляции должны иметь разные IP-адреса (и я бы предпочел не создавать модифицированную версию драйвера для снятия этого ограничения).

Что подводит нас к вопрос: может ли модуль связать дополнительные IP-адреса?

Тип адреса не имеет большого значения, если внутри контейнера или модуля возможно отправлять данные на этот адрес и получать от него. Связь по существу является обратной связью внутри contaner или pod. Если бы это была неконтейнерная среда, а простая Linux виртуальная машина, я мог бы создать дополнительные интерфейсы обратной связи, которые бы решили проблему. Но внутри контейнера невозможно создать интерфейсы.

Есть ли способ заставить Kubernetes связывать дополнительные IP-адреса с модулем?

Answer 1

Чтобы связать дополнительные IP-адреса с модулем, вы можете использовать Multus CNI . Он позволяет подключать к модулю несколько сетевых интерфейсов. Это требовало CNI по умолчанию для связи от модуля к модулю (например, Calico, Flannel).

Как это работает, создается NetworkAttachmentDefinition CRD , который затем вы добавляете в поле аннотации в манифесте модуля. Кроме того, вы можете определить маршруты по умолчанию для интерфейсов. Пример использования:

Определение CRD

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: macvlan-conf
spec:
  config: '{
      "cniVersion": "0.3.0",
      "type": "macvlan",
      "master": "eth0",
      "mode": "bridge",
      "ipam": {
        "type": "host-local",
        "subnet": "192.168.1.0/24",
        "rangeStart": "192.168.1.200",
        "rangeEnd": "192.168.1.216",
        "routes": [
          { "dst": "0.0.0.0/0" }
        ],
        "gateway": "192.168.1.1"
      }
    }'

Манифест модуля:

apiVersion: v1
kind: Pod
metadata:
  name: samplepod
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-conf
spec:
  containers:
  - name: samplepod
    command: ["/bin/ash", "-c", "trap : TERM INT; sleep infinity & wait"]
    image: alpine

И когда вы запускаете c в модуль, когда он запущен, вы можете видеть, что создан дополнительный интерфейс:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1440 qdisc noqueue state UP 
    link/ether 86:75:ed:87:a1:1a brd ff:ff:ff:ff:ff:ff
    inet 192.168.171.65/32 scope global eth0
       valid_lft forever preferred_lft forever
3: net1@tunl0: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1460 qdisc noqueue state UP 
    link/ether 1a:58:6e:88:fb:f5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.200/24 scope global net1
       valid_lft forever preferred_lft forever