Considerações sobre o kro para o EKS - Amazon EKS

Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Considerações sobre o kro para o EKS

Este tópico aborda considerações importantes para o uso da funcionalidade do EKS para o kro, incluindo quando utilizar a composição de recursos, os padrões de RBAC e a integração com outras funcionalidades do EKS.

Situações para o uso do kro

O kro foi projetado para criar padrões de infraestrutura reutilizáveis e APIs personalizadas que simplificam o gerenciamento de recursos complexos.

Use o kro quando for necessário:

  • Criar plataformas de autoatendimento com APIs simplificadas para as equipes destinadas ao trabalho com APIs aplicação

  • Padronizar padrões de infraestrutura entre diferentes equipes (banco de dados + backup + monitoramento)

  • Gerenciar dependências de recursos e realizar a transferência de valores entre recursos

  • Desenvolver abstrações personalizadas que ocultam a complexidade da implementação

  • Compor diversos recursos do ACK em blocos de criação de nível superior

  • Habilitar fluxos de trabalho de GitOps para pilhas de infraestrutura complexas

Não use kro ao:

  • Gerenciar recursos simples e isolados (empregue recursos do Kubernetes ou do ACK diretamente)

  • Necessitar de lógica dinâmica de runtime (visto que o kro é declarativo, e não imperativo)

  • Lidar com recursos que não têm dependências nem configurações compartilhadas

O kro se destaca na criação de “caminhos pavimentados”, que são padrões opinativos e reutilizáveis que facilitam a implantação correta de infraestruturas complexas pelas equipes.

Padrões de RBAC

O kro permite a separação de responsabilidades entre as equipes responsáveis pela plataforma, que criam as ResourceGraphDefinitions, e as equipes responsáveis pela aplicação, que criam as instâncias.

Responsabilidades da equipe responsável pela plataforma

As equipes responsáveis pela plataforma criam e mantêm as ResourceGraphDefinitions (RGDs) que definem as APIs personalizadas.

Permissões necessárias:

  • Criar, atualizar e excluir ResourceGraphDefinitions

  • Gerenciar tipos de recursos subjacentes (como Deployments, Services e recursos do ACK)

  • Acessar a todos os namespaces nos quais as RGDs serão aplicadas

Exemplo de ClusterRole para a equipe responsável pela plataforma:

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: platform-kro-admin rules: - apiGroups: ["kro.run"] resources: ["resourcegraphdefinitions"] verbs: ["*"] - apiGroups: ["*"] resources: ["*"] verbs: ["get", "list", "watch"]

Para obter a configuração detalhada de RBAC, consulte Configuração de permissões do kro.

Responsabilidades da equipe responsável pela aplicação

As equipes responsáveis pela aplicação criam instâncias de recursos personalizados definidos por RGDs, sem a necessidade de compreender a complexidade subjacente.

Permissões necessárias:

  • Criar, atualizar e excluir instâncias de recursos personalizados

  • Ter um acesso de leitura ao próprio namespace

  • Não conseguir acessar os recursos subjacentes ou as RGDs

Benefícios:

  • As equipes usam APIs simplificadas de alto nível

  • As equipes responsáveis pela plataforma detêm o controle dos detalhes de implementação

  • Risco reduzido de erros de configuração

  • Integração mais rápida para os novos membros da equipe

Integração com outras funcionalidades do EKS

Composição de recursos do ACK

O kro torna-se especialmente eficiente ao ser integrado ao ACK para o desenvolvimento de padrões de infraestrutura.

Padrões comuns:

  • Aplicação com armazenamento: bucket do S3 + fila do SQS + configuração de notificação

  • Pilha de banco de dados: instância do RDS + grupo de parâmetros + grupo de segurança + segredo do Secrets Manager

  • Rede: VPC + sub-redes + tabelas de rotas + grupos de segurança + gateways NAT

  • Computação com armazenamento: instância do EC2 + volumes do EBS + perfil de instância do IAM

O kro gerencia a ordenação de dependências, transfere valores entre recursos (como ARNs e strings de conexão) e gerencia o ciclo de vida completo como uma unidade única.

