Esta é a primeira parte de três artigos explicando e detalhando o modelo de rede do Kubernetes com uma abordagem prática. A série abordará a comunicação de Pod para Pod, a comunicação de Pod para Serviço e Ingress / Ingress Controllers. Estes artigos são baseados em um repositório que criei e que contém mais exemplos e conteúdo. Convido você a revisar o repositório em https://github.com/rafaelmnatali/kubernetes.
Comunicação de Pod para Pod
Como cada pod recebe um endereço IP "real" (não privado da máquina), os pods podem se comunicar sem proxies ou traduções dentro do cluster Kubernetes. Vamos ver isso na prática.
Vou usar o NGINX como exemplo:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: default
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
initContainers:
- name: init
image: busybox
command: ['sh', '-c', 'echo "Welcome to the home page of host $(hostname)!" > /usr/share/nginx/html/index.html']
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
containers:
- name: nginx
image: nginx
ports:
- name: http-web-svc
containerPort: 80
protocol: TCP
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
volumes:
- name: html
emptyDir: {}Aqui estão os Pods (versão resumida):
NAME READY STATUS RESTARTS AGE IP
nginx-6bfd886fb5-fvngf 1/1 Running 6 (30h ago) 9d 10.244.2.84
nginx-6bfd886fb5-n65xn 1/1 Running 6 (30h ago) 9d 10.244.2.82
nginx-6bfd886fb5-szz7q 1/1 Running 6 (30h ago) 9d 10.244.2.81 Use a imagem nicolaka/netshoot para realizar validações de rede.
kubectl run tmp-shell --rm -i --tty --image nicolaka/netshoot -- /bin/bashUsando o endereço IP do Pod
tmp-shell:~# ping -c1 10.244.2.84
PING 10.244.2.84 (10.244.2.84) 56(84) bytes of data.
64 bytes from 10.244.2.84: icmp_seq=1 ttl=64 time=0.544 ms
--- 10.244.2.84 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.544/0.544/0.544/0.000 msEnviamos com sucesso e recebemos uma resposta.
Como o NGINX é um web server, podemos usar o comando curl para enviar uma solicitação HTTP.
tmp-shell:~# curl 10.244.2.84
Welcome to the home page of host nginx-6bfd886fb5-fvngf!tmp-shell:~# curl 10.244.2.82
Welcome to the home page of host nginx-6bfd886fb5-n65xn!Podemos ver que ambas as solicitações foram bem-sucedidas. Cada solicitação se conecta a um Pod diferente e retorna a página inicial do servidor web.
Usando o Nome do Pod
Se tentarmos fazer ping no Pod usando o nome atribuído, receberemos um erro:
tmp-shell:~# ping -c1 nginx-6bfd886fb5-fvngf
ping: nginx-6bfd886fb5-fvngf: Name does not resolveÉ por que um Pod tem a seguinte resolução DNS:
pod-ip-address.my-namespace.pod.cluster-domain.example.Desta vez, use ping e curl com o nome DNS do Pod:
tmp-shell:~# ping -c1 10-244-2-84.default.pod.cluster.local
PING 10-244-2-84.default.pod.cluster.local (10.244.2.84) 56(84) bytes of data.
64 bytes from 10.244.2.84 (10.244.2.84): icmp_seq=1 ttl=64 time=0.169 ms
--- 10-244-2-84.default.pod.cluster.local ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.169/0.169/0.169/0.000 mstmp-shell:~# curl 10-244-2-84.default.pod.cluster.local
Welcome to the home page of host nginx-6bfd886fb5-fvngf!Ambos os comandos retornam os resultados esperados.
Resumo
Neste artigo, demonstrei dois exemplos de como e por que os Pods se comunicam entre si no Kubernetes. Esses comandos são úteis ao solucionar problemas de comunicação, onde precisamos garantir que os Pods se comuniquem independentemente de qualquer outro componente do Kubernetes, como um Service.
No entanto, se aplicativos em Pods diferentes precisarem se comunicar entre si, depender apenas do endereço IP não é a melhor prática. Em tais casos, devemos usar um Service. No próximo artigo, fornecerei alguns exemplos de como os Pods podem se comunicar com os Services.
Comentários