Como atualizar os Workers Nodes do Amazon EKS com o Karpenter Drift

Por Rajdeep Saha, Ratnopam Chakrabarti, Chance Lee e Robert Northard

Introdução

O Karpenter é um autoescalador (autoscaler) de cluster Kubernetes, de código aberto, que provisiona nós do tamanho certo em resposta a pods com status unschedulable e com base nos valores de CPU, memória, volume, e outras informações de schedule do Kubernetes (por exemplo, afinidades e restrições de dispersão da topologia dos pods), o que simplifica o gerenciamento da infraestrutura. Ao usar o Cluster Autoscaler como um autoescalador, todos os nós do Kubernetes em um node group devem ter a mesma capacidade (vCPU e memória) para que o escalonamento automático funcione de forma eficaz. Isso faz com que os clientes tenham muitos Node Groups de diferentes tamanhos de instância, cada um apoiado por um Amazon EC2 Auto Scaling Group, para atender aos requisitos do workload. Como um workload evolui continuamente ao longo do tempo, mudanças nos requisitos de seus recursos significam que escolher o tamanho correto de instâncias Amazon Elastic Compute Cloud (Amazon EC2) pode ser desafiador. Além disso, como o Karpenter não orquestra o gerenciamento de capacidade com Node Groups e autoescaling group do Amazon EC2, ele introduz uma perspectiva diferente aos processos operacionais para manter os componentes e sistemas operacionais dos Worker Nodes atualizados com os patches e recursos de segurança mais recentes.

Neste post, descreveremos o mecanismo para realizar o patching dos worker nodes do Kubernetes, provisionados com o Karpenter, por meio de um recurso chamado Drift. Se você tiver muitos worker nodes em vários clusters do Amazon EKS, esse mecanismo poderá ajudá-lo a aplicar patches continuamente em grande escala.

Visão geral da solução

Mecanismos de patching de nós do Karpenter

Quando o Amazon Elastic Kubernetes Service (Amazon EKS) oferece suporte a uma nova versão do Kubernetes, você pode atualizar seu Control Plane do cluster EKS para a próxima versão com uma única chamada de API. A atualização do Data Plane do Kubernetes envolve a atualização da Amazon Machine Image (AMI) para os worker nodes do Kubernetes. A AWS lança AMIs para novas versões do Kubernetes, bem como patches e CVEs (Common Vulnerabilities and Exposures). Você pode escolher entre uma grande variedade de AMIs otimizadas para Amazon EKS. Como alternativa, você também pode usar suas próprias AMIs personalizadas. Atualmente, o recurso AWSNodeTemplate do Karpenter suporta como Família AMI (AMIFamily) os valores AL2, Bottlerocket, Ubuntu, Windows 2019, Windows 2022 e Custom. Quando uma AMIFamily com valor Custom é escolhida, é necessário especificar um AMISelector que informe ao Karpenter quais AMIs personalizadas devem ser usadas. Se nenhuma AMIFamily for definida, o Karpenter definirá a AMIFamily padrão como AL2 e usará a AMI Linux otimizada para Amazon EKS.

O Karpenter usa o Drift para atualizar a versão dos nós do Kubernetes e os atualiza após uma implantação do tipo Rolling. À medida que os nós são desprovisionados, eles são isolados (cordoned) para evitar o agendamento de novos pods e os pods são despejados (evicted) usando a API Kubernetes Eviction. O mecanismo Drift é o seguinte:

Drift
Para os nós do Kubernetes provisionados com o Karpenter e que divergiram da especificação desejada, o Karpenter provisiona os novos nós primeiro, despeja os pods dos nós antigos e depois encerra o nó. No momento da escrita desta postagem, o intervalo do Drift está definido para 5 minutos. No entanto, se o Provisioner ou o AWSNodeTemplate forem atualizados, a verificação do Drift será acionada imediatamente. O Drift for AMIs tem dois comportamentos: um quando uma AMI é fornecida por um usuário e outro sem.

Drift com valores de AMI especificados

Você pode considerar essa abordagem para controlar a promoção de AMIs por meio de ambientes de aplicativos para fins de consistência. Se você alterar a(s) AMI(s) no AWSNodeTemplate para um provisionador ou associar um Node Template diferente ao provisionador, o Karpenter detectará que os worker nodes existentes se desviaram da configuração desejada.

