Termos - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Cluster

Um cluster é um conjunto de recursos de nuvem que executa aplicações em contêineres, incluindo instâncias ECS, rede VPC e balanceamento de carga SLB.

O ACK oferece tipos de cluster para diferentes necessidades operacionais e de infraestrutura:

Tipo de cluster	Descrição	Ideal para
ACK managed Pro cluster	Estende os clusters ACK managed Basic com maior confiabilidade, segurança reforçada e um SLA com cláusulas de compensação.	Cargas de trabalho empresariais e produção em grande escala que exigem disponibilidade garantida
ACK managed Basic cluster	O ACK cria e gerencia o plano de controle. Crie e mantenha apenas os nós de trabalho.	Equipes que desejam Kubernetes gerenciado com menor custo de recursos
ACK dedicated cluster	Exige três planos de controle e nós de trabalho. Oferece controle refinado da infraestrutura, mas exige planejamento, gerenciamento e atualização dos nós por sua conta.	Equipes que precisam de controle direto sobre o plano de controle
ACK cluster that supports sandboxed containers	Executa contêineres em sandbox em instâncias ECS Bare Metal para alto desempenho sob cargas intensas e alta largura de banda.	Cargas de trabalho com requisitos rigorosos de isolamento ou altas demandas de I/O
ACK cluster for confidential computing	Usa Intel Software Guard Extensions (Intel SGX) para proteger código e dados durante a execução.	Proteção de dados, blockchain, gerenciamento de chaves, proteção de propriedade intelectual e computação genômica
ACK Edge cluster	Estende o Kubernetes para a borda com autonomia de nó, gerenciamento baseado em células e gerenciamento de tráfego de rede. Suporta APIs nativas do Kubernetes — nenhuma reescrita de código necessária.	Aplicações que abrangem ambientes de nuvem e de borda
ACK Serverless cluster	Não há planos de controle ou nós de trabalho para provisionar. Configure recursos, especifique imagens de contêiner e inicie aplicações pelo console do ACK ou CLI.	Equipes que querem executar contêineres sem gerenciar infraestrutura
ACK One registered cluster	Conecta clusters Kubernetes externos ao ACK para gerenciamento centralizado, incluindo clusters on-premises e de nuvens de terceiros.	Ambientes multicloud ou híbridos

Nó

Um nó é uma VM ou servidor físico com o docker Engine instalado. Ao adicioná-lo a um cluster ACK, o sistema instala um agente e registra o nó. Escale os nós vertical ou horizontalmente conforme a demanda da carga de trabalho.

Pool de nós

Um pool de nós agrupa nós com a mesma configuração para permitir dimensionamento e atualizações centralizadas.

Os pools de nós do ACK oferecem recursos automatizados de O&M que reduzem a sobrecarga operacional:

Correção automática para Common Vulnerabilities and Exposures (CVE) do SO
Autorrecuperação para nós com falha
Atualizações automáticas de versão para kubelet e containerd

Consulte Pools de nós.

VPC

Uma VPC é uma rede logicamente isolada na Alibaba Cloud. Personalize o bloco CIDR, as tabelas de rotas e os gateways. Implante instâncias ECS, SLB e RDS em uma VPC.

Grupo de segurança

Um grupo de segurança atua como firewall virtual com Stateful Packet Inspection (SPI) e filtragem de pacotes para instâncias na mesma região. As instâncias em um grupo de segurança compartilham as mesmas regras de segurança.

Catálogo de aplicativos

O catálogo de aplicativos é um recurso do ACK que simplifica a implantação pela integração com Helm e por uma interface gráfica para navegar e instalar charts do Helm.

Modelo de orquestração

Um modelo de orquestração armazena configurações de recursos do Kubernetes em YAML para versionamento, reutilização e compartilhamento.

Knative

Knative é um framework serverless baseado em Kubernetes para criar e executar aplicações cloud-native em diversas plataformas.

Kubernetes

Kubernetes é uma plataforma open source para cargas de trabalho e serviços em contêineres. Ela oferece configuração declarativa, rollouts e rollbacks automatizados, autorrecuperação e dimensionamento horizontal.

Contêiner

Um contêiner empacota uma aplicação e suas dependências de runtime em uma unidade portátil e isolada. Um único nó pode executar múltiplos contêineres.

Imagem de contêiner

Uma imagem de contêiner empacota uma aplicação e suas dependências. Baixe imagens do docker Hub, do Container Registry ou de um registro privado.

Cada imagem é identificada pela combinação do URI do registro e uma tag. A tag padrão é latest.

Registro de imagens

Um registro de imagens armazena imagens fornecidas pelo Kubernetes e imagens criadas a partir de contêineres.