Para obter exemplos da composição de recursos do ACK, consulte Conceitos do ACK.

GitOps com Argo CD

Use a funcionalidade do EKS para o Argo CD com a finalidade de implantar tanto RGDs quanto instâncias usando repositórios do Git.

Organização de repositórios:

  • Repositório de plataforma: contém as ResourceGraphDefinitions gerenciadas pela equipe responsável pela plataforma

  • Repositórios de aplicação: contêm instâncias de recursos personalizados gerenciadas pelas equipes responsáveis pela aplicação

  • Repositório compartilhado: contém tanto RGDs quanto instâncias para organizações de menor porte

Considerações:

  • Implante as RGDs antes das instâncias (os ciclos de sincronização do Argo CD podem ser úteis)

  • Use Projects distintos do CD Argo para as equipes responsáveis pela plataforma e pela aplicação

  • A equipe responsável pela plataforma controla o acesso ao repositório de RGDs

  • As equipes responsáveis pela aplicação têm acesso somente de leitura às definições de RGDs

Para saber mais sobre o Argo CD, consulte Como trabalhar com o Argo CD.

Organização de ResourceGraphDefinitions

Organize as RGDs por finalidade, complexidade e propriedade.

Por finalidade:

  • Infraestrutura: pilhas de banco de dados, rede e armazenamento

  • Aplicação: aplicativos web, APIs e trabalhos em lote

  • Plataforma: serviços compartilhados, monitoramento e registro em log

Por complexidade:

  • Simples: dois a três recursos com o mínimo de dependências

  • Intermediária: cinco a dez recursos com algumas dependências

  • Complexa: mais de dez recursos com dependências complexas

Convenções de nomenclatura:

  • Use nomes descritivos: webapp-with-database e s3-notification-queue

  • Inclua a versão no nome para alterações incompatíveis: webapp-v2

  • Use prefixos consistentes para RGDs relacionadas: platform- e app-

Estratégia de namespace:

  • As RGDs têm escopo de cluster (não pertencem a um namespace)

  • As instâncias pertencem a um namespace

  • Use seletores de namespace nas RGDs para controlar em qual local as instâncias podem ser criadas

Versionamento e atualizações

Planeje a evolução das RGDs e a migração de instâncias.

Atualizações de RGD:

  • Alterações compatíveis: atualize a RGD diretamente (adicione campos opcionais e novos recursos com includeWhen)

  • Alterações incompatíveis: crie uma nova RGD com um nome diferente (como webapp-v2)

  • Descontinuação: sinalize as RGDs antigas com anotações e comunique o cronograma de migração

Migração de instâncias:

  • Crie novas instâncias com a RGD atualizada

  • Valide se as novas instâncias funcionam corretamente

  • Exclua as instâncias antigas

  • O kro gerencia as atualizações dos recursos subjacentes automaticamente

Práticas recomendadas:

  • Teste as alterações de RGD primeiro em ambientes que não são de produção

  • Use o versionamento semântico nos nomes das RGDs para alterações significativas

  • Documente as alterações incompatíveis e os caminhos de migração

  • Forneça exemplos de migração para as equipes responsáveis pela aplicação

Validação e testes

Valide as RGDs antes de implantá-las em ambientes de produção.

Estratégias de validação:

  • Validação de esquema: o kro valida a estrutura da RGD automaticamente

  • Instâncias de simulação: crie instâncias de teste em namespaces de desenvolvimento

  • Testes de integração: verifique se os recursos compostos funcionam em conjunto

  • Aplicação de políticas: use controladores de admissão para aplicar padrões organizacionais

Problemas comuns em testes:

  • Dependências e ordenação de recursos

  • Transferência de valores entre recursos (expressões CEL)

  • Inclusão condicional de recursos (includeWhen)

  • Propagação de status provenientes de recursos subjacentes

  • Permissões de RBAC para criação de instâncias

Documentação original

Para obter informações detalhadas sobre o uso do kro:

Próximas etapas