Kubernetes + Calico на облачных виртуальных машинах Oracle - PullRequest
Новая
       82

Kubernetes + Calico на облачных виртуальных машинах Oracle

0 голосов
/ 11 ноября 2018

[Отказ от ответственности: этот вопрос был первоначально размещен на ServerFault . Однако, поскольку официальная документация K8s гласит «задайте свои вопросы по StackOverflow», я также добавляю их сюда]

Я пытаюсь развернуть тестовый кластер Kubernetes в Oracle Cloud, используя экземпляры виртуальной машины OCI - однако у меня возникают проблемы с сетью pod.

Сетевой плагин Calico - кажется, он установлен правильно, но трафик не проходит через туннели от одного хоста к другому. Например, здесь я пытаюсь получить доступ к nginx, запущенному на другом узле: 

root@kube-01-01:~# kubectl get pod -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP              NODE              NOMINATED NODE
nginx-dbddb74b8-th9ns   1/1     Running   0          38s   192.168.181.1   kube-01-06   <none>
root@kube-01-01:~# curl 192.168.181.1
[ ... timeout... ]

Используя tcpdump, я вижу пакеты IP-in-IP (протокол 4), покидающие первый хост, но, похоже, они никогда не доходят до второго (хотя все другие пакеты, включая трафик BGP, проходят через него нормально ). 

root@kube-01-01:~# tcpdump -i ens3 proto 4 &
[1] 16642
root@kube-01-01:~# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes

root@kube-01-01:~# curl 192.168.181.1
09:31:56.262451 IP kube-01-01 > kube-01-06: IP 192.168.21.64.52268 > 192.168.181.1.http: Flags [S], seq 3982790418, win 28000, options [mss 1400,sackOK,TS val 9661065 ecr 0,nop,wscale 7], length 0 (ipip-proto-4)
09:31:57.259756 IP kube-01-01 > kube-01-06: IP 192.168.21.64.52268 > 192.168.181.1.http: Flags [S], seq 3982790418, win 28000, options [mss 1400,sackOK,TS val 9661315 ecr 0,nop,wscale 7], length 0 (ipip-proto-4)
09:31:59.263752 IP kube-01-01 > kube-01-06: IP 192.168.21.64.52268 > 192.168.181.1.http: Flags [S], seq 3982790418, win 28000, options [mss 1400,sackOK,TS val 9661816 ecr 0,nop,wscale 7], length 0 (ipip-proto-4)

root@kube-01-06:~# tcpdump -i ens3 proto 4 &
[1] 12773
root@kube-01-06:~# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes

То, что я проверил до сих пор:

  1. Сетка маршрутизации Calico подходит просто отлично. Я могу видеть трафик BGP при захвате пакета, и я могу видеть все узлы как "вверх", используя calicoctl

root @ kube-01-01: ~ # ./calicoctl статус узла Ситцевый процесс запущен. 

IPv4 BGP status
+--------------+-------------------+-------+----------+-------------+
| PEER ADDRESS |     PEER TYPE     | STATE |  SINCE   |    INFO     |
+--------------+-------------------+-------+----------+-------------+
| 10.13.23.123 | node-to-node mesh | up    | 09:12:50 | Established |
| 10.13.23.124 | node-to-node mesh | up    | 09:12:49 | Established |
| 10.13.23.126 | node-to-node mesh | up    | 09:12:50 | Established |
| 10.13.23.129 | node-to-node mesh | up    | 09:12:50 | Established |
| 10.13.23.127 | node-to-node mesh | up    | 09:12:50 | Established |
| 10.13.23.128 | node-to-node mesh | up    | 09:12:50 | Established |
| 10.13.23.130 | node-to-node mesh | up    | 09:12:52 | Established |
+--------------+-------------------+-------+----------+-------------+
  1. Правила безопасности для подсети разрешают весь трафик. Все узлы находятся в одной подсети, и у меня есть правило без состояния, разрешающее весь трафик от других узлов в подсети (я также попытался добавить правило, разрешающее трафик IP-in-IP явно - тот же результат).
  2. Проверка источника / назначения отключена на всех vNIC на узлах K8.

Другие вещи, которые я заметил:

  1. Я могу заставить ситцевую камеру работать, если я отключу IP в инкапсуляции IP для трафика той же подсети и использую обычную маршрутизацию внутри подсети (как описано здесь для AWS)
  2. Другие сетевые плагины (например, weave) работают правильно.

Итак, мой вопрос здесь - что происходит с инкапсулированным трафиком IP-in-IP? Могу ли я проверить что-нибудь еще, чтобы выяснить, что происходит?

И да, я знаю, что мог бы использовать управляемый движок Kubernetes напрямую, но где в этом удовольствие (и возможность обучения)? : D

Отредактировано с учетом ответа Рико ниже:

1) Я также не получаю трафик pod-to-pod для прохождения (нет связи между модулями на разных хостах). Но мне не удалось захватить этот трафик, поэтому я использовал в качестве примера узел-к-моду.

2) Я также получаю аналогичный результат, если подключаю svc NodePort к другому узлу, нежели тот, на котором запущен модуль - я вижу исходящие пакеты IP-in-IP с первого узла, но они никогда не отображаются на втором узле (тот, на котором фактически запущен модуль): 