Para acionar a atualização, associe as novas AMIs ao NodeTemplate e o Karpenter atualizará os worker nodes por meio de uma implantação do tipo rolling. As AMIs podem ser especificadas explicitamente pelo ID da AMI, pelos nomes da AMI ou até mesmo por tags específicas. Se várias AMIs satisfizerem os critérios, a AMI mais recente será escolhida. Os clientes podem rastrear quais AMIs são descobertas pelo AWSNodeTemplate a partir dos valores de AMIs no campo de status do AWSNodeTemplate. Uma forma de obter o status seria executando kubectl describe no AWSNodeTemplate. Em certos cenários, se as AMIs antigas e novas forem descobertas pelo AWSNodeTemplate, os nós em execução com AMIs antigas não passarão por Drift, embora os novos nós sejam provisionados usando a nova AMI. Para saber mais sobre a seleção de AMIs no Node Template, consulte aqui.

apiVersion: karpenter.k8s.aws/v1alpha1
kind: AWSNodeTemplate
metadata:
   name: amiwithid
spec:
   amiSelector:
      aws::ids: "ami-123"

Exemplo 1 — Selecionar AMIs por IDs

apiVersion: karpenter.k8s.aws/v1alpha1
kind: AWSNodeTemplate
metadata:
   name: amiwithname
spec:
   amiSelector:
      aws::name: appA-ami
      aws::owners: ownerAccountID

Exemplo 2 — Selecione AMIs em que a tag Name tenha o valor Appa-AMI, na conta do aplicativo OwnerAccountID

Drift sem AMI especificada

Se não houver nenhum AMISelector especificado no AWSNodeTemplate, o Karpenter monitora os parâmetros SSM publicados para as AMIs otimizadas para Amazon EKS. Você pode especificar uma AMIFamily (por exemplo, AL2, Bottlerocket, Ubuntu etc.) para que o Karpenter considere uma família de AMI específica ou deixá-la em branco para usar como padrão a AMI AL2 (ou seja, Amazon Linux AMI otimizada para Amazon EKS). O Karpenter detecta quando uma nova AMI é lançada para a versão do cluster Kubernetes e desvia (drift) os nós existentes. O valor das AMIs do AWSNodeTemplate no campo de status reflete a AMI recém-descoberta. Esses nós são desprovisionados e substituídos por worker nodes com a AMI mais recente. Com essa abordagem, os nós com AMIs mais antigas são reciclados automaticamente (por exemplo, quando há uma nova AMI disponível ou após uma atualização do Control Plane do Kubernetes). Com a abordagem anterior de usar o AMISelector, você tem mais controle quando os nós são atualizados. Considere a diferença e selecione a abordagem adequada para sua aplicação. Atualmente, o Karpenter não suporta parâmetros SSM personalizados.

Passo a passo

Analisaremos os seguintes cenários:

Ativando o recurso Karpenter Drift.
Automação da atualização de nós com o Drift.
Atualização de nós com controle de promoção de AMIs.

Pré-requisitos

Você precisará dos seguintes items para concluir as etapas desta postagem:

Um cluster Amazon EKS existente. Se você não tiver um, siga qualquer método descrito aqui para criar um cluster.
Karpenter implementado no seu cluster Kubernetes. Siga o guia de introdução ao Karpenter listado aqui para instalá-lo.

Primeiro, exportaremos o nome do cluster Amazon EKS para continuar com o passo a passo no terminal de comando.

export CLUSTER_NAME=<nome do seu cluster EKS>

Etapa 1. Ativando o recurso Karpenter Drift

Atualmente, o Drift está sob o feature gates. Você pode habilitar isso no ConfigMap do karpenter-global-settings.

kubectl edit configmap -n karpenter karpenter-global-settings

Vamos encontrar FeatureGates.driftEnabled e alterar o valor de false para true.

Para aplicar a configuração alterada do ConfigMap do karpenter-global-settings, você precisa reiniciar a deployment do Karpenter:

kubectl rollout restart deploy karpenter -n karpenter

Etapa 2. Automatize a atualização do worker node com o Drift

Primeiro, criaremos um provisionador padrão do Karpenter com um AWSNodeTemplate padrão sem AMISelector e AMIFamily especificados. Quando o AMISelector não é especificado, o Karpenter combina a versão da AMI do worker node com a versão do Control Plane do Amazon EKS Kubernetes. Conforme descrito na seção de visão geral, quando a AMIFamily não está selecionada, a Amazon Linux AMI otimizada para Amazon EKS é usada.

mkdir -p ~/environment/karpenter
cd ~/environment/karpenter

