Container Service for Kubernetes:Workload FAQ

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

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

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

2. Crie uma imagem de contêiner 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 contêiner é mais completa que pacotes tradicionais (JAR, WAR ou RPM), pois agrupa a aplicação com todos os arquivos necessários ao runtime do contêiner. Use essa imagem para iniciar o contêiner, que representa a aplicação em execução. Para obter instruções passo a passo, consulte Criar, empacotar e executar imagens usando um Dockerfile.

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

   • Personal Edition — para desenvolvedores individuais

   • Enterprise Edition — para clientes empresariais

4. Implante workloads no ACK para executar a aplicação conteinerizada. O ACK gerencia todo o ciclo de vida dos workloads conteinerizados, 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 pela rede pública

• Verifique se o cluster tem acesso à rede pública. Consulte Ativar acesso à rede pública para um cluster.

• Confirme se o registro de imagens também permite acesso público. Para um exemplo com ACR, consulte Configurar controle de acesso à rede pública para o ACR.

• Verifique se a largura de banda do ip público não está configurada com valor muito baixo.

Pull a partir do ACR

• Verifique se o secret de pull de imagem está correto. Consulte Como usar imagePullSecrets?.

• Se utilizar o componente de pull sem senha, verifique se ele está configurado corretamente. Consulte Realizar pull de imagens na mesma conta e Realizar pull de imagens entre contas.

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 Atualizar do Helm v2 para o Helm v3.

Como puxar 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, utilize uma instância de sincronização para replicar imagens da região da China continental para a região fora da China continental. Consulte Instância de sincronização na mesma conta. Após a sincronização, obtenha o endereço do registro 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 Informações de faturamento .

Como realizar atualizações contínuas sem interrupção de serviço?

Durante a substituição de pods em uma atualização contínua, 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 causar erros 5XX temporários. Configure o desligamento gracioso para obter atualizações contínuas sem tempo de inatividade. Consulte Como implementar atualizações contínuas sem tempo de inatividade no Kubernetes.

Como obter uma imagem de contêiner para um workload?

Para pré-requisitos e orientações sobre como puxar uma imagem de contêiner, consulte Realizar pull de imagem.

Como reiniciar um contêiner?

O Kubernetes não suporta o reinício direto de contêineres 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 contêineres 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 um namespace diferente 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 para contêineres 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 contêiner por meio de variáveis de ambiente. Consulte Expor informações do pod para contêineres por meio de variáveis de ambiente.

• Arquivos — montam informações do pod como arquivos dentro do contêiner usando o volume Downward API. Consulte Expor informações do pod para contêineres 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 seguintes métodos:

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

Verificação

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 as instruções em Realizar pull de imagens na mesma conta para verificar a configuração.

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

Por que os contêineres falham ao iniciar em novos nós após ativar a aceleração de imagens 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 Configurar credenciais de pull de imagens de contêiner.