Поскольку мне нравится иметь отдельные вещи (соображения безопасности), я сейчас экспериментирую, чтобы увидеть, могу ли я иметь полностью отдельные сети в Kubernetes для сети «хостов» и «внешней» сети, где я хочу. МеталлЛБ управлять трафиком.
В качестве экспериментальной установки у меня теперь есть два отдельных vlan и виртуальная машина VMware, которая просто видит два обычных сетевых интерфейса.
На этой виртуальной машине я установил CentOS 7, Kubernetes 1.17, Calico 3.13.1 и MetalLB 0.8.2.
Я ожидаю, что мне не нужно давать узлу IP-адрес на «внешнем» интерфейсе, потому что в Руководство MetalLB Я читаю
Режим уровня 2 не требует привязки IP-адресов к сетевым интерфейсам ваших рабочих узлов. Он работает, отвечая на запросы ARP напрямую в вашей локальной сети, чтобы предоставить клиентам MAC-адрес машины.
Это хорошо, потому что в этом случае узел будет фактически недоступен из «внешней» сети.
Для тестирования я настроил Metallb для управления диапазоном IP-адресов в обеих сетях (только для тестирования)
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 10.123.123.100-10.123.123.199
- 10.123.45.100-10.123.45.199
На виртуальной машине я даю хост-интерфейсу IP-адрес (DHCP), и все работает нормально. Я не даю «внешнему» интерфейсу IP / маршрутизацию /… но я убедился, что он «активен».
Итак, я вижу это (ens192 = хосты, ens224 = внешние)
[root@node1 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
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: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:0c:29:ca:06:13 brd ff:ff:ff:ff:ff:ff
inet 10.123.123.6/24 brd 10.123.123.255 scope global dynamic ens192
valid_lft 75786sec preferred_lft 75786sec
3: ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:0c:29:ca:06:1d brd ff:ff:ff:ff:ff:ff
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:dc:25:87:ec brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
(и много интерфейсов cali *)
[root@node1 ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.123.123.1 0.0.0.0 UG 0 0 0 ens192
10.123.123.0 0.0.0.0 255.255.255.0 U 0 0 0 ens192
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.135.192 0.0.0.0 255.255.255.192 U 0 0 0 *
192.168.135.242 0.0.0.0 255.255.255.255 UH 0 0 0 calia47abf08c66
…
Для тестирования у меня есть простое веб-приложение и я подключил к нему две службы K8s: одну с loadBalancerIP в «хост-сети» и одну во «внешней» сети.
[root@node1 ~]# kubectl -n yauaa get all
NAME READY STATUS RESTARTS AGE
pod/yauaa-7d7bffd9fc-tdhg9 1/1 Running 5 2d6h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/yauaa LoadBalancer 10.104.33.179 10.123.123.100 80:31908/TCP 2d3h
service/yauaa-pub LoadBalancer 10.105.4.161 10.123.45.100 80:30695/TCP 2d7h
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/yauaa 1/1 1 1 2d7h
NAME DESIRED CURRENT READY AGE
replicaset.apps/yauaa-7d7bffd9fc 1 1 1 2d6h
Запустившись локально на самом узле k8s, я могу выполнить curl для любого IP-адреса, и оба ответят немедленно. Так что привязка, предоставленная Metallb к сервисам, похоже, работает.
Теперь на моем брандмауэре (Linux-устройстве) я могу выполнить завиток для любого IP-адреса, «хост» отвечает, а «внешний» - нет. Я вижу, что правильное сопоставление IP-MAC присутствует в таблице arp этого межсетевого экрана. Пока я не получаю ответа.
# arp -a | fgrep 10.123
node1.k8s.basjes.nl (10.123.123.6) at 00:0c:29:ca:06:13 [ether] on eth1.2222
? (10.123.123.100) at 00:0c:29:ca:06:13 [ether] on eth1.2222
? (10.123.45.100) at 00:0c:29:ca:06:1d [ether] on eth1.2345
Я попытался установить Ens224 в неразборчивом режиме, я попытался добавить запись маршрутизации в шлюз для этого интерфейса, но это не помогло.
Мне действительно удалось запустить его, фактически предоставив этому интерфейсу ens224 IP-адрес, но это то, чего я предпочитаю не иметь и который (если я правильно понимаю документацию) не нужен.
Видимо я что-то не так делаю.
Как правильно это настроить?