Create an ACK Edge cluster - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Este tópico explica como criar um cluster ACK Edge no console para obter gerenciamento colaborativo integrado entre cloud e edge.Cluster ACK Edge no console.

Pré-requisitos

Você ativou o ACK.
Você ativou o Auto Scaling.
Você ativou o Resource Access Management (RAM).

Limites

Item		Limite	Links para aumentar cotas/referências
Redes		Os clusters ACK suportam apenas VPCs.	What is VPC
Recursos de cloud	ECS	Os métodos de faturamento pagamento conforme o uso e assinatura são suportados. Após criar uma instância ECS, altere o método de faturamento de pagamento conforme o uso para assinatura no console ECS.	Change the billing method of an ECS instance from pay-as-you-go to subscription
	Entradas de rota da VPC	Por padrão, é possível adicionar no máximo 200 entradas de rota à VPC de um cluster ACK que executa Flannel. As VPCs de clusters ACK com Terway não possuem esse limite. Para adicionar mais entradas de rota à VPC do seu cluster ACK, solicite um aumento de cota para a VPC.	Quota Center
	Grupos de segurança	Por padrão, cada conta pode criar no máximo 100 grupos de segurança.	Security groups
	Instâncias SLB	Por padrão, cada conta pode criar no máximo 60 instâncias SLB com pagamento conforme o uso.	Quota Center
	EIP	Por padrão, cada conta pode criar no máximo 20 EIPs.	Quota Center

Etapa 1: Fazer login no console

Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.
No canto superior esquerdo da página, selecione o grupo de recursos e a região do recurso de destino.
Na página Clusters, clique em Create Kubernetes Cluster.
Na página Create Kubernetes Cluster, clique na aba ACK Edge.

Etapa 2: Configurar o cluster

Na página ACK Edge Cluster, defina as configurações do cluster.

Configurações básicas

Parâmetro	Descrição
Cluster Name	Insira um nome personalizado para o cluster.
Cluster Specification	Basic Edition: Possui cota limitada (cada conta pode criar dois clusters). Destinado apenas a aprendizado pessoal e testes. Pro Edition: Oferece um Service-Level Agreement (SLA) e é adequada para ambientes corporativos de produção e staging. Para comparar as duas edições, consulte Cluster management.
Region	A região 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 dos recursos, menor será a latência de rede.
Kubernetes Version	É possível criar clusters apenas com as três versões menores mais recentes. Recomendamos usar a versão mais recente. Para mais informações sobre as versões suportadas pelo ACK, consulte ACK version support overview.
Maintenance Window	O ACK executa operações automatizadas de O&M em node pools gerenciados, como correções automáticas de vulnerabilidades CVE do SO, durante a janela de manutenção. Clique em Set para configurar a política de manutenção específica.

Configurações de rede

