Crie uma aplicação stateless usando o console ou kubectl - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Um Deployment é um tipo comum de workload do Kubernetes que permite que você gerencie aplicações stateless. Ele garante que um número especificado de Pods réplica esteja sempre em execução no seu cluster, no estado definido por você. Este tópico descreve como criar uma aplicação stateless em um cluster do Container Service for Kubernetes (ACK) usando o console do ACK e o kubectl.

Antes de começar

Antes de criar um workload, leia Workloads para entender os conceitos básicos e as principais considerações. Este tópico está dividido nas seguintes seções:

Crie um Deployment: Fornece guias de início rápido sobre como criar um Deployment usando o console e o kubectl.
Configuration parameters: Explica os parâmetros de configuração do console e fornece um arquivo yaml de exemplo para o kubectl.

Importante

Os exemplos neste tópico usam uma imagem pública. Para fazer o pull de uma imagem pública, seu cluster ou nós precisam ter acesso à internet pública. Ative esse acesso de uma das seguintes formas:

Ative o acesso à rede pública para um cluster (Recomendado): Crie um gateway NAT para a VPC onde o cluster está implantado. Isso fornece acesso à internet pública para todos os recursos no cluster.
Atribua um static public IP address a um nó: Nós com um endereço IP público podem fazer o pull de imagens públicas. No entanto, você deve atribuir um endereço IP público a cada nó onde implantar o workload.

Crie um Deployment

Use o console

Importante

As etapas a seguir apresentam um processo simplificado para criar um workload. Siga estas etapas para implantar a aplicação e verifique sua aplicação rapidamente. Depois de se familiarizar com as operações básicas, crie workloads mais complexos e consulte Configuration parameters para personalizar seu workload.

Configure basic application information
1. Faça login no ACK console e clique em Clusters no painel de navegação à esquerda. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, escolha Workloads > Deployments. Na página Deployments, clique em Create from Image.
2. Na página Basic Information, configure as definições básicas da aplicação. Em seguida, clique em Next.
Configure the container

Na seção Container Configuration, configure o Image Name e a Port. As outras configurações são opcionais e você pode manter os valores padrão. Em seguida, clique em Next para abrir a página do assistente Advanced Settings. O endereço da imagem é o seguinte.

Importante
Para fazer o pull desta imagem, você precisa ativar o acesso à internet pública para o seu cluster. Se você manteve a opção Configure SNAT for VPC selecionada ao criar o cluster, o acesso à internet pública já está ativado. Caso contrário, consulte Ative o acesso à rede pública para um cluster.
Configure advanced settings

Na página Advanced, configure o controle de acesso, o dimensionamento e as definições de agendamento. Na seção Access Control, configure como expor os Pods de backend e clique em OK. Em seguida, clique em Create na parte inferior da página.

Importante
Esta etapa cria um service do tipo LoadBalancer para expor o workload. A instância do Server Load Balancer (SLB) associada incorre em taxas. Para mais informações, consulte Pay-as-you-go. Se você não precisar mais da instância do SLB, libere-a prontamente para evitar cobranças desnecessárias.
View the application

Após a criação da aplicação, a página Complete é exibida. No painel Creation Task Submitted, clique em View Details. Clique na aba Access Method, encontre o service recém-criado (nginx-test-svc) e, em seguida, clique no link na coluna External Endpoint para acessar a página de boas-vindas do NGINX.

Você pode usar as opções View, Edit ou Redeploy para o workload criado.

Use o kubectl

Importante

Antes de criar um workload, conecte-se ao seu cluster ACK usando o kubectl e bash. Para mais informações, consulte Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster.

Copie a seguinte configuração yaml e salve-a em deployment.yaml. Esta configuração define um Deployment e um service do tipo LoadBalancer para acesso externo.
Execute o seguinte comando para criar o Deployment e o service:

Saída esperada:
Execute o seguinte comando para consultar o endereço IP público do service:

Saída esperada:
Insira o endereço IP público do Nginx (106.14.**.***) em um navegador para acessar o contêiner Nginx do workload.

Parâmetros de configuração

Parâmetros do console

Informações básicas

