Pontos de extensão do Kubernetes
Diferentes maneiras de mudar o comportamento do seu cluster do Kubernetes.
O Kubernetes é altamente configurável e extensível. Como resultado, raramente existe a necessidade de criar um fork ou submeter alterações de código para o projeto Kubernetes.
Este guia descreve as opções para personalizar um cluster do Kubernetes. Este guia tem como público-alvo os operadores de clusters que desejam entender melhor como adaptar seus clusters às necessidades do seu ambiente de trabalho. Desenvolvedores que desejam tornar-se Desenvolvedores de Plataforma ou Contribuidores do Projeto Kubernetes também irão beneficiar-se deste guia como uma introdução aos pontos de extensão e padrões existentes, e suas contrapartidas e limitações.
As abordagens de personalização podem ser divididas nos grandes grupos de configuração, que envolve somente a modificação de argumentos de linha de comando, arquivos locais de configuração, ou recursos da API; e extensões, que envolve executar programas adicionais, serviços de rede adicionais, ou ambos. Este documento cobre primariamente as extensões.
Arquivos de configuração e argumentos de comando estão documentados na seção de Referência da documentação online, com uma página para cada binário:
Argumentos de comando e arquivos de configuração podem não ser sempre alteráveis em um serviço hospedado do Kubernetes ou uma distribuição com instalação gerenciada. Quando são alteráveis, geralmente são alteráveis somente pelo operador do cluster. Além disso, são suscetíveis a mudanças em versões futuras do Kubernetes, e modificá-los pode requerer a reinicialização de processos. Por essas razões, devem ser utilizados somente quando não houver outras opções.
APIs de política embutidas, como ResourceQuota, NetworkPolicy e Role-based Access Control (RBAC), são APIs embutidas do Kubernetes que fornecem configurações declarativas de políticas. APIs são tipicamente utilizáveis mesmo nos serviços hospedados do Kubernetes e com instalações gerenciadas do Kubernetes. As APIs de política embutidas seguem as mesmas convenções de outros recursos do Kubernetes, como os Pods. Quando você utiliza uma API de políticas que é estável, você se beneficia de uma política definida de suporte como outras APIs do Kubernetes. Por essas razões, as APIs de política são recomendadas antes de arquivos de configuração e de argumentos de comando quando adequadas.
Extensões são componentes de software que estendem e integram profundamente com o Kubernetes. Elas adaptam o Kubernetes para suportar novos tipos e novos modelos de hardware.
Muitos administradores de cluster utilizam uma instância hospedada ou de distribuição do Kubernetes. Esses clusters vêm com extensões pré-instaladas. Como resultado, a maioria dos usuários do Kubernetes não precisa instalar extensões e ainda menos usuários precisarão criar novas extensões.
O Kubernetes é projetado para ser automatizado através de programas cliente. Qualquer programa que lê e/ou escreve através da API do Kubernetes pode fornecer automação útil. Uma automação pode executar no cluster ou fora dele. Seguindo as orientações neste documento, você pode escrever automações altamente disponíveis e robustas. Automações geralmente funcionam em quaisquer clusters do Kubernetes, incluindo clusters hospedados e instalações gerenciadas.
Há um padrão específico para a escrita de programas cliente que funcionam bem
com o Kubernetes, denominado padrão controlador.
Controladores tipicamente leem o campo .spec de um objeto, possivelmente executam
ações, e então atualizam o campo .status do objeto.
Um controlador é um cliente da API do Kubernetes. Quando o Kubernetes é o cliente e faz uma chamada para um serviço remoto, o Kubernetes chama isso de um webhook. O serviço remoto é chamado de backend de webhook. Assim como controladores personalizados, os webhooks adicionam um ponto de falha.
No modelo webhook, o Kubernetes faz uma requisição de rede a um serviço remoto. Com o modelo alternativo de Plugin binário, o Kubernetes executa um binário (programa). Plugins binários são utilizados pelo kubelet (por exemplo, plugins de armazenamento CSI e plugins de rede CNI), e pelo kubectl (veja Estendendo o kubectl com plugins).
Este diagrama mostra os pontos de extensão em um cluster do Kubernetes e os clientes que o acessam.
Pontos de extensão do Kubernetes
Os usuários interagem com frequência com a API do Kubernetes utilizando o kubectl.
Plugins personalizam o comportamento dos clientes. Existem
extensões genéricas que podem ser aplicadas a diferentes clientes, bem como
formas específicas de estender o kubectl.
O servidor da API manipula todas as requisições. Diversos tipos de pontos de extensão no servidor da API permitem autenticar requisições ou bloqueá-las baseada no seu conteúdo, editar o conteúdo de uma requisição, e manipular a remoção de objetos. Estes pontos de extensão estão descritos na seção Extensões de Acesso de API.
O servidor da API serve diversos tipos de recursos. Tipos de recurso embutidos, como Pods, são definidos pelo projeto Kubernetes e não podem ser modificados. Consulte Extensões de API para saber mais sobre estender a API do Kubernetes.
O alocador do Kubernetes decide em qual nó alocar Pods. Há diversas formas de estender a alocação e tais formas estão descritas na seção de Extensões de Alocação.
Muito do comportamento do Kubernetes é implementado por programas chamados controladores, que são clientes do servidor da API. Controladores são frequentemente usados em conjunto com recursos personalizados. Consulte combinando novas APIs com automação e modificando recursos embutidos para saber mais.
O kubelet roda em servidores (nós) e auxilia Pods a parecerem como servidores virtuais com seus próprios IPs na rede do cluster. Plugins de Rede permitem diferentes implementações de redes de Pod.
Você pode utilizar Plugins de Dispositivo para integrar hardware personalizado ou outras instalações locais ao nó e torná-los disponíveis aos Pods rodando no seu cluster. O kubelet inclui suporte para trabalhar com estes plugins de dispositivo.
O kubelet também monta e desmonta volumes em Pods e seus contêineres. Você pode utilizar Plugins de Armazenamento para adicionar suporte a novos tipos de armazenamento e outros tipos de volume.
Se você não tem certeza de onde começar, este fluxograma pode auxiliar. Note que algumas soluções podem envolver vários tipos de extensões.
Fluxograma guia para seleção de uma abordagem de extensão
Plugins para o kubectl são binários que adicionam ou substituem funcionalidade
em comandos específicos. A ferramenta kubectl também pode integrar com os
plugins de credenciais.
Essas extensões afetam somente o ambiente local de um usuário, e portanto não podem
garantir políticas para vários dispositivos.
Se você deseja estender a ferramenta kubectl, leia Estenda o kubectl com plugins.
Considere adicionar um Recurso Personalizado ao Kubernetes se você deseja definir
novos controladores, objetos de configuração da aplicação ou outras APIs declarativas,
e gerenciá-los utilizando ferramentas do Kubernetes, como o kubectl.
Para mais informações sobre Recursos Personalizados, veja o guia de conceito Recursos Personalizados.
Você pode utilizar a Camada de Agregação da API do Kubernetes para integrar a API do Kubernetes com serviços adicionais, como um serviço de métricas.
Uma combinação de uma API de recurso personalizado e um ciclo de controle é chamado de padrão controlador. Se o seu controlador toma o lugar de um operador humano na instalação de infraestrutura baseada em um estado desejado, então o controlador pode também estar seguindo o padrão operador. O padrão operador é usado para gerenciar aplicações específicas; normalmente, essas são aplicações que mantém estado e requerem cuidado em como são gerenciadas.
Você pode também criar suas próprias APIs e ciclos de controle personalizados que gerenciam outros recursos, como armazenamento, ou para definir políticas (como uma restrição de controle de acesso).
Quando você estende a API do Kubernetes adicionando recursos personalizados, os recursos adicionados sempre caem em um novo grupo de API. Você não pode substituir ou modificar grupos de API existentes. Adicionar uma nova API não permite a você diretamente alterar o comportamento de uma API existente (como Pods), enquanto Extensões de Acesso de API permitem.
Quando uma requisição chega ao servidor da API do Kubernetes, ela é primeiro autenticada, depois é autorizada, e então é submetida a vários tipos de controle de admissão (algumas requisições não são autenticadas e recebem tratamento especial). Consulte a página Controlando Acesso à API do Kubernetes para mais informações sobre esse fluxo.
Cada uma das etapas no fluxo de autenticação/autorização do Kubernetes oferece pontos de extensão.
A Autenticação transforma cabeçalhos ou certificados em todas as requisições em um nome de usuário para o cliente efetuando a requisição.
O Kubernetes suporta diversas formas diferentes de autenticação embutida. Ele pode
ainda estar situado atrás de um proxy de autenticação, e pode enviar um token de
um cabeçalho Authorization: para um serviço remoto para verificação (um
webhook de autenticação)
se as formas embutidas não atenderem às suas necessidades.
A Autorização determina se usuários específicos podem ler, escrever, e fazer outras operações em recursos da API. Ela funciona no nível de recursos completos -- e não discrimina baseado em campos arbitrários de um objeto.
Se as opções de autorização embutidas não atenderem às suas necessidades, um webhook de autorização permite efetuar uma chamada para um código personalizado que faça uma decisão de autorização.
Após uma requisição ser autorizada, quando se tratar de uma operação de escrita, ela também passará pelas etapas de Controle de Admissão. Além das etapas embutidas, há várias extensões:
Plugins de dispositivo permitem a um nó descobrir novos recursos Node (além dos preexistentes, como cpu e memória) através de um Plugin de Dispositivo.
Os plugins de Interface de Armazenamento de Contêiner (Container Storage Interface, ou CSI) fornecem uma maneira de estender o Kubernetes com suporte a novos tipos de volumes. Os volumes podem ser suportados por um sistema de armazenamento externo durável, fornecer armazenamento efêmero, ou oferecer uma interface somente-leitura a informações utilizando um paradigma de sistema de arquivos.
O Kubernetes também inclui suporte aos plugins FlexVolume, que estão descontinuados desde a versão 1.23 (em favor do CSI).
Os plugins FlexVolume permitem aos usuários montar tipos de volumes que não são suportados nativamente pelo Kubernetes. Quando você executa um Pod que depende de armazenamento FlexVolume, o kubelet chama um plugin binário que monta o volume. A proposta de projeto arquivada do FlexVolume tem mais detalhes desta abordagem.
A seção de Perguntas Frequentes sobre Volumes do Kubernetes para Fornecedores de Armazenamento inclui informações gerais de plugins de armazenamento.
O seu cluster do Kubernetes precisa de um plugin de rede para que a rede de Pods funcione e para suportar outros aspectos do modelo de rede do Kubernetes.
Plugins de Rede permitem que o Kubernetes funcione com diferentes topologias e tecnologias de rede.
Kubernetes v1.26 [stable]
Os plugins conseguem comunicar-se com serviços externos ou utilizar arquivos locais para obter credenciais. Dessa maneira, o kubelet não precisa ter credenciais estáticas para cada registro de imagens e pode suportar diversos métodos e protocolos de autenticação.
Para detalhes de configuração de plugins, consulte Configurar um fornecedor de credenciais de imagem do kubelet.
O alocador é um tipo especial de controlador que observa Pods, e os atribui aos nós. O alocador padrão pode ser totalmente substituído, enquanto outros componentes do Kubernetes permanecem em uso, ou múltiplos alocadores podem rodar simultaneamente.
Este é um compromisso significativo e a maior parte dos usuários do Kubernetes percebem que não precisam modificar o alocador.
Você pode controlar quais plugins de alocação estão ativos ou associar conjuntos de plugins com diferentes perfis do alocador nomeados. Você pode também escrever seu próprio plugin que integra com um ou mais dos pontos de extensão do kube-scheduler.
Por fim, o componente embutido kube-scheduler suporta um
webhook
que permite a um backend HTTP remoto (extensão do alocador) filtrar e/ou
priorizar os nós que o kube-scheduler escolhe para um Pod.
Recursos personalizados são extensões da API do Kubernetes. O Kubernetes fornece duas formas de adicionar recursos personalizados ao seu cluster:
apiGroup, kind e o formato que você especificar.
A camada de gerenciamento do Kubernetes irá servir e controlar o armazenamento
do seu recurso personalizado. CRDs permitem que você crie novos tipos de recurso
para o seu cluster sem precisar escrever e executar um servidor da API personalizado.A camada de agregação permite ao Kubernetes ser estendido com APIs adicionais, para além do que é oferecido pelas APIs centrais do Kubernetes. As APIs adicionais podem ser soluções prontas tal como o catálogo de serviços, ou APIs que você mesmo desenvolva.
A camada de agregação é diferente dos Recursos Personalizados, que são uma forma de fazer o kube-apiserver reconhecer novas espécies de objetos.
A camada de agregação executa em processo com o kube-apiserver.
Até que um recurso de extensão seja registado, a camada de agregação
não fará nada. Para registar uma API, terá de adicionar um objeto APIService
que irá "reclamar" o caminho URL na API do Kubernetes. Nesta altura, a camada
de agregação procurará qualquer coisa enviada para esse caminho da API
(e.g. /apis/myextension.mycompany.io/v1/…) para o APIService registado.
A maneira mais comum de implementar o APIService é executar uma extensão do servidor API em Pods que executam no seu cluster. Se estiver a usar o servidor de extensão da API para gerir recursos no seu cluster, o servidor de extensão da API (também escrito como "extension-apiserver") é tipicamente emparelhado com um ou mais controladores. A biblioteca apiserver-builder providencia um esqueleto para ambos os servidores de extensão da API e controladores associados.
Servidores de extensão de APIs devem ter baixa latência de rede de e para o kube-apiserver. Pedidos de descoberta são necessários que façam a ida e volta do kube-apiserver em 5 segundos ou menos.
Se o seu servidor de extensão da API não puder cumprir com o requisito de latência,
considere fazer alterações que permitam atingi-lo. Pode também definir
portal de funcionalidade EnableAggregatedDiscoveryTimeout=false no kube-apiserver para desativar
a restrição de intervalo. Esta portal de funcionalidade deprecado será removido
num lançamento futuro.
Plugins de redes no Kubernetes podem ser dos seguintes tipos:
cbr0 básico usando os plugins CNI bridge e host-localO kubelet possui um plugin único padrão, e um plugin padrão comum para todo o cluster. Ele verifica o plugin quando inicia, se lembra o que encontrou, e executa o plugin selecionado em momentos oportunos dentro do ciclo de vida de um Pod (isso é verdadeiro apenas com o Docker, uma vez que o CRI gerencia seus próprios plugins de CNI). Existem dois parâmetros de linha de comando no Kubelet para se ter em mente quando usando plugins:
cni-bin-dir: O Kubelet verifica esse diretório por plugins na inicializaçãonetwork-plugin: O plugin de rede que deve ser utilizado do diretório configurado em
cni-bin-dir. Deve ser igual ao nome configurado por um plugin no diretório de plugins.
Para plugins de CNI, isso equivale ao valor cni.Além de prover a interface NetworkPlugin
para configuração da rede do pod, o plugin pode necessitar de suporte específico ao
kube-proxy.
O proxy iptables obviamente depende do iptables, e o plugin deve garantir que o
tráfego do contêiner esteja disponível para o iptables. Por exemplo, se o plugin
conecta os contêineres à Linux bridge, o plugin deve configurar a diretiva de
sysctl net/bridge/bridge-nf-call-iptables com o valor 1 para garantir que o
proxy iptables opere normalmente. Se o plugin não faz uso da Linux Bridge (mas outro
mecanismo, como Open vSwitch) ele deve garantir que o tráfego do contêiner é roteado
apropriadamente para o proxy.
Por padrão, se nenhum plugin de rede é configurado no kubelet, o plugin noop é utilizado,
que configura net/bridge/bridge-nf-call-iptables=1 para garantir que configurações simples
(como Docker com bridge Linux) operem corretamente com o proxy iptables.
O plugin de CNI é selecionado utilizando-se da opção --network-plugin=cni no início do Kubeket.
O Kubelet lê um arquivo do diretório especificado em --cni-conf-dir (padrão /etc/cni/net.d)
e usa a configuração de CNI desse arquivo para configurar a rede de cada Pod. O arquivo de
configuração do CNI deve usar a especificação de CNI,
e qualquer plugin referenciado nesse arquivo deve estar presente no diretório
--cni-bin-dir (padrão /opt/cni/bin).
Se existirem múltiplos arquivos de configuração no diretório, o kubelet usa o arquivo de configuração que vier primeiro pelo nome, em ordem alfabética.
Adicionalmente ao plugin de CNI especificado no arquivo de configuração, o Kubernetes requer
o plugin CNI padrão lo ao menos na versão 0.2.0.
O plugin de redes CNI suporta hostPort. Você pode utilizar o plugin oficial
portmap
ou usar seu próprio plugin com a funcionalidade de portMapping.
Caso você deseje habilitar o suporte a hostPort, você deve especificar
portMappings capability no seu cni-conf-dir.
Por exemplo:
{
"name": "k8s-pod-network",
"cniVersion": "0.4.0",
"plugins": [
{
"type": "calico",
"log_level": "info",
"datastore_type": "kubernetes",
"nodename": "127.0.0.1",
"ipam": {
"type": "host-local",
"subnet": "usePodCidr"
},
"policy": {
"type": "k8s"
},
"kubernetes": {
"kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
}
},
{
"type": "portmap",
"capabilities": {"portMappings": true},
"externalSetMarkChain": "KUBE-MARK-MASQ"
}
]
}
Funcionalidade experimental
O plugin de rede CNI também suporta o controle de banda de entrada e saída. Você pode utilizar o plugin oficial bandwidth desenvolvido ou usar seu próprio plugin de controle de banda.
Se você habilitar o suporte ao controle de banda, você deve adicionar o plugin bandwidth
no seu arquivo de configuração de CNI (padrão /etc/cni/net.d) e garantir que o programa
exista no diretório de binários do CNI (padrão /opt/cni/bin).
{
"name": "k8s-pod-network",
"cniVersion": "0.4.0",
"plugins": [
{
"type": "calico",
"log_level": "info",
"datastore_type": "kubernetes",
"nodename": "127.0.0.1",
"ipam": {
"type": "host-local",
"subnet": "usePodCidr"
},
"policy": {
"type": "k8s"
},
"kubernetes": {
"kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
}
},
{
"type": "bandwidth",
"capabilities": {"bandwidth": true}
}
]
}
Agora você pode adicionar as anotações kubernetes.io/ingress-bandwidth e
kubernetes.io/egress-bandwidth em seu pod.
Por exemplo:
apiVersion: v1
kind: Pod
metadata:
annotations:
kubernetes.io/ingress-bandwidth: 1M
kubernetes.io/egress-bandwidth: 1M
...
Kubenet é um plugin de rede muito simples, existente apenas no Linux. Ele não implementa funcionalidades mais avançadas, como rede entre nós ou políticas de rede. Ele é geralmente utilizado junto a um provedor de nuvem que configura as regras de roteamento para comunicação entre os nós, ou em ambientes com apenas um nó.
O Kubenet cria uma interface bridge no Linux chamada cbr0 e cria um par veth
para cada um dos pods com o host como a outra ponta desse par, conectado à cbr0.
Na interface no lado do Pod um endereço IP é alocado de uma faixa associada ao nó,
sendo parte de alguma configuração no nó ou pelo controller-manager. Na interface cbr0
é associado o MTU equivalente ao menor MTU de uma interface de rede do host.
Esse plugin possui alguns requisitos:
bridge, lo e host-local são obrigatórios, ao menos na
versão 0.2.0. O Kubenet buscará inicialmente esses plugins no diretório /opt/cni/bin.
Especifique a opção cni-bin-dir no kubelet para fornecer um diretório adicional
de busca. O primeiro local equivalente será o utilizado.--network-plugin=kubenet para habilitar esse plugin.--non-masquerade-cidr=<clusterCidr> para
garantir que o tráfego de IPs para fora dessa faixa seja mascarado.--pod-cidr configurada
na inicialização do kubelet, ou as opções --allocate-node-cidrs=true --cluster-cidr=<cidr>
utilizadas na inicialização do controller-manager.O MTU deve sempre ser configurado corretamente para obter-se a melhor performance de rede. Os plugins de rede geralmente tentam detectar uma configuração correta de MTU, porém algumas vezes a lógica não irá resultar em uma configuração adequada. Por exemplo, se a Docker bridge ou alguma outra interface possuir um MTU pequeno, o kubenet irá selecionar aquela MTU. Ou caso você esteja utilizando encapsulamento IPSEC, o MTU deve ser reduzido, e esse cálculo não faz parte do escopo da maioria dos plugins de rede.
Sempre que necessário, você pode configurar explicitamente o MTU com a opção network-plugin-mtu
no kubelet. Por exemplo, na AWS o MTU da eth0 geralmente é 9001 então você deve
especificar --network-plugin-mtu=9001. Se você estiver usando IPSEC você deve reduzir
o MTU para permitir o encapsulamento excedente; por exemplo: --network-plugin-mtu=8773.
Essa opção faz parte do plugin de rede. Atualmente apenas o kubenet suporta a configuração
network-plugin-mtu.
--network-plugin=cni especifica que devemos usar o plugin de redes cni com os
binários do plugin localizados em --cni-bin-dir (padrão /opt/cni/bin) e as
configurações do plugin localizadas em --cni-conf-dir (default /etc/cni/net.d).--network-plugin=kubenet especifica que iremos usar o plugin de rede kubenet
com os plugins CNI bridge, lo e host-local localizados em /opt/cni/bin ou cni-bin-dir.--network-plugin-mtu=9001 especifica o MTU a ser utilizado, atualmente apenas em uso
pelo plugin de rede kubenetOperadores são extensões de software para o Kubernetes que fazem uso de recursos personalizados para gerir aplicações e os seus componentes. Operadores seguem os princípios do Kubernetes, notavelmente o ciclo de controle.
O padrão operador tem como objetivo capturar o principal objetivo de um operador humano que está gerenciando um serviço ou conjunto de serviços. Operadores humanos que cuidam de aplicativos e serviços específicos possuem um conhecimento profundo de como o sistema deve se comportar, como implantá-lo e como reagir se houver problemas.
As pessoas que executam cargas de trabalho no Kubernetes muitas vezes gostam de usar automação para cuidar de tarefas repetitivas. O padrão do operador captura como você pode escrever código para automatizar uma tarefa além do que o próprio Kubernetes fornece.
O Kubernetes é projetado para automação. Por padrão, você tem bastante automação integrada ao núcleo do Kubernetes. Você pode usar o Kubernetes para automatizar a implantação e execução de cargas de trabalho, e pode automatizar como o Kubernetes faz isso.
O conceito de padrão operador do Kubernetes permite a extensão do comportamento sem modificar o código do próprio Kubernetes, vinculando controladores a um ou mais recursos personalizados. Os operadores são clientes da API do Kubernetes que atuam como controladores para um recurso personalizado.
Algumas das coisas que você pode automatizar usando um operador incluem:
Como seria um operador com mais detalhes? Aqui está um exemplo:
A maneira mais comum de implantar um operador é adicionar a definição personalizada de recurso (Custom Resource Definition) e o Controlador associado ao seu cluster. O Controlador normalmente é executado fora da camada de gerenciamento, assim como você executaria qualquer aplicação que rode em contêineres. Por exemplo, você pode executar o controlador no seu cluster como um Deployment.
Depois de implantar um operador, você o usaria adicionando, modificando ou excluindo o tipo de recurso que o operador usa. Seguindo o exemplo acima, você configuraria um Deployment para o próprio operador, e depois:
kubectl get SampleDB # encontrar banco de dados configurados
kubectl edit SampleDB/example-database # alterar manualmente algumas configurações
…e é isso! O Operador cuidará de aplicar as alterações, bem como manter o serviço existente em bom estado.
Se não houver um operador no ecossistema que implemente o comportamento desejado, você pode programar o seu próprio.
Você também pode implementar um operador (ou seja, um Controlador) usando qualquer linguagem/agente de execução que possa atuar como um cliente para a API do Kubernetes.
A seguir estão algumas bibliotecas e ferramentas que você pode usar para escrever seu próprio operador nativo de nuvem.