Estendendo a API do Kubernetes
Recursos personalizados são extensões da API do Kubernetes.
O Kubernetes fornece duas formas de adicionar recursos personalizados ao seu cluster:
- O mecanismo CustomResourceDefinition
(CRD) permite que você defina uma nova API personalizada de forma declarativa
com os campos
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
roda por trás do servidor da API primário, que age como um proxy.
Este arranjo é chamado de Agregação de API (API aggregation, ou AA), e permite
que você forneça implementações especializadas dos seus recursos personalizados
através da escrita e instalação de um servidor de API próprio.
A API principal delega as requisições para o seu servidor de API para as APIs
personalizadas que você especificar, fazendo com que fiquem disponíveis para
todos os seus clientes.
1 - Extendendo a API do Kubernetes com a camada de agregação
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.
Camada de agregação
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.
Latência da resposta
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.
Próximos passos