cat <<EoF> basic.yaml
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  providerRef:
    name: default
    
  labels:
    team: my-team

  requirements:
    - key: "karpenter.k8s.aws/instance-category"
      operator: In
      values: ["c", "m", "r"]
    - key: "karpenter.k8s.aws/instance-generation"
      operator: Gt
      values: ["5"]

  limits:
    resources:
      cpu: "1000"
    
  ttlSecondsAfterEmpty: 60  
    
---
apiVersion: karpenter.k8s.aws/v1alpha1
kind: AWSNodeTemplate
metadata:
  name: default
spec:
  subnetSelector:
    alpha.eksctl.io/cluster-name: $CLUSTER_NAME
  securityGroupSelector:
    alpha.eksctl.io/cluster-name: $CLUSTER_NAME
  tags:
    managed-by: "karpenter"
    intent: "apps"
EoF

kubectl apply -f basic.yaml

Nota: Selecione suas próprias sub-redes e grupos de segurança se seu cluster Amazon EKS não for provisionado pelo eksctl. Consulte esta página para obter mais detalhes sobre como descobrir sub-redes e grupos de segurança com o Karpenter AWSNodeTemplate.

Vamos implantar um exemplo de deployment, chamado inflate, para escalar os worker nodes:

cd ~/environment/karpenter

cat <<EoF> sample-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
spec:
  replicas: 2
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      containers:
        - name: inflate
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
          resources:
            requests:
              cpu: 1
              memory: 128Mi
            limits:
              memory: 128Mi
      nodeSelector:
        team: my-team
EoF

kubectl apply -f sample-deploy.yaml

Você pode verificar os logs do Karpenter para ver se ele encontrou os unschedulables pods (ou seja, provisionáveis), selecionou várias instâncias do Amazon EC2, e passou para a API do Amazon EC2 Fleet para criar um novo worker node:

kubectl -n karpenter logs -l app.kubernetes.io/name=karpenter

2023-08-03T00:25:19.114Z        INFO    controller.provisioner  found provisionable pod(s)      {"commit": "34d50bf-dirty", "pods": 2}
2023-08-03T00:25:19.114Z        INFO    controller.provisioner  computed new machine(s) to fit pod(s)   {"commit": "34d50bf-dirty", "machines": 1, "pods": 2}
2023-08-03T00:25:19.130Z        INFO    controller.provisioner  created machine {"commit": "34d50bf-dirty", "provisioner": "default", "requests": {"cpu":"2125m","pods":"4"}, "instance-types": "c6a.2xlarge, c6a.xlarge, c6i.2xlarge, c6i.xlarge, c6id.2xlarge and 27 other(s)"}
2023-08-03T00:25:19.286Z        DEBUG   controller.machine.lifecycle    created launch template {"commit": "34d50bf-dirty", "machine": "default-v45qb", "provisioner": "default", "launch-template-name": "karpenter.k8s.aws/4979454979243700410", "id": "lt-080a99f7b8d64f581"}
2023-08-03T00:25:21.125Z        INFO    controller.machine.lifecycle    launched machine        {"commit": "34d50bf-dirty", "machine": "default-v45qb", "provisioner": "default", "provider-id": "aws:///us-west-2a/i-071302eeaa77d43f6", "instance-type": "c6a.xlarge", "zone": "us-west-2a", "capacity-type": "on-demand", "allocatable": {"cpu":"3920m","ephemeral-storage":"17Gi","memory":"6584Mi","pods":"58"}}
2023-08-03T00:25:41.044Z        DEBUG   controller.machine.lifecycle    registered machine      {"commit": "34d50bf-dirty", "machine": "default-v45qb", "provisioner": "default", "provider-id": "aws:///us-west-2a/i-071302eeaa77d43f6", "node": "ip-192-168-27-17.us-west-2.compute.internal"}
2023-08-03T00:25:56.341Z        DEBUG   controller.machine.lifecycle    initialized machine     {"commit": "34d50bf-dirty", "machine": "default-v45qb", "provisioner": "default", "provider-id": "aws:///us-west-2a/i-071302eeaa77d43f6", "node": "ip-192-168-27-17.us-west-2.compute.internal"}

Em seguida, verifique a versão da AMI de um nó recém-implantado. Nesse ambiente de demonstração, a versão da AMI é v1.24:

kubectl get nodes -l team=my-team

