Definições de recursos personalizados (CRDs) são extensões da API do Kubernetes que podem definir novos tipos de objetos. Pods, ReplicaSets, ConfigMaps e Ingresses são exemplos de recursos integrados comuns. Os CRDs permitem adicionar tipos totalmente novos a essa lista e gerenciá-los com ferramentas conhecidas do Kubernetes, como o Kubectl.
O mecanismo CRD é intencionalmente abstrato e pode ser usado de inúmeras maneiras para armazenar dados e criar novas funções. Encontre recursos personalizados em muitas ferramentas populares da comunidade: Cert-Manager define objetos que representam certificados e emissores SSL, enquanto o Helm renderiza gráficos como seu próprio CRD.
índice
- O que um recurso faz?
- Criando um CRD
- Usando seu CRD
- Criando APIs declarativas com CRD
- Quando usar CRD?
- Resumo
O que um recurso faz?
Os recursos do Kubernetes definem os tipos de dados que você pode armazenar em seu cluster. Eles são acessados por meio da API do Kubernetes, que fornece endpoints para criar, listar e modificar itens em cada tipo de recurso.
Você pode adicionar recursos personalizados para armazenar seus próprios dados arbitrários em seu cluster. Os elementos que você criar serão armazenados pelo componente do plano de controle etcd, juntamente com instâncias de recursos internos. A API exibe recursos personalizados automaticamente, para que você não precise configurar suas próprias ferramentas para instanciar elementos.
Os CRDs atuam como estruturas de dados simples por padrão. Embora os CRDs na natureza geralmente tenham seus próprios comportamentos, o mecanismo de CRD não fornece isso. Os controladores e operadores personalizados do Kubernetes podem ser usados para implementar funções em torno de recursos personalizados. Sem um controlador, os itens em um CRD sempre existirão como dados estáticos no cluster com os quais você pode interagir por meio de endpoints CRUD fornecidos pela API do Kubernetes.
CRDs são componentes dinâmicos que podem ser criados e excluídos a qualquer momento. Alguns tipos de objetos fornecidos com o Kubernetes também são implementados como CRDs, fornecendo mais modularidade no núcleo do cluster.
Criando um CRD
Os CRDs são eles próprios um tipo de objeto Kubernetes. Você os cria da mesma forma que faria com qualquer outro recurso, escrevendo um arquivo YAML e aplicando-o ao seu cluster:
apiVersion : apiextensions.k8s.io/v1 tipo : CustomResourceDefinition metadados : name : custom-apps.crds.example.com spec : group : crds.example.com versões : - name : v1 servido : true storage : true schema : openAPIV3Schema : type : object properties : spec : type : object properties : app-name : type : string app-version : type : string release-count : type : integer scope : Namespaced names : plural : custom-apps singular : custom-app kind : Aplicativo personalizado
Use o Kubectl para adicionar o CustomApp CRD ao seu cluster:
$ kubectl apply -f custom-apps-crd.yaml customresourcedefinition.apiextensions.k8s.io/custom-apps.crds.example.com criado
O arquivo YAML define um CRD que pode ser usado para armazenar dados sobre aplicativos. Os CRDs precisam de um campo metadata.name e spec.group em um formato preciso: o grupo assume a forma de um subdomínio ao qual o CRD pertence. O mesmo subdomínio deve ser incluído no metadata.name do CRD. O valor de names.plural é anexado como um novo componente de subdomínio para construir o metadata.name final.
O campo spec.names define como fazer referência ao CRD ao usar a API Kubernetes e os comandos Kubectl. Neste exemplo, você poderá executar kubectl get custom-apps e kubectl get custom-app/example-app para interagir com objetos que usam o CRD. Ao criar um novo objeto como um arquivo YAML, você precisa definir kind: CustomApp para torná-lo uma instância do CRD.
O CRD é configurado como um tipo de objeto de nível de namespace pelo campo de scope . Você pode usar Cluster como um valor alternativo para este campo para criar objetos que existem no nível do cluster, fora de qualquer namespace.
Os dados associados a seus objetos customizados são definidos no campo spec.versions.schema.openAPIV3Schema . Cada "versão" listada cria uma nova versão da API CRD que você pode fazer referência com o campo apiVersion em seus arquivos YAML de recurso. Os dados CRD são configurados usando as propriedades OpenAPI; aqui, cada "aplicativo personalizado" em seu cluster deve ter as propriedades app-name , app-version e release-count definidas em sua spec YAML .
Usando seu CRD
Pode levar alguns minutos para que os endpoints da API de um novo CRD sejam provisionados. Verifique o progresso recuperando os detalhes do CRD com o Kubectl:
$ kubectl describe crd custom-apps.crds.example.com ... Status: Nomes aceitos: Tipo: CustomApp List Tipo: CustomAppList Plural: custom-apps Singular: custom-app Condições: Hora da última transição: 2022-04-04T13: 29:24Z Mensagem: nenhum conflito encontrado Motivo: NoConflicts Status: True Tipo: NamesAccepted Hora da última transição: 2022-04-04T13:29:24Z Mensagem: os nomes iniciais foram aceitos Motivo: InitialNamesAccepted Status: True Tipo: Estabelecido ...
O CRD está pronto para uso quando você vê Type: Established próximo ao final da saída do comando. O Kubernetes aceita solicitações para o endpoint da API CRD. Nesse caso, a URL base da API será a seguinte:
/apis/custom-apps.crds.example.com/v1/namespaces/*/custom-apps/...
Agora você pode usar o Kubectl para ver os objetos que foram criados com o CRD:
$ kubectl get custom-apps Nenhum recurso encontrado no namespace padrão.
Embora ainda não existam objetos, o Kubernetes agora sabe que possui um tipo de recurso chamado custom-apps .
Para criar um objeto "aplicativo personalizado", escreva um novo arquivo YAML com o kind: CustomApp . A apiVersion deve ser definida com o nome do grupo e a versão da API fornecida pelo CRD. Na seção de spec , inclua as propriedades que você definiu no esquema CRD.
apiVersion : crds.example.com/v1 kind : CustomApp metadata : name : demo-app-1 spec : app-name : demo-app app-version : 1.1.0 release-count : 5
Use o Kubectl para adicionar o objeto ao seu cluster:
$ kubectl apply -f custom-app.yaml customapp.crds.example.com/demo-app criado
Agora você pode recuperar os detalhes do objeto usando os comandos familiares do Kubectl:
$ kubectl describe custom-app/demo-app-1 Nome: demo-app Namespace: default Labels: <none> Anotações: <none> Versão da API: crds.example.com/v1 Tipo: CustomApp ... Spec: App - Nome: demo-app App - Versão: 1.1.0 Release - Contagem: 5 ... Eventos: <nenhum>
Você tem um recurso personalizado em execução que agora armazena alguns dados em seu cluster Kubernetes. Você pode remover o CRD excluindo-o no Kubectl; isso limpará automaticamente todos os objetos que o utilizam.
$ kubectl delete crd custom-apps.crds.example.com customresourcedefinition.apiextensions.k8s.io "custom-apps.crds.example.com" deletado
Criando APIs declarativas com CRD
Este CRD não adiciona nenhuma funcionalidade ao cluster. Ele armazena dados, fornece uma API para interagir com eles e pode ser referenciado por outros objetos. Os CRDs se tornam mais poderosos quando combinados com um controlador personalizado que pode assumir a responsabilidade de gerenciá-los.
Os controladores rastreiam recursos e agem em resposta a seus eventos. Escrever um controlador para seus CRDs permite transformá-los em APIs declarativas que causam mudanças reais em seu cluster. Seus objetos podem representar o estado desejado , em vez do estado atual exato.
O Cert-Manager usa esse modelo para adquirir certificados SSL automaticamente quando novos objetos CertificateRequest aparecem em seu cluster. No núcleo do Kubernetes, os nós extraem e executam imagens de contêiner em resposta à aparência dos pods. Os controladores permitem que você anexe comportamentos aos seus próprios CRDs, portanto, adicionar um "aplicativo personalizado" pode ter suas configurações extraídas de um serviço externo. Você pode começar a criar controladores usando o Go SDK para integrar seu próprio código ao tempo de execução do Kubernetes.
Quando usar CRD?
Os CRDs são melhor usados para gerenciar dados internos de sua organização, equipe ou projeto. Eles são projetados para representar esquemas claramente definidos, seja como valores estáticos ou APIs declarativas apoiadas por uma implementação de controlador personalizado.
Recursos avançados permitem que você implemente rotinas de validação para os campos em seu esquema. Você também pode usar finalizadores para lidar com exclusões de objetos e adotar o sistema de controle de versão para lidar com alterações em suas definições de CRD.
Às vezes, os CRDs se sobrepõem aos ConfigMaps do Kubernetes. Esses são objetos integrados para armazenar dados de configuração genéricos associados a seus aplicativos. Um ConfigMap é apropriado quando você vai consumir os valores em um local específico do seu cluster, como um pod que acessa as configurações do banco de dados como variáveis de ambiente injetadas de um ConfigMap.
Os CRDs devem ser usados quando os dados precisam ser um cidadão de primeira classe em seu cluster. Você pode criar várias instâncias do tipo de recurso CRD, interagir diretamente com elas usando o Kubectl e criar seus próprios esquemas estruturados que orientam os usuários a inserir os valores corretos. Eles podem ser uma escolha melhor quando os dados existem independentemente de qualquer outra coisa em seu cluster.
Resumo
As definições de recursos personalizados (CRDs) do Kubernetes definem novos tipos de objetos que você pode usar com a API do Kubernetes e o Kubectl. Cada CRD obtém sua própria API com versão, possui um esquema estruturado e pode ser usado para implementar novas funcionalidades no cluster quando apoiado por um controlador complementar.
Os CRDs às vezes podem parecer complicados e reservados para situações avançadas. Este não tem que ser o caso. CRDs simples para armazenar valores estáticos em seu cluster são fáceis de criar, conforme ilustrado no exemplo de "aplicativo personalizado" acima. Eles podem ser usados para armazenar dados de cluster separados para tratamento de primeira classe no Kubernetes.
Também é importante reconhecer onde os CRDs não são adequados. Objetos integrados, como ConfigMaps e Secrets, são projetados para acomodar a maioria das formas de configuração que serão usadas diretamente pelos pods do seu aplicativo. Escrever um CRD que defina o esquema do arquivo de configuração do seu aplicativo geralmente é desnecessário e mais complicado de manter ao longo do tempo, pois você não se beneficiará dos recursos do ConfigMap, como atualizações contínuas automáticas e injeção de variável de ambiente.
- Como atualizar para o Docker Compose v2
- Como fazer o Docker Compose esperar por contêineres de dependência
descubra mais conteúdo
Google Pixel Watch também tem detecção de queda, mas não até o próximo ano
As melhores xícaras de café aquecidas de 2022
Como automatizar seu iPhone com base na hora, atividade ou localização
"Isso deve ter sido antes do meu tempo"
Por que a NASA enviou Snoopy para a Lua? – Revisão Geek
O que é uma carga fantasma?
O que são Crds?
reembolso da dívida social ( CRDS ).
O que é cluster Kubernetes?
Um cluster Kubernetes é um conjunto de máquinas de nós que executam aplicativos em contêiner. Se estiver executando Kubernetes , você está executando um cluster . Um cluster contém pelo menos um plano de controle e uma ou mais máquinas ou nós de computação.
O que é um manifesto do Kubernetes?
Um arquivo de manifesto do Kubernetes inclui instruções em um arquivo yaml ou json que especifica como implantar um aplicativo nos nós em um cluster do Kubernetes .