Как включить внешний доступ к моему сервису Kubernetes через мастер с помощью Calico на GCP?

У меня есть один главный и один рабочий кластер Kubernetes с развернутым Calico из здесь без изменений в манифестах. Мастер имеет внутренний IP-адрес 10.132.0.30, и я пытаюсь открыть свою службу (работающую на рабочем месте) на мастере следующим образом:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  type: ClusterIP
  externalIPs: [10.132.0.30]
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: nginx

curl http://10.132.0.30 от мастера работает как положено, а вот прокрутка мастера с моего ноута на его внешний IP-адрес зависает, хотя я вижу подключения через tcpdump:

# tcpdump -i eth0 dst 10.132.0.30 and dst port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:52:16.692059 IP cpc102582-walt20-2-0-cust85.13-2.cable.virginm.net.62882 > fail5-luke-master.c.jetstack-luke.internal.http: Flags [S], seq 3014275997, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 181016377 ecr 0,sackOK,eol], length 0
...

Выполнение других команд tcpdump на других интерфейсах кажется, что пакеты достигают nginx, но не возвращаются (cali3561fc118c0 — это интерфейс моего модуля nginx на рабочем сервере в пространстве имен корневой сети, а 192.168.1.4 — назначенный ему IP-адрес):

# tcpdump -i cali3561fc118c0 dst 192.168.1.4
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on cali3561fc118c0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:00:23.626170 IP 192.168.0.1.65495 > 192.168.1.4.http-alt: Flags [S], seq 2616662679, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 181480911 ecr 0,sackOK,eol], length 0
...

Я предполагаю, что есть много возможных проблем, но есть ли что-то очевидное, что я упускаю?

РЕДАКТИРОВАТЬ: я последовал совету из документации Calico здесь без везения

Версия Кубернета: 1.13.4


kubernetes google-cloud-platform project-calico
person dippynark    schedule 07.03.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я не установил --cluster-cidr на kube-proxy. Установка этого значения означала, что kube-proxy знал, что нужно маскировать внешний трафик, так как в противном случае обратный путь был бы асимметричным (он всегда отскакивал от узла к рабочему): https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/iptables/proxier.go#L841-L845

person dippynark    schedule 08.03.2019