NAME                                          STATUS   ROLES    AGE     VERSION
ip-192-168-27-17.us-west-2.compute.internal   Ready    <none>   4m41s   v1.24.15-eks-a5565ad

Agora vamos verificar a versão do Control Plane do Amazon EKS. Estamos assumindo que a versão do Control Plane é equivalente a versão do nó:

kubectl version --short

Agora, atualizaremos o control plane do Amazon EKS e validaremos se os worker nodes serão atualizados automaticamente para a nova versão que corresponda a versão do control plane. Você pode usar sua forma preferida de atualizá-lo, mas usaremos a AWS Command Line Interface (AWS CLI) como exemplo aqui. Substitua o código da região (region-code) pelo seu. Substitua 1.25 pelo número da versão compatível com o Amazon EKS para a qual você deseja atualizar seu cluster. Para obter as melhores práticas sobre atualizações de cluster do Amazon EKS, consulte a seção de atualização de clusters do guia de melhores práticas do Amazon EKS.

aws eks update-cluster-version --region <region-code> --name $CLUSTER_NAME --kubernetes-version 1.25

Monitore o status da atualização do cluster com o comando a seguir. Use a ID de atualização que o comando anterior retornou e substitua o <update-id> por esse valor no comando a seguir. Quando um status de sucesso é exibido, a atualização é concluída.

aws eks describe-update --region <region-code> --name $CLUSTER_NAME --update-id <update-id>

Depois que o status mudar para Ativo, vamos verificar os logs do Karpenter. Você pode verificar se o Karpenter detectou um drift e iniciou o desprovisionamento do nó por meio do Drift e substituiu por um novo nó.

kubectl -n karpenter logs -l app.kubernetes.io/name=karpenter | grep -i drift
 
2023-08-03T01:20:15.725Z        DEBUG   controller.machine.disruption   marking machine as drifted      {"commit": "34d50bf-dirty", "machine": "default-v45qb"}
2023-08-03T01:20:17.052Z        INFO    controller.deprovisioning       deprovisioning via drift replace, terminating 1 machines ip-192-168-27-17.us-west-2.compute.internal/c6a.xlarge/on-demand and replacing with on-demand machine from types m6a.2xlarge, r6a.2xlarge, r6id.2xlarge, c6in.xlarge, r6idn.2xlarge and 23 other(s)      {"commit": "34d50bf-dirty"}

Vamos verificar a versão da AMI do nó:

kubectl get nodes -l team=my-team

Você verá que o status de um nó v1.24 é Ready, SchedulingDisabled e um nó v1.25 recém-implantado ainda não está pronto (NotReady).

kubectl get nodes -l team=my-team

NAME STATUS ROLES AGE VERSION
ip-192-168-27-17.us-west-2.compute.internal Ready,SchedulingDisabled <none> 55m v1.24.15-eks-a5565ad
ip-192-168-41-50.us-west-2.compute.internal NotReady <none> 13s v1.25.11-eks-a5565ad

Observação: o tempo real para a atualização do nó varia de acordo com o ambiente.

Etapa 3. Atualização de nós com controle de promoção de AMIs

Como acabamos de ver, o Drift do Karpenter atualiza automaticamente a versão do nó da AMI quando o Control Plane do Amazon EKS é atualizado com uma AMI Amazon Linux otimizada para Amazon EKS, por padrão, quando o AMISelector e o AMIFamily não estão definidos. No entanto, há casos de uso (por exemplo, solicitar AMIs por meio de ambientes) em que você deseja ter mais controle sobre quando iniciar a atualização da AMI com uma AMI específica. Para isso, se você especificar a AMI no AMISelector (em AWSNodeTemplate), os nós só serão atualizados quando você alterar explicitamente a AMI sem seguir a atualização do Control Plane.

Neste exemplo, usamos o Ubuntu, mas você pode considerar um sistema operacional específico para executar contêineres como o Bottlerocket. Você pode obter o ID da AMI no link a seguir da Canonical.

Observe que o ID da AMI pode variar dependendo da versão do Kubernetes e da região da AWS que está sendo usada.

cd ~/environment/karpenter

cat << EOF > ubuntu-nt.yaml
apiVersion: karpenter.k8s.aws/v1alpha1
kind: AWSNodeTemplate
metadata:
  name: ubuntu-nt
spec:
  amiFamily: Ubuntu
  amiSelector:
    aws::ids: ami-0e4d51e5c9f7336cd
  subnetSelector:
    alpha.eksctl.io/cluster-name: $CLUSTER_NAME
  securityGroupSelector:
    alpha.eksctl.io/cluster-name: $CLUSTER_NAME
  tags:
    managed-by: "karpenter"
    intent: "apps"
