As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Executando aplicativos de alta disponibilidade

Seus clientes esperam que seu aplicativo esteja sempre disponível, inclusive quando você está fazendo alterações e, especialmente, durante picos de tráfego. Uma arquitetura escalável e resiliente mantém seus aplicativos e serviços funcionando sem interrupções, o que mantém seus usuários satisfeitos. Uma infraestrutura escalável cresce e diminui com base nas necessidades da empresa. Eliminar pontos únicos de falha é uma etapa crítica para melhorar a disponibilidade de um aplicativo e torná-lo resiliente.

Com o Kubernetes, você pode operar seus aplicativos e executá-los de forma altamente disponível e resiliente. Seu gerenciamento declarativo garante que, depois de configurar o aplicativo, o Kubernetes tente continuamente combinar o estado atual com o estado desejado.

Recomendações

Configurar orçamentos de interrupção de pods

https://kubernetes.io/docs/tasks/run-application/configure-pdb/Os orçamentos de interrupção do pod são usados para limitar a quantidade de interrupção simultânea que um aplicativo enfrentará. Eles devem ser configurados para cargas de trabalho se for importante ter sempre uma parte dessa carga de trabalho disponível. O EKS Auto Mode, o Karpenter e o Cluster Autoscaler estão cientes e cumprem os orçamentos de interrupção de pod configurados ao reduzir a escala. EKS Auto Mode, Karpenter e Managed Node Groups também aderem aos orçamentos de interrupção de pods ao atualizar os nós

Evite executar pods individuais

Se todo o seu aplicativo for executado em um único pod, seu aplicativo ficará indisponível se esse pod for encerrado. Em vez de implantar aplicativos usando pods individuais, crie implantações. Se um pod criado por uma implantação falhar ou for encerrado, o controlador de implantação iniciará um novo pod para garantir que o número especificado de pods de réplica esteja sempre em execução.

Execute várias réplicas

A execução de vários pods de réplicas de um aplicativo usando uma implantação ajuda a executá-lo de maneira altamente disponível. Se uma réplica falhar, as réplicas restantes continuarão funcionando, embora com capacidade reduzida, até que o Kubernetes crie outro pod para compensar a perda. Além disso, você pode usar o autoescalador horizontal de pod para escalar réplicas automaticamente com base na demanda da carga de trabalho.

Programe réplicas em todos os nós

A execução de várias réplicas não será muito útil se todas as réplicas estiverem sendo executadas no mesmo nó e o nó ficar indisponível. Considere usar restrições de antiafinidade de pod ou de distribuição de topologia de pod para distribuir réplicas de uma implantação em vários nós de trabalho.

Você pode melhorar ainda mais a confiabilidade de um aplicativo típico executando-o em várias AZs.

Usando as regras de antiafinidade do Pod

O manifesto abaixo informa ao programador do Kubernetes que prefira colocar os pods em nós e AZs separados. Ele não exige nós ou AZ distintos porque, se exigisse, o Kubernetes não conseguiria programar nenhum pods quando houver um pod em execução em cada AZ. Se seu aplicativo exigir apenas três réplicas, você pode usar requiredDuringSchedulingIgnoredDuringExecution fortopologyKey: topology.kubernetes.io/zone, e o agendador Kubernetes não agendará dois pods no mesmo AZ.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spread-host-az
  labels:
    app: web-server
spec:
  replicas: 4
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-server
              topologyKey: topology.kubernetes.io/zone
            weight: 100
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-server
              topologyKey: kubernetes.io/hostname
            weight: 99
      containers:
      - name: web-app
        image: nginx:1.16-alpine

Usando restrições de propagação da topologia Pod