VPC	A virtual private cloud (VPC) do cluster. Para alta disponibilidade, selecione duas ou mais zonas diferentes. Criação automática: O ACK cria um vSwitch correspondente em cada zona selecionada. Usar existente: Selecione um vSwitch para especificar a zona do cluster. É possível criar um novo vSwitch ou utilizar um já existente. Recomendamos usar blocos CIDR privados padrão para a VPC do cluster, como 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16. Se tiver requisitos especiais, acesse o Quota Center para solicitar permissão para use a public CIDR block to create a cluster. Recursos de cloud e faturamento: VPC
Configure SNAT for VPC	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 baixar imagens públicas ou acessar serviços 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, adquire 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 adquirir um EIP adicional e configurar uma regra SNAT. Se nenhum EIP estiver disponível, um novo será adquirido automaticamente. Se não existir uma regra SNAT no nível da VPC, uma regra SNAT será configurada para o vSwitch usado pelo cluster. Caso não selecione esta opção, configure o NAT Gateway e as regras SNAT manualmente após criar o cluster. Para mais informações, consulte Public NAT Gateway. Recursos de cloud e faturamento: NAT Gateway, EIP
vSwitch	Selecione um vSwitch existente na lista com base na zona ou clique em Create vSwitch para criar um novo. O plano de controle do cluster e o node pool padrão usarão o vSwitch especificado aqui. Recomendamos selecionar vSwitches em múltiplas zonas diferentes para garantir alta disponibilidade do cluster.
Security Group	Ao usar uma VPC existente, escolha Select Existing Security Group Este grupo de segurança é aplicado ao plano de controle do cluster, ao node pool padrão e a quaisquer node pools que não tenham um grupo de segurança personalizado especificado. Em comparação aos grupos de segurança básicos, os grupos de segurança avançados podem conter mais endereços IP privados, mas não suportam conectividade intragrupo. Para mais informações, consulte Security group classification. Criação automática: Todo o tráfego de saída é permitido por padrão. O tráfego de entrada é permitido com base na configuração recomendada. Se modificar as regras posteriormente, garanta que o bloco CIDR `100.64.0.0/10` esteja permitido para tráfego de entrada. Este bloco CIDR é usado para acessar outros serviços da Alibaba Cloud para operações como download de imagens e consulta de informações básicas do ECS. Usar existente: O ACK não configura regras de acesso adicionais para o grupo de segurança por padrão. Gerencie as regras do grupo de segurança manualmente para evitar problemas de acesso. Para mais informações, consulte Configure cluster security groups.
Access to API Server	O ACK cria automaticamente uma instância Classic Load Balancer (CLB) privada com pagamento conforme o uso como endpoint interno para o API Server. Esta instância CLB não pode ser reutilizada ou excluída. Se for excluída, o API Server ficará inacessível e não poderá ser recuperado. Para usar uma instância CLB existente, abra um ticket. Após selecionar Use Existing Gateway para VPC, defina SLB Source como Use Existing Gateway. Escolha ativar Expose API server with EIP. Open: Vincula um EIP à instância CLB privada do API Server, permitindo acessar e gerenciar o cluster pela rede pública. Isso não significa que os recursos dentro do cluster possam acessar a rede pública. Para permitir que os recursos do cluster acessem a rede pública, selecione Configure SNAT for VPC. Not open: Conecte-se e opere o cluster apenas usando o arquivo kubeconfig de dentro da VPC. Para ativar isso posteriormente, consulte Access the API server over the internet. A partir de 1º de dezembro de 2024, novas instâncias CLB incorrerão em taxa de instância. Para mais informações, consulte Billing item adjustment for Classic Load Balancer (CLB). Recursos de cloud e faturamento: CLB, EIP Aviso Os nós de edge se comunicam com o API server na cloud pela internet e exigem um EIP. Selecione Expose API server with EIP. Se não selecionado durante a criação, vincule um EIP ao API server posteriormente. Consulte Access the API server of an ACK cluster from the internet. Os clusters ACK Edge não suportam alteração ou desvinculação de um EIP.
Network Plug-in	Selecione e configure um plug-in de rede. Flannel e Terway-edge são suportados. Consulte Network management e How to choose a network plug-in. Flannel: Um plug-in CNI estável que usa rede overlay VXLAN. Baseado no projeto open-source Flannel. Terway-edge: Um plug-in de rede desenvolvido pelo Alibaba Cloud Container Service. Na cloud: atribui interfaces de rede elásticas da Alibaba Cloud aos containers. Na edge: atribui endereços IP de container a partir de um bloco CIDR pré-configurado e encaminha o tráfego usando rotas de host.
Pod vSwitch	Necessário apenas para Terway-edge. Especifique vSwitches para atribuir endereços IP de pod no node pool da cloud. Cada Pod vSwitch deve estar na mesma zona que o vSwitch do nó worker correspondente.
Edge Container CIDR Block	O pool de endereços IP para containers. Com Flannel, tanto os containers da cloud quanto os da edge recebem endereços IP deste bloco CIDR. Com Terway-edge, apenas os containers da edge recebem endereços IP deste bloco CIDR.
Number of Pods per Node	Define o número máximo de pods que um único nó pode acomodar.
Service CIDR	Também conhecido como Service CIDR. Este é o pool de endereços que atribui IPs aos serviços 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.

Configurações avançadas

Clique em Advanced Options (Optional) para configurar o modo de encaminhamento de serviço.

Parâmetro

Descrição

Forwarding Mode

Selecione o modo de proxy do kube-proxy, que determina como os serviços do cluster distribuem solicitações para os pods de backend.

iptables: Usa regras de firewall do Linux para encaminhamento de tráfego. É estável, mas tem desempenho limitado. À medida que o número de serviços aumenta, a quantidade de regras de firewall cresce, tornando o processamento de solicitações mais lento. Adequado para clusters com poucos serviços.
IPVS: Uma solução de distribuição de tráfego de alto desempenho. Utiliza uma tabela hash para localizar rapidamente os pods de destino, resultando em menor latência ao lidar com muitas solicitações de serviço. Ideal para clusters de produção em grande escala ou cenários com altos requisitos de desempenho de rede.
A partir do Kubernetes 1.35, o modo ipvs do kube-proxy está marcado como obsoleto e planeja-se sua remoção em uma versão futura.
nftables: Um substituto moderno para o iptables que fornece um modelo de regras mais eficiente. Sua busca de mapeamento de regras quase O(1) torna a latência do plano de dados independente do tamanho do cluster. As atualizações do plano de controle usam sincronização incremental, otimizando a eficiência das alterações de regras. Como direção principal de desenvolvimento para o framework de rede do kernel Linux, é o modo recomendado pela comunidade kube-proxy. Adequado para clusters de médio a grande porte ou cenários que exigem melhor desempenho e manutenibilidade que o iptables.
Ao usar o modo de encaminhamento de serviço nftables, a versão do kernel Linux dos nós no cluster deve ser 5,13 ou posterior. Caso contrário, os nós falharão ao serem adicionados.

Clique em Advanced Options (Optional) para mais configurações.

Expanda para visualizar as configurações avançadas

Parâmetro	Descrição
Cluster Deletion Protection	Recomendamos ativar este recurso para evitar a exclusão acidental do cluster pelo console ou OpenAPI.
Resource Group	Atribua o cluster ao grupo de recursos selecionado para facilitar o gerenciamento de permissões e a alocação de custos. Um recurso pode pertencer a apenas um grupo de recursos.
Label	Vincule tags chave-valor ao cluster para identificar recursos de cloud.
Secret Encryption	Selecione Select Key para criptografar Secrets do Kubernetes com uma chave KMS da Alibaba Cloud. Consulte Encrypt Secrets at rest by using Alibaba Cloud KMS.
RRSA OIDC	O cluster criará um Provedor OpenID Connect (OIDC). Usando o token OIDC temporário de seu ServiceAccount, os pods de aplicação podem chamar o serviço RAM da Alibaba Cloud e assumir uma função RAM especificada. Isso permite obter autorização temporária segura para acessar recursos de cloud, alcançando gerenciamento de privilégio mínimo 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.

Etapa 3: Configurar node pool da cloud

Importante

O node pool da cloud requer pelo menos dois nós workers para os componentes do plano de controle.

Configurações básicas do node pool

Parâmetro		Descrição
Node Pool Name		Insira um nome personalizado para o node pool.
Container Runtime		Selecione um Container Runtime com base na Kubernetes Version. containerd (recomendado): suporta todas as versões de cluster. docker: suporta Kubernetes 1.22 e versões anteriores.
Configurações de node pool gerenciado	Managed Node Pool	Ative node pools gerenciados para usar os recursos automatizados de O&M fornecidos pelo ACK. Se sua aplicação for sensível a alterações nos nós subjacentes e não tolerar reinicializações de nós ou migrações de pods, não recomendamos ativar este recurso. Para ativar isso posteriormente, use edit the node pool para habilitá-lo.
	Auto Repair	O ACK monitora automaticamente o status dos nós e executa tarefas de autorrecuperação quando um nó apresenta anomalias. Se selecionar Restart Faulty Node, o processo de autorrecuperação poderá envolver operações como drenagem do nó e substituição de discos. Para informações sobre condições de acionamento e eventos relacionados, consulte Enable node self-recovery.
	Auto Update Rule	Quando uma nova versão do kubelet estiver disponível, o ACK realizará a atualização automaticamente. Para mais informações, consulte Upgrade a node pool.
	Auto CVE Patching	Fix OS CVE vulnerabilities in the node pool. Configure o nível de correção de vulnerabilidades de segurança. Recursos de cloud e faturamento: Security Center
	Maintenance Window	O ACK executa operações automatizadas de O&M em node pools gerenciados apenas durante a janela de manutenção definida.

Configurações de instância e imagem

