Uma Primeira Visão das APIs de Serviço do Kubernetes

Prefácio

Sabemos que o Kubernetes tem várias soluções para expor serviços dentro do cluster, sendo uma das mais populares o Ingress, que é um padrão para expor serviços ao mundo externo e possui várias implementações de terceiros, cada uma com sua própria pilha tecnológica e dependências de gateways que não são compatíveis entre si.

Para unificar as diversas implementações de Ingress e facilitar a gestão uniforme no Kubernetes, a comunidade SIG-NETWORK lançou as Kubernetes Service APIs, um conjunto de implementações padrão chamado de Ingress de segunda geração.

Descrição do Assunto

Este artigo fornece uma introdução aos conceitos básicos das Kubernetes Service APIs, começando com algumas perguntas.

Introdução

As Kubernetes Service APIs são chamadas de segunda geração da tecnologia Ingress, mas em quais aspectos elas são melhores que a primeira geração

As Kubernetes Service APIs não foram projetadas para serem limitadas ao Ingress, mas sim para aprimorar a rede de serviços com foco nos seguintes aspectos: expressividade, escalabilidade e RBAC.

1. Mais funcionalidades, por exemplo, gerenciamento de tráfego com base no cabeçalho, peso.

kind: HTTPRoute
apiVersion: networking.x-k8s.io/v1alpha1
---
matches:
  - path:
      value: "/foo"
    headers:
      values:
        version: "2"
  - path:
      value: "/v2/foo"

2. Aprimorando a escalabilidade, as Service APIs introduzem o conceito de uma API de múltiplas camadas, com cada camada expondo sua própria interface, permitindo que outros recursos personalizados se conectem à API para um controle mais refinado (em nível de API).

3. RBAC orientado a funções: A realização de uma API de múltiplas camadas, uma das ideias é projetar objetos de recursos a partir da perspectiva dos usuários. Esses recursos serão eventualmente mapeados com as funções comuns de execução de aplicativos no Kubernetes.

Quais objetos de recursos são abstraídos pelas Kubernetes Service APIs

Com base nas funções dos usuários, as Kubernetes Service APIs definirão os seguintes recursos:

GatewayClass, Gateway, Route

1. GatewayClass define um conjunto de tipos de gateway com configuração e comportamento comuns:

• Relação com o Gateway, semelhante à anotação ingess.class no Ingress;
• Um GatewayClass define um grupo de gateways que compartilham a mesma configuração e comportamento. Cada GatewayClass será tratado por um único controlador, com o controlador tendo uma relação de um para muitos com o GatewayClass;
• GatewayClass é um recurso de cluster. Pelo menos um GatewayClass deve ser definido para ter um gateway funcional.

2. Gateway solicita um ponto onde o tráfego pode ser convertido em serviços dentro do cluster:

• O que faz: traz o tráfego de fora do cluster para dentro do cluster. Esta é a entidade de ingresso real;
• Define uma solicitação para uma configuração específica de LB, que também é a implementação da configuração e comportamento do GatewayClass;
• Os recursos de Gateway podem ser criados diretamente pelo operador ou pelo controlador que gerencia o GatewayClass;
• Gateway e Route têm uma relação de muitos para muitos.

3. Route descreve como o tráfego que passa por um gateway é mapeado para um serviço.

Além disso, as Kubernetes Service APIs definem um objeto de recurso BackendPolicy para permitir uma configuração flexível dos serviços de backend.

O objeto BackendPolicy permite configurar TLS, verificações de saúde e especificar o tipo de serviço de backend, como serviço ou pod.

Quais mudanças a introdução das Kubernetes Service APIs trará

As Kubernetes Service APIs, como um padrão de implementação, trazem as seguintes mudanças.

1. Generalidade: pode haver várias implementações, assim como há várias implementações de Ingress. Os controladores de Ingress podem ser personalizados de acordo com as características do gateway, mas todos têm uma estrutura de configuração consistente. Uma estrutura de dados pode ser usada para configurar vários controladores de Ingress.
2. O conceito de classes: GatewayClasses permite a configuração de diferentes tipos de implementações de balanceamento de carga. Essas classes permitem que o usuário entenda facilmente e explicitamente quais funções podem ser usadas como modelos de recursos.
3. Gateways compartilhados: Ao permitir que recursos de roteamento independentes HTTPRoute sejam vinculados ao mesmo GatewayClass, eles podem compartilhar balanceadores de carga e VIPs. Estratificado por usuário, isso permite que as equipes compartilhem a infraestrutura com segurança sem precisar se preocupar com a implementação específica do Gateway de nível inferior.
4. Referências de backend com tipos: Com referências de backend com tipos, as rotas podem referenciar Kubernetes Services, ou qualquer tipo de recurso Kubernetes projetado como backend de gateway, como um pod, ou um statefulset como um banco de dados, ou até mesmo um recurso externo acessível ao cluster.
5. Referências entre namespaces: Rotas em diferentes namespaces podem ser vinculadas a um Gateway, permitindo o acesso entre namespaces. Também é possível restringir o intervalo de namespaces que uma Rota sob um Gateway pode acessar.

Quais implementações de Ingress das Kubernetes Service APIs estão disponíveis atualmente

Os Ingress conhecidos por suportar os objetos de recurso das Kubernetes Service APIs no nível de código são Contour e ingress-gce.

Como as Kubernetes Service APIs gerenciam as permissões de leitura e escrita de recursos

As Kubernetes Service APIs são divididas em 3 funções com base na dimensão do usuário:

1. Provedor de infraestrutura GatewayClass;
2. Operador de cluster Gateway;
3. Desenvolvedor de aplicativos Route.

RBAC (Controle de Acesso Baseado em Funções) é o padrão usado para autorização no Kubernetes. Ele permite que os usuários configurem quem pode realizar operações em um intervalo específico de recursos. O RBAC pode ser usado para habilitar cada uma das funções definidas acima.

Na maioria dos casos, espera-se que todas as funções possam ler todos os recursos.

O modelo de três camadas tem as seguintes permissões de escrita.

Quais são os pontos de extensão das Kubernetes Service APIs

Os requisitos para gateways são muito ricos, e há muitas maneiras de implementar o mesmo cenário, cada uma com suas próprias vantagens e desvantagens. As Kubernetes Service APIs extraíram objetos de recursos de múltiplas camadas e também reservaram alguns pontos de extensão.

As Kubernetes Service APIs atualmente se concentram em Route:

• RouteMatch estende as regras de correspondência de Route.
• Especificar Backend estende tipos específicos de serviços de backend, como sistemas de arquivos, expressões de função, etc., além dos recursos Kubernetes mencionados acima.
• Filtro de Route adiciona extensões ao ciclo de vida da Route para lidar com solicitações/respostas.
• Se nenhuma das extensões acima puder ser satisfeita por uma Route personalizada, uma Route pode ser totalmente personalizada.

Resumo

Este artigo forneceu uma introdução básica às Kubernetes Service APIs por meio de perguntas. No geral, as Kubernetes Service APIs refinam muitas das melhores práticas do Ingress, como a expressividade aprimorada, que na verdade estende as capacidades da Route, e os objetos BackendPolicy, que podem especificar quase qualquer recurso de backend do Kubernetes para o upstream. As Kubernetes Service APIs atualmente especificam os objetos de recursos em um nível amplo, mas ainda há muitos detalhes dentro dos objetos de recursos que precisam ser discutidos antes que possam ser definidos para evitar possíveis cenários de conflito, e há certas variáveis na estrutura.