Semelhante às regras de antiafinidade de pods, as restrições de dispersão da topologia de pod permitem que você disponibilize seu aplicativo em diferentes domínios de falha (ou topologia), como hosts ou AZs. Essa abordagem funciona muito bem quando você está tentando garantir a tolerância a falhas e a disponibilidade por meio de várias réplicas em cada um dos diferentes domínios de topologia. As regras de antiafinidade de pods, por outro lado, podem facilmente produzir um resultado em que você tem uma única réplica em um domínio de topologia, pois os pods com antiafinidade entre si têm um efeito repelente. Nesses casos, uma única réplica em um nó dedicado não é ideal para tolerância a falhas nem é um bom uso dos recursos. Com as restrições de dispersão da topologia, você tem mais controle sobre a distribuição ou distribuição que o agendador deve tentar aplicar nos domínios da topologia. Aqui estão algumas propriedades importantes a serem usadas nessa abordagem:

Além desses campos acima, há outros campos sobre os quais você pode ler mais detalhadamente na documentação do Kubernetes.

A topologia do pod espalha restrições em 3 AZs

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spread-host-az
  labels:
    app: web-server
spec:
  replicas: 10
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "topology.kubernetes.io/zone"
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app: express-test
      containers:
      - name: web-app
        image: nginx:1.16-alpine

Execute o Kubernetes Metrics Server

Instale o servidor de métricas do Kubernetes para ajudar a escalar seus aplicativos. Os complementos do autoescalador do Kubernetes, como HPA e VPA, precisam rastrear as métricas dos aplicativos para escalá-los. O servidor de métricas coleta métricas de recursos que podem ser usadas para tomar decisões de escalabilidade. As métricas são coletadas dos kubelets e veiculadas no formato da Metrics API.

O servidor de métricas não retém nenhum dado e não é uma solução de monitoramento. Seu objetivo é expor métricas de uso de CPU e memória para outros sistemas. Se você quiser acompanhar o estado do seu aplicativo ao longo do tempo, precisará de uma ferramenta de monitoramento como o Prometheus ou a Amazon. CloudWatch

Siga a documentação do EKS para instalar o metrics-server em seu cluster EKS.

Autoescalador horizontal de cápsulas (HPA)

A HPA pode escalar automaticamente seu aplicativo em resposta à demanda e ajudar você a evitar impactar seus clientes durante picos de tráfego. Ele é implementado como um circuito de controle no Kubernetes que consulta periodicamente métricas de APIs que fornecem métricas de recursos.

O HPA pode recuperar métricas das seguintes APIs: 1. metrics.k8s.iotambém conhecida como API Resource Metrics — Fornece uso de CPU e memória para pods 2. custom.metrics.k8s.io — Fornece métricas de outros coletores de métricas, como o Prometheus; essas métricas são internas ao seu cluster Kubernetes. 3. external.metrics.k8s.io — Fornece métricas externas ao seu cluster Kubernetes (E.g., Profundidade da fila SQS, latência do ELB).

Você deve usar uma dessas três APIs para fornecer a métrica para escalar seu aplicativo.

Dimensionamento de aplicativos com base em métricas personalizadas ou externas

Você pode usar métricas personalizadas ou externas para escalar seu aplicativo com base em métricas que não sejam a utilização da CPU ou da memória. Os servidores da API Custom Metrics fornecem a custom-metrics.k8s.io API que a HPA pode usar para escalar aplicativos automaticamente.

Você pode usar as APIs do Prometheus Adapter for Kubernetes Metrics para coletar métricas do Prometheus e usá-las com o HPA. Nesse caso, o adaptador Prometheus exporá as métricas do Prometheus no formato Metrics API. https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/types.go

Depois de implantar o adaptador Prometheus, você pode consultar métricas personalizadas usando kubectl. kubectl get —raw /apis/custom.metrics.k8s.io/v1beta1/

As métricas externas, como o nome sugere, fornecem ao Horizontal Pod Autoscaler a capacidade de escalar implantações usando métricas externas ao cluster Kubernetes. Por exemplo, em cargas de trabalho de processamento em lote, é comum escalar o número de réplicas com base no número de trabalhos em andamento em uma fila SQS.

Para escalar automaticamente as cargas de trabalho do Kubernetes, você pode usar o KEDA (Kubernetes Event-driven Autoscaling), um projeto de código aberto que pode impulsionar o dimensionamento de contêineres com base em vários eventos personalizados. Este blog da AWS descreve como usar o Amazon Managed Service for Prometheus para escalar automaticamente a carga de trabalho do Kubernetes.

