Redes Kubernetes: Pods

O material, cuja tradução publicamos hoje, é dedicado aos recursos da rede da lareira Kubernetes. Destina-se a quem já possui alguma experiência com o Kubernetes. Se você ainda não conhece muito bem o Kubernetes, provavelmente vale a pena ler este tutorial do Kubernetes antes de ler este material, onde trabalhar com esta plataforma é destinado a iniciantes.

Pods

O que há sob (pod) Kubernetes? Sub é uma entidade que consiste em um ou mais contêineres hospedados no mesmo host e configurados para compartilhar recursos da pilha de rede e outros recursos, como volumes. Os pods são os blocos de construção básicos que compõem aplicativos executados na plataforma Kubernetes. Os pods compartilham uma pilha de rede. Na prática, isso significa que todos os contêineres que compõem a lareira podem se comunicar através do localhost . Se houver um contêiner no forno que executa nginx, escutando na porta 80 e outro contêiner que executa scrapyd, esse contêiner pode acessar o primeiro contêiner em http://localhost:80 . Não parece tão difícil. Agora vamos nos perguntar como isso realmente funciona. Vamos dar uma olhada em uma situação típica quando o contêiner do Docker é iniciado na máquina local.


Contêiner do Docker em execução na máquina local

Se você observar esse esquema de cima para baixo, verifica-se que existe uma interface de rede física eth0 . A ponte docker0 está docker0 e a interface de rede virtual docker0 está veth0 à ponte. Observe que as veth0 e veth0 estão na mesma rede; neste exemplo, é 172.17.0.0/24 . Nesta rede, a interface docker0 recebe o endereço IP 172.17.0.1 , essa interface é o gateway padrão para a interface veth0 , que recebe o endereço 172.17.0.2 . Devido às peculiaridades da configuração de namespaces de rede ao iniciar o contêiner, os processos dentro do contêiner veem apenas a interface veth0 e interagem com o mundo externo por meio das interfaces docker0 e eth0 . Agora execute o segundo contêiner.


Dois contêineres do Docker em execução na máquina local

Como você pode ver no diagrama acima, a nova interface de rede virtual veth1 é atribuída ao segundo contêiner, que é conectado à mesma ponte que o primeiro contêiner - ao docker0 . Esta é uma descrição bastante concisa do que realmente está acontecendo. Além disso, deve-se observar que a conexão entre o contêiner e a ponte é estabelecida graças a um par de interfaces Ethernet virtuais conectadas, uma delas no espaço de nomes do contêiner e a outra no espaço de nomes da rede raiz. Detalhes sobre isso podem ser encontrados aqui .

Tudo isso é bom, mas ainda não descreve o que chamamos de pilha de rede compartilhada, conforme aplicada aos pods do Kubernetes. Felizmente, os namespaces são altamente flexíveis. O Docker pode iniciar um contêiner e, em vez de criar uma nova interface de rede virtual, fazer com que ele use a interface existente junto com outros contêineres. Com essa abordagem, teremos que alterar o esquema acima, como mostrado abaixo.


Os contêineres usam uma interface de rede comum

Agora, o segundo contêiner interage com a interface veth0 já existente, e não com sua própria interface veth1 , como no exemplo anterior. O uso de tal esquema leva a várias consequências. Para começar, agora podemos dizer que os dois contêineres são visíveis externamente no mesmo endereço - 172.17.0.2 , e dentro de cada um deles podem acessar as portas no localhost aberto por outro contêiner. Além disso, isso significa que esses contêineres não podem abrir as mesmas portas. Obviamente, isso é uma limitação, mas não difere de uma limitação semelhante na situação em que vários processos abrem portas no mesmo host. Com essa abordagem, um conjunto de processos obtém todas as vantagens associadas à execução desses processos em contêineres, como baixa conectividade e isolamento, mas, ao mesmo tempo, os processos podem organizar a colaboração no mais simples dos ambientes de rede existentes.

O Kubernetes implementa esse padrão criando um contêiner especial para cada lareira, cujo único objetivo é fornecer uma interface de rede para outros contêineres da lareira. Se você se conectar ao nó do cluster Kubernetes ao qual é atribuído um sub específico pelo ssh e executar o docker ps , verá pelo menos um contêiner em execução com o comando pause . Este comando pausa o processo atual até que um sinal SIGTERM chegue. Esses recipientes não fazem absolutamente nada, eles estão no estado "adormecido" e aguardam esse sinal. Apesar de os contêineres "suspensos" não fazerem nada, eles são, por assim dizer, o "coração" da lareira, fornecendo aos outros contêineres uma interface de rede virtual que eles podem usar para interagir entre si ou com o mundo externo. Como resultado, verifica-se que, em um ambiente hipotético semelhante a, nosso esquema anterior se pareceria com o mostrado abaixo.


Recipientes hipotéticos

Rede de lareira

Um deles, cheio de contêineres, é o alicerce de um determinado sistema, mas até agora não o próprio sistema. A arquitetura do Kubernetes é baseada no requisito de que os lares devem poder interagir com outros, independentemente de serem executados no mesmo computador ou em máquinas diferentes. Para aprender como tudo isso funciona, precisamos ir para um nível mais alto de abstração e conversar sobre como os nós funcionam no cluster Kubernetes. Aqui abordaremos o tópico roteamento e rotas de rede. Esse tópico geralmente é evitado em materiais como esse, considerando-o muito complexo. Não é fácil encontrar um guia compreensível e não muito longo para o roteamento IP, mas se você quiser ver uma breve visão geral desse problema, consulte este material.

O cluster Kubernetes consiste em um ou mais nós. Um nó é um sistema host, físico ou virtual, que contém várias ferramentas de software e suas dependências (principalmente o Docker), além de vários componentes do sistema Kubernetes. O nó está conectado à rede, o que permite trocar dados com outros nós no cluster. Aqui está a aparência de um cluster simples de dois nós.


Um cluster simples de dois nós

Se o cluster em questão estiver sendo executado em um ambiente de nuvem como GCP ou AWS, esse esquema transmitirá com precisão a essência da arquitetura de rede padrão para projetos individuais. Para fins de demonstração, a rede privada 10.100.0.0/24 usada neste exemplo. Como resultado, o endereço 10.100.0.1 atribuído ao 10.100.0.1 e os endereços 10.100.0.2 e 10.100.0.3 dois nós. Usando essa arquitetura, cada um dos nós pode interagir com o outro usando sua interface de rede eth0 . Agora, lembre-se de que under, em execução no host, não está nesta rede privada. É conectado à ponte em uma rede completamente diferente. Esta é uma rede virtual que existe apenas dentro de um nó específico. Para tornar mais claro, vamos redesenhar o esquema anterior, adicionando a ele o que chamamos de lareira hipotética acima.


Pods e nós

O host localizado à esquerda deste diagrama possui uma interface eht0 com o endereço 10.100.0.2 , cujo gateway padrão é o roteador com o endereço 10.100.0.1 . A ponte docker0 com o endereço 172.17.0.1 conectada a essa interface e a ela, através da interface virtual veth0 com o endereço 172.17.0.2 , está conectada ao que chamamos aqui de lareira. A interface veth0 foi criada em um contêiner suspenso. É visível nos três contêineres através de uma pilha de rede compartilhada. Devido ao fato de as regras de roteamento local serem configuradas ao criar a ponte, qualquer pacote que chegue a eth0 e tenha o endereço de destino 172.17.0.2 será redirecionado para a ponte, que o encaminhará para a interface virtual veth0 . Enquanto tudo isso parece bastante decente. Se for sabido que o host que estamos discutindo possui o endereço 172.17.0.2 , podemos adicionar uma regra às configurações do roteador que descrevem que a próxima transição para esse endereço é 10.100.0.2 , após a qual os pacotes a partir daí deverão ser redirecionados para veth0 . Excelente. Agora vamos dar uma olhada em outro host.

