A E/S do cluster Kubernetes é uma grande bagunça, mas a ajuda está a caminho

A proliferação de interfaces, APIs e abstrações para entrada e saída do Kubernetes gerou vários desafios no mundo da orquestração de contêineres.

Não há outra maneira de descrever a grande proliferação de interfaces e abstrações para controlar o tráfego de rede que entra e sai, também chamado de entradas e saídas (E/S), nos clusters Kubernetes. É uma grande bagunça.

A boa notícia é que a comunidade está ciente disso e está trabalhando para melhorar as coisas.

Neste blog, discutiremos a proliferação e os esforços que estão sendo feitos para simplificar a paisagem.

Como chegamos aqui? Uma breve história da E/S do cluster Kubernetes

No início, havia apenas um recurso oficial de controle de entrada upstream para o Kubernetes, conhecido simplesmente como “entrada”. Era simples e tinha recursos mínimos que levaram à criação e implantação de vários outros recursos do controlador de entrada com diferentes recursos e APIs para interagir com eles.

O recurso de entrada original do Kubernetes está atualmente em processo de descontinuação em favor de um novo recurso de gateway e API que foram desenvolvidos no grupo de trabalho da Kubernetes SIG Network especificamente para lidar com a proliferação de implementações semelhantes, mas diferentes, de recursos de entrada.

Os gateways de API e as malhas de serviços compartilham a funcionalidade de entrada

À medida que as soluções de gerenciamento de API migraram para a nuvem e as soluções Kubernetes na forma de gateways de API, outro controle foi adicionado, que é funcionalmente um controlador de entrada. Além das cerca de uma dúzia de controladores de entrada do Kubernetes, há cerca de uma dúzia de gateways de API do Kubernetes que adicionam outra dimensão de complexidade e confusão aos usuários do Kubernetes.

Além disso, há as diversas implementações e APIs de service mesh que são efetivamente outra interface de entrada (na rede mesh implementada pelos proxies distribuídos). Todas as mesmas necessidades funcionais que abrangem controladores de entrada e gateways de API são necessárias para controlar o tráfego que entra e sai dos gateways de service mesh, onde a E/S de cluster ocorre em muitas redes de produção.

Resumindo, o estado atual da proliferação de interfaces e APIs em torno da E/S do cluster é a soma de todas essas diferentes implementações em todas as diferentes categorias de soluções.

As desvantagens da proliferação

Há duas grandes desvantagens nessa proliferação:

• O rápido crescimento de interfaces e APIs resultou em uma maior área de superfície de ataque, com vulnerabilidades de API se tornando mais predominante.
• O grande número de soluções disponíveis para controladores de entrada, gateways de API e funcionalidade de service mesh cria confusão e complicações para os usuários finais. Isso levou a um ambiente em que fornecedores e usuários precisam falar vários “idiomas” para fornecer suporte abrangente do Kubernetes para políticas de segurança.

À medida que mais soluções surgem no ecossistema Kubernetes, a funcionalidade das várias categorias de entrada e saída se sobrepõe cada vez mais. Essa sobreposição cria confusão para as pessoas que escolhem ferramentas e adiciona complexidade a um cenário já desafiador.

Por que o complexo ecossistema Kubernetes precisa de padronização de políticas

A Container Network Interface (CNI) define a API para enviar tráfego de rede intra-cluster entre pods, e há várias implementações interoperáveis populares, incluindo OVN, Calico, Cilium etc. Embora existam algumas extensões exclusivas nos diferentes produtos, elas compartilham um núcleo comum de recursos de política de rede que permitem aos operadores da plataforma especificar quais entidades habilitadas pela rede podem se comunicar e como.

As políticas de rede são otimizadas para fornecer um ambiente de negação padrão em que as regras de permissão são exceções a esse comportamento com base na identificação do tráfego com base em rótulos, namespaces, implantações e outros atributos de metadados nativos da nuvem. Esses são exatamente os tipos de funções primitivas que seriam uma boa base para a filtragem do tráfego que entra e sai dos clusters Kubernetes. No entanto, o CNI não tem escopo extra-cluster e, portanto, não houve compartilhamento dessa abordagem padronizada no mundo dos controladores de entrada e gateways de API.