Autoescalador vertical de pods (VPA)

O VPA ajusta automaticamente a reserva de CPU e memória para seus pods para ajudá-lo a “dimensionar corretamente” seus aplicativos. Para aplicativos que precisam ser dimensionados verticalmente, o que é feito aumentando a alocação de recursos, você pode usar o VPA para escalar automaticamente as réplicas de pods ou fornecer recomendações de escalabilidade.

Seu aplicativo pode ficar temporariamente indisponível se o VPA precisar escalá-lo porque a implementação atual do VPA não realiza ajustes locais nos pods; em vez disso, ele recriará o pod que precisa ser escalado.

A documentação do EKS inclui um passo a passo para configurar o VPA.

O projeto Fairwinds Goldilocks fornece um painel para visualizar as recomendações de VPA para solicitações e limites de CPU e memória. Seu modo de atualização de VPA permite escalar automaticamente os pods com base nas recomendações do VPA.

Atualizar aplicativos

As aplicações modernas exigem inovação rápida com alto grau de estabilidade e disponibilidade. O Kubernetes oferece as ferramentas para atualizar seus aplicativos continuamente sem interromper seus clientes.

Vejamos algumas das melhores práticas que possibilitam a implantação rápida de mudanças sem sacrificar a disponibilidade.

Tenha um mecanismo para realizar reversões

Ter um botão de desfazer pode evitar desastres. É uma prática recomendada testar implantações em um ambiente inferior separado (ambiente de teste ou desenvolvimento) antes de atualizar o cluster de produção. Usar um CI/CD pipeline pode ajudar você a automatizar e testar implantações. Com um pipeline de implantação contínua, você pode reverter rapidamente para a versão mais antiga se a atualização estiver com defeito.

Você pode usar implantações para atualizar um aplicativo em execução. Isso geralmente é feito atualizando a imagem do contêiner. Você pode usar kubectl para atualizar uma implantação como esta:

kubectl --record deployment.apps/nginx-deployment set image nginx-deployment nginx=nginx:1.16.1

O --record argumento registra as alterações na implantação e ajuda você se precisar realizar uma reversão. kubectl rollout history deploymentmostra as alterações registradas nas implantações em seu cluster. Você pode reverter uma alteração usando. kubectl rollout undo deployment <DEPLOYMENT_NAME>

Por padrão, quando você atualiza uma implantação que exige a recriação de pods, a implantação realiza uma atualização contínua. Em outras palavras, o Kubernetes atualizará apenas uma parte dos pods em execução em uma implantação e não todos os pods de uma só vez. Você pode controlar como o Kubernetes realiza atualizações contínuas por meio da propriedade. RollingUpdateStrategy

Ao realizar uma atualização contínua de uma implantação, você pode usar a Max Unavailable propriedade para especificar o número máximo de pods que podem ficar indisponíveis durante a atualização. A Max Surge propriedade de Deployment permite que você defina o número máximo de pods que podem ser criados sobre o número desejado de pods.

Considere max unavailable fazer ajustes para garantir que um lançamento não atrapalhe seus clientes. Por exemplo, o Kubernetes define 25% max unavailable por padrão, o que significa que se você tiver 100 pods, poderá ter apenas 75 pods trabalhando ativamente durante um lançamento. Se seu aplicativo precisar de um mínimo de 80 pods, esse lançamento pode causar interrupções. Em vez disso, você pode max unavailable definir como 20% para garantir que haja pelo menos 80 pods funcionais durante o lançamento.

Use blue/green implantações

Mudanças são inerentemente arriscadas, mas mudanças que não podem ser desfeitas podem ser potencialmente catastróficas. Os procedimentos de alteração que permitem que você efetivamente reverta o tempo por meio de uma reversão tornam os aprimoramentos e a experimentação mais seguros. Blue/green as implantações oferecem um método para retirar rapidamente as alterações se algo der errado. Nessa estratégia de implantação, você cria um ambiente para a nova versão. Esse ambiente é idêntico à versão atual do aplicativo que está sendo atualizado. Depois que o novo ambiente é provisionado, o tráfego é roteado para o novo ambiente. Se a nova versão produzir os resultados desejados sem gerar erros, o ambiente antigo será encerrado. Caso contrário, o tráfego será restaurado para a versão antiga.

