Container Service for Kubernetes:Cluster gerenciado pelo ACK: Parâmetros

• Basic Edition: Possui quota limitado (cada conta pode criar dois clusters). Apenas para aprendizado e testes pessoais.

• Pro Edition: Fornece um Service-Level Agreement (SLA) e é adequada para ambientes corporativos de produção e staging.

A region onde os recursos do cluster, como instâncias ECS e discos de cloud, estão localizados. Quanto mais próxima a região estiver dos seus usuários e da região de implantação de recursos, menor será a latência de rede.

Você só pode criar clusters com as três minor versions mais recentes. Recomendamos o uso da versão mais recente. Para mais informações sobre as versões suportadas pelo ACK, consulte ACK version support overview.

Ative as atualizações automáticas do cluster para manter o plano de controle do cluster e os node pools atualizados periodicamente.

Para mais informações sobre a política de upgrade automático e instruções, consulte Automatically upgrade clusters.

O ACK executa tarefas automatizadas de O&M, como upgrades automáticos de cluster e correções automáticas de vulnerabilidades CVE do SO, apenas durante a janela de manutenção definida.

Este parâmetro é necessário apenas para o Flannel

O pool de endereços que atribui endereços IP aos pods. Este bloco CIDR não pode se sobrepor ao bloco CIDR da VPC, aos blocos CIDR usados por clusters ACK existentes na VPC ou ao Service CIDR.

Você só precisa configurar o Flannel.

Define o número máximo de pods que um único nó pode acomodar.

Este parâmetro é necessário apenas quando você seleciona o Terway.

Também conhecido como Service CIDR. Este é o pool de endereços que atribui endereços IP aos services dentro do cluster. Este bloco CIDR não pode se sobrepor ao bloco CIDR da VPC, aos blocos CIDR usados por clusters existentes na VPC ou ao Container CIDR Block.

Não selecione esta opção ao usar uma VPC compartilhada

Selecione esta opção se os nós precisarem acessar a rede pública (por exemplo, para fazer pull de imagens públicas ou acessar services externos). O ACK configurará automaticamente um NAT Gateway e regras SNAT para garantir que os recursos dentro do cluster possam acessar a rede pública.

• Se a VPC não tiver um NAT Gateway: O ACK cria automaticamente um NAT Gateway, compra um novo EIP e configura uma regra SNAT para o vSwitch usado pelo cluster.

• Se a VPC já tiver um NAT Gateway: O ACK determina se deve comprar um EIP adicional e configurar uma regra SNAT. Se nenhum EIP estiver disponível, um novo é comprado automaticamente. Se não existir nenhuma regra SNAT no nível da VPC, uma regra SNAT é configurada para o vSwitch usado pelo cluster.

Se você não selecionar esta opção, poderá configurar o NAT Gateway e as regras SNAT por conta própria após criar o cluster. Para mais informações, consulte Public NAT Gateway.

Recursos de cloud e faturamento: NAT Gateway, EIP

Recomendamos ativar este recurso para evitar a exclusão acidental do cluster através do console ou OpenAPI.

Atribua o cluster ao resource group selecionado para facilitar o gerenciamento de permissões e a alocação de custos.

Um recurso pode pertencer a apenas um grupo de recursos.

O time zone usado pelo cluster. Por padrão, este é o fuso horário configurado no seu navegador.

O campo Subject Alternative Name (SAN) no certificado do API Server inclui o nome de domínio local do cluster, o endereço IP privado e o EIP público por padrão. Para acessar o cluster através de um servidor proxy, domínio personalizado ou ambiente de rede especial, adicione esses endereços de acesso ao campo SAN.

Para ativar isso posteriormente, consulte Customize the SAN of the cluster API Server certificate.

No modelo tradicional, as credenciais de identidade de um pod são permanentes e compartilhadas entre vários pods, o que representa um risco de segurança. Quando ativado, cada pod obtém suas próprias credenciais de identidade temporárias, que suportam expiração automática e restrições de permissão.

Para ativar isso posteriormente, consulte Use ServiceAccount token volume projection.

Este recurso está disponível apenas para clusters Pro Edition

Use uma chave criada no KMS do Alibaba Cloud para fornecer criptografia de nível profissional para chaves Secret, aumentando a segurança dos dados.

Para ativar isso posteriormente, consulte Use Alibaba Cloud KMS to encrypt Secrets at rest.

Recursos de cloud e faturamento: KMS

O cluster criará um Provedor OpenID Connect (OIDC). Usando o token OIDC temporário de seu ServiceAccount, os pods da aplicação podem chamar o service RAM do Alibaba Cloud e assumir uma função RAM especificada. Isso permite que eles obtenham com segurança autorização temporária para acessar recursos de cloud, alcançando o gerenciamento de menor privilégio no nível do pod.