O host mostrado no diagrama à direita possui uma interface física eth0 com o endereço 10.100.0.3 . Ele usa o mesmo gateway padrão - 10.100.0.1 e, novamente, está conectado à ponte docker0 com o endereço 172.17.0.1 . Há um sentimento de que tudo não está indo tão bem. Este endereço, de fato, pode diferir daquele usado no host localizado à esquerda. Os endereços das pontes aqui são os mesmos para demonstrar o pior cenário possível, o que, por exemplo, pode ocorrer se você acabou de instalar o Docker e deixá-lo funcionar como bem entender. Mas, mesmo que as redes em questão sejam diferentes, nosso exemplo destaca um problema mais profundo: os nós geralmente não sabem nada sobre quais endereços privados são atribuídos a pontes localizadas em outros nós. E precisamos saber sobre isso - para poder enviar pacotes para essas pontes e ter certeza de que eles chegarão onde precisam. Obviamente, aqui precisamos de algum tipo de entidade, o que nos permite garantir a configuração correta de endereços em diferentes nós.

A plataforma Kubernetes fornece uma solução em duas etapas para esse problema. Primeiro, essa plataforma atribui um espaço de endereço comum para pontes em cada nó e, em seguida, atribui às pontes os endereços nesse espaço com base em qual nó a ponte está. Em segundo lugar, o Kubernetes adiciona regras de roteamento ao gateway localizado, no nosso caso, em 10.100.0.1 . Essas regras definem as regras para rotear pacotes destinados a cada uma das pontes. Ou seja, eles descrevem através da qual a interface física eth0 pode ser contatada com cada uma das pontes. Essa combinação de interfaces de rede virtual, pontes e regras de roteamento é comumente chamada de rede de sobreposição . Por falar em Kubernetes, costumo chamar essa rede de “rede de lareira”, pois é uma rede de sobreposição que permite que pods localizados em diferentes nós se comuniquem. Aqui está a aparência do diagrama anterior depois que os mecanismos do Kubernetes começarem a funcionar.


Rede de lareira

Imediatamente chama a atenção que os nomes da ponte foram alterados de docker0 para cbr0 . O Kubernetes não usa pontes padrão do Docker. O que chamamos de cbr é uma abreviação de “ponte personalizada”, ou seja, estamos falando de algumas pontes especiais. Não estou pronto para fornecer uma lista completa das diferenças entre executar contêineres do Docker em pods e executá-los em computadores comuns, mas o que estamos falando aqui é uma das importantes diferenças semelhantes. Além disso, você precisa prestar atenção ao fato de que o espaço de endereço atribuído às pontes neste exemplo é 10.0.0.0/14 . Esse endereço é obtido de um de nossos clusters de armazenamento temporário, implantados na plataforma Google Cloud. Portanto, o exemplo acima é um exemplo muito real de uma rede de lareira. Seu cluster pode receber um intervalo completamente diferente de endereços. Infelizmente, no momento não há como obter informações sobre esses endereços usando o utilitário kubectl , mas, por exemplo, se você usa o GCP, pode executar um comando como os gcloud container clusters describe <cluster> e observa a propriedade clusterIpv4Cidr .

Em geral, pode-se notar que você geralmente não precisa pensar em como a rede da lareira funciona. Quando uma sub-troca de dados com outra lareira, na maioria das vezes isso acontece através dos serviços Kubernetes. Este é um pouco de proxy definido por software. Mas os endereços de rede das lareiras aparecem nos logs. Em algumas situações, principalmente durante a depuração, pode ser necessário definir explicitamente as regras de roteamento nas redes da lareira. Por exemplo, o tráfego que deixa o Kubernetes vinculado a qualquer endereço no intervalo 10.0.0.0/8 não é processado por padrão usando o NAT. Portanto, se você interagir com serviços localizados em outra rede privada com o mesmo intervalo de endereços, pode ser necessário configurar regras de roteamento que permitam organizar a entrega correta dos pacotes.

Sumário

Hoje falamos sobre os pods do Kubernetes e os recursos de suas redes. Esperamos que este material ajude você a tomar as medidas corretas para implementar cenários complexos de interação da lareira nas redes Kubernetes.

Caros leitores! Este artigo é o primeiro de uma série de redes Kubernetes. A segunda parte deste ciclo já foi traduzida . Estamos pensando em traduzir a terceira parte. Pedimos que você comente sobre isso nos comentários.