Recursos personalizados
Nesta página
O Atlas Kubernetes Operator oferece suporte às seguintes definições de recursos personalizados:
Resource | Descrição | Nome curto |
---|---|---|
Configuração de uma Política de compliance de backup para proteger seus dados de backup. | abcp | |
Política de backup para fazer backup do seu Atlas cluster. | abp | |
Agendamento de backup para fazer backup do seu Atlas cluster. | abs | |
a custom database role to allocate privileges to your database users. | acr | |
Cluster dentro de algum projeto no Atlas. | ad | |
Usuário do banco de dados dentro de algum projeto no Atlas. | adu | |
Projeto no Atlas. | ap | |
Equipe de projeto no Atlas. | em | |
instância do banco de dados federado e seus endpoints privados no Atlas. | adf | |
Private endpoint connection from your chosen cloud provider to Atlas. | ape | |
Índice para alguma coleção em seu cluster do Atlas. | asic | |
Conexão Atlas Stream Processing. | asc | |
Instância de Atlas Stream Processing . | asi | |
Autenticação federada no Atlas. | afa |
Importante
Os Recursos Personalizados Não Excluem Mais Objetos por Padrão
O Atlas Kubernetes Operator usa arquivos de configuração de recurso personalizado para gerenciar sua configuração do Atlas , mas a partir do Atlas Kubernetes Operator 2.0, os recursos personalizados que você exclui no Kubernetes não são mais (por padrão) excluídos no Atlas. Em vez disso, o Atlas Kubernetes Operator simplesmente para de gerenciar estes recursos no Atlas. Por exemplo, se você excluir um
AtlasProject
Recurso Personalizado em Kubernetes, por padrão, o Atlas Kubernetes Operator não excluirá mais automaticamente o projeto correspondente do Atlas. Essa mudança no comportamento destina-se a ajudar a evitar exclusões acidentais ou inesperadas. Para saber mais, incluindo como reverter este comportamento para o padrão utilizado antes do Atlas Kubernetes Operator 2.0, consulte Novo Padrão: Proteção de Exclusão no Atlas Kubernetes 2 Operator.0.Da mesma forma, o Atlas Kubernetes Operator não exclui equipes do Atlas se você as remover de um projeto do Atlas no Kubernetes com o Atlas Kubernetes Operator.
Defina explicitamente os detalhes de configuração desejados para evitar o uso implícito de valores de configuração padrão do Atlas . Em alguns casos, herdar os padrões do Atlas pode resultar em um loop de reconciliação que pode impedir que seu recurso personalizado atinja um estado
READY
. Por exemplo, definir explicitamente o comportamento de autoscaling desejado em seu recurso personalizadoAtlasDeployment
, conforme mostrado no exemplo incluído, garante que um tamanho de instância estática em seu recurso personalizado não esteja sendo aplicado repetidamente a um sistema do Atlas que tenha o autoscaling ativado.autoScaling: diskGB: enabled: true compute: enabled: true scaleDownEnabled: true minInstanceSize: M30 maxInstanceSize: M40
Gerenciando o Atlas Kubernetes Operator com kubectl
Para listar todos os recursos do Atlas Kubernetes Operator em seu cluster com kubectl
, você pode executar:
kubectl get atlas
Para sua conveniência, para listar ou descrever tipos específicos de CRDs do Atlas Kubernetes Operator , você pode utilizar os nomes curtos listados na tabela acima. Por exemplo, para listar todos os atlasdatabaseusers
no namespace mongodb
, você pode executar:
kubectl get adu -n mongodb
Fluxo de trabalho do Atlas Kubernetes Operator
Ao utilizar o Atlas Kubernetes Operator, você pode criar um novo projeto do Atlas ou pode trabalhar com um projeto do Atlas existente.
Você precisa das seguintes informações da chave de API pública, chave de API privada e ID da organização para configurar o acesso do Atlas Kubernetes Operator ao Atlas.
Se você quiser que o Atlas Kubernetes Operator crie um novo projeto do Atlas , concedaacesso programático a uma organização. Se sua organização exigir uma lista de acesso IP para a API Atlas Administration, você também deverá configurar a lista de acesso da API.
Importante
Você deve atribuir a chave API ao role da organização Organization Project Creator ou superior.
Se você quiser trabalhar com um projeto Atlas existente, adicione acesso a um projeto. Se sua organização exigir uma lista de acesso IP para a API Atlas Administration, você também deverá configurar a lista de acesso da API.
Importante
Você deve atribuir à chave de API ao role de projeto Project Owner .
Para saber mais, consulte Configurar Acesso ao Atlas.
Processo de criação e atualização
Cada vez que você altera o campo spec
em qualquer um dos recursos personalizados suportados, o seguinte fluxo de trabalho é iniciado no Atlas Kubernetes Operator:
O Atlas Kubernetes Operator recebe um evento sobre o recurso personalizado alterado.
O Atlas Kubernetes Operator atualiza o campo
status.conditions
para refletir que o recurso não está pronto:conditions: - lastTransitionTime: "2021-03-13T16:26:17Z" status: "False" type: Ready Para se conectar à API de Administração do Atlas, o Atlas Kubernetes Operator lê o ID da organização e as chaves deAPI do de um dos seguintes locais:
spec.connectionSecretRef.name
(se especificado no Recurso PersonalizadoAtlasProject
).Por padrão, o Atlas Kubernetes Operator mantém segredos de conexão no mesmo namespace como o
AtlasProject
Recurso Personalizado. Para armazenar segredos em outro namespace, especifique o parâmetrospec.connectionSecretRef.namespace
.global
Segredo do Atlas Kubernetes Operator<operator-deployment-name>-api-key
(sespec.connectionSecretRef.name
não for especificado).
Para criar ou atualizar recursos no Atlas, o Atlas Kubernetes Operator utiliza as informações de conexão para fazer chamadas de API para o Atlas.
Observação
Às vezes, o Atlas Kubernetes Operator faz múltiplas chamadas de API no Atlas durante a reconciliação de um recurso personalizado. Por exemplo,
AtlasProject
tem uma configuração de lista de acesso IP para chamar a API correspondente.Se ocorrer algum erro durante a reconciliação,
status.conditions
será atualizado para refletir o erro.Exemplo
- lastTransitionTime: "2021-03-15T14:26:44Z" message: 'POST https://cloud.mongodb.com/api/atlas/v1.0/groups/604a47de73cd8cag77239021/accessList: 400 (request "INVALID_IP_ADDRESS_OR_CIDR_NOTATION") The address 192.0.2.1dfdfd5 must be in valid IP address or CIDR notation.' reason: ProjectIPAccessListNotCreatedInAtlas status: "False" type: IPAccessListReady Se a atualização for bem-sucedida,
status.conditions
reflete que o recurso está pronto:conditions: - lastTransitionTime: "2021-03-13T16:26:17Z" status: "True" type: Ready
Excluir processo
A partir do Atlas Kubernetes Operator 2.0, quando você exclui um recurso personalizado do Kubernetes, o objeto permanece no Atlas por padrão, mas o Atlas Kubernetes Operator não controla mais o objeto. Você pode reverter esse padrão para todo o seu sistema ou substituir esse padrão por um recurso personalizado específico por uma anotação para permitir que o Atlas Kubernetes Operator exclua o objeto correspondente do Atlas. Se você substituir por uma anotação, o seguinte fluxo de trabalho será iniciado:
O Atlas Kubernetes Operator recebe um evento sobre o recurso personalizado excluído.
Para se conectar à API de Administração do Atlas, o Atlas Kubernetes Operator lê o ID da organização e as chaves de API de um dos seguintes locais:
spec.connectionSecretRef.name
(se especificado no Recurso PersonalizadoAtlasProject
).Por padrão, o Atlas Kubernetes Operator mantém segredos de conexão no mesmo namespace como o
AtlasProject
Recurso Personalizado. Para armazenar segredos em outro namespace, especifique o parâmetrospec.connectionSecretRef.namespace
.global
Segredo do Atlas Kubernetes Operator<operator-deployment-name>-api-key
(sespec.connectionSecretRef.name
não for especificado).
Para excluir o recurso do Atlas, o Atlas Kubernetes Operator utiliza as informações de conexão para fazer chamadas de API para o Atlas.
Observação
O Atlas Kubernetes Operator remove quaisquer objetos relacionados criados no Kubernetes. Por exemplo, se você
AtlasDatabaseUser
remover o , o Atlas Kubernetes Operator removerá os segredos de conexão relacionados .
Usar anotações para ignorar ou substituir padrões
Você pode utilizar anotações para modificar o novo comportamento padrão do Atlas Kubernetes Operator.
Se você adicionar a
mongodb.com/atlas-resource-policy: "delete"
anotação ao de um recursometadata
personalizado, o Atlas Kubernetes Operator excluirá o objeto correspondente no Atlas quando você excluir o recurso do Atlas Kubernetes Operator.Exemplo
apiVersion: atlas.mongodb.com/v1 kind: AtlasProject metadata: name: my-project annotations: mongodb.com/atlas-resource-policy: "delete" Se você tiver revertido o novo comportamento de exclusão para o padrão usado antes do Atlas Kubernetes Operator 2.0, você poderá adicionar a
mongodb.com/atlas-resource-policy: "keep"
anotação ao de um recurso personalizadometadata
para que o Atlas Kubernetes Operator não exclua o recurso quando você excluir o Atlas Kubernetes Recurso do operador.Se você adicionar a
mongodb.com/atlas-reconciliation-policy: "skip"
anotação ao de ummetadata
recurso personalizado, o Atlas Kubernetes Operator não iniciará a reconciliação para o recurso. Essa anotação permite pausar a sincronização com a especificação até remover a anotação. Você pode usar essa anotação para fazer alterações manuais em um recurso personalizado e evitar que o Atlas Kubernetes Operator as desfaça durante uma sincronização. Quando você remove essa anotação, o Atlas Kubernetes Operator reconcilia o recurso e o sincroniza com a especificação.Se você adicionar a
mongodb.com/atlas-resource-version-policy: "allow"
anotação ao de ummetadata
recurso personalizado, o Atlas Kubernetes Operator permitirá que você use um recurso mesmo que o rótulo de versão não corresponda à versão do Atlas Kubernetes Operator que você está usando. Se a sua versão do recurso for uma versão principal atrás da versão do Atlas Kubernetes Operator, os recursos mais recentes podem não funcionar. As inconsistências de versão secundárias são compatíveis com versões anteriores.