Para ativar isso posteriormente, consulte Use RRSA to configure RAM permissions for a ServiceAccount and achieve pod-level permission isolation.

Insira um nome personalizado para o node pool.

Ative os node pools gerenciados para usar o automated O&M capabilities fornecido pelo ACK.

Se o seu negócio for sensível a mudanças nos nós subjacentes e não puder tolerar reinicializações de nós ou migrações de pods de aplicação, não recomendamos ativar este recurso.

Para ativar isso posteriormente, você pode edit the node pool para ativá-lo.

O ACK monitora automaticamente o status do nó e executa tarefas de autorrecuperação quando um nó se torna anormal. Se você selecionar Restart Faulty Node, o processo de autorrecuperação pode envolver operações como drenar o nó e substituir discos. Para informações sobre condições de gatilho e eventos relacionados, consulte Enable node self-recovery.

Fix OS CVE vulnerabilities in the node pool. Você pode configurar o nível de correção de vulnerabilidade de segurança.

Recursos de cloud e faturamento: Security Center

O ACK executa operações de O&M automatizadas em node pools gerenciados apenas durante a janela de manutenção definida.

Quando um node pool expande, ele aloca instâncias a partir do ECS instance family configurado. Para melhorar a taxa de sucesso das expansões, selecione vários tipos de instância em várias zonas para evitar indisponibilidade ou falta de estoque. O tipo de instância específico para expansão é determinado pela Preemptible Instance configurada.

Para garantir a estabilidade do negócio e o agendamento preciso de recursos, não misture tipos de instância GPU e não-GPU no mesmo node pool.

Você pode configurar os tipos de instância usados para expansão das duas maneiras a seguir:

• Tipos específicos: Especifique tipos de instância com base em dimensões como vCPU, memória, família de instâncias e arquitetura de CPU (a arquitetura de CPU da instância deve ser consistente com o OS image architecture).

  Ao usar o Terway, visualize o maximum number of pods per node para o tipo de instância de destino na lista de tipos de instância.

• Generalization configuration: Selecione uma lista de tipos de instância para usar ou excluir com base em atributos (como vCPU e memória) para melhorar ainda mais a taxa de sucesso da expansão.

Você pode consultar as recomendações de força de elasticidade no console ou view the node pool elasticity strength após a criação do node pool.

Para informações sobre tipos de instância não suportados e recomendações de configuração de nós, consulte ECS instance type configuration recommendations.

Recursos de cloud e faturamento: ECS Instance, GPU-accelerated Instance

O número total de nós que o node pool deve manter. Recomendamos configurar pelo menos dois nós para garantir que os componentes do cluster sejam executados corretamente. Você pode ajustar a contagem desejada de nós para expandir ou reduzir o node pool. Para mais informações, consulte Scale a node pool.

Se você não precisar criar nós, poderá definir isso como 0 e, em seguida, ajustá-lo manualmente ou add existing nodes posteriormente.

Configure como o node pool seleciona instâncias durante o dimensionamento de nós.

• Advanced Options (Optional): Dimensiona com base na prioridade dos vSwitches configurados para o cluster (a prioridade do vSwitch diminui de cima para baixo). Se uma instância não puder ser criada na zona de um vSwitch de maior prioridade, o próximo vSwitch de prioridade será usado automaticamente.

• Scaling Policy: Dimensiona com base no preço unitário da vCPU do menor para o maior.

  Se o node pool usar Priority-based Policy, as instâncias spot serão priorizadas. Você também pode configurar a Cost Optimization. Se os tipos de instância spot não puderem ser criados devido a estoque ou outros motivos, as instâncias pay-as-you-go serão usadas automaticamente como suplemento.

• Preemptible Instance: Distribui instâncias ECS uniformemente em várias zonas, mas apenas em cenários de múltiplas zonas. Se a distribuição ficar desequilibrada devido a estoque insuficiente ou outros motivos, você pode executar uma operação de rebalanceamento.

Isso requer que o método de faturamento seja definido como Spot Instance.

Quando ativado, se não for possível criar instâncias spot suficientes devido a preço, estoque ou outros motivos, o ACK tentará automaticamente criar instâncias on-demand como suplemento.

Recursos de cloud e faturamento: ECS Instance

Isso requer que o método de faturamento seja definido como Spot Instance.

Adicione tags às instâncias ECS criadas automaticamente pelo ACK para identificar recursos de cloud. Cada instância ECS pode ser vinculada a até 20 tags. Para aumentar esse limite, envie uma solicitação na plataforma Quota Center. Como o ACK e o Auto Scaling (ESS) ocupam algumas tags, você pode especificar até 17 tags personalizadas para uma instância.

