Então, eu tenho um cluster do kubernets em funcionamento usando oGuia de instalação manual do Kubernetes no 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

Como no guia, configurei uma rede de serviço10.3.0.0/16 e uma rede de pods10.2.0.0/16. A rede de pods parece boa, pois o busybox e os curl containers obtêm IPs. Mas a rede de serviços tem problemas. Originalmente, eu encontrei isso ao implantarkube-dns: o IP do serviço10.3.0.1 não pôde ser alcançado, portanto, o kube-dns não pôde iniciar todos os contêineres e o DNS não estava funcionando.

No pod de curl, posso reproduzir o 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 que há apenas uma rota padrão no contêiner. Pelo que entendi, a solicitação (rota padrão) deve ser interceptada pelokube-proxy no nó do trabalhador, encaminhado para o proxy no nó principal em que o IP é convertido via iptables no IP público do mestre.

Parece haver um problema comum com uma configuração de ponte / netfilter sysctl, mas isso parece bom na minha instalação:

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

Estou com muita dificuldade para solucionar problemas, pois não compreendo para que serve o IP do serviço, como a rede de serviço deve funcionar em termos de fluxo de tráfego e qual a melhor maneira de depurar isso.

Então, aqui estão as perguntas que tenho:

Para que é utilizado o 1º IP da rede de serviço (10.3.0.1 neste caso)?A descrição acima do fluxo de tráfego está correta? Caso contrário, que etapas são necessárias para que um contêiner alcance um IP de serviço?Quais são as melhores maneiras de depurar cada etapa do fluxo de tráfego? (Não consigo ter idéia do que há de errado nos logs)

Obrigado!