Container Service for Kubernetes:Workload FAQ

Como implantar uma aplicação containerizada em um cluster ACK?

A implantação de uma aplicação containerizada envolve quatro fases:

1. Escreva o código da aplicação em qualquer linguagem.

2. Crie uma imagem de container com um Dockerfile — arquivo de texto que empacota o código e todas as dependências em um artefato de entrega portátil. A imagem de container é mais completa que pacotes tradicionais (como JAR, WAR ou RPM), pois agrupa a aplicação com todos os arquivos necessários ao runtime do container. Use essa imagem para iniciar o container, que representa a aplicação em execução. Para obter instruções passo a passo, consulte Build, package, and run images using a Dockerfile.

3. Envie a imagem para um registry. O Container Registry (ACR) armazena, gerencia, distribui e serve imagens. O ACR oferece duas edições. Para mais informações, consulte What is Container Registry ACR.

   • Personal Edition — para desenvolvedores individuais

   • Enterprise Edition — para clientes corporativos

4. Implante workloads no ACK para executar a aplicação containerizada. O ACK gerencia todo o ciclo de vida dos workloads containerizados, incluindo agendamento de pods em nós específicos, dimensionamento conforme mudanças de carga, entre outros recursos. Para mais informações, consulte Workloads.

Por que os pulls de imagem demoram muito ou falham?

Verifique os itens abaixo conforme a origem do pull:

Pull via rede pública

• Verifique se o cluster tem acesso à rede pública. Consulte Enable public network access for a cluster.

• Confirme se o registry de imagens também permite acesso público. Para um exemplo com o ACR, consulte Configure public network access control for ACR.

• Verifique se a largura de banda do IP público está configurada com valor muito baixo.

Pull a partir do ACR

• Verifique se o secret de pull de imagem está correto. Consulte How do I use imagePullSecrets?.

• Se usar o componente de pull sem senha, verifique se ele está configurado corretamente. Consulte Pull images within the same account e Pull images across accounts.

Como solucionar problemas de aplicações no ACK?

Falhas em aplicações geralmente têm origem em pods, controladores (Deployment, StatefulSet, DaemonSet) ou Services. Identifique qual camada apresenta o problema e siga as etapas abaixo.

kubectl get endpoints <service_name>

Como atualizar o Helm manualmente?

O componente Tiller do Helm v2, executado no lado do servidor, possui vulnerabilidades de segurança conhecidas que permitem a invasores instalar aplicações não autorizadas nos clusters. Atualize para o Helm v3. Consulte Upgrading from Helm v2 to Helm v3.

Como fazer pull de imagens de uma instância do Container Registry Enterprise Edition na China continental para um cluster ACK fora da China continental?

Adquira as seguintes instâncias do Container Registry Enterprise Edition:

• Instância Standard ou Premium na região dentro da China continental

• Instância Basic na região fora da China continental

Em seguida, use uma instância de sincronização para replicar imagens da região da China continental para a região fora da China continental. Consulte Same-account sync instance. Após a sincronização, obtenha o endereço do registry da instância Enterprise Edition na região fora da China continental e utilize-o ao criar aplicações no ACK.

O ACR Personal Edition apresenta velocidades de sincronização mais lentas. Para repositórios autogerenciados, é necessário adquirir o Global Acceleration (GA) para acelerar o pull de imagens, o que aumenta o custo. O Container Registry Enterprise Edition é a opção recomendada. Consulte Billing information .

Como realizar rolling updates sem interrupção de service?

Durante a substituição de pods em um rolling update, ocorre um atraso de alguns segundos antes que as alterações nos pods sejam sincronizadas com a instância do Classic Load Balancer (CLB). Isso pode gerar erros 5XX temporários. Configure o desligamento gracioso para garantir rolling updates sem tempo de inatividade. Consulte Implement zero-downtime rolling deployments.

Como obter uma imagem de container para um workload?

Para pré-requisitos e orientações sobre o pull de imagens de container, consulte Pull image.

Como reiniciar um container?

O Kubernetes não suporta o reinício direto de containers individuais. Em vez disso, exclua o pod — o controlador (Deployment, DaemonSet, etc.) cria automaticamente um substituto.

