Please enable JavaScript.
Coggle requires JavaScript to display documents.
Deep Dive Kubernetes (Misc Part 2) - Coggle Diagram
Deep Dive Kubernetes (Misc Part 2)
CNI
Container Network Interface (CNI), ajuda a simplificar a rede de contêineres no Kubernetes. CNI é um padrão para interface de rede comum, descrevendo a interface mais simples possível entre o container runtime e a implementação da rede.
O Kubernetes visa conectar esses Pods de maneira contínua, agnóstica e roteável.
Para torná-lo um padrão aberto e evitar a construção de rodas próprias, a comunidade Kubernetes inicia o projeto CNI de código aberto para tornar as soluções de rede de contêineres integráveis com vários orquestradores e runtimes
CNI define uma solução genérica de rede baseada em plugins, onde também é fornecido um conjunto de plugins e bibliotecas. Ele cria uma camada abstrata entre a execução do contêiner e a rede.
Especificação CNI
A especificação descreve a interface entre os container runtimes e os plug-ins CNI
Também oferece a libcni para integração entre CNI e container runtimes
Plugins
Um grupo de plug-ins de criação de interface está integrado, como bridge, macvlan, vlan, ptp e assim por diante.
Os plugins são importantes para criar todos os recursos de rede necessários.
Kubernetes Network Model
Containers estão contidos em Pods. Esses aplicativos compartilham todos os recursos do cluster Kubernetes, incluindo CPU, memória e rede. No entanto, não podemos executar aplicativos com a mesma porta no mesmo nó. Isso é fisicamente impossível.
Diretrizes Kubernetes para rede
Cada pod obtém seu próprio endereço IP. O endereço IP que um pod se vê é exatamente o mesmo IP que outros pods o veem.
Este IP é único em todo um cluster. Todos os containers deste Pod compartilham este IP. Eles podem funcionar com portas diferentes. Para conseguir esse compartilhamento de IP para vários contêineres em um pod, há um contêiner de pausa (ou contêiner sandbox) para cada pod.
A finalidade deste contêiner de pausa é armazenar um namespace de rede (netns), que é compartilhado por todos os outros contêineres neste pod (IP-per-Pod)
Os pods podem usar endereços IP de pod para se comunicar com todos os outros pods em outros nós sem conversão de endereço de rede (NAT).
Agentes (como daemons de sistema, kubelet etc.) em um nó podem se comunicar com todos os pods nele.
Cenários possíveis
Container to container communications
Os contêineres dentro de um pod compartilham o namespace da rede, como endereço IP, portas, etc. Eles podem se comunicar entre si por meio do host local, pois residem no mesmo namespace da rede.
Pod to Pod communication (Intra-node)
Cada nó kubelet possui um intervalo CIDR designado para os pods em execução nele. Isso ajuda a garantir que os pods nunca tenham endereços IP sobrepostos.
Cada pod tem seu próprio namespace Ethernet. Para conectar namespaces Pod, podemos usar um dispositivo Ethernet virtual ou um par veth
Esse par veth canaliza duas interfaces virtuais e permite que o tráfego de rede flua entre elas. Para tornar os pods conectados entre si, uma bridge de rede virtual (por exemplo, cbr0) é usada para conectar essas interfaces virtuais.
Além disso, os pods podem se comunicar entre si por meio do namespace raiz usando o Address Resolution Protocol (ARP).
Pod to Pod communication (Inter-node)
Somente se pudermos garantir que cada pod tenha um IP exclusivo que não entre em conflito com pods em outro nó, teremos várias maneiras de fazer isso, como ARP entre nós (camada 2), roteamento IP entre nós (camada 3), redes de sobreposição, etc.
Service to Pod networking
No Kubernetes, os pods são efêmeros, pois podem ser ampliados ou reduzidos sob demanda. Eles também poderão ser excluídos a qualquer momento.
Kubernetes apresenta um Service conceitualmente para descrever um grupo de pods.
Podemos atribuir um endereço IP virtual estático que pode ser usado para acesso no cluster. Este endereço IP virtual está associado a vários IPs de pods de back-end.
O tráfego endereçado a esse IP virtual pode ter balanceamento de carga para o conjunto de pods de back-end.
External to cluster communication
CNI Plugins
O Container Runtime chama o plugin CNI para configurar a rede e gerenciar as interfaces
Plugins são executáveis binários do sistema que o Container Runtime executa, podem ser feitos em Go, Bash, etc.
Quando o container runtime (por exemplo, containerd) executa operações de rede em um contêiner, como criar ou excluir um contêiner, ele chama o plug-in CNI com o comando desejado
Vários plug-ins podem ser encadeados
Alguns desses plug-ins fornecem apenas recursos básicos, como adicionar e remover interfaces de rede, enquanto outros fornecem recursos mais sofisticados
Mesmo que precisemos implementar um, normalmente não o construímos do zero. Podemos construí-lo sobre outros plugins encadeados, como ptp, vlan, bridge, portmap, firewall, etc.
CRI
É o kubelet que transforma os Pods em um grupo de contêineres em execução. No entanto, o kubelet em si não gerencia diretamente o ciclo de vida dos contêineres, quem faz isso é o Container Runtime em um interface padrão, o que chamamos de CRI
O Container Runtime Interface (CRI) define o protocolo gRPC principal usado para comunicações entre o kubelet e um container runtime.
Protocol Buffers
RuntimeService
Fornece RPCs para gerenciar todo o ciclo de vida de pods e contêineres, como criar um contêiner sandbox ou excluir um contêiner. Outras interações (exec/attach/port-forward) com contêineres também são suportadas.
ImageService
Contém RPCs para gerenciar imagens de contêiner, como extrair uma imagem de um registro ou excluir uma imagem. Quaisquer container runtimes que implementem o CRI podem ser usados junto com o kubelet.
Como funciona
O CRI define um grupo de APIs, especificações e bibliotecas protobuf que permitem que o kubelet interaja com vários container runtimes para criar e executar contêineres.
Com o CRI, o kubelet pode se comunicar com qualquer container runtimes que seja compatível com a Open Container Initiative (OCI).
Um container runtimes inicial de baixo nível chamado
runc
também é fornecido. A maioria dos container runtimes, como containerd e CRI-O, são baseados nele.
Utilizando o Kind RuntimeClass podemos adicionar outros Container Runtimes no fluxo de criação de um container. Por exemplo, podemos utilizar o containerd como CRI, mas adicionar a criação o gvisor para validar a segurança da imagem que está sendo importada e configs básicas para serem validadas antes de executar na camada do Runc
É essencial tornar os container runtimes e kubelet fracamente acoplados. É por isso que o Container Runtime Interface (CRI) foi proposto.