Container Service for Kubernetes:Configurações recomendadas de workloads

Declare requests e limits para cada pod

Agendar pods em excesso em um nó pode causar contenção de recursos e interromper o service. Declarar requests e limits para cada pod permite que o scheduler identifique nós adequados com base nos requisitos específicos de recursos durante a implantação.

Exemplo de configuração de pod Nginx:

• Request de CPU de 1 núcleo e request de memória de 1024 Mi

• Limit de CPU de 2 núcleos e limit de memória de 4096 Mi

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
    resources: # Resource declaration
      requests:
        memory: "1024Mi"
        cpu: "1000m"
      limits:
        memory: "4096Mi"
        cpu: "2000m"

Agendamento estático de recursos

O Kubernetes utiliza um mecanismo de agendamento estático de recursos. O cálculo dos recursos disponíveis no nó segue a fórmula:

Available node resources = Total node resources - Allocated resources

O Kubernetes não rastreia o consumo real de recursos de programas intensivos executados manualmente (fora das declarações de pod). Portanto, o scheduler toma decisões com base nos recursos alocados, e não no uso em tempo real. Se um pod não tiver resources declarados, o Kubernetes não reserva nada para ele após o agendamento. Isso resulta em mais pods compartilhando um nó do que sua capacidade suporta.

Aplicação dos limits:

• Limits de CPU: o sistema aplica throttling de CPU. Quando um contêiner se aproxima de seu limit de CPU, o kernel restringe seu acesso à CPU. O contêiner continua em execução, mas processa as tarefas mais lentamente.

• Limits de memória: o kernel encerra o processo por falta de memória (OOM). Quando um contêiner excede seu limit de memória, o kernel o finaliza.

Essa diferença é importante na definição dos limits: defina limits de CPU de forma conservadora, pois o throttling degrada o desempenho gradualmente. Por outro lado, calibre os limits de memória com cuidado, pois excedê-los causa o encerramento do contêiner.

Melhor prática: use o perfilamento de recursos

Use o recurso Resource Profiling para obter recomendações de recursos no nível do contêiner com base em dados históricos de uso. Essa funcionalidade simplifica a configuração de requests e limits.

Aguarde as dependências na inicialização

Aplicações frequentemente possuem dependências externas, como bancos de dados ou APIs downstream, que podem não estar prontas no momento da inicialização.

Em ambientes manuais tradicionais, uma abordagem de falha rápida faz sentido: a aplicação encerra imediatamente se uma dependência estiver indisponível e alerta os operadores sobre o problema. No entanto, no Kubernetes, isso pode gerar ciclos desnecessários de reinicialização. Considere duas aplicações, A e B, em que A depende de B e ambas são agendadas no mesmo nó. Uma reinicialização do nó pode fazer com que A inicie antes de B estar pronta. Nesse cenário, A encerra antes que B fique disponível e, sem intervenção, pode não se recuperar mesmo depois que B iniciar.

Em vez de encerrar, as aplicações executadas no Kubernetes devem aguardar suas dependências de forma elegante. Use um Init Container para verificar periodicamente os services necessários. O Init Container impede que o contêiner principal inicie até que todas as dependências estejam acessíveis.

Configure a política de reinicialização

Processos podem encerrar por diversos motivos, como bugs, eventos de OOM ou erros transitórios. Configure uma restartPolicy para que o kubelet recupere o pod automaticamente, sem necessidade de intervenção manual.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-test
spec:
  restartPolicy: OnFailure
  containers:
  - name: nginx
    image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6

restartPolicy aceita um dos seguintes valores:

Configure sondas de verificação de integridade

As sondas de verificação de integridade fornecem ao Kubernetes as informações necessárias para recuperar falhas automaticamente e rotear tráfego apenas para instâncias prontas. Três tipos de sonda funcionam em conjunto:

• startupProbe: verifica se a aplicação terminou de iniciar. Até que essa sonda tenha sucesso, o kubelet não executa readinessProbe ou livenessProbe. Utilize startupProbe quando o tempo de inicialização for imprevisível (por exemplo, aplicações Java que realizam carregamento de classes ou migrações de banco de dados). Se sua aplicação sempre iniciar dentro de uma janela fixa, defina initialDelaySeconds nas outras sondas.

• readinessProbe: controla o roteamento de tráfego. O IP de um pod é adicionado aos endpoints do service somente após o sucesso dessa sonda. Isso garante que as requisições cheguem apenas a contêineres prontos para atendê-las.