Os nós recém-adicionados serão definidos como não agendáveis por padrão quando forem registrados no cluster. Você precisa ajustar manualmente o node scheduling status na lista de nós.

Esta configuração só entra em vigor para clusters de versões anteriores a 1.34. Para mais informações, consulte Kubernetes 1.34 version guide.

Este recurso é suportado apenas para runtimes containerd da versão 1.6.34 e posteriores.

Os nós recém-adicionados detectarão automaticamente se uma imagem de contêiner suporta carregamento sob demanda. Se suportar, usará o carregamento sob demanda por padrão para acelerar a inicialização do contêiner, reduzindo o tempo de inicialização da aplicação. Para mais informações, consulte Use on-demand loading of container images to accelerate container startup.

Por padrão, os nomes dos nós são gerados automaticamente. Se você precisar de uma convenção de nomenclatura unificada para facilitar o gerenciamento de nós e a identificação de O&M, poderá ativar esta configuração. Quando ativado, o nome do nó, o nome da instância ECS e o nome do host serão alterados.

O Método 3 é aplicável apenas a node pools Lingjun, e os node pools Lingjun suportam apenas o Método 3.

Suportado apenas para clusters gerenciados pelo ACK. Só pode ser especificado ao criar um novo node pool

Especifique uma função RAM Worker no nível do node pool para reduzir os riscos de segurança associados a todos os nós compartilhando uma única função RAM Worker.

• Auto: Use a função RAM Worker padrão criada para o cluster.

• Worker RAM Role: Use a função especificada como a função RAM Worker. Se deixado vazio, a função padrão será usada. Para mais informações, consulte Use a custom Worker RAM role.

Suportado apenas para clusters da versão 1.28 e posteriores

Configure o modo de acesso a metadados para instâncias ECS. Você pode acessar o Metadata Service de dentro de uma instância ECS para recuperar metadados da instância, incluindo ID da instância, informações da VPC, informações da NIC e outros atributos da instância. Para mais informações, consulte Instance metadata.

• Custom: Suporta o acesso ao service de metadados da instância usando os modos normal e reforçado.

• Instance Metadata Access Mode: Suporta apenas o acesso ao service de metadados da instância usando o modo reforçado. Para mais informações, consulte Use reinforced mode only to access ECS instance metadata.

Antes de um nó entrar no cluster, o User-Data script de pré-personalização especificado será executado.

Por exemplo, se você especificar os dados de pré-personalização como touch /tmp/pre-script, o script combinado no nó será executado na seguinte ordem.

#!/bin/bash
    # The input instance pre-customization data is executed here
    touch /tmp/pre-script

    # The ACK node initialization script is executed here

Para informações sobre como esta configuração entra em vigor durante a inicialização do nó, consulte Node initialization process overview.

Especifique um grupo de segurança básico ou avançado para o node pool. O ACK não configura regras de acesso adicionais para o grupo de segurança por padrão. É necessário que você gerencie as regras do grupo de segurança por conta própria para evitar problemas de acesso. Para mais informações, consulte Configure cluster security groups.

Cada instância ECS tem um limite para o número de grupos de segurança aos quais pode se juntar. Certifique-se de ter um security group quota suficiente.

Adicione os endereços IP do nó à lista de permissões de uma instância RDS.

Após creating a deployment set no console ECS, atribua-o ao node pool. Isso garante que os nós expandidos pelo node pool sejam distribuídos em diferentes servidores físicos, melhorando a alta disponibilidade.

Um deployment set suporta um máximo de 20 × number of zones nós por padrão (o número de zonas é determinado pelos vSwitches). O número máximo de nós no node pool será limitado. Certifique-se de que a cota no deployment set seja suficiente.

Para ativar isso posteriormente, consulte Best practices for node pool deployment sets.

A política de pool de recursos usada ao adicionar novos nós (suportada apenas quando o Deployment Set está definido como Specify Instance Type). Os pools de recursos incluem pools privados gerados após os services Elastic Assurance ou Capacity Reservation (Immediate ou Timed) entrarem em vigor, juntamente com pools públicos, para seleção de inicialização de nós.

• Instance Configuration Mode: Prioriza o uso do pool privado especificado. Se nenhum pool privado for especificado ou se o pool privado especificado tiver capacidade insuficiente, ele corresponderá automaticamente a um pool privado do tipo aberto. Se nenhum pool privado adequado for encontrado, a instância será criada a partir do pool público.