Você pode realizar blue/green implantações no Kubernetes criando uma nova implantação que seja idêntica à implantação da versão existente. Depois de verificar se os pods na nova implantação estão em execução sem erros, você pode começar a enviar tráfego para a nova implantação alterando a selector especificação no serviço que encaminha o tráfego para os pods do seu aplicativo.

Muitas ferramentas de integração contínua, como Flux, Jenkins e Spinnaker, permitem automatizar as implantações. blue/green O blog de contêineres da AWS inclui um passo a passo sobre o uso do AWS Load Balancer Controller: usando o AWS Load Balancer Controller para blue/green implantação, implantação e teste de canários A/B

Use implantações Canary

As implantações Canary são uma variante das blue/green implantações que podem remover significativamente os riscos das mudanças. Nessa estratégia de implantação, você cria uma nova implantação com menos pods junto com a implantação antiga e desvia uma pequena porcentagem do tráfego para a nova implantação. Se as métricas indicarem que a nova versão está funcionando tão bem ou melhor do que a versão existente, você aumenta progressivamente o tráfego para a nova implantação e, ao mesmo tempo, aumenta a escala até que todo o tráfego seja desviado para a nova implantação. Se houver um problema, você pode rotear todo o tráfego para a implantação antiga e parar de enviar tráfego para a nova implantação.

Embora o Kubernetes não ofereça uma maneira nativa de realizar implantações canárias, você pode usar ferramentas como o Flagger com o Istio. https://github.com/weaveworks/flagger https://docs.flagger.app/tutorials/istio-progressive-delivery

Exames de saúde e autocura

Nenhum software está livre de erros, mas o Kubernetes pode ajudar você a minimizar o impacto das falhas de software. Antigamente, se um aplicativo falhava, alguém precisava corrigir a situação reiniciando o aplicativo manualmente. O Kubernetes permite detectar falhas de software em seus pods e substituí-los automaticamente por novas réplicas. Com o Kubernetes, você pode monitorar a integridade de seus aplicativos e substituir automaticamente as instâncias não íntegras.

O Kubernetes oferece suporte a três tipos de verificações de integridade: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

O Kubelet, o agente do Kubernetes, é responsável por executar todas as verificações mencionadas acima. O Kubelet pode verificar a integridade de um Pods de três maneiras: o kubelet pode executar um comando shell dentro do contêiner de um pod, enviar uma solicitação HTTP GET para seu contêiner ou abrir um soquete TCP em uma porta especificada.

Se você escolher uma sonda exec baseada, que executa um script de shell dentro de um contêiner, certifique-se de que o comando shell saia antes que o timeoutSeconds valor expire. Caso contrário, seu nó terá <defunct> processos, levando à falha do nó.

Recomendações

Use o Liveness Probe para remover frutos não saudáveis

A sonda Liveness pode detectar condições de impasse em que o processo continua em execução, mas o aplicativo deixa de responder. Por exemplo, se você estiver executando um serviço web que escuta na porta 80, você pode configurar uma sonda Liveness para enviar uma solicitação HTTP GET na porta 80 do pod. O Kubelet enviará periodicamente uma solicitação GET ao Pod e espera uma resposta; se o Pod responder entre 200-399, o kubelet considerará que o Pod está íntegro; caso contrário, o Pod será marcado como não íntegro. Se um pod falhar continuamente nas verificações de integridade, o kubelet o encerrará.

Você pode usar initialDelaySeconds para atrasar a primeira sonda.

Ao usar o Liveness Probe, certifique-se de que seu aplicativo não se depare com uma situação em que todos os pods falhem simultaneamente no Liveness Probe, pois o Kubernetes tentará substituir todos os seus pods, o que deixará seu aplicativo offline. Além disso, o Kubernetes continuará criando novos pods que também falharão no Liveness Probes, sobrecarregando desnecessariamente o plano de controle. Evite configurar o Liveness Probe para depender de um fator externo ao seu pod, por exemplo, um banco de dados externo. Em outras palavras, um banco de dados externo não responsivo ao seu pod não deve fazer com que seus pods falhem em suas sondas de vida.