Parâmetro		Descrição
Billing Method		O método de faturamento padrão para nós escalados horizontalmente pelo node pool. Pay-As-You-Go: Pode ser ativado e liberado sob demanda. Subscription: Requer configuração de Duration e Auto Renewal. Preemptible Instance: Atualmente suporta apenas instâncias spot com período de proteção. Configure também o Instance Price Cap. Quando o preço em tempo real do tipo de instância especificado for inferior ao lance máximo para uma única instância, a instância será criada com sucesso. Após o período de proteção (1 hora), o sistema verifica o preço em tempo real e o estoque do tipo de instância a cada 5 minutos. Se o preço de mercado for superior ao seu lance ou o estoque for insuficiente, a instância spot será liberada. Para recomendações de uso, consulte Best practices for spot instance node pools. Para garantir a uniformidade do node pool, não é possível alterar um node pool Pay-As-You-Go ou Subscription para um node pool Preemptible Instance, ou vice-versa.
Configurações de instância		Quando um node pool escala horizontalmente, ele aloca instâncias a partir da família de instâncias ECS configurada. Para melhorar a taxa de sucesso do scale-out, selecione vários tipos de instância em múltiplas zonas para evitar indisponibilidade ou falta de estoque. O tipo específico de instância para scale-out é determinado pela Scaling Policy configurada. Para garantir estabilidade operacional e agendamento preciso de recursos, não misture tipos de instância GPU e não-GPU no mesmo node pool. Configure os tipos de instância usados para scale-out das seguintes maneiras: Tipos específicos: Especifique tipos de instância com base em dimensões como vCPU, memória, família de instância e arquitetura de CPU (a arquitetura de CPU da instância deve ser consistente com a arquitetura da imagem do SO). Ao usar Terway, visualize o número máximo de pods por nó para o tipo de instância de destino na lista de tipos de instância. Configuração de generalização: Selecione uma lista de tipos de instância para usar ou excluir com base em atributos (como vCPU e memória) para aumentar ainda mais a taxa de sucesso do scale-out. Consulte as recomendações de força de elasticidade no console ou visualize a força de elasticidade do node pool 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 Nota Recursos avançados dos clusters ACK Edge, como logging, monitoramento e tunelamento reverso, exigem componentes implantados na cloud. Crie pelo menos um nó worker ECS.
Operating System		Public Image: Uma imagem pública do Container Service for Kubernetes. Imagens públicas incluem Alibaba Cloud Linux 3 Container-Optimized Image, ContainerOS, Alibaba Cloud Linux 3 e Ubuntu. Para mais informações, consulte Operating system. Custom Image: Use uma imagem de SO personalizada. Para mais informações, consulte How do I create a custom image based on an existing ECS instance and use it to create a node?. Para atualizar ou alterar o SO posteriormente, consulte Change the operating system.
Security Hardening		Ao criar um nó, o ACK aplica a política de linha de base de segurança selecionada. Disable: Nenhum hardening de segurança é realizado na instância ECS. MLPS Security Hardening: A Alibaba Cloud fornece padrões de verificação de linha de base e ferramentas de varredura para a imagem da edição Alibaba Cloud Linux MLPS 2.0 Level 3 que atendem aos requisitos de conformidade de proteção classificada. Além de garantir compatibilidade e desempenho nativos da imagem, foi adaptada para conformidade MLPS 2.0, atendendo aos requisitos da GB/T 22239-2019 Information Security Technology - Basic Requirements for Classified Protection of Cybersecurity. Para mais informações, consulte Instructions for using ACK MLPS 2.0 security hardening. No entanto, neste modo, o usuário root não pode fazer login remotamente via SSH. Use connect to the instance via VNC no console ECS e crie um usuário comum que suporte login SSH. OS Security Hardening: Suporta apenas Alibaba Cloud Linux 2 ou Alibaba Cloud Linux 3.
Logon Type		Key Pair: As pares de chaves SSH da Alibaba Cloud são um método de autenticação de login seguro e conveniente, consistindo em uma chave pública e uma chave privada. São suportadas apenas para instâncias Linux. Configure tanto o Username (root ou ecs-user) quanto a Key Pair necessária. Password: Configure o Username (root ou ecs-user) e uma senha.

Configurações de armazenamento