1. Liste os pods para encontrar aquele que deseja reiniciar:

   kubectl get pods

2. Exclua o pod:

   kubectl delete pod <pod-name>

3. Verifique se o novo pod está em execução:

   kubectl get pods

   Confirme se o status do pod é Running.

Em produção, gerencie containers por meio de objetos de nível superior, como ReplicaSets e Deployments, em vez de manipular pods diretamente. Isso preserva a consistência do estado do cluster.

Como alterar o namespace de um Deployment?

Mover um Deployment para outro namespace também exige a atualização manual dos recursos dependentes — persistent volume claims (PVCs), ConfigMaps e Secrets — para o novo namespace.

1. Exporte a configuração do Deployment:

   kubectl get deploy <deployment-name> -n <old-namespace> -o yaml > deployment.yaml

2. Edite o arquivo deployment.yaml e substitua o valor de namespace:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     annotations:
     generation: 1
     labels:
       app: nginx
     name: nginx-deployment
     namespace: new-namespace # Specify the new namespace.
     ... ...

3. Aplique a configuração atualizada:

   kubectl apply -f deployment.yaml

4. Verifique se o Deployment está em execução no novo namespace:

   kubectl get deploy -n new-namespace

Como expor informações do pod a containers em execução?

O ACK segue as especificações nativas da comunidade Kubernetes. Dois métodos são suportados:

• Variáveis de ambiente — transmitem informações do pod para um container por meio de variáveis de ambiente. Consulte Expor informações do pod a containers por meio de variáveis de ambiente.

• Arquivos — montam informações do pod como arquivos dentro do container usando o volume da Downward API. Consulte Expor informações do pod a containers por meio de arquivos.

Como usar imagePullSecrets?

Instâncias do ACR Personal Edition criadas em ou após 9 de setembro de 2024 não suportam aliyun-acr-credential-helper. Armazene suas credenciais em um Secret do Kubernetes e referencie-as via imagePullSecrets.

Etapa 1: Criar o Secret

kubectl create secret docker-registry image-secret \
  --docker-server=<ACR-registry> \
  --docker-username=<username> \
  --docker-password=<password> \
  --docker-email=<email@example.com>

Etapa 2: Referenciar o Secret

Escolha um dos métodos a seguir:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: default
imagePullSecrets:
- name: image-secret # Enter the ACR Secret

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
  namespace: default
  labels:
    app: nginx
spec:
  serviceAccountName: default # If using the default ServiceAccount for the namespace, you do not need to specify it.
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: <acrID>.cr.aliyuncs.com/<repo>/nginx:latest  # Replace with the ACR instance link

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
  namespace: default
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      imagePullSecrets:
      - name: image-secret  # Use the Secret created in the previous step
      containers:
      - name: nginx
        image: <acrID>.cr.aliyuncs.com/<repo>/nginx:latest  # Replace with the Registry Address of the ACR repository

Verificar

Após aplicar a configuração, confirme se o pod está em execução:

kubectl get pods

Por que os pulls ainda falham após configurar o componente sem senha?

O componente de pull sem senha pode estar mal configurado. Verifique estas duas causas comuns:

• As informações da instância no componente não correspondem à instância do ACR.

• O endereço da imagem usado para o pull não corresponde ao nome de domínio configurado no componente.

Siga Pull images within the same account para verificar a configuração.

Se o pull ainda falhar após a configuração correta, um campo imagePullSecrets especificado manualmente no YAML do workload pode estar em conflito com o componente sem senha. Remova o campo imagePullSecrets, exclua o pod e crie-o novamente.

Por que os containers falham ao iniciar em novos nós após ativar a aceleração de imagem no node pool?

Após ativar a Container Image Acceleration para um node pool, você pode encontrar o seguinte erro:

failed to create containerd container: failed to attach and mount for snapshot 46: failed to enable target for /sys/kernel/config/target/core/user_99999/dev_46, failed:failed to open remote file as tar file xxxx

Esse erro ocorre porque a Container Image Acceleration exige que o componente aliyun-acr-acceleration-suite esteja instalado e que as credenciais de pull estejam configuradas para imagens privadas. Consulte Configure container image pull credentials.