EOF

kubectl -f ubuntu-nt.yaml create

Agora, vamos editar o provisionador padrão para usar esse AWSNodeTemplate recém-criado, ubuntu-nt.

kubectl edit provisioner default

Pesquise por ProviderRef nas especificações e altere o valor do nome do padrão para ubuntu-nt:

....
spec:
  labels:
    team: my-team
  limits:
    resources:
      cpu: "10"
  providerRef:
    name: ubuntu-nt

Vamos verificar os logs do Karpenter. Você pode verificar se o Karpenter detectou o drift e desprovisionou o nó via drift replace e o substituiu po rum novo nó:

kubectl -n karpenter logs -l app.kubernetes.io/name=karpenter | grep -i drift

2023-08-03T04:15:43.499Z        DEBUG   controller.machine.disruption   marking machine as drifted      {"commit": "34d50bf-dirty", "machine": "default-5jdcs"}
2023-08-03T04:15:53.480Z        INFO    controller.deprovisioning       deprovisioning via drift replace, terminating 1 machines ip-192-168-41-50.us-west-2.compute.internal/c6a.xlarge/on-demand and replacing with on-demand machine from types m6a.2xlarge, r6id.xlarge, r6a.xlarge, r6id.2xlarge, r6i.xlarge and 27 other(s)    {"commit": "34d50bf-dirty"}

Vamos verificar a versão da AMI do nó:

kubectl get nodes -l team=my-team

Você verá que o status atual de uma AMI Linux v1.25 otimizada para Amazon EKS (v1.25.11-eks-a5565ad) é Ready, SchedulingDisabled e um nó ubuntu v.1.25 recém-implantado (v1.25.10) ainda não está pronto (Not Ready).

kubectl get nodes -l team=my-team

NAME                                          STATUS                     ROLES    AGE    VERSION
ip-192-168-41-50.us-west-2.compute.internal   Ready,SchedulingDisabled   <none>   176m   v1.25.11-eks-a5565ad
ip-192-168-7-119.us-west-2.compute.internal   NotReady                   <none>   4s     v1.25.10

Depois de alguns segundos, agora você pode verificar se o novo nó do Ubuntu v.1.25 está pronto (Ready) e o nó anterior do Linux AMI v1.25 otimizado para Amazon EKS foi encerrado.

kubectl get nodes -l team=my-team

NAME                                          STATUS   ROLES    AGE   VERSION
ip-192-168-7-119.us-west-2.compute.internal   Ready    <none>   44s   v1.25.10

Ao usar o Karpenter, há algumas considerações adicionais de design que podem ajudá-lo a realizar operações contínuas:

Use as Pod Topology Spread Constraints para distribuir workloads entre domínios de falha para obter alta disponibilidade — Semelhantes às regras de anti-afinidade do pod, as restrições de dispersão da topologia do pod permitem que você disponibilize seu aplicativo em diferentes domínios de falha (ou topologia), como hosts ou zonas de disponibilidade.
Considere as Pod Readiness Gates — Para workloads que entram por meio de um Elastic Load Balancer (ELB) para validar se foram registrados com sucesso nos target groups, considere usar os Pod Readiness Gates. Consulte o guia de melhores práticas do Amazon EKS para obter mais informações.
Considere os Pod Disruptions Budgets — use os Pod Disruptions Budgets para controlar o encerramento de pods durante interrupções voluntárias. O Karpenter respeita os Pod Disruptions Budgets (PDBs) usando uma estratégia de repetição de backoff para despejo.
Considere se a seleção automática de AMIs é a abordagem correta — É recomendável considerar as melhores e mais recentes AMIs otimizadas para o Amazon EKS; no entanto, se você quiser controlar a implantação de AMIs em todos os ambientes, pense em deixar o Karpenter escolher a AMI mais recente ou especificar sua própria AMI. Ao especificar sua própria AMI, você pode controlar a promoção de AMIs por meio de ambientes de aplicativos.
Considere definir sh/do-not-evict: “true” — Para workloads que podem não ser interrompidos (por exemplo, jobs batch de longa execução sem ponto de verificação), considere anotar pods com do not evict annotation. Ao desativar o despejo dos pods, você está dizendo ao Karpenter que ele não deve remover voluntariamente os nós que contêm esse pod. No entanto, se um pod de não despejo for adicionado a um nó enquanto o nó estiver sendo drenado, os pods restantes ainda serão despejados. Nesse caso, esse pod bloqueia o encerramento até ser removido. Em ambos os casos, o nó é isolado para evitar que trabalhos adicionais sejam agendados.

