Así que tengo un clúster de kubernets funcionando con elKubernetes en la guía de instalación manual de CoreOS.

$ kubectl get no
NAME              STATUS                     AGE
coreos-master-1   Ready,SchedulingDisabled   1h
coreos-worker-1   Ready                      54m

$ kubectl get cs
NAME                 STATUS    MESSAGE              ERROR
controller-manager   Healthy   ok
scheduler            Healthy   ok
etcd-0               Healthy   {"health": "true"}
etcd-2               Healthy   {"health": "true"}
etcd-1               Healthy   {"health": "true"}

$ kubectl get pods --all-namespaces -o wide
NAMESPACE     NAME                                      READY     STATUS    RESTARTS   AGE       IP               NODE
default       curl-2421989462-h0dr7                     1/1       Running   1          53m       10.2.26.4        coreos-worker-1
kube-system   busybox                                   1/1       Running   0          55m       10.2.26.3        coreos-worker-1
kube-system   kube-apiserver-coreos-master-1            1/1       Running   0          1h        192.168.0.200   coreos-master-1
kube-system   kube-controller-manager-coreos-master-1   1/1       Running   0          1h        192.168.0.200   coreos-master-1
kube-system   kube-proxy-coreos-master-1                1/1       Running   0          1h        192.168.0.200   coreos-master-1
kube-system   kube-proxy-coreos-worker-1                1/1       Running   0          58m       192.168.0.204   coreos-worker-1
kube-system   kube-scheduler-coreos-master-1            1/1       Running   0          1h        192.168.0.200   coreos-master-1

$ kubectl get svc --all-namespaces
NAMESPACE   NAME         CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
default     kubernetes   10.3.0.1     <none>        443/TCP   1h

Al igual que con la guía, he configurado una red de servicio10.3.0.0/16 y una red pod10.2.0.0/16. La red de pod parece estar bien, ya que los contenedores busybox y curl obtienen IP. Pero la red de servicios tiene problemas. Originalmente, me encontré con esto al implementarkube-dns: el servicio IP10.3.0.1 no se pudo alcanzar, por lo que kube-dns no pudo iniciar todos los contenedores y DNS finalmente no funcionaba.

Desde dentro del pod curl, puedo reproducir el problema:

[ root@curl-2421989462-h0dr7:/ ]$ curl https://10.3.0.1
curl: (7) Failed to connect to 10.3.0.1 port 443: No route to host

[ root@curl-2421989462-h0dr7:/ ]$ ip route
default via 10.2.26.1 dev eth0
10.2.0.0/16 via 10.2.26.1 dev eth0
10.2.26.0/24 dev eth0  src 10.2.26.4

Parece correcto que solo haya una ruta predeterminada en el contenedor. Tal como lo entendí, la solicitud (a la ruta predeterminada) debe ser interceptada por elkube-proxy en el nodo trabajador, reenviado al proxy en el nodo maestro donde la IP se traduce mediante iptables a la IP pública maestra.

Parece que hay un problema común con una configuración sysctl de bridge / netfilter, pero eso parece estar bien en mi configuración:

core@coreos-worker-1 ~ $ sysctl net.bridge.bridge-nf-call-iptables
net.bridge.bridge-nf-call-iptables = 1

Me está costando mucho resolver problemas, ya que no entiendo para qué se utiliza la IP del servicio, cómo se supone que funciona la red de servicios en términos de flujo de tráfico y cómo depurarla mejor.

Aquí están las preguntas que tengo:

¿Para qué se utiliza la primera IP de la red de servicio (10.3.0.1 en este caso)?¿Es correcta la descripción anterior del flujo de tráfico? Si no es así, ¿qué pasos se requieren para que un contenedor llegue a una IP de servicio?¿Cuáles son las mejores formas de depurar cada paso en el flujo de tráfico? (No puedo tener idea de lo que está mal de los registros)

¡Gracias!