Parâmetro		Descrição
System Disk		Selecione um tipo de disco de cloud com base nas necessidades do seu negócio, incluindo ESSD AutoPL, enterprise SSD (ESSD), ESSD Entry e discos de cloud de geração anterior (standard SSD e ultra disk). Configure a capacidade e IOPS. Os tipos de disco de sistema disponíveis dependem da família de instâncias selecionada. Tipos de disco não exibidos não são suportados. Desempenho personalizado e criptografia para ESSDs Personalize o nível de desempenho (PL). Quanto maior a capacidade do disco, maior o PL selecionável (PL2 disponível para capacidades de 460 GiB ou mais, e PL3 para 1260 GiB ou mais). Para mais informações, consulte ESSDs. Entre os discos de sistema, apenas ESSDs suportam Encrypted. Ao selecionar uma chave, a Alibaba Cloud usa a chave de serviço padrão (Default Service CMK) para criptografia. Também é possível selecionar uma chave personalizada (Bring-Your-Own-Key, ou BYOK) criada no KMS. Selecione More Disk Categories para configurar tipos de disco diferentes do System Disk e melhorar a taxa de sucesso do scale-out. Ao criar um nó, o ACK seleciona o primeiro tipo correspondente na ordem especificada de tipos de disco. Recursos de cloud e faturamento: ECS Elastic Block Storage
Data Disk		Selecione um tipo de disco de cloud com base nas necessidades do seu negócio, incluindo ESSD AutoPL, enterprise SSD (ESSD), ESSD Entry e discos de cloud de geração anterior (standard SSD e ultra disk). Configure a capacidade e IOPS. Os tipos de disco de dados disponíveis dependem da família de instâncias selecionada. Tipos de disco não exibidos não são suportados. Suporte a ESSD AutoPL Desempenho provisionado: Configure flexivelmente o desempenho provisionado do disco de cloud sem alterar sua capacidade de armazenamento, desacoplando capacidade de disco de desempenho. Pico de desempenho: Quando sua aplicação enfrenta pressão súbita de leitura/gravação de dados, o disco de cloud aumenta temporariamente seu desempenho para lidar com a demanda de pico até que a aplicação estabilize. Suporte a ESSD Personalize o nível de desempenho (PL). Quanto maior a capacidade do disco, maior o PL selecionável (PL2 disponível para capacidades de 460 GiB ou mais, e PL3 para 1260 GiB ou mais). Para mais informações, consulte ESSDs. Ao anexar um disco de dados, todos os tipos de disco de cloud suportam Encrypted. Ao selecionar uma chave, a Alibaba Cloud usa a chave de serviço padrão (Default Service CMK) para criptografia. Também é possível selecionar uma chave personalizada (Bring-Your-Own-Key, ou BYOK) criada no KMS. Durante a criação do nó, o último disco de dados é formatado automaticamente e `/var/lib/container` é montado nele. `/var/lib/kubelet` e `/var/lib/containerd` são montados em `/var/lib/container`. Para personalizar o diretório de montagem, ajuste a configuração de inicialização do disco de dados. Selecione no máximo um disco de dados como diretório para o runtime de container. Para mais informações, consulte Can I customize the mount directory for data disks in an ACK node pool? Em cenários que exigem aceleração de imagem de container ou carregamento rápido de modelos grandes, crie discos de dados a partir de snapshots para melhorar a velocidade de resposta do sistema e as capacidades de processamento. Selecione Add Data Disk Type para configurar tipos de disco diferentes do Data Disk e melhorar a taxa de sucesso do scale-out. Ao criar um nó, o ACK seleciona o primeiro tipo correspondente na ordem especificada de tipos de disco. Uma instância ECS pode ter até 64 discos de dados anexados. O limite específico varia conforme o tipo de instância. Chame a operação DescribeInstanceTypes para consultar o limite de quantidade de discos de cloud (`DiskQuantity`) para o tipo de instância correspondente. Recursos de cloud e faturamento: ECS Elastic Block Storage

Quantidade de instâncias

Parâmetro		Descrição
Expected Number of Nodes		Contagem total de nós mantida pelo node pool. Ajuste para escalar horizontalmente para dentro ou para fora. Recomenda-se pelo menos dois nós na cloud.

Configurações avançadas do node pool

Expanda Advanced Options (Optional) para configurar a política de dimensionamento de nós.

Parâmetro	Descrição
Scaling Policy	Configure como o node pool seleciona instâncias durante o dimensionamento de nós. Priority-based Policy: Escala 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 prioritário será usado automaticamente. Cost Optimization: Escala com base no preço unitário da vCPU do menor para o maior. Se o node pool usar Preemptible Instance, instâncias spot terão prioridade. Configure também a Percentage of On-Demand Instances (%). Se tipos de instância spot não puderem ser criados devido a estoque ou outros motivos, instâncias com pagamento conforme o uso serão usadas automaticamente como complemento. Distribution Balancing: Distribui instâncias ECS uniformemente entre múltiplas zonas, mas apenas em cenários multizona. Se a distribuição ficar desequilibrada devido a estoque insuficiente ou outros motivos, execute uma operação de reequilíbrio.
Use Pay-as-you-go Instances When Spot Instances Are Insufficient	Isso requer que o método de faturamento esteja 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 sob demanda como complemento. Recursos de cloud e faturamento: ECS Instance
Enable Supplemental Spot Instance	Isso requer que o método de faturamento esteja definido como Spot Instance. Quando ativado, ao receber uma mensagem do sistema indicando que uma instância spot está prestes a ser recuperada (5 minutos antes da recuperação), o ACK tentará escalar horizontalmente uma nova instância como compensação. Compensação bem-sucedida: O ACK drena o nó antigo e o remove do cluster. Falha na compensação: O ACK não drena o nó antigo. A instância ainda será recuperada e liberada após 5 minutos. Quando o estoque for restaurado ou as condições de preço forem atendidas, o ACK comprará automaticamente uma instância para manter o número desejado de nós. Para mais informações, consulte Best practices for spot instance node pools. A liberação proativa de instâncias spot pode causar interrupções nos negócios. Para melhorar a taxa de sucesso da compensação, recomendamos ativar também Use Pay-as-you-go Instances When Spot Instances Are Insufficient. Recursos de cloud e faturamento: ECS Instance