root@kube-01-01:~# tcpdump -i ens3 proto 4 &
[1] 6499
root@kube-01-01:~# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
root@kube-01-01:~# curl 127.0.0.1:32137
20:24:08.460069 IP kube-01-01 > kube-01-06: IP 192.168.21.64.40866 > 192.168.181.1.http: Flags [S], seq 3175451438, win 43690, options [mss 65495,sackOK,TS val 19444115 ecr 0,nop,wscale 7], length 0 (ipip-proto-4)
20:24:09.459768 IP kube-01-01 > kube-01-06: IP 192.168.21.64.40866 > 192.168.181.1.http: Flags [S], seq 3175451438, win 43690, options [mss 65495,sackOK,TS val 19444365 ecr 0,nop,wscale 7], length 0 (ipip-proto-4)
20:24:11.463750 IP kube-01-01 > kube-01-06: IP 192.168.21.64.40866 > 192.168.181.1.http: Flags [S], seq 3175451438, win 43690, options [mss 65495,sackOK,TS val 19444866 ecr 0,nop,wscale 7], length 0 (ipip-proto-4)
20:24:15.471769 IP kube-01-01 > kube-01-06: IP 192.168.21.64.40866 > 192.168.181.1.http: Flags [S], seq 3175451438, win 43690, options [mss 65495,sackOK,TS val 19445868 ecr 0,nop,wscale 7], length 0 (ipip-proto-4)

Ничего на втором узле (kube-01-06, тот, который фактически запускает модуль nginx): 

root@kubespray-01-06:~# tcpdump -i ens3 proto 4
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes

Я использовал 127.0.0.1 для простоты демонстрации - конечно, то же самое происходит, когда я нажимаю на этот NodePort с внешнего хоста: 

20:25:17.653417 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56630 > 192.168.181.1.http: Flags [S], seq 980178400, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)
20:25:17.654371 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56631 > 192.168.181.1.http: Flags [S], seq 3932412963, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)
20:25:17.667227 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56632 > 192.168.181.1.http: Flags [S], seq 2017119223, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)
20:25:20.653656 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56630 > 192.168.181.1.http: Flags [S], seq 980178400, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)
20:25:20.654577 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56631 > 192.168.181.1.http: Flags [S], seq 3932412963, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)
20:25:20.668595 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56632 > 192.168.181.1.http: Flags [S], seq 2017119223, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)

3) Насколько я могу судить (пожалуйста, исправьте меня, если я здесь не прав), узлы осведомлены о маршрутах к сетям pod, и трафик pod-to-node также инкапсулирован IP -in-IP (обратите внимание на протокол 4 пакета в первом захвате выше) 

root@kube-01-01:~# kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP               NODE              NOMINATED NODE
alpine-9d85bf65c-2wx74   1/1     Running   1          23m   192.168.82.194   kube-01-08   <none>
nginx-dbddb74b8-th9ns    1/1     Running   0          10h   192.168.181.1    kube-01-06   <none>

root@kube-01-01:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
<snip>
192.168.181.0   10.13.23.127    255.255.255.192 UG    0      0        0 tunl0

Ответы [ 2 ]

0 голосов
/ 11 ноября 2018

Возможно, это проблема MTU:

Обычно MTU для ваших интерфейсов рабочей нагрузки должен соответствовать MTU сети.Если вам нужен IP-in-IP, то размер MTU для интерфейсов рабочей нагрузки и туннеля должен быть на 20 байт меньше, чем сетевой MTU для вашей сети.Это связано с дополнительным 20-байтовым заголовком, который туннель будет добавлять к каждому пакету.

Подробнее здесь .

0 голосов
/ 11 ноября 2018

У вас есть проблемы с подключением от Pod к Pod?

Короткий ответ здесь может показаться, что пакеты PodCidr инкапсулируются, когда они связываются с другим модулем либо на том же узле, либо на другом узле.

Примечание:

По умолчанию инкапсуляция Calico IPIP применяется ко всему трафику контейнер-контейнер.

Таким образом, вы сможете подключиться к модулюна другом узле, если вы находитесь внутри стручка.Например, если вы подключаетесь с помощью kubectl exec -it <pod-name>.

. По этой причине вы не можете подключиться к модулю / контейнеру из root@kube-01-01:~#, поскольку ваш узел / хост ничего не знает о PodCidr.Он отправляет 192.168.xx пакетов через маршрут узла / хоста по умолчанию, однако ваша физическая сеть не является 192.168.xx, поэтому они теряются, поскольку нет другого узла / хоста, который физически это понимает.

Способ, которым вы могли быподключение к службе nginx будет осуществляться через Kubernetes Service , это отличается от сетевого наложения и позволяет подключаться к модулям за пределами PodCidr.Обратите внимание, что эти правила обслуживания управляются kube-proxy и, как правило, являются iptables правилами.Кроме того, с iptables вы можете явно делать такие вещи, как если вы хотите общаться с IP AAAA, вам нужно пройти через физический интерфейс (например, tun0) или через IP BBBB

Надеюсь, это поможет!

...