As malhas de serviços tendem a ter ferramentas de política de filtragem de tráfego semelhantes que não têm uma abordagem padronizada em comparação com a política de rede definida para CNIs. O Service Mesh também introduz a filtragem e as listas de permissões da camada 7 que não foram consideradas no escopo das APIs da CNI e ainda não tiveram progresso na adoção no grupo de trabalho da CNI.

Esforços de padronização da comunidade Kubernetes

Para resolver esses problemas, os grupos estão adotando várias iniciativas para padronizar interfaces e APIs de entrada e saída. Isso inclui vários esforços importantes sob a liderança do Kubernetes Network Special Interest Group (SIG), incluindo o Network Policy Working Group, o Gateway Working Group e a GAMMA Initiative.

Grupo de Trabalho Gateway

O Gateway Working Group é responsável por desenvolver uma API unificada para gerenciar o tráfego de entrada e saída em clusters Kubernetes. O principal projeto do grupo é o API Kubernetes Gateway que foi projetado para fornecer uma API mais flexível e expressiva para configurar o tráfego de entrada e saída do Kubernetes6]]. Ao oferecer uma API padronizada, o Gateway Working Group visa simplificar o processo de implantação e gerenciamento de componentes de rede Kubernetes.

Ao oferecer uma API padronizada, o Gateway Working Group visa simplificar o processo de implantação e gerenciamento de componentes de rede Kubernetes.

API Kubernetes Gateway V1.0

A API Kubernetes Gateway foi projetada para resolver algumas das limitações e problemas associados ao recurso de entrada original. Esses aprimoramentos abordam as limitações do recurso de entrada original e fornecem uma abordagem mais eficiente e fácil de usar para gerenciar o tráfego de rede em ambientes Kubernetes.

Para saber mais sobre as principais melhorias do grupo, acesse estes recursos:

• Visão geral da API Kubernetes Gateway
• Guia rápido do novo Kubernetes API Gateway

Iniciativa GAMMA

O Iniciativa GAMMA (API de gateway, malha e middleware) é um esforço colaborativo entre vários SIGs do Kubernetes e partes interessadas do setor. Seu objetivo é consolidar e padronizar as APIs e interfaces usadas para o tráfego de entrada e saída do Kubernetes. Essa iniciativa visa reduzir a confusão e a complexidade para os usuários finais, facilitando a implantação e o gerenciamento de componentes de rede Kubernetes.

Grupo de trabalho de política de rede

O Grupo de Trabalho de Políticas de Rede se concentra na definição e implementação de políticas de rede para Kubernetes para aprimorar a segurança e o isolamento entre pods, serviços e outras entidades de rede em um cluster Kubernetes. Atualmente, ele suporta um rico conjunto de ferramentas para especificar o tráfego de rede. Ele é amplamente implementado por CNIs populares e, portanto, não é uma ferramenta aplicada ao tráfego de entrada/saída do cluster.

Atualmente, o grupo está trabalhando em vários projetos:

• Política administrativa de rede: fornece aos administradores de cluster mais controle sobre as políticas de rede, introduzindo um nível mais alto de abstração. Isso permite que os administradores definam políticas globais em todo o cluster que podem ser aplicadas de forma consistente em todos os namespaces.
• Política de rede V2: aborda as limitações na implementação atual da política de rede introduzindo novos recursos e estendendo a API existente, como suporte para filtragem de tráfego de saída, recursos aprimorados de correspondência de políticas e melhor aplicação de políticas para melhorar a segurança.

• NetworkPolicy++: introduzindo recursos avançados de política de rede estendendo a API de política de rede existente. Isso fornece um controle mais granular sobre gerenciamento de tráfego, segurança e isolamento, permitindo que os usuários criem políticas sofisticadas adaptadas às suas necessidades específicas.

A adoção comunitária está substituindo as organizações de padrões

No início deste blog, há referências a esforços para padronizar abstrações e APIs, mas isso não é necessariamente um endosso para fazer isso por meio de organizações de padrões tradicionais, como IETF, ITU, IEEE etc. As comunidades de código aberto votam com o tempo de seus desenvolvedores e sua base de código, portanto, alcançar a “padronização” de fato devido à ampla implantação comunitária é a medida mais importante de sucesso.

A introdução da API Kubernetes Gateway e a descontinuação do recurso de entrada são um exemplo de uma comunidade dedicada a melhorar sua plataforma de infraestrutura se unindo para fazer mudanças generalizadas sem obter nenhuma vantagem competitiva com esse investimento.