• Private Pool Only: Você deve especificar um ID de pool privado. Se o pool privado especificado tiver capacidade insuficiente, o nó falhará ao iniciar.

• Private Pool First: Não use uma política de pool de recursos.

Este item de configuração está obsoleto. Mude para o uso de Resource Pool Policy para especificar um pool privado.

Os recursos private pool disponíveis para a zona e o tipo de instância atualmente selecionados. Os tipos incluem o seguinte:

• Open: A instância corresponderá automaticamente a um pool de capacidade privada do tipo aberto. Se nenhum pool privado adequado for encontrado, ela começará a usar recursos do pool público.

• Resource Pool Policy: A instância não usará nenhuma capacidade de pool privado e começará a usar diretamente os recursos do pool público.

• Specified: Você precisa selecionar ainda um ID de pool privado para especificar que a instância só começará a usar a capacidade desse pool privado. Se o pool privado estiver indisponível, a instância falhará ao iniciar.

Instale o NodeLocal DNSCache para armazenar em cache os resultados de consultas DNS nos nós. Isso melhora o desempenho e a estabilidade da resolução de nomes de domínio e acelera as chamadas service-to-service dentro do cluster.

Implementa o persistent data storage based on the CSI storage plugin. Você pode usar discos de cloud do Alibaba Cloud, NAS, OSS, CPFS e outros recursos de persistent volume (PV).

Se você optar por criar NAS e CNFS por padrão, o ACK criará um sistema de arquivos NAS de uso geral e o gerenciará usando Container Network File System (CNFS).

Para criar o CNFS posteriormente, consulte Manage NAS file systems with CNFS.

Recursos de cloud e faturamento: NAS

Monitore a saúde do cluster, o uso de recursos, o desempenho da aplicação e muito mais através do service de monitoramento de cluster de contêineres e acione alertas relevantes quando ocorrerem anomalias.

• ACK Cluster Monitoring Pro Edition: Fornece um service gerenciado de monitoramento de contêineres com um painel Grafana integrado. Os dados são armazenados por 90 dias por padrão.

  Para regras de faturamento, consulte Container monitoring billing. Para relatar métricas personalizadas ou ajustar a duração básica de armazenamento, serão incorridas taxas adicionais. Para mais informações, consulte Prometheus instance billing.

• Container Monitoring: Fornece um service gratuito e não gerenciado de monitoramento de contêineres com um painel de monitoramento básico integrado. Os dados são armazenados por 7 dias por padrão.

  O componente é de réplica única por padrão, ocupando 3 núcleos e 4 GB de memória, e requer automanutenção. Para relatar métricas personalizadas, serão incorridas taxas adicionais. Para mais informações, consulte Prometheus instance billing.

• Disable: Não ativa o service de monitoramento de contêineres. Você não poderá monitorar o status de execução do service de contêineres ou criar alertas relacionados.

Para ativar isso posteriormente, consulte Connect to and configure Alibaba Cloud Prometheus monitoring.

Recursos de cloud e faturamento: Prometheus

Fornece análise de custos e uso de recursos para clusters, namespaces, node pools e workloads para melhorar a utilização de recursos do cluster e economizar custos.

Para ativar isso posteriormente, consulte Cost Insight.

Use um SLS Project existente ou crie um novo para coletar logs de aplicações do cluster.

Isso também ativará o recurso de auditoria do API Server do cluster para coletar requisições para a API do Kubernetes e seus resultados.

Para ativar isso posteriormente, consulte Collect container logs from an ACK cluster e Use the cluster API Server audit feature.

• Create Ingress Dashboard: Crie um Ingress Dashboard no console SLS para coletar logs de acesso do Nginx Ingress. Para mais informações, consulte Nginx Ingress access log analysis and monitoring.

• Install node-problem-detector and create an event center: Adicione um event center no console SLS para coletar todos os eventos do Kubernetes no cluster em tempo real. Para mais informações, consulte Create and use the K8s event center.

Recursos de cloud e faturamento: SLS

Ative o Container Service Alert Management. Com base nas fontes de dados SLS, Managed Service for Prometheus e Cloud Monitor, ele envia notificações de alerta para grupos de contatos de alerta quando ocorrem anomalias no cluster.

Colete logs de componentes do plano de controle em um SLS Project para solução de problemas aprofundada e análise de causa raiz.

Para ativar isso posteriormente, consulte Collect control plane component logs for an ACK managed cluster.

Recursos de cloud e faturamento: SLS

Ative o cluster inspection feature de inteligência artificial para operações de TI para verificar periodicamente as cotas do cluster, uso de recursos, versões de componentes e muito mais. Isso garante que a configuração do cluster siga as melhores práticas e exponha riscos potenciais com antecedência.