O post LIVENESS PROBES ARE DANGEROUS, de Sandor Szücs, descreve problemas que podem ser causados por sondas mal configuradas.

Use o Startup Probe para aplicativos que demoram mais para iniciar

Quando seu aplicativo precisar de mais tempo para inicializar, você pode usar o Startup Probe para atrasar o Liveness and Readiness Probe. Por exemplo, um aplicativo Java que precisa hidratar o cache de um banco de dados pode precisar de até dois minutos antes de estar totalmente funcional. Qualquer sonda de vivacidade ou prontidão até que fique totalmente funcional pode falhar. A configuração de uma sonda de inicialização permitirá que o aplicativo Java se torne saudável antes que o Liveness ou o Readiness Probe sejam executados.

Até que a sonda de inicialização seja bem-sucedida, todas as outras sondas serão desativadas. Você pode definir o tempo máximo que o Kubernetes deve esperar pela inicialização do aplicativo. Se, após o tempo máximo configurado, o pod ainda falhar nas sondas de inicialização, ele será encerrado e um novo pod será criado.

O Startup Probe é semelhante ao Liveness Probe — se eles falharem, o Pod é recriado. Como Ricardo A. explica em seu post Fantastic Probes And How To Configure Them, os Startup Probes devem ser usados quando o tempo de inicialização de um aplicativo é imprevisível. Se você sabe que seu aplicativo precisa de dez segundos para iniciar, use o Liveness/Readiness Probe with initialDelaySeconds em vez disso.

Use o Readiness Probe para detectar indisponibilidade parcial

Enquanto a sonda Liveness detecta falhas em um aplicativo que são resolvidas ao encerrar o pod (portanto, reiniciar o aplicativo), o Readiness Probe detecta condições em que o aplicativo pode estar temporariamente indisponível. Nessas situações, o aplicativo pode deixar de responder temporariamente; no entanto, espera-se que ele volte a funcionar quando a operação for concluída.

Por exemplo, durante I/O operações intensas de disco, os aplicativos podem ficar temporariamente indisponíveis para lidar com solicitações. Aqui, encerrar o pod do aplicativo não é uma solução; ao mesmo tempo, solicitações adicionais enviadas ao pod podem falhar.

Você pode usar o Readiness Probe para detectar indisponibilidade temporária em seu aplicativo e parar de enviar solicitações ao pod até que ele volte a funcionar. Ao contrário do Liveness Probe, em que uma falha resultaria na recriação do Pod, uma falha no Readiness Probe significaria que o Pod não receberá nenhum tráfego do Kubernetes Service. Quando o Readiness Probe for bem-sucedido, o Pod voltará a receber tráfego do Service.

Assim como o Liveness Probe, evite configurar sondas de prontidão que dependam de um recurso externo ao pod (como um banco de dados). Aqui está um cenário em que uma prontidão mal configurada pode tornar o aplicativo infuncional: se a sonda de prontidão de um pod falhar quando o banco de dados do aplicativo estiver inacessível, outras réplicas de pod também falharão simultaneamente, pois compartilham os mesmos critérios de verificação de integridade. Configurar a sonda dessa forma garantirá que, sempre que o banco de dados estiver indisponível, as sondas de prontidão do pod falhem e o Kubernetes pare de enviar tráfego para todos os pods.

Um efeito colateral do uso de sondas de prontidão é que elas podem aumentar o tempo necessário para atualizar as implantações. As novas réplicas não receberão tráfego a menos que as sondas de prontidão sejam bem-sucedidas; até lá, as réplicas antigas continuarão recebendo tráfego.

Lidando com interrupções

Os pods têm uma vida útil finita. Mesmo que você tenha pods de longa duração, é prudente garantir que os pods terminem corretamente quando chegar a hora. Dependendo da sua estratégia de atualização, as atualizações de cluster do Kubernetes podem exigir que você crie novos nós de trabalho, o que exige que todos os pods sejam recriados em nós mais novos. O tratamento adequado da rescisão e os orçamentos de interrupção do pod podem ajudar você a evitar interrupções no serviço, pois os pods são removidos dos nós mais antigos e recriados nos nós mais novos.