Plano de controle

O plano de controle gerencia os nós de trabalho e os componentes do cluster. Ele expõe a API do Kubernetes, agenda cargas de trabalho, mantém o estado do cluster e gerencia a rede de contêineres.

O plano de controle inclui os seguintes componentes:

Componente	Função
`kube-apiserver`	Expõe a API do Kubernetes. Todas as operações do cluster passam por ele.
`kube-scheduler`	Atribui novos pods aos nós com base na disponibilidade de recursos e nas restrições de agendamento.
`kube-controller-manager`	Executa loops de controlador que reconciliam o estado real do cluster com o estado desejado (por exemplo, reinicia pods com falha).
`etcd`	Armazenamento chave-valor distribuído que contém todos os dados de configuração e estado do cluster.
Plugins de rede de contêiner	Implementam a rede de pods e a política de rede para o cluster.

Nó de trabalho

Um nó de trabalho é uma VM ou máquina física que executa cargas de trabalho, hospeda pods agendados e se comunica com o plano de controle. Os nós de trabalho executam estes componentes:

Ambiente de runtime docker
kubelet — o principal agente do nó que garante a execução dos contêineres conforme especificado
kube-proxy — mantém as regras de rede para comunicação pod-a-pod e pod-a-serviço
Componentes opcionais específicos da configuração do seu cluster

Namespace

Namespaces dividem os recursos do cluster em espaços virtuais isolados. Separe ambientes, equipes ou aplicações dentro de um único cluster. Administradores do cluster podem criar namespaces adicionais.

Todo cluster ACK inclui estes namespaces padrão:

Namespace	Finalidade
`default`	Namespace padrão para recursos criados sem um namespace explícito.
`kube-system`	Reservado para componentes de sistema do Kubernetes. Não implante suas aplicações aqui.
`kube-public`	Legível por todos os usuários, incluindo os não autenticados. Reservado para recursos públicos de todo o cluster.

Pod

Um pod é a menor unidade implantável do Kubernetes. Ele encapsula um ou mais contêineres, volumes de armazenamento, um IP exclusivo no cluster e configurações de runtime.

ReplicationController

Um ReplicationController mantém um número especificado de réplicas de pods. Ele substitui pods com falha e encerra réplicas excedentes. A contagem mínima é um.

O ReplicationController é um recurso legado. Use ReplicaSet (gerenciado por um Deployment) para novas cargas de trabalho.

ReplicaSet

O ReplicaSet sucede o ReplicationController com seletores de rótulo mais flexíveis. Deployments criam e gerenciam ReplicaSets para manter a contagem desejada de pods.

Carga de trabalho

Uma carga de trabalho é uma aplicação em execução no Kubernetes. Escolha o tipo de carga de trabalho com base no comportamento e nos requisitos da aplicação:

Tipo de carga de trabalho	Descrição	Quando usar
Deployment	Gerencia aplicações replicadas em um cluster Kubernetes. Adequado para aplicações independentes com os mesmos recursos.	Executar múltiplas réplicas de uma aplicação stateless
StatefulSet	Garante implantação ordenada, dimensionamento e atualizações contínuas; suporta armazenamento persistente.	Aplicações que precisam de identidades estáveis ou dados persistentes (bancos de dados, filas)
DaemonSet	Executa um pod em cada nó (ou em um subconjunto selecionado).	Operações em todo o cluster, como coleta de logs, agentes de monitoramento ou plugins de rede no nível do nó
Job	Executa uma tarefa até a conclusão, com paralelismo opcional.	Processamento em lote e tarefas únicas
CronJob	Executa um Job conforme um cronograma.	Tarefas periódicas, como backups ou notificações por e-mail
CustomResourceDefinition (CRD)	Estende a API do Kubernetes com tipos de recursos personalizados.	Integrar controladores de terceiros ou definir recursos específicos de domínio

Rótulo

Rótulos são pares chave-valor em recursos do Kubernetes e não possuem semântica de sistema. Use rótulos para organizar e selecionar recursos — por exemplo, para seletores de Service ou agendamento nodeAffinity. Adicione rótulos na criação ou modifique-os posteriormente. Cada recurso pode ter múltiplos rótulos, mas cada chave deve ser única.

Service

Um Service expõe pods como um endpoint de rede estável. O kube-proxy seleciona um pod de backend e roteia o tráfego para a porta do Service.

Ingress

Um Ingress roteia tráfego HTTP e HTTPS externo para Services dentro do cluster. Configure URLs acessíveis, distribua tráfego, faça terminação SSL e ative hospedagem virtual baseada em nome.