No momento da publicação deste blog, havia 19 projetos de controlador de entrada e service mesh de código aberto em vários estágios de desenvolvimento de sua implementação de API de gateway para substituir sua implementação personalizada anterior. A maioria deles está atualmente na versão beta e vários estão em disponibilidade geral (GA).

A implementação rápida e compartilhada é a nova forma de padronizar as interfaces de software na velocidade do desenvolvimento da comunidade. O trabalho que está sendo feito na Rede SIG não é um trabalho acadêmico; a comunidade demonstrou vontade de contribuir e, posteriormente, adotar as interfaces e APIs comuns definidas nos grupos de trabalho. Qualquer pessoa pode participar e contribuir como quiser.

Ainda há espaço para melhorias?

O trabalho atualmente em andamento no Network SIG eliminará grande parte da confusão de proliferação que existe atualmente em relação à E/S do cluster. No entanto, existem outras dimensões de confusão e complexidade que não foram alvo de alinhamento pela comunidade.

O trabalho da Iniciativa GAMMA de compartilhar recursos de entrada e APIs com o trabalho do grupo de trabalho da API de gateway ajuda muito a reconhecer que os requisitos funcionais da malha de serviço podem ser muito semelhantes aos de uma CNI, onde a entrada tradicional ocorre para quem não é malha de serviço.

Apesar desse trabalho, continua havendo uma sobreposição funcional entre a CNI e a malha de serviço que não está sendo alinhada. Nos primeiros dias, a CNI implementou políticas de rede de camadas para filtrar o tráfego nas camadas 3 e 4 e o service mesh filtrava exclusivamente um subconjunto desse tráfego observando apenas os elementos do protocolo da camada 7.

O grupo de trabalho de políticas de rede está desenvolvendo e padronizando a API que será adotada por todos os vários provedores da CNI, mas a maioria das soluções populares de service mesh também tem alguma forma não padronizada de API de política de filtragem das camadas 3 e 4. Ninguém planeja alinhar isso com o trabalho do Grupo de Trabalho de Políticas de Rede.

Ao mesmo tempo, não há um grupo equivalente tentando padronizar as APIs para filtragem da camada 7 que são implementadas de forma diferente por diferentes malhas de serviços (embora o uso compartilhado do Envoy Proxy de código aberto para a fiscalização da filtragem resulte em muita uniformidade). Organizacionalmente, pode ser difícil unificar as abstrações entre os diferentes artefatos de software (CNIs versus malhas de serviços) porque não há nenhum projeto autorizado a se preocupar com isso e implementá-lo. Do ponto de vista arquitetônico, isso faz sentido, mas a unificação pode assumir uma perspectiva de liderança do CNCF em vez de uma perspectiva centrada no projeto.

Onde tudo isso vai acabar?

Aceitar que a sobreposição funcional contínua entre CNIs e malhas de serviço é inevitável significa que o objetivo do Network SIG deve, em última instância, ser definir uma API comum para os recursos relevantes de segurança, gerenciamento de tráfego e roteamento, independentemente de serem implementados em algo empacotado como CNI, malha de serviço ou alguma outra forma de fornecer uma abstração de rede virtual.

Os especialistas em infraestrutura do Kubernetes levantarão algumas boas objeções com base nos princípios arquitetônicos que diferenciam um CNI de uma malha de serviços e ditam uma separação lógica de recursos e padrões. Mas, do ponto de vista da experiência do usuário, existe o risco de ficar surdo e expor os usuários do sistema a uma interface de baixo para cima, centrada no desenvolvedor de sistemas, que expõe os “nerds knobs”.

Se for natural que os usuários pensem que um provedor de CNI e uma malha de serviços implementam sua pilha e recursos de rede, isso pode melhorar o apelo da plataforma de compartilhar abstrações e APIs mais comuns. A política de rede tem um rico conjunto de primitivas de filtragem para selecionar tráfego e realizar ações condicionais. Ele poderia ser estendido e aprimorado para lidar com todas as regras de correspondência/ação abstratas e compatíveis com o Kubernetes para redes intra-cluster, entre clusters e extra-cluster.

Diga-nos o que você acha do valor das abstrações comuns em todos os casos de uso de processamento de tráfego. Se você se preocupa com esse tópico, fique de olho neste trabalho que está progredindo rapidamente e afetará muitos usuários do Kubernetes.

Saiba mais sobre Illumio de entrando em contato conosco hoje.