A maneira preferida de atualizar os nós de trabalho é criar novos nós de trabalho e encerrar os antigos. Antes de encerrar os nós de trabalho, você deve fazer drain isso. Quando um nó de trabalho é drenado, todos os seus pods são despejados com segurança. Segurança é uma palavra-chave aqui; quando os pods de um trabalhador são despejados, eles não recebem simplesmente um sinal. SIGKILL Em vez disso, um SIGTERM sinal é enviado para o processo principal (PID 1) de cada contêiner nos pods que está sendo despejado. Depois que o SIGTERM sinal for enviado, o Kubernetes dará ao processo algum tempo (período de carência) antes que o SIGKILL sinal seja enviado. Esse período de carência é de 30 segundos por padrão; você pode substituir o padrão usando grace-period flag no kubectl ou declare terminationGracePeriodSeconds no seu Podspec.

kubectl delete pod <pod name> —grace-period=<seconds>

É comum ter contêineres nos quais o processo principal não tenha PID 1. Considere este recipiente Python-based de amostra:

$ kubectl exec python-app -it ps
 PID USER TIME COMMAND
 1   root 0:00 {script.sh} /bin/sh ./script.sh
 5   root 0:00 python app.py

Neste exemplo, o shell script recebeSIGTERM, o processo principal, que por acaso é um aplicativo Python neste exemplo, não recebe um SIGTERM sinal. Quando o Pod for encerrado, o aplicativo Python será encerrado abruptamente. Isso pode ser corrigido alterando o ENTRYPOINT contêiner para iniciar o aplicativo Python. Como alternativa, você pode usar uma ferramenta como o dumb-init para garantir que seu aplicativo possa lidar com sinais.

Você também pode usar ganchos de contêiner para executar um script ou uma solicitação HTTP no início ou na parada do contêiner. A ação do PreStop gancho é executada antes que o contêiner receba um SIGTERM sinal e deve ser concluída antes que esse sinal seja enviado. O terminationGracePeriodSeconds valor se aplica a partir do momento em que a ação do PreStop gancho começa a ser executada, não quando o SIGTERM sinal é enviado.

Recomendações

Proteja cargas de trabalho críticas com orçamentos de interrupção de pods

O Pod Disruption Budget ou PDB pode interromper temporariamente o processo de despejo se o número de réplicas de um aplicativo cair abaixo do limite declarado. O processo de remoção continuará quando o número de réplicas disponíveis ultrapassar o limite. Você pode usar o PDB para declarar o maxUnavailable número minAvailable e o número de réplicas. Por exemplo, se você quiser que pelo menos três cópias do seu aplicativo estejam disponíveis, você pode criar um PDB.

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: my-svc-pdb
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: my-svc

A política de PDB acima diz ao Kubernetes que interrompa o processo de despejo até que três ou mais réplicas estejam disponíveis. PodDisruptionBudgetsRespeita a drenagem de nós. Durante uma atualização do grupo de nós gerenciados pelo EKS, os nós são drenados com um tempo limite de quinze minutos. Após quinze minutos, se a atualização não for forçada (a opção é chamada Atualização contínua no console EKS), a atualização falhará. Se a atualização for forçada, os pods serão excluídos.

Para nós autogerenciados, você também pode usar ferramentas como o AWS Node Termination Handler, que garante que o plano de controle do Kubernetes responda adequadamente a eventos que podem fazer com que sua instância do EC2 fique indisponível, como eventos de manutenção do EC2 e interrupções spot do EC2. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html Ele usa a API Kubernetes para isolar o nó e garantir que nenhum novo pods seja agendado, depois o drena, encerrando todos os pods em execução.

Você pode usar a antiafinidade de pod para programar os pods de uma implantação em nós diferentes e evitar atrasos relacionados ao PDB durante as atualizações dos nós.

Pratique engenharia do caos

