Não é possível acessar um serviço do Kubernetes em um nó convidado

Question

Eu tentei executar o exemplo de livro de visitas no repositório Kubernetes Github, mas não consigo acessar este serviço a partir do meu host local. Meu ambiente de teste consiste em duas máquinas virtuais (com o CentOS7) provisionadas pelo CloudStack, com o OpenShift Origin instalado nele. Aqui está a lista de serviços:

    [root@openshift-master amd64]# ./oc get svc
NAME              CLUSTER-IP       EXTERNAL-IP   PORT(S)                   AGE
docker-registry   172.30.39.251    <none>        5000/TCP                  1d
guestbook         172.30.55.125    nodes         3000/TCP                  56m
kubernetes        172.30.0.1       <none>        443/TCP,53/UDP,53/TCP     1d
redis-master      172.30.24.94     <none>        6379/TCP                  1h
redis-slave       172.30.132.250   <none>        6379/TCP                  1h
router            172.30.33.117    <none>        80/TCP,443/TCP,1936/TCP   1d

O serviço exposto é o livro de visitas. Aqui está a descrição do livro de visitas do serviço:

[root@openshift-master amd64]# ./oc describe svc guestbook
Name:           guestbook
Namespace:      default
Labels:         app=guestbook
Selector:       app=guestbook
Type:           NodePort
IP:         172.30.55.125
Port:           <unset> 3000/TCP
NodePort:       <unset> 30642/TCP
Endpoints:      172.17.0.6:3000,172.17.0.7:3000,172.17.0.8:3000
Session Affinity:   None
No events.

Se eu fizer:

curl 172.30.55.125:3000

Funciona apenas a partir do nó que hospeda o pod de guestbook, dos outros nós do cluster e da minha máquina host (192.168.1.2) Não funciona.

Eu abri todas as portas no CloudStack, caso contrário eu não posso ssh os nós e no nó eu definir essa regra de firewall:

firewall-cmd --permanent --zone=public --add-port=30642/tcp

30642 é o NodePort, que é obrigatório para alcançá-lo a partir do cluster. Você tem alguma idéia sobre como resolver? Desde já, obrigado.

    

Answer 1

curl 172.17.0.6:3000 (ou seja, cada um dos Endpoints endereços) deve ser utilizável diretamente de cada nó do cluster. Se isso não funcionar, a rede do cluster não está configurada corretamente. Isso pode incluir qualquer firewall ou SDN que filtre pacotes enviados de um nó para outro.

172.30.55.125:3000 deve ter uma entrada na lista iptables em cada nó do cluster, mantida pelo daemon local kube-proxy em cada nó do cluster. Se o curling de um endpoint remoto funcionar, mas o uso do ip virtual e da porta falhar, é possível que kube-proxy não esteja funcionando. Verifique suas entradas do iptables, seu status de processo e seu arquivo de log.

Por último, é possível que o aplicativo de livro de visitas esteja de fato recebendo a conexão, mas ele está abortando ou bloqueando enquanto tenta uma pesquisa DNS reversa condenada.