top of page
Foto do escritorRafael Natali

Kubernetes Network na Prática - 1/3

Atualizado: 16 de fev.

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/bash

Usando o endereço IP do Pod

Primeiro, vamos enviar uma solicitação ICMP para um dos pods usando o comando ping:

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 ms

Enviamos 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 ms
tmp-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.


Referências

11 visualizações0 comentário

Comments


bottom of page