A Engenharia do Caos é a disciplina de experimentar em um sistema distribuído para criar confiança na capacidade do sistema de resistir a condições turbulentas na produção.

Em seu blog, Dominik Tornow explica que o Kubernetes é um sistema declarativo em que "o usuário fornece uma representação do estado desejado do sistema para o sistema. O sistema então considera o estado atual e o estado desejado para determinar a sequência de comandos para fazer a transição do estado atual para o estado desejado. ” Isso significa que o Kubernetes sempre armazena o estado desejado e, se o sistema se desviar, o Kubernetes tomará medidas para restaurar o estado. Por exemplo, se um node de trabalho ficar indisponível, o Kubernetes reagendará os pods em outro node de trabalho. Da mesma forma, em caso de replica falha, o Deployment Controller criará um novo. replica Dessa forma, os controladores do Kubernetes corrigem automaticamente as falhas.

Ferramentas de engenharia do caos, como o Gremlin, ajudam você a testar a resiliência do seu cluster Kubernetes e identificar pontos únicos de falha. Ferramentas que introduzem caos artificial em seu cluster (e além) podem revelar pontos fracos sistêmicos, apresentar uma oportunidade de identificar gargalos e configurações incorretas e corrigir problemas em um ambiente controlado. A filosofia da Chaos Engineering defende quebrar as coisas de propósito e testar a infraestrutura de estresse para minimizar o tempo de inatividade imprevisto.

Use um Service Mesh

Você pode usar uma malha de serviços para melhorar a resiliência do seu aplicativo. As malhas de serviços permitem a comunicação de serviço a serviço e aumentam a observabilidade de sua rede de microsserviços. A maioria dos produtos de service mesh funciona com um pequeno proxy de rede executado junto com cada serviço que intercepta e inspeciona o tráfego de rede do aplicativo. Você pode colocar seu aplicativo em uma malha sem modificá-lo. Usando os recursos integrados do proxy de serviço, você pode fazer com que ele gere estatísticas de rede, crie registros de acesso e adicione cabeçalhos HTTP às solicitações de saída para rastreamento distribuído.

Uma malha de serviços pode ajudar você a tornar seus microsserviços mais resilientes com recursos como novas tentativas automáticas de solicitações, tempos limite, interrupção de circuitos e limitação de taxa.

Se você opera vários clusters, pode usar uma malha de serviços para habilitar a comunicação entre clusters de serviço a serviço.

Malhas de serviço

Observabilidade

Observabilidade é um termo genérico que inclui monitoramento, registro e rastreamento. Os aplicativos baseados em microsserviços são distribuídos por natureza. Diferentemente dos aplicativos monolíticos em que o monitoramento de um único sistema é suficiente, em uma arquitetura de aplicativo distribuída, você precisa monitorar o desempenho de cada componente. Você pode usar sistemas de monitoramento, registro e rastreamento distribuído em nível de cluster para identificar problemas em seu cluster antes que eles atrapalhem seus clientes.

As ferramentas integradas do Kubernetes para solução de problemas e monitoramento são limitadas. O servidor de métricas coleta métricas de recursos e as armazena na memória, mas não as persiste. Você pode visualizar os registros de um pod usando kubectl, mas o Kubernetes não retém registros automaticamente. E a implementação do rastreamento distribuído é feita no nível do código do aplicativo ou usando malhas de serviços.

A extensibilidade do Kubernetes brilha aqui. O Kubernetes permite que você traga sua solução centralizada preferida de monitoramento, registro e rastreamento.

Recomendações

Monitore seus aplicativos

O número de métricas que você precisa monitorar em aplicativos modernos está crescendo continuamente. Ajuda se você tiver uma forma automatizada de rastrear seus aplicativos para que possa se concentrar na solução dos desafios de seus clientes. Cluster-wide ferramentas de monitoramento como o Prometheus ou o CloudWatch Container Insights podem monitorar seu cluster e sua carga de trabalho e fornecer sinais quando, ou preferencialmente, antes que as coisas dêem errado.