Crie um Ingress com uma solicitação HTTP POST para o servidor de API do cluster. Um controlador de Ingress (geralmente um balanceador de carga) aplica as regras. Para alta disponibilidade, adicione roteadores de borda ou proxies frontend.

ConfigMap

Um ConfigMap armazena configurações não sensíveis como pares chave-valor. Separe a configuração das imagens de contêiner para portar aplicações entre ambientes. ConfigMaps armazenam valores individuais, arquivos de configuração ou objetos JSON.

Secret

Um Secret armazena dados sensíveis, como senhas e certificados, separados da configuração geral para reduzir a exposição acidental.

Volume

Um volume do Kubernetes é um armazenamento com escopo definido pelo tempo de vida de um pod. Diferente dos volumes do docker (com escopo para um contêiner), um volume do Kubernetes é compartilhado entre todos os contêineres no mesmo pod.

Persistent volume (PV)

Um persistent volume (PV) é um armazenamento no nível do cluster, independente de qualquer pod. Provisione tipos de PV, como discos em nuvem ou NAS, por meio de StorageClasses.

Persistent volume claim (PVC)

Um persistent volume claim (PVC) solicita armazenamento. Pods consomem PVCs assim como consomem recursos de nó.

StorageClass

Uma StorageClass define um tipo de armazenamento e permite o provisionamento dinâmico de PV. Quando um PVC referencia uma StorageClass, o Kubernetes cria automaticamente um PV correspondente.

Auto Scaling

O Auto Scaling ajusta os recursos de computação com base na demanda da carga de trabalho. O ACK realiza dimensionamento em dois níveis:

O dimensionamento no nível do pod ajusta a quantidade ou o tamanho dos pods dentro de um cluster:

Componente	Descrição
Horizontal Pod Autoscaler (HPA)	Dimensiona a quantidade de pods com base na utilização de CPU para Deployments e StatefulSets.
CronHPA	Dimensiona cargas de trabalho em um cronograma predefinido usando o componente `kubernetes-cronhpa-controller add-on`. Compatível com HPA — use ambos quando precisar de dimensionamento baseado em tempo e em métricas.
Vertical Pod Autoscaler (VPA)	Ajusta os valores de `request` e `limit` de CPU e memória para pods com base no uso observado. Use VPA para aplicações que não podem escalar horizontalmente ou para redimensionar pods após recuperação de anomalias.

O dimensionamento no nível do nó ajusta a quantidade de nós do cluster:

Componente	Descrição
Cluster Autoscaler	Adiciona ou remove nós quando os pods não podem ser agendados devido a recursos insuficientes. Suporta instâncias regulares, aceleradas por GPU e preemptíveis em múltiplas zonas e tipos de instância.

Use o auto scaling para cargas de trabalho online, computação e treinamento em grande escala, deep learning acelerado por GPU, inferência e treinamento de modelos com GPUs compartilhadas e padrões de carga periódicos.

Observabilidade

A observabilidade no Kubernetes abrange monitoramento e logs:

Monitoramento — rastreia métricas de integridade e desempenho para detecção de problemas em tempo real.
Logs — captura eventos de aplicação e sistema para diagnósticos e solução de problemas.

Helm

Helm é o gerenciador de pacotes do Kubernetes. Um chart do Helm agrupa configurações de recursos para implantar, atualizar e compartilhar aplicações.

nodeAffinity

O nodeAffinity restringe em quais nós um pod pode ser executado com base nos rótulos do nó. Use nodeAffinity para direcionar cargas de trabalho a nós com hardware específico, regiões ou atributos personalizados.

Taint

Um taint marca um nó para repelir pods que não tenham uma tolerância correspondente. Taints funcionam de forma oposta ao nodeAffinity — eles repelem pods em vez de atraí-los.

Toleration

Uma tolerância permite que um pod seja agendado em um nó com um taint correspondente. Tolerâncias permitem, mas não exigem, a alocação em nós com taints.

podAffinity

O podAffinity coloca um pod no mesmo domínio topológico (como o mesmo nó ou zona) que os pods correspondentes a um seletor. Use podAffinity para colocalizar serviços que se comunicam frequentemente e reduzir a latência de rede.

podAntiAffinity

O podAntiAffinity impede que um pod compartilhe um domínio topológico com pods correspondentes a um seletor. Use podAntiAffinity para distribuir réplicas entre nós ou zonas visando maior disponibilidade.

Malha de serviços (Istio)

Istio é uma malha de serviços open source que conecta, protege, controla e observa microsserviços.

O Service Mesh (ASM) é a malha de serviços totalmente gerenciada da Alibaba Cloud, compatível com o Istio open source. Roteie e divida o tráfego entre serviços, proteja a comunicação com autenticação e observe o comportamento do serviço sem modificar o código da aplicação.