Autorizar, instalar e reconciliar componentes

Autorizar o pedido exato

Um pedido tem identidade, verbo, grupo, recurso, subrecurso e âmbito. Uma Role com get em pods não concede automaticamente get em pods/log. Uma RoleBinding concede as permissões no seu namespace, mesmo quando referencia uma ClusterRole.

Para um ServiceAccount, confirma o namespace do sujeito; dois sujeitos com o mesmo nome em namespaces diferentes não são a mesma identidade. Compara a necessidade com a regra efetiva antes de adicionar privilégios. kubectl auth can-i ajuda a verificar uma operação, mas uma consulta com impersonation exige que o operador tenha essa autorização. Não uses cluster-admin como diagnóstico permanente.

Do chart ao serviço utilizável

Para instalar um componente, identifica a origem e versão do chart, os valores, o namespace e as dependências. Uma renderização local ajuda a inspecionar imagens, permissões e recursos resultantes; não demonstra aceitação pelo API server nem disponibilidade.

Guarda os valores efetivamente usados e consulta o estado da release e dos seus recursos após a instalação. Um timeout pode coexistir com objetos já criados. Antes de repetir, determina o que existe e qual é a estratégia de recuperação.

A saída de dry-run pode incluir Secrets: uma evidência partilhada deve preservar a informação operacional sem publicar credenciais. Flags e recuperação automática dependem da versão do Helm.

Bases e overlays com uma saída verificável

Uma base Kustomize expressa recursos comuns; um overlay acrescenta diferenças de um ambiente. Inspeciona a saída de kubectl kustomize antes de a aplicar: namespace, referências, imagem, selectors e labels devem continuar coerentes. O nome do diretório production não é uma proteção de acesso nem prova que a imagem é a pretendida.

Um patch pode selecionar zero recursos ou alterar um campo válido com um significado errado. Compara o resultado final com a intenção e com o objeto publicado. Na passagem de equipa, entrega a base, o overlay e a revisão exata, evitando depender de alterações locais não registadas.

API disponível e controlador capaz

Uma CRD permite ao API server reconhecer um tipo. O controller observa objetos e tenta realizar o estado pedido. Se um objeto personalizado existe sem o efeito esperado, verifica a instalação do controller, os logs, as permissões e as condições publicadas.

Um erro Forbidden ao criar Deployments aponta para o pedido do controller, não para a sintaxe já aceite da CRD. Corrige a permissão mínima no âmbito necessário e confirma depois o recurso dependente e a função. Quando um operador gere objetos, identifica essa autoridade antes de editar os objetos gerados; a reconciliação pode desfazer alterações manuais.

Armadilhas comuns

Confundir o sujeito da falha; conceder acesso global; tratar renderização como instalação; editar recursos reconciliados sem identificar o controller.