Parâmetro	Descrição
Name	O nome do workload. Os nomes dos Pods são derivados deste nome.
Namespace	O namespace que contém o workload.
Replicas	O número de réplicas de Pods. Valor padrão: 2.
Type	O tipo do workload. Para mais informações sobre como selecionar um tipo de workload, consulte Crie um workload.
Label	Os rótulos do workload.
Annotations	As anotações do workload.
Synchronize Timezone	Especifica se o contêiner usa o mesmo fuso horário do seu nó host.

Configuração do contêiner

General

Parâmetro	Descrição
Image Name	Select images Clique em Select images e escolha uma imagem. Você pode selecionar um dos seguintes tipos de imagem: Container Registry Enterprise Edition: Selecione uma imagem da Enterprise Edition hospedada no Alibaba Cloud Container Registry (ACR). Especifique a região e a instância do ACR onde a imagem está localizada. Para mais informações sobre o ACR, consulte What is ACR?. Container Registry Personal Edition: Selecione uma imagem da Personal Edition hospedada no ACR. Você deve especificar a região e a instância do ACR onde a imagem está localizada. Artifact Center: Imagens comuns fornecidas pela Alibaba Cloud e pela comunidade OpenAnolis. Para usar uma imagem do Artifact Center, você deve ative o acesso à internet pública para o cluster. Para mais informações, consulte Artifact Center. Ao usar uma imagem de outro source, você pode inserir diretamente o endereço da imagem no formato `domainname/namespace/imagename:tag`. Se você não especificar o `domainname`, por exemplo, insira `nginx:1.7.9`, e a imagem será baixada do Docker Hub. Select image pull policy O ACK oferece suporte às seguintes políticas de pull de imagem (`imagePullPolicy`): IfNotPresent (Padrão): Se a imagem já estiver presente no nó, a versão local será usada. Caso contrário, a imagem será baixada do repositório. Always: A imagem é sempre baixada do repositório toda vez que um Pod é criado. Never: Apenas a imagem local é usada. Se a imagem não estiver presente no nó, o Pod falhará ao iniciar. Set image pull Secret Ao usar imagens do ACR ou de um repositório de terceiros, talvez seja necessário configurar um Secret para fazer o pull das imagens. Nota Para instâncias do ACR Enterprise Edition, você pode usar um componente sem senha para fazer o pull de imagens. Para mais informações, consulte Instale e use o componente sem senha para clusters não gerenciados.
Resource limit	O `resources.limits` do contêiner (CPU, memória). Para mais informações, consulte Requests and Limits.
Resource requests	O `resources.requests` dos recursos do contêiner. Para mais informações, consulte Requests and Limits.
Container start parameter	`stdin`: Indica que a entrada padrão está ativada para o contêiner. `tty`: Aloca um terminal virtual para o contêiner, permitindo o envio de sinais para ele. Essas duas opções são normalmente usadas juntas para anexar um terminal (`tty`) à entrada padrão (`stdin`) do contêiner. Por exemplo, um programa interativo recebe a entrada padrão do usuário e a exibe no terminal.
Privileged container	Se você selecionar esta caixa de seleção, `privileged` é definido como `true` para ativar o modo privilegiado. Se você não selecionar esta caixa de seleção, `privileged` é definido como `false` para desativar o modo privilegiado. O modo privilegiado concede a um contêiner quase o mesmo nível de acesso ao sistema operacional host que os processos em execução no host. Isso inclui acesso a dispositivos de hardware e a capacidade de montar sistemas de arquivos.
Init containers	Selecione esta opção para criar um contêiner de inicialização (init container). Os init containers são executados e concluídos antes que os contêineres principais da aplicação iniciem. Eles podem ser usados para atrasar a inicialização dos contêineres da aplicação até que certas pré-condições sejam atendidas, como aguardar a disponibilidade de um service dependente. Os init containers também podem conter ferramentas utilitárias ou scripts de configuração que não estão presentes na imagem da aplicação para inicializar o ambiente de execução, como definir parâmetros do kernel ou gerar arquivos de configuração. Para mais informações, consulte Init Containers na documentação do Kubernetes.

Ports

