Padrões do Kubernetes

Para começar o Kubernetes é o mais conhecido e talvez o mais robusto sistema de orquestração de containers do mercado atual. Ele é um projeto da Cloud Native Computing Foundation que utiliza, gera e exige um conjunto de padrões para seu funcionamento. Não fossem esses padrões não haveria todo um ecossistema de fornecedores envolvidos nesse mercado interessados em prover soluções para ou através do k8s.

A alta modularidade do kubernetes propicia que diversos players diferentes criem soluções para ele, seja para prover rede, seja para prover soluções de storage, seja para rodar imagens, entre outros. Os Padrões do Kubernetes demonstrados aqui nesse artigo evidenciam porque o uso do Kubernetes pode reduzir o risco de obsolescência do produto uma vez que todo o mercado se move para suporta-lo, reduzindo assim o vendor lock-in.

OCI – Open Container Initiative

O OCI é um padrão da indústria que define se um container runtime está apto a ser como tal. Criado em 2015 por vários líderes da indústria de containers (tais como Red Hat, Docker, e outros), o OCI atualmente contém os seguintes tipos de especificação. Para encontrar mais detalhes sobre a especificação consulte o site Open Container Iniciative.

• a Runtime Specification (runtime-spec), definindo como devem ser os arquivos do container quando descompactados;
  
• a Image Specification (image-spec), definindo parâmetros como comandos, argumentos, variáveis de ambiente, e afins; formatos de manifesto, formato de serialização das camadas da imagem e formatos de configuração da imagem;
  
• Distribution Specification (distribution-spec e artifact), especificação relativamente nova (de maio de 2020), como uma forma mais generalista de definição sobre o aproveitamento de pacotes e distribuição em mecanismos desse tipo de conteúdo. Container registries implementam esse padrão estabelencedo bases para resiliência, escalabilidade e segurança na publicação de imagens.

O RunC, por exemplo, foi doado pela Docker para a Open Container Iniciative, servindo de base para a definição do padrão.

CRI – Container Runtime Interface

O CRI é uma interface definida para o uso de diversos runtimes diferentes para a mesma estrutura base de orquestração. Bem como o k8s está em conformidade do OCI os runtimes precisam estar estruturados para estarem em conformidade com essa interface. Sendo assim é possível trocar o runtime do kubernetes em tempo de execução sem necessidade de recompilação. Assim sendo, os exemplos mais conhecidos de container runtimes são: runC, containerD, CRI-O e crun (menos conhecido).

CNI – Container Network Interface

O CNI é uma interface para implementação de camada de rede nos containers. Ele é um projeto da CNCF, Cloud Native Computing Foundation, que define blibliotecas e referências para construção de tal infraestrutura. Por exemplo, no kubernetes, para que uma aplicação – instalada em um pod – possa falar com outra aplicação é necessário o uso de rede. Essa infraestrutura não é definida a priori pelo k8s: na configuração do k8s é necessário instalar uma ferramenta que forneça rede de modo adequado com as suas necessidades (não é necessário instalar nada em sistemas gerenciados como AKS, EKS, GKE, etc.)

Há diversos players no mercado que criam soluções em conformidade com a CNI, tais como: Calilo, Canal, Cilium, Flannel, Kube-router, WeaveNet, etc.

CSI – Container Storage Interface

O CSI é um padrão da indústria que auxilia fornecedores de solução de storage a proverem produtos que funcionem em diferentes container runtimes. Desse modo uma Amazon, por exemplo, ao fornecer suas soluções de storage precisam fazer apenas um plugin baseado em CSI para funcionar em qualquer orquestrador que implemente esse padrão.

De forma semelhante a outros padrões do kubernetes esse padrão estabelece conceitos como Volume, Mounted Volume, Storage Provider e afins. Há vários itens que estruturam a especificação no repositório do Container Storage Interface. Mas há também na própria página do Kubernetes uma grande lista com storages compatíveis com a CSI, tais como: Cephfs, hostPath, NFS; storages de players como AWS, Azure, Google, entre outros.

SMI – Service Mesh Interface

O SMI é uma especificação feita exclusivamente para o Kubernetes lidar com questões de Service Mesh. Com esse padrão se estabelece de que forma se garante segurança para o tráfego de rede entre os workloads, telemetria e todo seu gerenciamento. Há no mercado uma quantidade interessante de players que seguem esse padrão, tais como: Istio, Linkerd, Consul entre outros.

CPI – Cloud Provider Interface

O CPI é uma especificação estebelecida pelo próprio Kubernetes para implementação de clusters que se relacionam com estruturas de nuvem. O cloud-controller manager é o responsável por estabelecer uma relação de qualidade para as questões associadas a esse tema. A CPI separa os recursos da infraestrutura específicas da nuvem do núcleo do kubernetes, provendo o isolamento adequado. Além disso ela reforça padrões do kubernetes como:

• Estabelecimento de padrões para provisionamento de storage quando solicitado por um PV (Persistent Volume)
• Estruturação dos padrões para prover endereços IP externos para Services do tipo LoadBalancer
• Garantia de não gerar loops infinitos entre a cloud e o k8s com as seguintes estruturas: node control loop, route control loop, service control loop e custom control loop.

Conclusão

O Kubernetes é uma solução preparada para suportar flutuações de mercado e ainda assim ficando relevante. Os padrões do kubernetes e sua alta modularidade associada a seu uso de padrões fortes de indústria garantem todo um ecossistema resiliente que vai muito além dos workloads nele instalados.