As ferramentas de monitoramento permitem que você crie alertas que sua equipe de operações possa assinar. Considere regras para ativar alarmes para eventos que, quando exacerbados, podem causar uma interrupção ou afetar o desempenho do aplicativo.

Se você não tiver certeza sobre quais métricas deve monitorar, pode se inspirar nesses métodos:

O post da Sysdig As melhores práticas para alertar no Kubernetes inclui uma lista abrangente de componentes que podem afetar a disponibilidade de seus aplicativos.

Use a biblioteca de cliente do Prometheus para expor as métricas do aplicativo

Além de monitorar o estado do aplicativo e agregar métricas padrão, você também pode usar a biblioteca de cliente do Prometheus para expor métricas personalizadas específicas do aplicativo para melhorar a observabilidade do aplicativo.

Use ferramentas de registro centralizadas para coletar e manter registros

O registro no EKS se enquadra em duas categorias: registros do plano de controle e registros do aplicativo. O registro do plano de controle EKS fornece registros de auditoria e diagnóstico diretamente do plano de controle para CloudWatch os registros em sua conta. Os registros de aplicativos são registros produzidos por pods em execução dentro do seu cluster. Os registros de aplicativos incluem registros produzidos por pods que executam os aplicativos de lógica de negócios e os componentes do sistema Kubernetes, como CoreDNS, Cluster Autoscaler, Prometheus etc.

O EKS fornece cinco tipos de registros do plano de controle:

Os registros do gerenciador do controlador e do agendador podem ajudar a diagnosticar problemas no plano de controle, como gargalos e erros. Por padrão, os registros do plano de controle do EKS não são enviados para CloudWatch os registros. Você pode ativar o registro do plano de controle e selecionar os tipos de registros do plano de controle EKS que gostaria de capturar para cada cluster em sua conta.

A coleta de registros de aplicativos exige a instalação de uma ferramenta agregadora de registros, como Fluent Bit, Fluentd ou CloudWatch Container Insights , em seu cluster.

As ferramentas agregadoras de registros do Kubernetes são executadas como DaemonSets e extraem registros de contêineres dos nós. Os registros do aplicativo são então enviados para um destino centralizado para armazenamento. Por exemplo, o CloudWatch Container Insights pode usar o Fluent Bit ou o Fluentd para coletar registros e enviá-los para o CloudWatch Logs para armazenamento. O Fluent Bit e o Fluentd suportam muitos sistemas populares de análise de log, como Elasticsearch e InfluxDB, permitindo que você altere o back-end de armazenamento de seus logs modificando o Fluentbit ou a configuração de log do Fluentd.

Use um sistema de rastreamento distribuído para identificar gargalos

Um aplicativo moderno típico tem componentes distribuídos pela rede e sua confiabilidade depende do funcionamento adequado de cada um dos componentes que compõem o aplicativo. Você pode usar uma solução de rastreamento distribuído para entender como as solicitações fluem e como os sistemas se comunicam. Os rastreamentos podem mostrar onde existem gargalos na sua rede de aplicativos e evitar problemas que podem causar falhas em cascata.

Você tem duas opções para implementar o rastreamento em seus aplicativos: você pode implementar o rastreamento distribuído no nível do código usando bibliotecas compartilhadas ou usar uma malha de serviços.

Implementar o rastreamento no nível do código pode ser desvantajoso. Nesse método, você precisa fazer alterações no seu código. Isso é ainda mais complicado se você tiver aplicativos poliglotas. Você também é responsável por manter mais uma biblioteca em todos os seus serviços.

Service Meshes como LinkerD e Istio podem ser usados para implementar o rastreamento distribuído em seu aplicativo com alterações mínimas no código do aplicativo. Você pode usar o service mesh para padronizar a geração, o registro e o rastreamento de métricas.

Ferramentas de rastreamento como AWS X-Ray e Jaeger oferecem suporte a implementações de bibliotecas compartilhadas e de service mesh.

Considere usar uma ferramenta de rastreamento, como a AWS X-Ray ou a Jaeger, que ofereça suporte a ambas as implementações (biblioteca compartilhada e service mesh), para que você não precise trocar de ferramenta se adotar a malha de serviços posteriormente.