Parâmetro	Descrição
Name	O nome da porta do contêiner. Isso serve apenas para fins de identificação e não tem impacto funcional.
Container Port	A porta que o contêiner expõe. O valor deve ser um número inteiro de 1 a 65535. Um contêiner deve expor uma porta para ser acessível de fora do Pod e permitir a comunicação com outros contêineres no mesmo Pod. Todos os contêineres em um Pod compartilham o mesmo namespace de rede, portanto, os números de porta devem ser exclusivos dentro de um Pod.
Protocol	O protocolo da camada 4 usado pela porta do contêiner. Valores válidos: TCP e UDP.

Environment variables

Parâmetro	Descrição
Type	O método usado para definir variáveis de ambiente. Os seguintes tipos são suportados: Custom Você pode usar `env` para codificar diretamente variáveis de ambiente em um workload. ConfigMaps Use `envFrom` para recuperar dados de configuração não sensíveis de um ConfigMap. Secrets Você pode usar `envFrom` para recuperar informações sensíveis armazenadas em um ConfigMap, como senhas e chaves de API. Value/ValueFrom Use `value/valueFrom` para recuperar outras variáveis de ambiente ou valores predefinidos. ResourceFieldRef Use `resourceFieldRef` para obter informações de recursos sobre o nó em que o Pod está em execução. Você pode referenciar todos os pares chave-valor de um ConfigMap ou Secret. Por exemplo, para referenciar todos os dados de um Secret, selecione o tipo Secrets e, em seguida, selecione o Secret de destino sem especificar uma chave. O yaml correspondente também referencia o Secret inteiro. Para selecionar uma referência de recurso, você pode usar o parâmetro `resourceFieldRef`. Este parâmetro referencia os valores de recurso declarados para um contêiner na especificação do Pod e passa esses valores para o contêiner como variáveis de ambiente. O yaml correspondente é o seguinte:
Variable Key	O nome da variável de ambiente dentro do Pod.
Value/ValueFrom	O valor da variável de ambiente ou uma referência a um valor de outra fonte.

Health checks

