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 as funcionalidades do EKS
Este tópico aborda considerações importantes para o uso das funcionalidades do EKS, incluindo o planejamento do controle de acesso, a escolha entre as funcionalidades do EKS e as soluções autogerenciadas, os padrões de arquitetura para implantações em vários clusters e as práticas recomendadas de operação.
Perfis do IAM para a funcionalidade e controle de acesso RBAC do Kubernetes
Cada recurso de funcionalidade do EKS tem um perfil do IAM para a funcionalidade configurado. O perfil da funcionalidade é usado para conceder permissões de serviços da AWS às funcionalidades do EKS para agirem em seu nome. Por exemplo, para usar a funcionalidade do EKS para o ACK gerenciar buckets do Amazon S3, você concederá permissões administrativas de buckets do S3 à funcionalidade, permitindo que ela crie e gerencie buckets.
Após a configuração da funcionalidade, é possível criar e gerenciar recursos do S3 na AWS usando recursos personalizados do Kubernetes no cluster. O RBAC do Kubernetes atua como um mecanismo de controle de acesso no cluster, definindo quais usuários e grupos têm permissão para criar e gerenciar esses recursos personalizados. Por exemplo, conceda a usuários e grupos específicos do RBAC do Kubernetes permissões para criar e gerenciar recursos de Bucket nos namespaces que você escolher.
Assim, o IAM e o RBAC do Kubernetes atuam como duas metades de um sistema de controle de acesso completo, que gerencia as permissões vinculadas às funcionalidades do EKS e aos seus recursos. É fundamental definir a combinação adequada de permissões do IAM e de políticas de acesso do RBAC para atender ao seu caso de uso.
Para obter informações adicionais sobre perfis do IAM de funcionalidades e permissões do Kubernetes, consulte Considerações sobre segurança para funcionalidades do EKS.
Padrões de arquitetura de vários clusters
Ao implantar funcionalidades em vários clusters, considere estes padrões arquiteturais comuns:
Modelo hub-and-spoke com gerenciamento centralizado
Execute todas as três funcionalidades em um cluster com gerenciamento centralizado para orquestrar workloads e gerenciar a infraestrutura de nuvem em vários clusters de workload.
-
O Argo CD, no cluster de gerenciamento, implanta aplicações nos clusters de workload em diferentes regiões ou contas.
-
O ACK, no cluster de gerenciamento, provisiona recursos da AWS (como RDS, S3 e IAM) para todos os clusters.
-
O kro, no cluster de gerenciamento, cria abstrações de plataforma portáveis que funcionam em todos os clusters.
Esse padrão centraliza o gerenciamento de workloads e da infraestrutura de nuvem, podendo simplificar as operações para organizações que gerenciam muitos clusters.
GitOps descentralizadas
As workloads e a infraestrutura de nuvem são gerenciadas pelas funcionalidades no mesmo cluster em que as workloads estão sendo executadas.
-
O Argo CD gerencia os recursos de aplicações no cluster local
-
Os recursos do ACK são usados para atender às necessidades do cluster e das workloads.
-
As abstrações de plataforma do kro são instaladas e orquestram recursos locais.
Esse padrão descentraliza as operações, com equipes responsáveis pelo gerenciamento dos próprios serviços de plataforma dedicados a um ou mais clusters.
Modelo hub-and-spoke com implantação híbrida do ACK
Combine modelos centralizados e descentralizados, com implantações de aplicações centralizadas e gerenciamento de recursos baseado em escopo e em propriedade.
-
Cluster de hub:
-
Argo CD gerencia implantações de GitOps no cluster local e em todos os clusters de workload remotos.
-
O ACK é usado no cluster de gerenciamento para recursos de escopo administrativo (como bancos de dados de produção, perfis do IAM e VPCs).
-
O kro é usado no cluster de gerenciamento para abstrações de plataforma reutilizáveis.
-
-
Clusters de spoke:
-
As workloads são gerenciadas por meio do Argo CD no cluster centralizado do hub.
-
O ACK é usado localmente para recursos de escopo da workload (como buckets do S3, instâncias do ElastiCache e filas do SQS).
-
O kro é usado localmente para composições de recursos e padrões de blocos de criação.
-
Esse padrão separa responsabilidades: equipes responsáveis pela plataforma gerenciam a infraestrutura crítica de forma centralizada nos clusters de gerenciamento (opcionalmente incluindo clusters de workload), enquanto equipes responsáveis pela aplicação definem e administram recursos de nuvem juntamente com as workloads.
Escolha de um padrão
Considere estes fatores ao selecionar uma arquitetura:
-
Estrutura organizacional: equipes responsáveis pela plataforma centralizadas geralmente optam por padrões de hub, enquanto equipes descentralizadas podem preferir funcionalidades por cluster
-
Escopo dos recursos: recursos de escopo administrativo, como bancos de dados e perfis do IAM, costumam se beneficiar de um gerenciamento centralizado; recursos de workload, por sua vez, como buckets e filas, podem ser administrados localmente
-
Autoatendimento: equipes responsáveis pela plataforma centralizadas podem desenvolver e distribuir recursos personalizados prescritivos, possibilitando o autoatendimento seguro de recursos de nuvem para demandas comuns de workloads
-
Gerenciamento da frota de clusters: clusters de gerenciamento centralizados fornecem um ambiente de gerenciamento de propriedade do cliente para o gerenciamento da frota de clusters do EKS, juntamente com outros recursos de escopo administrativo
-
Requisitos de conformidade: algumas organizações requerem controle centralizado para fins de auditoria e governança
-
Complexidade operacional: menos instâncias de funcionalidades simplificam as operações, mas podem gerar gargalos
nota
É possível começar a usar um padrão e migrar para outro à medida que a plataforma se desenvolve. As funcionalidades são independentes, permitindo que você as implante de formas diferentes em clusters distintos, de acordo com suas necessidades.
Comparação entre funcionalidades do EKS e soluções autogerenciadas
As funcionalidades do EKS oferecem experiências totalmente gerenciadas para ferramentas e controladores populares do Kubernetes que são executadas no EKS. Isso difere das soluções autogerenciadas, que precisam ser instaladas e gerenciadas diretamente no cluster.
Principais diferenças
Implantação e gerenciamento
As funcionalidades do EKS são totalmente gerenciadas pela AWS, sem necessidade de instalação, configuração ou manutenção do software dos componentes. A AWS instala e gerencia automaticamente todas as definições de recursos personalizados (CRDs, na sigla em inglês) do Kubernetes necessárias no cluster.
Com soluções autogerenciadas, você instala e configura o software do cluster usando charts do Helm, kubectl ou outros operadores. Nas soluções autogerenciadas, você mantém controle total sobre o ciclo de vida do software e a configuração do runtime, possibilitando personalizações em todas as camadas da solução.
Operações e manutenção
A AWS gerencia a aplicação de patches e outras operações do ciclo de vida do software para as funcionalidades do EKS, com atualizações automáticas e patches de segurança. As funcionalidades do EKS são integradas aos recursos da AWS para configurações simplificadas, oferecem alta disponibilidade e tolerância a falhas incorporadas e eliminam a necessidade de solução de problemas de workloads de controladores dentro do cluster.
As soluções autogerenciadas requerem que você monitore a integridade dos componentes e dos logs, aplique patches de segurança e atualizações de versão, configure alta disponibilidade com várias réplicas e budgets de interrupção de pods, realize a solução e a correção de problemas em workloads de controladores, e gerencie lançamentos e versões. Você tem controle total sobre as implantações, mas isso geralmente exige soluções sob medida para acesso a clusters privados e outras integrações, que devem estar alinhadas aos padrões organizacionais e aos requisitos de conformidade da segurança.
Consumo de recursos
As funcionalidades do EKS são executadas no EKS e de forma externa aos clusters, liberando tanto recursos de nós quanto recursos de cluster. As funcionalidades não usam recursos de workloads do cluster, não consomem CPU ou memória nos nós de processamento, escalam automaticamente e têm impacto mínimo no planejamento de capacidade do cluster.
As soluções autogerenciadas executam controladores e outros componentes nos nós de processamento, consumindo diretamente recursos desses nós, IPs do cluster e outros recursos do cluster. O gerenciamento de serviços do cluster exige planejamento de capacidade para as workloads, além de planejamento e configuração de solicitações e limites de recursos para atender aos requisitos de escalabilidade e de alta disponibilidade.
Suporte a recursos
Por serem recursos de serviço totalmente gerenciados, as funcionalidades do EKS são naturalmente opinativas quando comparadas às soluções autogerenciadas. Apesar de as funcionalidades oferecerem suporte à maior parte dos recursos e casos de uso, a abrangência será diferente quando comparadas às soluções autogerenciadas.
Com as soluções autogerenciadas, você tem controle total sobre a configuração, os recursos opcionais e outros aspectos da funcionalidade do software. É possível executar imagens personalizadas próprias, ajustar todos os aspectos da configuração e manter controle completo sobre a funcionalidade da solução autogerenciada.
Considerações sobre custos
Cada recurso da funcionalidade do EKS tem um custo horário relacionado, que varia conforme o tipo de funcionalidade. Os recursos do cluster gerenciados por essa funcionalidade também têm custo horário próprio, com precificação separada. Para obter mais informações, consulte Preços do Amazon EKS
As soluções autogerenciadas não têm custos diretos relacionados a cobranças da AWS, mas é necessário pagar pelos recursos de computação do cluster consumidos por controladores e workloads relacionados. Além do consumo de recursos de nós e de cluster, o custo total de propriedade das soluções autogerenciadas inclui despesas operacionais e com manutenção, solução de problemas e suporte.
Como escolher entre funcionalidades do EKS e soluções autogerenciadas
Funcionalidades do EKS Considere esta opção quando desejar reduzir a sobrecarga operacional e se concentrar em valor diferenciado no software e nos sistemas, em vez de nas operações de plataforma do cluster para requisitos fundamentais. Use as funcionalidades do EKS quando desejar minimizar a carga operacional de patches de segurança e o gerenciamento do ciclo de vida do software, liberar recursos de nós e do cluster para workloads de aplicação, simplificar a configuração e o gerenciamento de segurança, e se beneficiar da abrangência de suporte da AWS. As funcionalidades do EKS são adequadas para a maioria dos casos de uso em ambientes de produção e constituem a abordagem recomendada para novas implantações.
Soluções autogerenciadas Considere esta opção quando precisar de versões específicas da API de recursos do Kubernetes, desenvolvimentos personalizados de controladores, tiver automação e ferramentas existentes voltadas a implantações autogerenciadas, ou necessitar de um nível avançado de personalização das configurações de runtime dos controladores. Nas soluções autogerenciadas, é possível obter flexibilidade para casos de uso específicos, mantendo controle total sobre a implantação e a configuração de runtime.
nota
As funcionalidades do EKS podem coexistir com soluções autogerenciadas em seu cluster, permitindo que migrações sejam feitas de forma gradual.
Comparações específicas por funcionalidade
Para comparações detalhadas, incluindo funcionalidades específicas de cada funcionalidade, diferenças na versão original e caminhos de migração, consulte:
