View a markdown version of this page

Comparação da funcionalidade do EKS para o ACK em relação ao ACK autogerenciado - Amazon EKS
Diferenças em relação à versão original do ACKCaminho de migraçãoControladores de versão prévia e promoção automáticaPróximas etapas

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.

Comparação da funcionalidade do EKS para o ACK em relação ao ACK autogerenciado

A funcionalidade do EKS para o ACK é equivalente à dos controladores do ACK autogerenciados, porém apresenta vantagens operacionais significativas. Para obter uma comparação geral das funcionalidades do EKS em relação às soluções autogerenciadas, consulte Considerações sobre as funcionalidades do EKS. Este tópico se concentra nas diferenças específicas do ACK.

Diferenças em relação à versão original do ACK

A funcionalidade do EKS para o ACK se baseia na versão original dos controladores do ACK, porém apresenta diferenças na integração com o IAM.

Perfil de funcionalidade do IAM: a funcionalidade usa um perfil do IAM dedicado com uma política de confiança que permite o serviço capabilities.eks.amazonaws.com da entidade principal, e não o IRSA (perfis do IAM para contas de serviços). É possível anexar políticas do IAM diretamente ao perfil da funcionalidade, sem a necessidade de criar ou anotar contas de serviços do Kubernetes ou configurar provedores OIDC. Uma prática recomendada para casos de uso em ambientes de produção é configurar permissões de serviços usando o IAMRoleSelector. Consulte Configuração das permissões do ACK para obter mais detalhes.

Tags de sessão: o recurso gerenciado define automaticamente as tags de sessão em todas as solicitações da AWS API, permitindo controle de acesso e auditoria refinados. As tags incluem eks:eks-capability-arn, eks:kubernetes-namespace e eks:kubernetes-api-group. Isso difere do ACK autogerenciado, que não define essas tags por padrão. Consulte Configuração das permissões do ACK para obter detalhes sobre o uso de tags de sessão nas políticas do IAM.

Tags de recursos: a funcionalidade aplica tags padrão diferentes aos recursos da AWS do ACK autogerenciado. O recurso usa tags prefixadas eks: (comoeks:kubernetes-namespace, eks:eks-capability-arn) em vez das tags services.k8s.aws/ usadas pelo ACK autogerenciado. Consulte Considerações sobre o ACK para o EKS para obter a lista completa das tags de recursos padrão.

Compatibilidade de recursos: os recursos personalizados do ACK funcionam de forma idêntica à versão original do ACK, sem a necessidade de alterações nos arquivos YAML de recursos do ACK. A funcionalidade usa as mesmas APIs do Kubernetes e CRDs, portanto, ferramentas como o kubectl funcionam de maneira semelhante. A capacidade oferece suporte somente a controladores e recursos que estão disponíveis para o público geral (GA) no ACK upstream. A capacidade não inclui controladores que estão em versão prévia upstream. O status de um controlador pode mudar de versão prévia para GA upstream ao longo do tempo, e a capacidade pode então começar a gerenciá-lo automaticamente. Se você executar um controlador de versão prévia autogerenciado junto com a capacidade, revise Controladores de versão prévia e promoção automática antes de migrar.

Para obter a documentação completa do ACK e os guias específicos dos serviços, consulte a documentação do ACK no site do ACK.

Caminho de migração

É possível migrar de um ACK autogerenciado para a capacidade gerenciada com o mínimo de interrupção de seus recursos da AWS. A migração depende da eleição do líder do Kubernetes: o controlador autogerenciado e a capacidade disputam a mesma concessão, portanto, apenas um deles reconcilia um determinado recurso a qualquer momento. Para que isso funcione, ambos devem compartilhar uma concessão no mesmo namespace. A capacidade não toma à força a concessão de um controlador autogerenciado em execução, então você controla quando a transferência ocorre reduzindo a escala verticalmente do controlador autogerenciado.

Importante

Antes de começar, conceda ao perfil de capacidade do IAM permissões equivalentes às permissões que seus controladores autogerenciados usam atualmente. A capacidade é autenticada com um perfil de capacidade dedicado por meio da entidade principal de serviço capabilities.eks.amazonaws.com, e não por meio do mecanismo que seus controladores autogerenciados usam atualmente, como a Identidade de Pods do EKS e IRSA (consulte Configuração das permissões do ACK). Se o perfil de capacidade não tiver permissões, a capacidade adotará seus recursos. Ela então não consegue reconciliá-los e registra em log erros AccessDenied.

Conclua as etapas a seguir para fazer a migração. As etapas usam o controlador do S3 (ack-s3-controller) como exemplo. Repita-as para cada controlador ACK autogerenciado que você deseja migrar para a capacidade, substituindo o chart do Helm e o nome do controlador correspondente.

nota