Parâmetro	Descrição
Liveness probe: Uma liveness probe verifica se um contêiner está em execução. Se a probe falhar várias vezes, o kubelet reinicia o contêiner. Isso pode ajudar a resolver problemas como deadlocks, onde o contêiner está em execução, mas não consegue progredir.	Tipo de requisição: requisição HTTP Envia uma requisição HTTP para o contêiner para verificar periodicamente sua integridade. Protocol: HTTP, HTTPS ou TLS. Path: O caminho a ser acessado no servidor HTTP. Port: A porta ou nome da porta exposta pelo contêiner. O número da porta deve ser um inteiro de 1 a 65535. HTTP Headers: Cabeçalhos personalizados a serem definidos na requisição HTTP. Especifique vários cabeçalhos com a mesma chave. Initial Delay (seconds): O número de segundos a aguardar após o início de um contêiner antes que a primeira probe seja executada. Isso corresponde ao parâmetro initialDelaySeconds. O padrão é 3 segundos. Probe interval (seconds): O intervalo para executar uma probe, especificado pelo parâmetro periodSeconds. O valor padrão é 10 segundos e o valor mínimo é 1 segundo. Timeout (seconds): O tempo limite para uma probe, especificado pelo parâmetro timeoutSeconds. O valor padrão é 1 segundo e o valor mínimo é 1 segundo. Healthy threshold: O número mínimo de probes consecutivas bem-sucedidas necessárias para marcar o contêiner como íntegro após uma falha. Valor padrão: 1. Valor mínimo: 1. Para uma liveness probe, este valor deve ser 1. Unhealthy threshold: O número mínimo de probes consecutivas com falha necessárias para marcar o contêiner como não íntegro. Valor padrão: 3. Valor mínimo: 1. Tipo de requisição: conexão TCP O kubelet tenta abrir um soquete TCP na porta especificada. Se a conexão for estabelecida, o contêiner é considerado íntegro. Caso contrário, é considerado como falha. Port: A porta ou nome da porta exposta pelo contêiner. O número da porta deve ser um inteiro de 1 a 65535. Initial delay (seconds): O valor do parâmetro initialDelaySeconds. Este é o número de segundos a aguardar após o início de um contêiner antes que a primeira probe seja executada. O padrão é 15 segundos. Probe frequency (seconds): O intervalo para executar a probe, especificado pelo parâmetro periodSeconds. O valor padrão é 10 segundos e o valor mínimo é 1 segundo. Timeout (seconds): O tempo limite para uma probe. Isso corresponde ao parâmetro timeoutSeconds. O valor padrão é 1 segundo e o valor mínimo é 1 segundo. Healthy threshold: O número mínimo de probes consecutivas bem-sucedidas necessárias para marcar o contêiner como íntegro após uma falha. Valor padrão: 1. Valor mínimo: 1. Para uma liveness probe, este valor deve ser 1. Unhealthy threshold: O número mínimo de probes consecutivas com falha necessárias para marcar o contêiner como não íntegro. Valor padrão: 3. Valor mínimo: 1. Tipo de requisição: linha de comando Executa um comando dentro do contêiner para determinar seu status de integridade. Command: O comando usado para sondar a integridade do contêiner. Initial delay (seconds): O valor para initialDelaySeconds, que é o número de segundos a aguardar após o início de um contêiner antes que a primeira probe seja executada. O padrão é 5 segundos. Probe Interval (seconds): O intervalo de tempo para executar uma probe. Isso corresponde ao parâmetro periodSeconds. O valor padrão é 10 segundos e o valor mínimo é 1 segundo. Timeout (seconds): O parâmetro timeoutSeconds, que especifica o tempo limite para uma probe. O valor padrão é 1 segundo. O valor mínimo é 1 segundo. Healthy threshold: O número mínimo de probes consecutivas bem-sucedidas necessárias para marcar o contêiner como íntegro após uma falha. Valor padrão: 1. Valor mínimo: 1. Para uma liveness probe, este valor deve ser 1. Unhealthy threshold: O número mínimo de probes consecutivas com falha necessárias para marcar o contêiner como não íntegro. Valor padrão: 3. Valor mínimo: 1.
Readiness probe: Uma readiness probe verifica se um contêiner está pronto para aceitar tráfego. Um Pod é adicionado como backend a um service somente após sua readiness probe ser bem-sucedida.
Startup Probes: Essas probes são executadas apenas quando um contêiner inicia para verificar se ele foi iniciado com sucesso. As Liveness Probes e Readiness Probes são executadas somente após a startup probe ser bem-sucedida. Nota Startup probes são suportadas apenas em clusters Kubernetes que executam a versão 1,18 ou posterior.

Lifecycle

Parâmetro	Descrição
Start	Define o comando e os argumentos de início para o contêiner. Estes definem as operações realizadas quando o contêiner inicia e são usados para inicializar o service da aplicação. Isso é adequado para implantações de aplicações que requerem variáveis de ambiente, pontos de montagem ou mapeamentos de porta específicos.
Post Start	Define um comando que é executado imediatamente após a criação de um contêiner. Isso é útil para realizar tarefas como inicializar configurações ou executar scripts antes que o processo principal inicie.
Pre Stop	Define um comando que é executado imediatamente antes de um contêiner ser encerrado. Isso é útil para desligar o processo da aplicação de forma graceful, garantindo a consistência dos dados e evitando perda de dados ou anomalias no service.
Você pode configurar handlers de start, post-start e pre-stop para o ciclo de vida de um contêiner. Para mais informações, consulte Attach Handlers to Container Lifecycle Events na documentação do Kubernetes.

Volumes

Parâmetro	Descrição
Add Local Storage	Monta um volume de armazenamento local do nó host no Pod. Os dados em um volume de armazenamento local são armazenados no nó e são perdidos se o nó for desligado. O armazenamento local também suporta a montagem de Secrets, ConfigMaps e outros tipos de volumes efêmeros. Antes de usar volumes de armazenamento, leia Storage para entender os conceitos básicos de armazenamento no ACK.
Add PVC (PersistentVolumeClaim)	Monta um volume de armazenamento em cloud no Pod para persistir dados importantes. Um volume de armazenamento em cloud é um service de armazenamento remoto independente dos nós de trabalho e não é afetado por alterações nos nós. O ACK suporta vários services de armazenamento da Alibaba Cloud, como discos em cloud, Apsara File Storage NAS e Object Storage Service (OSS). Antes de usar volumes de armazenamento, leia Storage para entender os conceitos básicos de armazenamento no ACK.

