Cargas de trabalho stateless não persistem dados ou estado — como o Nginx, por exemplo. É possível criar uma aplicação stateless usando uma imagem, um modelo ou a CLI. Ao utilizar uma imagem privada, configure um Secret de pull de imagem no console do ACK para garantir a segurança. Este tópico explica como criar uma aplicação stateless a partir de uma imagem no console, em um cluster ACK Serverless.
Pré-requisitos
Certifique-se de que:
Um cluster ACK Serverless foi criado.
Etapa 1: Configure as definições básicas
Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no cluster desejado. No painel de navegação à esquerda, escolha Workloads > Deployments.
Na página Deployments, clique em Create from Image.
Na página Basic Information, selecione um namespace. Este exemplo utiliza o namespace default.
-
Configure as definições básicas.
Parâmetro
Descrição
Name
Insira um nome para a aplicação.
Replicas
Especifique a quantidade de pods a serem provisionados.
Type
Selecione o tipo de recurso: Deployment, StatefulSet, Job ou CronJob.
Label
Adicione rótulos para identificar a aplicação.
Annotations
Adicione anotações à aplicação.
Clique em Next.
Etapa 2: Configure o contêiner
Na etapa Container, configure a imagem do contêiner, os recursos computacionais, as portas, as variáveis de ambiente, as verificações de integridade, o ciclo de vida e os volumes.
Clique em Add Container para adicionar mais contêineres.
Configure a imagem
Na seção General, defina as seguintes configurações:
|
Parâmetro |
Descrição |
|
Image Name |
Selecione ou insira uma imagem de contêiner. Consulte Escolha uma origem de imagem abaixo. |
|
Required Resources |
Reserve CPU e memória para o contêiner. Isso evita interrupções por contenção de recursos e é obrigatório para o HPA. |
|
Container Start Parameter |
stdin: passa a entrada do console do ACK para o contêiner. tty: aloca um pseudo-TTY para que o contêiner use o console como entrada padrão.: passa parâmetros de início de um terminal virtual para o console do ACK. |
|
Init Containers |
Crie um contêiner de inicialização para preparar o pod. Consulte Init containers. |
Escolha uma origem de imagem
Clique em Select images. Origens disponíveis:
Container Registry Enterprise Edition: imagens em uma instância do Container Registry Enterprise Edition. Selecione a região e a instância. Nenhum Secret é necessário.
Container Registry Personal Edition: imagens armazenadas em uma instância do Container Registry Personal Edition. Selecione a região e a instância.
-
Artifact Center: imagens base de SO, imagens base de linguagem e imagens de IA/big data mantidas pela Alibaba Cloud e OpenAnolis. Este exemplo usa uma imagem NGINX. Consulte Visão geral do centro de artefatos.
Para dúvidas ou solicitações de imagens, participe do grupo DingTalk 33605007047.
Private registry: insira o endereço da imagem no formato
domainname/namespace/imagename:tag.
Política de pull de imagem
|
Política |
Comportamento |
|
IfNotPresent |
Usa uma imagem em cache local, se disponível; caso contrário, faz o pull do registro. |
|
Always |
Faz o pull do registro sempre que a aplicação for implantada ou dimensionada. |
|
Never |
Usa apenas imagens em cache local; nunca faz o pull do registro. |
Se nenhuma opção for selecionada, nenhuma política de pull será aplicada.
Set Image Pull Secret
Para fazer o pull de imagens de um registro privado (como o Container Registry Personal Edition), clique em Set Image Pull Secret e selecione um Secret. Consulte Gerenciar Secrets. Não é necessário Secret para o Container Registry Enterprise Edition.
Configure as portas
Na seção Ports, clique em Add.
|
Campo |
Descrição |
|
Name |
Insira um nome para a porta. |
|
Container Port |
Insira um número de porta (1–65535). |
|
Protocol |
Selecione TCP ou UDP. |
Configure as variáveis de ambiente
Na seção Environments, clique em Add para configurar as variáveis de ambiente.
Para usar ConfigMaps ou Secrets como origens de variáveis de ambiente, crie-os primeiro. Consulte Gerenciar ConfigMaps e Gerenciar Secrets .
Defina o Type como uma das opções: Custom, ConfigMaps, Secrets, Value/ValueFrom ou ResourceFieldRef. Ao selecionar ConfigMaps ou Secrets, todos os dados do recurso escolhido são passados ao contêiner como variáveis de ambiente.
Este exemplo utiliza Secrets: selecione Secrets na lista Type e, em seguida, escolha um Secret em Value/ValueFrom. Todos os dados do Secret selecionado serão transmitidos como variáveis de ambiente.

