Как я могу написать минимальную NetworkPolicy для брандмауэра приложения Kubernetes со службой типа LoadBalancer, использующей Calico? - PullRequest
Новая
       31

Как я могу написать минимальную NetworkPolicy для брандмауэра приложения Kubernetes со службой типа LoadBalancer, использующей Calico?

0 голосов
/ 28 июня 2018

У меня есть кластер Kubernetes, на котором запущен Calico в качестве оверлея и реализация NetworkPolicy, настроенная для инкапсуляции IP-in-IP, и я пытаюсь представить простое приложение nginx, используя следующую службу: 

apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: nginx

Я пытаюсь написать NetworkPolicy, который разрешает соединения только через балансировщик нагрузки. В кластере без наложения это может быть достигнуто путем разрешения соединений из CIDR, используемых для выделения IP-адресов самим рабочим экземплярам - это позволяет соединению подключаться к NodePort службы для конкретного работника и перенаправляться в один из контейнеров за Сервис по правилам IPTables. Однако при использовании Calico, настроенного для IP-in-IP, соединения, сделанные через NodePort, используют IP-адрес туннеля IP-in-IP Calico в качестве адреса источника для связи между узлами, как показано в поле ipv4IPIPTunnelAddr объекта Calico Node. здесь (я понял это, наблюдая IP-адрес источника соединений с приложением nginx, выполненным через балансировщик нагрузки). Следовательно, моя NetworkPolicy должна разрешать такие подключения.

У меня вопрос: как я могу разрешить эти типы соединений, не зная заранее значений ipv4IPIPTunnelAddr и не разрешая соединения со всеми модулями в кластере (поскольку значения ipv4IPIPTunnelAddr взяты из диапазона CIDR модуля кластера). Если рабочие экземпляры появляются и умирают, список таких IP-адресов наверняка изменится, и я не хочу, чтобы мои правила NetworkPolicy зависели от них.

  • Калико версия: 3.1.1
  • Kubernetes версия: 1.9.7
  • Etcd версия: 3.2.17
  • Облачный провайдер: AWS

1 Ответ

0 голосов
/ 29 июня 2018

Боюсь, у нас нет простого способа динамического сопоставления туннельных IP-адресов. Если возможно, лучшим решением было бы отказаться от IPIP; как только вы удалите это наложение, все станет намного проще.

В случае, если вам интересно, нам нужно заставить узлы использовать IP-адрес туннеля, потому что, если вы используете IPIP, мы предполагаем, что ваша сеть не разрешает прямой обратный трафик от узла к узлу (так как сеть не будет ожидать IP-адреса pod, она может отбросить пакеты)

...