Limpando

Para limpar os recursos criados, você pode executar as seguintes etapas:

1. Exclua o provisionador Karpenter para desprovisionar nós, limpar os Node Templates e o aplicativo de exemplo:

kubectl delete -f basic.yml
kubectl delete -f ubuntu-nt.yaml
kubectl delete -f sample-deploy.yaml

2. Se você criou um novo cluster Amazon EKS para o passo a passo, não se esqueça de limpar todos os recursos ou incorrerá em custos.

Conclusão

Para clientes com muitos clusters e Node Groups do Kubernetes, a adoção do Karpenter simplifica o gerenciamento da infraestrutura. Neste post, descrevemos como atualizar e corrigir os nós do Kubernetes ao usar um recurso do Karpenter chamado Drift. Essas estratégias de correção podem reduzir seu trabalho pesado, o que ajuda você a corrigir os worker nodes em grande escala, passando de uma estratégia pontual para um mecanismo contínuo. O recurso Karpenter Drift ainda está evoluindo e para obter as informações mais recentes e atualizadas, confira a documentação do Karpenter.

Nota: O Karpenter está se preparando para atualizar para a API v1beta1, descrita aqui. O comportamento do Drift em si não mudará com a v1beta1, mas haverá mais recursos com as mudanças de nome do CRD, que serão atualizadas nesta postagem após a primeira publicação.

Se você quiser saber mais, venha discutir o Karpenter no canal #karpenter no slack do Kubernetes ou participe das chamadas do grupo de trabalho do Karpenter.

Para obter informações práticas, confira o workshop da Karpenter.

Este blog é uma tradução do conteúdo original em inglês (link aqui).

Autores

	Rajdeep Saha é Principal Solutions Architect de Serverless e Contêineres na Amazon Web Services (AWS). Ele ajuda os clientes a projetar aplicativos escaláveis e seguros na AWS. Rajdeep é apaixonado por ajudar e ensinar recém-chegados sobre computação em nuvem. Ele mora na cidade de Nova York.
	Ratnopam Chakrabarti é arquiteto especializado em soluções para modernização de contêineres e infraestrutura na Amazon Web Services (AWS). Em sua função atual, Ratnopam ajuda os clientes da AWS a acelerar sua adoção da nuvem e executar workloads de contêineres escaláveis, seguras e otimizadas em grande escala. Você pode se conectar com ele no LinkedIn em https://www.linkedin.com/in/ratnopam-chakrabarti/.
	Chance Lee é arquiteto sênior de soluções especializadas em contêineres na AWS, com sede na Bay Area. Ele ajuda os clientes a arquitetar workloads de contêineres altamente escaláveis e seguras com os serviços de contêineres da AWS e várias soluções de ecossistema. Antes de ingressar na AWS, Chance foi consultor de serviços de laboratório da IBM.
	Robert Northard é arquiteto sênior de soluções especialista em contêineres na AWS. Ele tem experiência em tecnologias de contêineres e práticas de DevOps.

Revisores

Gerson Itiro Hidaka atualmente trabalha como Enterprise Solution Architect na AWS e atua no atendimento a clientes da área Financeira no Brasil. Entusiasta de tecnologias como Internet das Coisas (IoT), Drones, Devops e especialista em tecnologias como contêineres, serverless computing e Kubernetes. Trabalha com soluções de TI há mais de 26 anos, tendo experiência em inúmeros projetos de otimização de infraestrutura, redes, migração, disaster recovery e DevOps em seu portifólio.

Rafael Weffort é engenheiro da computação pós-graduado, quase-biólogo, pai do Martin e montanhista. Atualmente é arquiteto de soluções da AWS para o segmento de Fornecedores de Software Independente (ISV – Independent Software Vendor). Começou a carreira nos primórdios da internet brasileira, desenvolvendo e vendendo websites aos 12 anos. Por uma década foi desenvolvedor full-stack no mercado financeiro e desde 2019 vem apoiando clientes do mundo de SaaS e e-commerce em modernização e otimização na nuvem, se especializando em arquitetura, design de APIs, integrações de sistemas, micros-serviços e contêineres.

O blog da AWS