Configure as verificações de integridade
Na seção Health Check, ative as sondas conforme necessário:
|
Sonda |
Finalidade |
Quando usar |
|
Liveness |
Detecta se o contêiner está executando corretamente e o reinicia em caso de falha. |
Configure sempre para contêineres de longa duração. |
|
Readiness |
Determina se o contêiner está pronto para receber tráfego. |
Utilize quando a aplicação precisar de tempo de aquecimento antes de atender requisições. |
|
Startup |
Verifica se a aplicação foi iniciada e desativa outras sondas até obter sucesso. |
Recomendado para aplicações com tempo de inicialização prolongado. |
As sondas de startup exigem Kubernetes 1.18 ou posterior.
Cada sonda suporta os seguintes tipos de requisição:
HTTP — envia uma requisição HTTP para verificar a integridade do contêiner.
|
Parâmetro |
Descrição |
Padrão |
|
Protocol |
HTTP ou HTTPS. |
— |
|
Path |
Caminho HTTP no servidor. |
— |
|
Port |
Número ou nome da porta exposta pelo contêiner (1–65535). |
— |
|
HTTP Header |
Cabeçalhos personalizados em pares chave-valor; duplicatas permitidas. |
— |
|
Initial Delay (s) |
Segundos de espera após o início do contêiner antes da primeira sonda ( |
Liveness: 3; TCP: 15; Command: 5 |
|
Period (s) |
Intervalo entre sondas ( |
10 |
|
Timeout (s) |
Tempo limite antes que a sonda expire ( |
1 |
|
Healthy Threshold |
Sucessos consecutivos necessários para considerar o contêiner íntegro. Deve ser 1 para sondas de liveness. |
1 |
|
Unhealthy Threshold |
Falhas consecutivas necessárias para considerar o contêiner não íntegro. Valores maiores toleram falhas transitórias; valores menores acionam reinícios mais cedo. |
3 |
TCP — abre um soquete TCP para verificar a integridade do contêiner. Usa os mesmos parâmetros do HTTP, exceto Protocol, Path e HTTP Header.
Command — executa um comando dentro do contêiner para verificar a integridade. Suporta Command, Initial Delay, Period, Timeout, Healthy Threshold e Unhealthy Threshold.
Configure o ciclo de vida
Na seção Lifecycle, configure os hooks de ciclo de vida:
Start: executado antes do contêiner iniciar.
Post Start: executado após o contêiner iniciar.
Pre Stop: executado antes do contêiner parar.
Configure os volumes
Na seção Volume, adicione volumes de armazenamento:
Volume de armazenamento local
PVC (PersistentVolumeClaim)
NAS (File Storage NAS)
Disco
Consulte Usar um volume de disco provisionado estaticamente, Usar um volume de disco provisionado dinamicamente e Montar um volume NAS provisionado estaticamente.
Configure a coleta de logs
Na seção Log, configure a coleta de logs. Consulte Criar uma aplicação a partir de uma imagem e configurar o Simple Log Service para coletar logs da aplicação.
Clique em Next.
Etapa 3: Configure as definições avançadas
Na etapa Advanced, configure o controle de acesso, o dimensionamento, os rótulos e as anotações.
Configure o controle de acesso
Na seção Access Control, escolha como expor os pods da aplicação.
Aplicações internas: crie um Service do tipo ClusterIP ou NodePort para comunicação dentro do cluster.
Aplicações externas: exponha a aplicação para a internet:
LoadBalancer Service: defina o tipo de Service como Server Load Balancer. Selecione ou crie uma instância SLB para rotear o tráfego externo.
Ingress: utilize um recurso Ingress para rotear tráfego HTTP/HTTPS para o Service. Consulte Ingress.
Este exemplo cria um Service ClusterIP e um Ingress para expor uma aplicação NGINX.
Crie um Service
Clique em Create ao lado de Services e configure os seguintes parâmetros:
|
Parâmetro |
Descrição |
|
Name |
Insira um nome para o Service. Este exemplo usa nginx-svc. |
|
Type |
Este exemplo utiliza Cluster IP.Server Load Balancer. Opções: Cluster IP, Server Load Balancer, Node Port. |
|
Port Mapping |
Mapeie uma porta do Service para uma porta do contêiner. Este exemplo usa a Porta do Service 80 e a Porta do Contêiner 80. |
|
External Traffic Policy |
Local: roteia o tráfego apenas para o nó onde o Service está executando. Cluster: roteia o tráfego para pods em qualquer nó. Aplica-se apenas aos tipos NodePort e Server Load Balancer. |
|
Annotations |
Adicione anotações de configuração do SLB. Por exemplo, |
|
Label |
Adicione rótulos para identificar o Service. |
Ao usar instâncias SLB:
Os listeners em uma instância SLB existente sobrescrevem os listeners do Service.
Uma instância SLB criada junto com um Service não pode ser reutilizada por outros Services. Apenas instâncias SLB criadas manualmente no console ou via API podem ser compartilhadas.
Services que compartilham a mesma instância SLB devem usar portas de frontend diferentes para evitar conflitos.
Não modifique nomes de listeners ou grupos vServer em instâncias SLB compartilhadas, pois o ACK os utiliza como identificadores únicos.
Instâncias SLB não podem ser compartilhadas entre clusters.
Crie um Ingress
Clique em Create ao lado de Ingresses e configure os seguintes parâmetros:
|
Parâmetro |
Descrição |
|
Name |
Insira um nome para o Ingress. Este exemplo usa nginx-ingress. |
|
Rule |
Defina regras de roteamento: Domain (este exemplo usa o domínio de teste |
|
Weight |
Defina o peso do tráfego para cada Service no caminho. Padrão: 100. |
|
Canary Release |
Ative o canary release. Recomendação: Open Source Solution. |
|
Ingress Class |
Especifique a classe do Ingress. |
|
Annotations |
Adicione anotações ao Ingress. Consulte Annotations. |
|
Labels |
Adicione rótulos para descrever o Ingress. |
Cada Service pode ter apenas um Ingress. Este exemplo utiliza um nome de host virtual como domínio de teste. Adicione o IP do Ingress ao seu arquivo hosts. Para encontrá-lo, acesse a página de detalhes da aplicação > aba Access Method > coluna External Endpoint. Em produção, utilize um domínio com registro ICP.
101.37.xx.xx foo.bar.com # Replace with the actual Ingress IP address
Após criar o Service e o Ingress, eles aparecerão na seção Access Control. Clique em Update ou Delete para modificá-los.
Configure o auto scaling
Na seção Scaling, configure o Horizontal Pod Autoscaler (HPA) ou CronHPA.
O HPA exige que os Required Resources estejam configurados na Etapa 2.
O HPA dimensiona automaticamente os pods com base no uso de CPU ou memória:
|
Parâmetro |
Descrição |
|
Metric |
Selecione CPU Usage ou Memory Usage. Deve corresponder ao tipo de recurso configurado em Required Resources. |
|
Condition |
Limiar de uso que aciona o scale-out. Por exemplo, 70% de CPU significa que o HPA adicionará pods quando o uso médio exceder 70%. |
|
Max. Replicas |
Número máximo de pods para os quais a aplicação pode escalar. |
|
Min. Replicas |
Número mínimo de pods que devem estar sempre em execução. |
O CronHPA também é suportado para dimensionamento baseado em agendamento.
Adicione rótulos e anotações
Na seção Labels,Annotations, clique em Add.
Pod Labels: rótulos para identificar o pod.
Pod Annotations: anotações para o pod.
Clique em Create.
Etapa 4: Verifique a implantação
Verifique se o Deployment, o Service e a aplicação estão executando corretamente.
Verifique o Deployment
Na etapa Complete, clique em View Details. Na página Deployments, confirme que a aplicação chamada serverless-app-svc aparece na lista.

Verifique o Service
No painel de navegação à esquerda, escolha Network > Services. Confirme que o Service chamado serverless-app-svc aparece na lista.

Acesse a aplicação
Abra o endpoint externo ou o nome de domínio em um navegador para visitar a página de boas-vindas do NGINX.

O tipo de Service deve ser Server Load Balancer para acesso via navegador.
Se estiver usando
foo.bar.com, adicione o IP do Ingress ao seu arquivo hosts conforme descrito em Criar um Ingress.