• livenessProbe: detecta deadlocks e travamentos em que o processo ainda está em execução, mas a aplicação não responde. Em caso de falha, o kubelet reinicia o contêiner.

  Importante

  Use livenessProbe apenas para verificar a integridade da própria aplicação. Nunca dependa de recursos externos, como um banco de dados, pois isso pode desencadear reinicializações em cascata durante indisponibilidades externas.

Escolha dos parâmetros das sondas:

Defina os limiares de startupProbe e livenessProbe com base no tempo máximo tolerável antes que o Kubernetes tome uma ação:

Maximum tolerated time = failureThreshold × periodSeconds

Para livenessProbe, utilize um failureThreshold maior do que o de readinessProbe. Isso garante que o pod seja marcado como não pronto por um período antes que o kubelet realize uma reinicialização forçada, proporcionando uma janela para observar o problema.

O exemplo a seguir configura todas as três sondas para um Deployment Nginx stateless:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-demo
spec:
  replicas: 1                 # For production environments, set this to 2 or more to ensure high availability
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 500m
            memory: 1Gi
          limits:
            cpu: 500m
        # --- Health check probes ---
        # Startup Probe: Ensures the application in the container has started.
        startupProbe:
          httpGet:
            path: / # Accessing the Nginx default root path indicates a successful startup.
            port: 80
          # Allow enough time for the application to start. Total timeout = failureThreshold x periodSeconds, which is 30 x 10 = 300 seconds.
          failureThreshold: 30
          periodSeconds: 10
        # Readiness Probe: Determines if the container is ready to accept traffic.
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5  # Starts probing 5 seconds after the container starts.
          periodSeconds: 5        # Probes every 5 seconds.
          timeoutSeconds: 2       # Probe timeout.
          successThreshold: 1     # 1 success marks it as ready.
          failureThreshold: 3     # 3 consecutive failures mark it as not ready.
        # Liveness Probe: Determines if the container is alive for automatic fault recovery.
        # This configuration should be looser than the readinessProbe to avoid unnecessary restarts due to temporary jitter.
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 15 # Starts the first probe 15 seconds after the container starts, allowing the application to initialize and stabilize.
          periodSeconds: 10       # The probe frequency is lower than the readinessProbe to reduce system resource consumption.
          timeoutSeconds: 3       # The timeout can be slightly longer than the readinessProbe.
          successThreshold: 1     # 1 success marks it as alive.
          failureThreshold: 3     # After 3 consecutive failures (3 x 10 = 30 seconds), the kubelet restarts the container.

Consulte Implement zero-downtime rolling deployments para ambientes de produção.

Execute um processo por contêiner

Alguns desenvolvedores tratam contêineres como máquinas virtuais e executam múltiplos processos — agentes de monitoramento, daemons de log, sshd — dentro de um único contêiner. Essa prática gera dois problemas:

• A contabilização de recursos torna-se imprecisa. Com vários processos compartilhando um contêiner, fica mais difícil definir requests e limits precisos. Isso leva a provisionamento excessivo ou contenção de recursos.

• Falhas passam despercebidas. Quando um contêiner executa um único processo, o mecanismo de contêiner detecta imediatamente se esse processo encerra e pode reiniciar o contêiner. Quando múltiplos processos são executados juntos, o mecanismo de contêiner não consegue detectar se um deles falhar silenciosamente.

Quando múltiplos processos realmente precisam trabalhar em conjunto — por exemplo, Nginx e PHP-FPM comunicando-se através de um Unix Domain Socket — coloque cada processo em seu próprio contêiner e execute-os como um pod multicontêiner. Armazene o Unix Domain Socket em um volume compartilhado entre os contêineres.

Evite pontos únicos de falha

Uma única instância de pod representa um ponto único de falha. Mesmo com reinicializações automáticas, ocorre uma breve interrupção durante o processo de recuperação. Indisponibilidade semelhante também pode ocorrer durante atualizações contínuas ou lançamentos de novas versões.

Para garantir alta disponibilidade, evite gerenciar Pods diretamente. Gerencie seus workloads por meio de Deployments ou StatefulSets e garanta que pelo menos duas réplicas estejam em execução o tempo todo. Essa redundância permite que o Kubernetes mantenha a continuidade do service mesmo se uma instância individual falhar.

Próximos passos

• O ACK oferece suporte a liberações graduais, implantações blue-green e outras estratégias de lançamento. Para mais detalhes, consulte Deployment and release.

• Para orientações mais amplas sobre gerenciamento de aplicações, consulte Workload best practices.

• Se um pod apresentar comportamento inesperado, consulte Solucionar exceções de pod. Para perguntas frequentes, consulte FAQ sobre Workloads.