A execução de um controlador autogerenciado junto com a capacidade deve ser um estado temporário durante a migração, não uma configuração de longo prazo. Enquanto ambos estão em execução, uma interrupção em qualquer um dos lados (como a implantação de uma capacidade ou uma atualização do controlador autogerenciado) pode liberar a concessão e permitir que o outro lado a adquira, fazendo com que a reconciliação alterne inesperadamente entre eles. Conclua a migração de cada controlador em vez de executá-lo autogerenciado junto com a capacidade indefinidamente.

  1. Habilite a eleição de líder em seu controlador ACK autogerenciado e transfira sua concessão para kube-system:

    helm upgrade --install ack-s3-controller \
  oci://public.ecr.aws/aws-controllers-k8s/s3-chart \
  --namespace ack-system \
  --set leaderElection.enabled=true \
  --set leaderElection.namespace=kube-system

    Você deve definir os dois valores. Nos charts do Helm do ACK, o sinalizador --leader-election-namespace só é aplicado quando leaderElection.enabled está true e a eleição de líder está desabilitada por padrão. Definir leaderElection.namespace sozinho não tem efeito. O controlador continua a executar sem concessão, e os dois controladores reconciliam os mesmos recursos ao mesmo tempo após a criação da capacidade. Isso se aplica a todos os gráficos de controladores de serviço do ACK, não apenas ao S3.

    Isso transfere a concessão do controlador para o kube-system, permitindo que a funcionalidade gerenciada se coordene com ele.

  2. Crie a capacidade do ACK no seu cluster (consulte Criação de uma funcionalidade do ACK). A capacidade é iniciada e disputa a concessão, mas o controlador autogerenciado ainda a mantém. Seu controlador autogerenciado continua reconciliando seus recursos, e a capacidade espera pela liderança em vez de forçar uma aquisição.

  3. Quando estiver tudo pronto para começar a migração, reduza a escala verticalmente do controlador autogerenciado para zero réplica. Isso libera a concessão para que a capacidade possa adquirir liderança e assumir a reconciliação:

    kubectl scale deployment ack-s3-controller \
  --namespace ack-system --replicas=0

    Depois de reduzir a escala verticalmente do controlador autogerenciado, a capacidade adquire a concessão e inicia a reconciliação, geralmente em pouco tempo. Aumentar a escala verticalmente do controlador autogerenciado não devolve a concessão a ele, pois a capacidade continua retendo e renovando a concessão. Para retornar a reconciliação ao controlador autogerenciado, aumente a escala verticalmente para pelo menos uma réplica e, em seguida, exclua a capacidade do ACK. Depois de excluir a capacidade, o controlador autogerenciado readquire a concessão e retoma a reconciliação.

    Na adoção, a capacidade aplica suas próprias tags de recursos padrão (prefixadas com eks:) no lugar das tags services.k8s.aws/ usadas pelo ACK autogerenciado (consulte Considerações sobre o ACK para o EKS). Espere um conjunto único de chamadas de API de marcação para os recursos adotados e atualize qualquer ferramenta de alocação de custos ou política que esteja inserida no prefixo de tag services.k8s.aws/.

  4. Verifique se a capacidade está íntegra e se assumiu a reconciliação de seus recursos. Confirme se os recursos indicam uma condição Synced de True e se a capacidade não está registrando em log erros AccessDenied.

  5. Depois de confirmar que a capacidade está gerenciando seus recursos corretamente, remova o controlador autogerenciado:

    helm uninstall ack-s3-controller --namespace ack-system

Com essa abordagem, ambos os controladores podem coexistir com segurança durante a migração. A capacidade gerenciada adota os recursos que antes eram gerenciados pelos controladores autogerenciados após você liberar a concessão, garantindo uma reconciliação contínua sem conflitos.

Controladores de versão prévia e promoção automática

A capacidade é compatível somente com controladores que estão disponíveis para o público em geral no ACK upstream. Um controlador de versão prévia hoje pode ser promovido para GA no projeto upstream posteriormente. Quando isso acontece, a capacidade começa a gerenciar o controlador de forma automática, sem nenhuma ação da sua parte.

Isso criará um risco se você executar um controlador de versão prévia autogerenciado em um cluster que também usa a capacidade para outros controladores. Você pode executar o controlador de versão prévia como uma única réplica com a eleição de líder desabilitada, porque não há outro controlador com o qual coordenar. Quando esse controlador é promovido para GA, a capacidade começa a gerenciá-lo. Nesse ponto, dois reconciliadores atuam nos mesmos recursos sem nenhuma concessão compartilhada para coordená-los. O resultado é o mesmo conflito de reconciliação dupla que as etapas de migração foram projetadas para evitar. Ambos os reconciliadores emitem chamadas de API concorrentes da AWS e gravam atualizações conflitantes no status do recurso personalizado.

Para evitar isso, antes de executar um controlador de versão prévia autogerenciado junto com a capacidade:

  • Habilite a eleição de líder no controlador de versão prévia autogerenciado e aponte sua concessão para kube-system, usando as mesmas configurações leaderElection.enabled=true e leaderElection.namespace=kube-system mostradas nas etapas de migração. Isso garante que, se o controlador for promovido e a capacidade assumir o controle, os dois se coordenarão por meio de uma concessão compartilhada, em vez de se reconciliarem em paralelo.

  • Acompanhe o status de GA upstream de todos os controladores de versão prévia dos quais você depende e planeje migrá-los seguindo o caminho de migração quando forem promovidos. Você pode verificar o status atual de cada controlador na página de serviços do ACK no site do ACK.

Próximas etapas