Expanda Advanced Options (Optional) para configurar tags ECS, taints e outras definições.

Visualizar opções avançadas

Parâmetro	Descrição
ECS Tags	Adicione tags às instâncias ECS criadas automaticamente pelo ACK para identificar recursos de cloud. Cada instância ECS pode ter até 20 tags vinculadas. Para aumentar esse limite, envie uma solicitação na plataforma Quota Center. Como o ACK e o Auto Scaling (ESS) ocupam algumas tags, especifique até 17 tags personalizadas para uma instância. Expanda para ver detalhes de uso de tags O ACK ocupa duas tags ECS por padrão. `ack.aliyun.com:<your_cluster_id>` `ack.alibabacloud.com/nodepool-id:<your_nodepool_id>` O ESS ocupa uma tag ECS por padrão: `acs:autoscaling:scalingGroupId:<your_nodepool_scaling_group_id>`. Após ativar node autoscaling, o Auto Scaling ocupará duas tags ECS adicionais por padrão, então o node pool ocupará mais duas tags ECS: `k8s.io/cluster-autoscaler:true` e `k8s.aliyun.com:true`. Após ativar node autoscaling, o componente registra os rótulos e taints do nó através de tags ECS para pré-verificar o comportamento de agendamento dos nós escalados horizontalmente. Cada rótulo do nó é convertido para `k8s.io/cluster-autoscaler/node-template/label/<label_key>:<label_value>`. Cada taint do nó é convertido para `k8s.io/cluster-autoscaler/node-template/taint/<taint_key>/<taint_value>:<taint_effect>`.
Taints	Adicione taints chave-valor ao nó. Uma chave de taint válida consiste em um prefixo opcional e um nome. Se houver um prefixo, ele é separado do nome por uma barra (/). Expanda para ver instruções detalhadas Key: O nome deve ter de 1 a 63 caracteres, começar e terminar com um caractere alfanumérico `[a-z0-9A-Z]`, e pode conter letras, números, hífens (-), sublinhados (_) e pontos (.). Se especificar um prefixo, ele deve ser um subdomínio DNS, que é uma série de rótulos DNS separados por pontos (.), não excedendo 253 caracteres e terminando com uma barra (/). Value: O valor do taint pode estar vazio, ter até 63 caracteres, deve começar e terminar com um caractere alfanumérico `[a-z0-9A-Z]`, e pode conter letras, números, hífens (-), sublinhados (_) e pontos (.). Effect: NoSchedule: Nenhum novo pod que não tolere este taint será agendado para o nó, mas os pods em execução não são afetados. NoExecute: Não apenas nenhum novo pod que não tolere este taint será agendado para o nó, mas qualquer pod em execução no nó que não tolere este taint será despejado. PreferNoSchedule: O ACK tentará evitar agendar pods em nós com taints que eles não toleram, mas isso não é imposto.
Node Labels	Adicione rótulos chave-valor ao nó. Uma chave válida consiste em um prefixo opcional e um nome. Se houver um prefixo, o prefixo e o nome são separados por uma barra (/). Expanda para ver instruções detalhadas Chave: O nome deve ter de 1 a 63 caracteres, começar e terminar com um caractere alfanumérico `[a-z0-9A-Z]`, e pode conter letras, números, hífens (-), sublinhados (_) e pontos (.). Se especificar um prefixo, ele deve ser um subdomínio DNS, que é uma série de rótulos DNS separados por pontos (.), não excedendo 253 caracteres e terminando com uma barra (/). Os seguintes prefixos são reservados pelos componentes principais do Kubernetes e não podem ser especificados `kubernetes.io/` `k8s.io/` prefixos terminando com `kubernetes.io/` e `k8s.io/`. Por exemplo, `test.kubernetes.io/`. As seguintes são exceções: `kubelet.kubernetes.io/` `node.kubernetes.io` prefixos terminando com `kubelet.kubernetes.io/`. prefixos terminando com `node.kubernetes.io`. Valor: Pode estar vazio, ter até 63 caracteres, deve começar e terminar com um caractere alfanumérico `[a-z0-9A-Z]`, e pode conter letras, números, hífens (-), sublinhados (_) e pontos (.).
Set to Unschedulable	Os nós recém-adicionados serão definidos como não agendáveis por padrão quando registrados no cluster. Ajuste manualmente o status de agendamento do nó 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.
CPU Policy	Especifique a política de gerenciamento de CPU do kubelet para o nó. None: A política padrão. Static: Permite que pods com certas características de recursos no nó recebam afinidade de CPU aprimorada e exclusividade. Recomendamos usar configurações personalizadas do kubelet para node pools.
Custom Node Name	Por padrão, os nomes dos nós são gerados automaticamente. Se precisar de uma convenção de nomenclatura unificada para facilitar o gerenciamento de nós e identificação de O&M, ative esta configuração. Quando ativada, o nome do nó, o nome da instância ECS e o hostname serão alterados. O Método 3 aplica-se apenas a node pools Lingjun, e node pools Lingjun suportam apenas o Método 3. Método 1: Endereço IP completo + prefixo/sufixo Descrição: O nome do nó consiste em um prefixo, o endereço IP do nó e um sufixo. Quando ativado, o nome do nó, o nome da instância ECS e o hostname da instância ECS também mudarão. Exemplo: O endereço IP do nó é `192.XX.YY.55`, o prefixo especificado é `aliyun.com` e o sufixo é `test`. Nó Linux: O nome do nó, o nome da instância ECS e o hostname da instância ECS são todos `aliyun.com192.XX.YY.55test`. Nó Windows: Seu hostname é fixado no endereço IP, usando `-` para substituir o `.` no endereço IP, e não inclui o prefixo e sufixo. Portanto, o hostname da instância ECS é `192-XX-YY-55`, e o nome do nó e o nome da instância ECS são ambos `aliyun.com192.XX.YY.55test`. Método 2: Número especificado de dígitos do endereço IP + prefixo/sufixo Lista de permissões Descrição: O nome do nó consiste em um prefixo, um número especificado de dígitos do endereço IP do nó e um sufixo. Quando ativado, o nome do nó, o nome da instância ECS e o hostname da instância ECS mudarão adequadamente. Exemplo: O endereço IP do nó é `192.XX.YY.55`, o prefixo é `aliyun.com`, o sufixo é `test` e o número de dígitos do endereço IP a truncar é `6`. O nome do nó resultante é `aliyun.com0YY055test`. Importante Quando o formato de nome de nó personalizado depende do truncamento de parte do endereço IP, se o bloco CIDR da VPC for grande e o número de dígitos IP truncados (`lenOfIP`) for insuficiente, poderá causar conflitos de nome de nó, levando a falhas de scale-out em cenários node instant scaling. Defina o número de dígitos do endereço IP a truncar com base nas seguintes recomendações para o bloco CIDR da sua VPC: Para blocos CIDR de grande escala como 10.0.0.0/8 e 172.16.0.0/12, recomendamos definir `lenOfIP` para pelo menos 9. Para o bloco CIDR 192.168.0.0/16, recomendamos definir `lenOfIP` para pelo menos 6. Método 3: Sincronizar hostname da instância (suportado apenas para node pools Lingjun) Recurso de lista de permissões, não aplicável a node pools não-Lingjun Descrição: Sincroniza diretamente o hostname de um nó Lingjun com seu NodeName. Exemplo: Se o hostname da instância for `test`, o NodeName do nó será `test`. Método 4: ID incremental + prefixo/sufixo (suportado apenas para node pools ECS) Recurso de Lista de Permissões. Após ativar este método, não é possível ativar node scaling (ou seja, Scaling Mode definido como Auto) simultaneamente. Node pools com auto scaling já ativado não podem ser alternados para este método. Descrição: O nome do nó consiste em um prefixo, um ID incremental e um sufixo, no formato `auto_increment,name_prefix(AUTO_INCREMENT)[begin_number,bits]name_suffix` (sem espaço entre `[begin_number,bits]`). Os parâmetros são descritos abaixo. Para mais informações sobre as regras, consulte Fixed increment sorting. `beginNumber`: O número inicial, com intervalo de valores de `[0, 999999]`. O valor inicial especificado entra em vigor no primeiro scale-out. Se não definido, o padrão é `0`. Para scale-outs subsequentes, o valor inicial incrementa a partir do número máximo existente no grupo de dimensionamento. `bits`: O número de dígitos para o número, com intervalo de valores de `[1, 6]`. Se o número de dígitos em `beginNumber` exceder o valor de `bits`, `bits` assume o padrão 6. Se `beginNumber` ou `bits` não forem definidos, assumem os padrões `0` e `6`, respectivamente. Recomendamos definir `bits` para pelo menos `3` para evitar atingir o limite de numeração. Se o limite for atingido e você ainda precisar escalar horizontalmente, o scale-out falhará e parará. Será necessário redefinir a regra de nomenclatura. O sistema incrementa sequencialmente por padrão. No entanto, se uma instância ECS escalada horizontalmente falhar ao iniciar, ela será removida e uma nova será escalada, o que pode resultar em números não consecutivos. Exemplo: O formato de nomenclatura é `auto_increment,start(AUTO_INCREMENT)[1,3]end`, `beginNumber` é `1` e `bits` é `3`. Os nomes dos nós são gerados em sequência: 1ª instância: `start001end` 2ª instância: `start002end` ...
Pre-defined Custom Data	Antes de um nó entrar no cluster, o script User-Data de pré-personalização especificado será executado. Por exemplo, se 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.
User Data	Depois que um nó entra no cluster, o script User-Data da instância especificado será executado. Por exemplo, se especificar os user data da instância como `touch /tmp/post-script`, o script combinado no nó será executado na seguinte ordem. `#!/bin/bash # The ACK node initialization script is executed here # The input instance user data is executed here touch /tmp/post-script` Para informações sobre como esta configuração entra em vigor durante a inicialização do nó, consulte Node initialization process overview. A criação bem-sucedida do cluster ou scale-out de nó não garante que o script de user data da instância foi executado com sucesso. Faça login no nó e execute `grep cloud-init /var/log/messages` para visualizar os logs de execução.
CloudMonitor Agent	Visualize e monitore o status de execução de nós e aplicações no console Cloud Monitor. Esta configuração aplica-se apenas a novos nós no node pool, não aos existentes. Para ativar em nós existentes, instale-o através do console Cloud Monitor. Recursos de cloud e faturamento: Cloud Monitor
Public IP	O ACK atribuirá um endereço IP público IPv4 ao nó. Esta configuração aplica-se apenas a novos nós no node pool, não aos existentes. Se os nós existentes precisarem acessar a rede pública, configure e vincule um EIP. Para mais informações, consulte Associate an EIP with a cloud resource. Recursos de cloud e faturamento: ECS public network
Custom Security Group	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. Gerencie as regras do grupo de segurança manualmente para evitar problemas de acesso. Para mais informações, consulte Configure cluster security groups. Cada instância ECS tem um limite no número de grupos de segurança aos quais pode ingressar. Garanta que tenha cota de grupo de segurança suficiente.
RDS Whitelist	Adicione os endereços IP dos nós à lista de permissões de uma instância RDS.
[Deprecated] Private pool type	Este item de configuração está obsoleto. Mude para usar Resource Pool Policy para especificar um pool privado. Os recursos private pool disponíveis para a zona e 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, começará a usar recursos do pool público. Do Not Use: A instância não usará nenhuma capacidade de pool privado e começará a usar diretamente recursos do pool público. Specified: Selecione adicionalmente um ID de pool privado para especificar que a instância começará a usar apenas a capacidade desse pool privado. Se o pool privado estiver indisponível, a instância falhará ao iniciar.

