Назад | Перейти на главную страницу

Загрузка кластера Kubernetes с помощью Kubeadm на RHEL 7 - проблемы с брандмауэром

Я пытаюсь запустить кластер Kubernetes на RHEL 7.8, но у меня проблемы с брандмауэром.

nftables является не поддерживается в Kubernetes и iptables-legacy должен быть установлен вместо этого. В то время iptables-legacy пакет существует в таких дистрибутивах, как Debian Buster, похоже, что он недоступен для RHEL 7. Однако Эта статья упоминает установку iptables-services, отключение firewalld, и позволяя iptables. Соответствующий материал из статьи:

yum install iptables-services.x86_64 -y
systemctl stop firewalld.service
systemctl disable firewalld.service
systemctl mask firewalld.service
systemctl start iptables
systemctl enable iptables
systemctl unmask iptables
iptables -F
service iptables save

После этого, если я побегу iptables --version на сервере я вижу, что 1.4.2 установлен. Поскольку эта версия старше 1.8, как следует из проблемы GitHub, указанной выше, с этой версией должно быть все в порядке.

Перед запуском kubeadm join с моих рабочих узлов следующие задачи Ansible запускаются против моего мастера для настройки iptables:

- iptables:
    chain: INPUT
    destination_port: "{{ port }}"
    jump: ACCEPT
    protocol: tcp
  loop:
    - 6443
    - 2379:2380
    - 10250:10252
  loop_control:
    loop_var: port

- command: service iptables save

- systemd:
    name: iptables
    state: restarted

И это против моих узлов для настройки iptables:

- iptables:
    chain: INPUT
    destination_port: "{{ port }}"
    jump: ACCEPT
    protocol: tcp
  loop:
    - 10250
    - 30000:32767
  loop_control:
    loop_var: port

- command: service iptables save

- systemd:
    name: iptables
    state: restarted

После этого я могу подтвердить, что правило присутствует в памяти:

$> iptables -S | grep 6443
-A INPUT -p tcp -m tcp --dport 6443 -j ACCEPT

Затем, когда я бегу kubeadm join с рабочего узла не удается подключиться:

I0406 22:07:19.205714    5715 token.go:73] [discovery] Created cluster-info discovery client, requesting info from "https://192.168.50.10:6443"
I0406 22:07:19.206720    5715 token.go:78] [discovery] Failed to request cluster info: [Get https://192.168.50.10:6443/api/v1/namespaces/kube-public/configmaps/cluster-info?timeout=10s: dial tcp 192.168.50.10:6443: connect: no route to host]
I0406 22:07:19.206749    5715 token.go:191] [discovery] Failed to connect to API Server "192.168.50.10:6443": Get https://192.168.50.10:6443/api/v1/namespaces/kube-public/configmaps/cluster-info?timeout=10s: dial tcp 192.168.50.10:6443: connect: no route to host
I0406 22:07:24.207648    5715 token.go:188] [discovery] Trying to connect to API Server "192.168.50.10:6443

Однако если я systemctl stop iptables на мастере рабочие узлы могут присоединиться без каких-либо проблем. Указывая мне, что брандмауэр на главном компьютере неправильно настроен?

Модуль Ansible iptables использует append действие по умолчанию. Это вызвало reject правила не располагаться там, где они должны быть. Добавление action: insert к моему iptables задачи в Ansible решили проблему.