Log

Collection configuration	Log Service: Um Logstore é criado no projeto do Log Service associado ao cluster para armazenar os logs coletados. Antes de usar logs, leia Log Management para entender os conceitos básicos de logging no ACK. O caminho do log no contêiner. Defina como `Stdout` para coletar os logs de saída padrão do contêiner.
Custom Tag	Após definir uma tag personalizada, a tag é coletada junto com a saída de log do contêiner. Isso ajuda na análise, como estatísticas e filtragem de logs.

Configuração avançada

Cartão de configuração	Parâmetro	Descrição
Access Control	Services	Um service fornece um endpoint unificado e estável da Camada 4 (camada de transporte) para um grupo de Pods. É um recurso obrigatório para expor um workload. Os Services suportam vários tipos, incluindo Cluster IP, Node Port e Load Balancer. Antes de configurar um service, consulte Service management para entender os conceitos básicos.
Access Control	Ingresses	Um Ingress fornece um ponto de entrada da Camada 7 (camada de aplicação) para vários Services em um cluster e encaminha requisições para diferentes Services com base na correspondência de nome de domínio. Antes de usar um Ingress, instale um controlador de Ingress. O ACK fornece várias opções para diferentes cenários. Para mais informações, consulte Comparison of NGINX Ingress Controller, ALB Ingress Controller, and MSE Ingress gateways.
Scaling	Horizontal Pod Autoscaler (HPA)	O Horizontal Pod Autoscaler (HPA) dimensiona automaticamente o número de Pods com base nas métricas de desempenho do contêiner. Isso ajuda a ajustar o total de recursos usados pelo seu workload em resposta a flutuações na carga de negócios, escalando horizontalmente para lidar com cargas altas e reduzindo para economizar recursos durante cargas baixas. Para mais informações, consulte Use a HorizontalPodAutoscaler to automatically scale Pods.
Scaling	Cron Horizontal Pod Autoscaler (CronHPA)	O Cron Horizontal Pod Autoscaler (CronHPA) dimensiona workloads em horários agendados. Isso é adequado para cenários com alterações cíclicas e previsíveis na carga de negócios, como os picos de tráfego em plataformas de redes sociais após o almoço e o jantar. Para mais informações, consulte Use a CronHPA to automatically scale Pods.
Scheduling	Upgrade strategy	A estratégia usada para substituir Pods antigos por novos quando a configuração do Pod muda. `rolling update`: Substitui os Pods um por um ou em lotes. A próxima substituição começa apenas após os novos Pods estarem em execução com sucesso. Este método garante a continuidade do service, mas os clientes podem acessar diferentes versões dos Pods simultaneamente sempre que atualize o workload. `recreate`: Encerra todos os Pods existentes de uma só vez antes de criar novos. Isso pode causar uma interrupção no service, mas garante que todos os Pods executem a mesma versão após a atualização.
Scheduling	Node affinity Pod affinity Pod anti-affinity Tolerations	Afinidade, anti-afinidade e tolerâncias são usados para controlar como os Pods são agendados nos nós. Essas operações são complexas e requerem planejamento antecipado. Para mais informações, consulte Scheduling.
Labels and annotations	Pod labels	Adicione um rótulo a cada Pod que pertence ao workload. Em um cluster, recursos como workloads e Services usam rótulos para corresponder aos Pods. Por padrão, o ACK adiciona um rótulo no formato `app:(application name)` aos Pods.
Labels and annotations	Pod annotations	Adiciona anotações a cada Pod neste workload. Alguns recursos no ACK usam anotações; adicione ou modifique conforme necessário ao usar esses recursos.

yaml de exemplo de workload

Referência

Para aplicações que requerem armazenamento estável e persistente, como bancos de dados, use um StatefulSet. Para mais informações, consulte Crie um workload stateful (StatefulSet).
Se você encontrar problemas ao criar um workload, consulte Workloads FAQ.
Se um Pod estiver em um estado anormal, consulte Troubleshoot Pod exceptions.