Etapa 4: Configuração de componentes

Clique em Next: Component Configuration para configurar os componentes do cluster.

Parâmetro	Descrição
Cloud-edge Communication Component	O Raven cria um túnel de rede pública para comunicação cloud-edge entre regiões, permitindo monitoramento e O&M de nós de edge. Não é necessário se o cluster usar Express Connect. Consulte Raven: A Cross-Region O&M Communication Component.
CloudMonitor Agent	Visualize e monitore o status de execução de nós e aplicações no console Cloud Monitor. Esta configuração aplica-se apenas a novos nós no node pool, não aos existentes. Para ativar em nós existentes, instale-o através do console Cloud Monitor. Recursos de cloud e faturamento: Cloud Monitor
Log Service	Use um Projeto SLS 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 solicitações à 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 centro de eventos 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

Etapa 5: Confirmar configuração e faturamento

Na página Confirm Configuration, confirme a configuração do cluster, incluindo configurações de recursos, faturamento de recursos e verificações de dependência de produtos de cloud. Em seguida, leia os Termos de Serviço.

Um cluster ACK Edge incorre em taxas de gerenciamento de cluster (apenas para a edição Pro) e custos de recursos de cloud. Visualize o resumo de custos na parte inferior da página de criação ou consulte Billing for ACK Edge clusters.

Clique também em Equivalent Code no canto superior direito da página Confirm Configuration para gerar parâmetros de exemplo Terraform ou SDK para a configuração atual do cluster.

Faturamento

Consulte Billing for ACK Edge clusters.