DEV Community: Rafael Conceição

Update Addons AWS EKS

Rafael Conceição — Tue, 06 May 2025 10:08:35 +0000

https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html

export CLUSTER=
export AWS_REGION=
export AWS_ACCOUNT_ID=$(aws sts get-caller-identity | jq --raw-output ".Account")
export ENV=

Amazon VPC CNI

kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3

Deve ser >= 1.8.0

kubectl get daemonset aws-node -n kube-system -o yaml > aws-k8s-cni-old.yaml

eksctl create iamserviceaccount \
--name aws-node \
--namespace kube-system \
--cluster $CLUSTER \
--attach-policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
--approve \
--role-only \
--role-name "AmazonEKSVPCCNIRole-${ENV}"

aws eks create-addon \
--cluster-name $CLUSTER \
--addon-name vpc-cni \
--service-account-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/AmazonEKSVPCCNIRole-${ENV} \
--resolve-conflicts OVERWRITE

eksctl get addon --name vpc-cni --cluster $CLUSTER

aws eks update-addon \
--addon-name vpc-cni \
--addon-version v1.15.1-eksbuild.1 \
--cluster-name $CLUSTER \
--service-account-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/AmazonEKSVPCCNIRole-${ENV}

CoreDNS

kubectl describe deployment coredns --namespace kube-system | grep coredns: | cut -d : -f 3

kubectl get deployment coredns -n kube-system -o yaml > aws-k8s-coredns-old.yaml

aws eks create-addon \
--cluster-name $CLUSTER \
--addon-name coredns \
--resolve-conflicts OVERWRITE

eksctl get addon --name coredns --cluster $CLUSTER

aws eks update-addon \
--addon-name coredns \
--addon-version v1.9.3-eksbuild.21 \
--cluster-name $CLUSTER

Kube-proxy

kubectl describe daemonset kube-proxy -n kube-system | grep kube-proxy: | cut -d : -f 3

Deve ser max 2 versões para tras

kubectl get daemonset kube-proxy -n kube-system -o yaml > aws-k8s-kube-proxy-old.yaml

aws eks create-addon \
--cluster-name $CLUSTER \
--addon-name kube-proxy \
--resolve-conflicts OVERWRITE

eksctl get addon --name kube-proxy --cluster $CLUSTER

Atualizar apos upgrade do eks

aws eks update-addon \
--addon-name kube-proxy \
--addon-version v1.25.9-eksbuild.1 \
--cluster-name $CLUSTER

ALB Controller

kubectl describe deployment -n kube-system aws-load-balancer-controller | grep aws-alb-ingress-controller: | cut -d : -f 3

kubectl get deployment -n kube-system aws-load-balancer-controller -o yaml > aws-k8s-aws-alb-ingress-controller-old.yaml

kubectl set image deployment/aws-load-balancer-controller -n kube-system controller=public.ecr.aws/eks/aws-load-balancer-controller:v2.4.7

k get pod -n kube-system | grep aws-load-balancer-controller

Por que os times precisam de SLOs, SLIs e Error Budget?

Rafael Conceição — Sun, 17 Mar 2024 18:06:28 +0000

Os SLOs (Objetivos de Nível de Serviço) são um instrumento para auxiliar na definição de quais tarefas de engenharia devem ser priorizadas. Ao avaliar o impacto previsto em nosso orçamento de erros (Error Budget), podemos identificar qual projeto trará mais benefícios para os nossos usuários.

O que um SLO deve ser e o que ele deve abranger.

Um SLO estabelece um nível de confiabilidade alvo para os usuários do serviço. Acima deste limite, quase todos os usuários devem estar contentes com o seu serviço. No final do dia, a satisfação do usuário é o que importa (leia o texto: Confiabilidade: um dos recursos mais importantes de um sistema)

100% de confiabilidade é o alvo errado

Alguns motivos para essa afirmação:

Mesmo que um sistema tenha 100% de disponibilidade, o cliente não experimenta os 100%. A jornada do cliente geralmente é longa e complexa, e qualquer um dos componentes ao longo do caminho pode falhar. À medida que você passa de 99% para 99,9% para 99,99% de confiabilidade, cada nove extra tem um custo maior, mas a utilidade para seus clientes se aproxima constantemente de zero.
Se você conseguir criar uma experiência 100% confiável para seus clientes e quiser manter esse nível de confiabilidade, nunca poderá atualizar ou melhorar seu serviço. A principal fonte de interrupções são mudanças.
Um SLO de 100% significa que você só tem tempo para ser reativo.

Uma vez que você tenha uma meta de SLO abaixo de 100%, ela precisa ser de propriedade de alguém na organização que esteja capacitado para fazer compensações entre velocidade e confiabilidade.

Por mais que o time SRE possa ser o guardião do SLO, o time do produto e de negócios devem estar envolvidos em todo o ciclo, sedo co-responsáveis nas definições e ações.

O que medir: usando SLIs e Error Budget

SLI é um indicador do nível de serviço que você está fornecendo.

Recomendamos tratar o SLI como a razão de dois números: o número de eventos bons dividido pelo número total de eventos. Por exemplo:

Número de solicitações HTTP bem-sucedidas / total de solicitações HTTP
(taxa de sucesso)

O SLO é uma porcentagem alvo e o orçamento de erro é 100% menos o SLO. Por exemplo:

Se você tiver um SLO de taxa de sucesso de 99,9%, um serviço que
recebe 3 milhões de solicitações em um período de quatro semanas tem
um orçamento de erros de 3.000 (0,1%) erros nesse período. Se uma
única interrupção for responsável por 1.500 erros, esse erro custará
50% do orçamento.

Sua primeira tentativa de SLI e SLO não precisa ser perfeita; O objetivo mais importante é colocar algo em prática e medir, e configurar um ciclo de feedback para que você possa aprimorar a estratégia.

Começando a definir SLIs

Escolha um aplicativo para o qual você deseja definir SLOs.
Decida claramente quem são os “usuários” nessa situação.
Considere as maneiras comuns como seus usuários interagem com seu sistema - tarefas comuns e atividades críticas.
Desenhe um diagrama de arquitetura de alto nível do seu sistema; Mostre os principais componentes, o fluxo de solicitação, o fluxo de dados e as dependências críticas.

Escolha um aspecto do seu sistema que seja relevante, mas fácil de medir - você sempre pode iterar e refinar mais tarde.

Estratégia baseada no Error Budget

Para implementar uma estratégia baseada em orçamento de erros, é necessário alcançar um estado onde:

Os SLOs foram aprovados por todas as partes interessadas como adequados para o produto.
Os encarregados de assegurar o SLO concordaram que é viável atingir este SLO em condições normais.
A organização se comprometeu a utilizar o orçamento de falhas para tomada de decisões e priorização.
Um processo para aprimorar o SLO deve ser definido.

Caso contrário, a conformidade com o SLO será apenas mais um indicador de desempenho em vez de uma ferramenta de tomada de decisão.

Error Budget é um assunto que merece um texto dedicado sobre o assunto ;)

Aprimorando o SLO

Durante o processo de revisão de um SLO algumas perguntas podem ser feitas que irão nos ajudar a saber ser estamos no caminho correto ou não:

Consideramos o SLO determinado como sendo adequado e possível cumprir em circunstâncias normais?
O SLO tem ajudado a determinar qual trabalho de engenharia priorizar e qual projeto é mais benéfico para nossos usuários?

Ao refinar o SLO pense em como responder sim para essas perguntas.

Concluindo

A implementação de SLOs, SLIs e Error Budget é uma estratégia essencial para equilibrar a confiabilidade do serviço e a velocidade de desenvolvimento. Ao estabelecer metas de confiabilidade realistas e mensuráveis, as equipes podem priorizar efetivamente o trabalho de engenharia e melhorar a satisfação do usuário.

A chave para o sucesso é a colaboração entre todas as partes interessadas e a adoção de um ciclo de feedback contínuo.

Conheça os meus outros posts sobre SRE

Por que os times precisam de SLOs, SLIs e Error Budget?

Rafael Conceição — Sun, 17 Mar 2024 18:04:57 +0000

O que um SLO deve ser e o que ele deve abranger.

100% de confiabilidade é o alvo errado

Alguns motivos para essa afirmação:

Mesmo que um sistema tenha 100% de disponibilidade, o cliente não experimenta os 100%. A jornada do cliente geralmente é longa e complexa, e qualquer um dos componentes ao longo do caminho pode falhar. À medida que você passa de 99% para 99,9% para 99,99% de confiabilidade, cada nove extra tem um custo maior, mas a utilidade para seus clientes se aproxima constantemente de zero.
Se você conseguir criar uma experiência 100% confiável para seus clientes e quiser manter esse nível de confiabilidade, nunca poderá atualizar ou melhorar seu serviço. A principal fonte de interrupções são mudanças.
Um SLO de 100% significa que você só tem tempo para ser reativo.

Uma vez que você tenha uma meta de SLO abaixo de 100%, ela precisa ser de propriedade de alguém na organização que esteja capacitado para fazer compensações entre velocidade e confiabilidade.

Por mais que o time SRE possa ser o guardião do SLO, o time do produto e de negócios devem estar envolvidos em todo o ciclo, sedo co-responsáveis nas definições e ações.

O que medir: usando SLIs e Error Budget

SLI é um indicador do nível de serviço que você está fornecendo.

Recomendamos tratar o SLI como a razão de dois números: o número de eventos bons dividido pelo número total de eventos. Por exemplo:

Número de solicitações HTTP bem-sucedidas / total de solicitações HTTP
(taxa de sucesso)

O SLO é uma porcentagem alvo e o orçamento de erro é 100% menos o SLO. Por exemplo:

Se você tiver um SLO de taxa de sucesso de 99,9%, um serviço que
recebe 3 milhões de solicitações em um período de quatro semanas tem
um orçamento de erros de 3.000 (0,1%) erros nesse período. Se uma
única interrupção for responsável por 1.500 erros, esse erro custará
50% do orçamento.

Começando a definir SLIs

Escolha um aplicativo para o qual você deseja definir SLOs.
Decida claramente quem são os “usuários” nessa situação.
Considere as maneiras comuns como seus usuários interagem com seu sistema - tarefas comuns e atividades críticas.
Desenhe um diagrama de arquitetura de alto nível do seu sistema; Mostre os principais componentes, o fluxo de solicitação, o fluxo de dados e as dependências críticas.

Escolha um aspecto do seu sistema que seja relevante, mas fácil de medir - você sempre pode iterar e refinar mais tarde.

Estratégia baseada no Error Budget

Para implementar uma estratégia baseada em orçamento de erros, é necessário alcançar um estado onde:

Os SLOs foram aprovados por todas as partes interessadas como adequados para o produto.
Os encarregados de assegurar o SLO concordaram que é viável atingir este SLO em condições normais.
A organização se comprometeu a utilizar o orçamento de falhas para tomada de decisões e priorização.
Um processo para aprimorar o SLO deve ser definido.

Caso contrário, a conformidade com o SLO será apenas mais um indicador de desempenho em vez de uma ferramenta de tomada de decisão.

Error Budget é um assunto que merece um texto dedicado sobre o assunto ;)

Aprimorando o SLO

Durante o processo de revisão de um SLO algumas perguntas podem ser feitas que irão nos ajudar a saber ser estamos no caminho correto ou não:

Consideramos o SLO determinado como sendo adequado e possível cumprir em circunstâncias normais?
O SLO tem ajudado a determinar qual trabalho de engenharia priorizar e qual projeto é mais benéfico para nossos usuários?

Ao refinar o SLO pense em como responder sim para essas perguntas.

Concluindo

A chave para o sucesso é a colaboração entre todas as partes interessadas e a adoção de um ciclo de feedback contínuo.

Conheça os meus outros posts sobre SRE

Contribuições de uma equipe de SRE no ciclo de vida de um serviço

Rafael Conceição — Sat, 05 Aug 2023 14:38:16 +0000

Importante: o texto a seguir é fruto de um exercício de criação de um time de SRE, onde os times de desenvolvedores seriam os responsáveis por criar e manter a infraestrutura e aplicações.
Não existe um modelo certo ou errado, nem considere esse texto como uma verdade absoluta.
Boa parte desse material foi baseado nos livros: The Site Reliability Workbook e Site Reliability Engineering. Você poderá encontrar frases ou partes do livros, nesse texto e nos outros.

Nos posts anteriores abordei um pouco sobre os:

Nesse post vamos ver como as contribuições de uma equipe de SRE, podem acontecer em várias fases do ciclo de vida de um serviço.

Fase 1: Arquitetura e Design

Como o SRE pode influenciar a arquitetura e o design de um sistema:

Criação de práticas recomendadas, como resiliência a vários pontos únicos de falha
Documentar prós e contras de um determinado sistema/infra, para que os desenvolvedores possam escolher com sabedoria
Apoio a discussões para escolha de arquiteturas e design ajuda na validação de suposições e PoC
Atuar junto com a equipe de desenvolvimento, participando do trabalho de desenvolvimento
Co-projetando parte do serviço

O envolvimento precoce do SRE pode ajudar a evitar reformulações dispendiosas.

Fase 2: Desenvolvimento Ativo

Nessa fase começa a produtização do serviço, para que possa ser liberado para produção. A produtização normalmente inclui:

Planejamento de capacidade
Configuração de recursos extras para redundância
Implementação de infraestrutura extra
Planejamento para picos e sobrecargas
Implementação de monitoramentos e alertas

Fase 3: Disponibilidade limitada

Nessa fase o SRE pode ajudar a:

Medir e avaliar a confiabilidade.
Dimensionar o sistema criando um modelo de capacidade
Garantir uma cobertura de monitoramento adequada
Ajudar a criar alertas que correspondam idealmente aos próximos SLOs de serviço.

Recomendável que sejam definidos os SLOs nesse ponto, para que se tenha uma medida objetiva de quão confiável é o serviço.
A equipe de produto ainda tem a opção de retirar um produto que não pode atingir sua confiabilidade alvo.

Fase 4: Disponibilidade geral

Nessa fase o serviço já passou pelo PRR (Revisão de Prontidão da Produção) ou deverá passar.

Os objetivos da PRR são os seguintes:

Verifica se um serviço atende aos padrões aceitos de configuração de produção e prontidão operacional
Melhorar a confiabilidade do serviço de forma que minimize o número e a gravidade dos incidentes que podem ser esperados

A equipe de desenvolvedores deve continuar colocando em campo uma pequena parte de todo o trabalho operacional e de resposta a incidentes para que eles não percam a perspectiva sobre esses aspectos do serviço.

Fase 5: Fim de suporte

Não há mais usuários e o serviço foi desligado. O SRE pode ajudar a excluir referências ao serviço nas configurações de produção e na documentação, caso exista algum bloqueio.

Confiabilidade: um dos recursos mais importantes de um sistema

Rafael Conceição — Sat, 15 Jul 2023 19:28:02 +0000

Definição de confiabilidade

qualidade do que é confiável;
capacidade de uma unidade funcional desempenhar, sem falhas ou avarias, dada tarefa sob certas condições e dentro de um período determinado.
(Definições de Oxford Languages)

A confiabilidade é a característica mais importante de qualquer sistema

Desde que tenhamos cuidado para mostrar que a confiabilidade abrange uma grande área, as pessoas não discordam muito desta frase.

Alguns argumentos simples:

Se um sistema não for confiável, os usuários não confiarão nele (simples assim).
Se os usuários não confiarem em um sistema, quando tiverem escolha, eles não o usarão.
Se um sistema não tem usuários, esse sistema não vale de nada.

Os usuários, não seu monitoramento, decidem sua confiabilidade

Você é o que você mede, então escolha suas métricas com cuidado.

Seu monitoramento, registros e alertas são valiosos apenas na medida em que ajudam você a perceber problemas antes que seus clientes o façam.

Dizer que tudo parece bem não fará seus usuários mais felizes. Se eles estão experimentando seu sistema como instável, será disso que eles lembrarão na a hora de escolher entre você e seu concorrente, usar ou não seu sistema.

O valor de qualquer sistema está relacionado com seus usuários. Sendo assim, no fim, a medida de confiabilidade que importa é como os usuários estão experimentando a confiabilidade.

Modelos de engajamentos de um SRE com um grupo de trabalho

Rafael Conceição — Sat, 08 Jul 2023 19:33:24 +0000

Importante: o texto a seguir é fruto de um exercício de criação de um time de SRE, onde os times de desenvolvedores seriam os responsáveis por criar e manter a infraestrutura e aplicações.
Não existe um modelo certo ou errado, nem considere esse texto como uma verdade absoluta.
Boa parte desse material foi baseado nos livros: The Site Reliability Workbook e Site Reliability Engineering. Você poderá encontrar frases ou partes do livros, nesse texto e nos outros.

No post anterior abordei um pouco sobre os Compromissos de um SRE com um grupo de trabalho. Nesse abordarei algumas formas que um time de SRE poderia se envolver com as equipes de desenvolvimento.

Os Modelos de Engajamento SRE

Os SREs podem trabalham com equipes de desenvolvimento de produtos de acordo com os seguintes modelos de envolvimento diferentes:

Part Time, em projetos pontuais e/ou de forma temporária
Full time, com dedicação quase exclusiva e permanente
Suporte alternativo

Part Time em projetos pontuais e/ou de forma temporária

Os SREs junto com as lideranças avaliam a importância do serviço e a disponibilidade da equipe SRE. Se o serviço necessita do suporte e ambos concordam com os níveis de pessoal para facilitar esse suporte, um envolvimento Part Time é estabelecido.

A etapa inicial do envolvimento do SRE é a Revisão de Prontidão de Produção (PRR), um processo que identifica as necessidades de confiabilidade de um serviço.

Os objetivos da PRR são os seguintes:

Avaliar a maturidade da equipe em relação às práticas de SRE;
Verificar se um serviço atende aos padrões aceitos de configuração de produção e prontidão operacional;
Melhorar a confiabilidade do serviço na produção e minimizar o número e a gravidade dos incidentes que podem ser esperados.

O modelo de PRR segue as seguintes fases:

Avaliação

A avaliação é o primeiro segmento do trabalho. Durante esta fase, os revisores do SRE aprendem sobre o serviço e começam a analisá-lo em busca de deficiências de produção.

Visam aferir a maturidade do serviço ao longo dos vários eixos de preocupação da engenharia de confiabilidade. Eles também examinam o design e a implementação do serviço para verificar se ele segue as práticas recomendadas de produção.

É utilizado um Guia de Produção, que consiste em uma lista de verificação específica para o serviço e geralmente é baseada em conhecimento e experiência com sistemas relacionados ou semelhantes e com as melhores práticas.

A equipe SRE também pode consultar outras equipes que tenham mais experiência com determinados componentes ou dependências do serviço, como times de arquitetura e produtos.

Melhorias e Refatoração

A fase de Avaliação leva à identificação das melhorias recomendadas para o serviço. Esta próxima fase procede da seguinte forma:

As melhorias são priorizadas com base na importância para a confiabilidade do serviço;
As prioridades são discutidas e negociadas com a equipe de desenvolvimento (negócio e produto também podem ser envolvidos), e um plano de execução é acordado;

A equipe de SRE e de desenvolvimento participam e ajudam umas às outras na refatoração de partes do serviço ou na implementação de recursos adicionais.

Esta fase normalmente varia em duração e quantidade de esforço. A quantidade de tempo e esforço depende da disponibilidade de tempo de engenharia para refatoração, da maturidade e complexidade do serviço.

Terminando o envolvimento

O envolvimento do SRE, nesse modelo, não é indefinido. O trabalho dos SREs deve gerar impacto e valor. Alguns motivos que podem levar ao fim do envolvimento:

O serviço ter sido otimizado para um nível em que não é mais necessário o envolvimento ou um marco é atingido;
A importância ou relevância do serviço diminuir.
Fim do ciclo de vida do serviço.

Depois que o trabalho termina e a equipe de desenvolvimento está atuando por conta própria, realizamos a avaliação novamente para medir o valor que foi agregado pelo time de SRE.

Full time, com dedicação quase exclusiva

No modelo Part time, nem todas as equipes irão se beneficiar do envolvimento direto da equipe de SRE. O Suporte alternativo também nem sempre se mostra viável.

Alguns fatores são levados em conta:

Capacidade de atendimento da equipe de SRE

Falta de conhecimento e maturidade do time de desenvolvimento;
Alta demanda de correções necessárias no ambiente, novas funcionalidades e adoção de tecnologias emergentes na empresa;
Devido às altas demandas, os times são obrigados a priorizar as entregas de negócios ao invés dos aspectos de confiabilidade, qualidade e resiliência.

Levando em consideração os pontos acima, um outro envolvimento é proposto: Full Time, com dedicação quase exclusiva.

Esse envolvimento tem com objetivo:

Ter um (ou mais) integrante do time de SRE como responsável por atender dois ou três times relacionadas da empresa. Essa pessoa será responsável por:

Suprir gaps de conhecimentos;
Ajudar a fornecer foco e tempo para aliviar algum fardo das equipes de desenvolvimento;
Envolvimento precoce em todo ciclo de vida da aplicação;
Aplicar o Guia de Produção.

Os SREs não deverão atuar de forma isolada nos times, um elemento central será responsável por direcionar os objetivos e as ações com base nas necessidades comuns da empresa ou grupo de trabalho (por exemplo: reduzir tempo de incidente), respeitando sempre a necessidade do time, bem como ser um facilitador e gerador de evolução.

Suporte alternativo

Nem todos os serviços recebem um envolvimento próximo do SRE. Alguns fatores podem ser levados em conta aqui:

Nem sempre os serviços precisam de alta confiabilidade e disponibilidade, portanto, o suporte pode ser fornecido por outros meios.
O número de equipes de desenvolvimento que solicitam suporte SRE excede a capacidade disponível das equipes SRE

Quando o SRE não pode fornecer suporte completo, ele fornece outras opções para fazer melhorias na produção, como documentações e consultorias.

Documentação

Guias de desenvolvimento e configurações estão disponíveis para tecnologias internas e de sistemas amplamente utilizados. O Guia de Produção documenta as práticas recomendadas de produção para serviços, conforme determinado pelas experiências dos SRE e equipes demais equipes.

Consultoria

Os desenvolvedores também podem procurar a consultoria da equipe de SRE para discutir serviços específicos ou áreas problemáticas. A equipe de desenvolvimento leva até o time de SRE os pontos que precisam de atenção e então é realizada uma discussão sobre padrões conhecidos ou soluções que podem ser incorporadas para melhorar o serviço em produção. Porém não é estabelecido um envolvimento.

Compromissos de um SRE em um grupo de trabalho

Rafael Conceição — Sun, 02 Jul 2023 16:04:07 +0000

Importante: o texto a seguir é fruto de um exercício de criação de um time de SRE, onde os times de desenvolvedores seriam os responsáveis por criar e manter a infraestrutura e aplicações.
Não existe um modelo certo ou errado, nem considere esse texto como uma verdade absoluta.
Boa parte desse material foi baseado nos livros: The Site Reliability Workbook e Site Reliability Engineering. Você poderá encontrar frases ou partes do livros, nesse texto e nos outros.

Compromissos com os times

A principal missão da função de SRE no grupo de Squads é capacitar as equipes de desenvolvimento de produtos com ferramentas e processos para maximizar a confiabilidade e a resiliência das aplicações que suportam o ecossistema desses produtos.

Compartilhando as expectativas

Definir as expectativas certas é fundamental para cumprir os prazos e a conclusão da tarefa. Para isso, trabalhamos de acordo com os seguintes princípios:

Enfatizamos que os proprietários das aplicações, não os SREs, são diretamente responsáveis por fazer alterações em um aplicativo.
O envolvimento com a equipe de SRE é para benefício de todas as Squads. Qualquer nova automação ou ferramental deve melhorar as ferramentas comuns e as automações usadas em todo grupo e evitando o desenvolvimento de soluções únicas
Os SREs devem dar à equipe de desenvolvedores um alerta sobre quaisquer novos processos que a empresa possa introduzir.
As mudanças propostas devem ser priorizadas conjuntamente pelos desenvolvedores e pelos SREs. Os desenvolvedores devem comprometer-se a dedicar uma porcentagem razoável de tempo de engenharia para corrigir e prevenir os pontos que estão quebrando a confiabilidade.
Os SREs não são engenheiros de operações tradicionais. Os proprietários das aplicações são responsáveis por desenvolver e suportar suas aplicações.
Parte do trabalho de SRE se concentra na entrega de ferramentas: para monitoramento, alertas, implementações, melhores práticas e listas de verificação.

Preocupações gerais

O SRE se preocupa com vários aspectos de um serviço, dentre esses aspectos podemos destacar os seguintes:

Instrumentação, métricas e monitoramento
Resposta de emergência
Planejamento de capacidade
Desempenho: disponibilidade, latência e eficiência

Definindo o envolvimento

Os SREs podem trabalham com equipes de desenvolvimento de produtos de acordo com os seguintes modelos de envolvimento diferentes:

Part Time, em projetos pontuais e/ou de forma temporária
Full time, com dedicação quase exclusiva
Suporte alternativo

Quando as equipes abordam os SREs para obter envolvimento, um dos fatores que é considerado ao priorizar uma solicitação é se um compromisso conjunto pode ajudar a reduzir a lista de pendências das Squads.

Confira os Modelos de engajamentos de um SRE com um grupo de trabalho

Explorando o Limit Range no Kubernetes para gerenciar recursos

Rafael Conceição — Sun, 21 May 2023 11:31:54 +0000

Introdução:

Uma das principais preocupações no ambiente Kubernetes é o gerenciamento eficiente dos recursos computacionais disponíveis. Nesse sentido, o Kubernetes oferece o conceito de Limit Range, que permite aos administradores definir limites e solicitações de recursos para os contêineres em um cluster. Abaixo, exploraremos o uso do Limit Range e forneceremos um exemplo prático para ilustrar seu funcionamento.

O que é o Limit Range:

O Limit Range é um objeto do Kubernetes que permite aos administradores definir políticas de limites e solicitações de recursos para pods em um namespace específico. Ele fornece uma maneira de garantir que os contêineres tenham acesso aos recursos necessários e impõe restrições para evitar o uso excessivo de recursos.

Exemplo de utilização do Limit Range:

Suponha que temos um namespace chamado "my-app" e desejamos definir limites de CPU e memória, e também adicionamos os valores mínimos e máximos para CPU e memória para os contêineres executados nesse namespace. Podemos criar um arquivo YAML contendo a definição do Limit Range da seguinte maneira:

apiVersion: v1
kind: LimitRange
metadata:
  name: resource-limits
spec:
  limits:
  - default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 200m
      memory: 256Mi
    min:
      cpu: 100m
      memory: 128Mi
    max:
      cpu: 1
      memory: 1Gi
    type: Container

No exemplo acima, definimos os limites e as solicitações de recursos para os contêineres do namespace "my-app".

O limite padrão máximo de CPU é de 500 milicores, enquanto "512Mi" define o limite padrão máximo de memória. As solicitações de recursos padrão são definidas pelos valores "200m" para CPU e "256Mi" para memória. Esses valores serão usados como padrão caso nenhum limite ou solicitação específica seja definido para um contêiner individual.

Além de definir os limites padrão e as solicitações de recursos, também adicionamos os valores mínimos e máximos para CPU e memória.

O limite mínimo de CPU é de 100 milicores, enquanto "128Mi" define o limite mínimo de memória. Por outro lado, os valores "1" para CPU e "1Gi" para memória estabelecem o limite máximo permitido para esses recursos.

Esses valores mínimos e máximos ajudam a controlar e garantir que os contêineres estejam dentro de intervalos aceitáveis de uso de recursos. Com essa definição, os administradores podem evitar que um contêiner utilize muito poucos recursos, o que pode prejudicar o desempenho do aplicativo, ou que um contêiner monopolize uma quantidade excessiva de recursos, prejudicando outros componentes do cluster.

Conclusão:

O uso do Limit Range é uma prática recomendada para garantir o uso eficiente dos recursos em um cluster. Ele permite aos administradores definir limites e solicitações de recursos de maneira granular, controlando o consumo e evitando problemas de alocação inadequada. Ao aplicar políticas adequadas de Limit Range, é possível otimizar o desempenho dos aplicativos e evitar gargalos de recursos em ambientes de produção.

Saiba mais:

Link para a documentação oficial do Kubernetes sobre Limit Ranges:

Documentação oficial do Kubernetes sobre Limit Ranges:
- Limit Ranges

Razões para monitorar um sistema

Rafael Conceição — Mon, 17 Apr 2023 19:21:28 +0000

Por que Monitorar?

Algumas razões porquê você deve monitorar um sistema.

Analisar tendências de longo prazo

Qual o tamanho do meu storage e em quanto tempo estará cheio? Qual a taxa de crescimento de acessos ao meu site?

Comparações ao longo do tempo ou grupos de experimentos

Minhas consultas são mais rápidas usando o banco XPTO ou o Banco XYZ? Minha aplicação está mais lenta do que na semana passada?

Gerar Alertas

Algo parou de funcionar e precisa ser consertado. Ou algo está preste a parar de funcionar.

Criar dashboards

Os dashboards devem responder a perguntas básica sobre o estado do serviço. Normalmente abordam os quatro sinais de ouro (golden signals)

Realizar um debugging

A latência de um serviço aumentou muito. O que mais estava ocorrendo no momento do evento?

O monitoramento também é útil para fornecer informações brutas sobre análises de negócios. Junto com os alertas permite que um sistema nos diga quando algo está quebrado, ou nos diga o que está prestes a quebrar.

Os Quatro Sinais de Ouro

Os quatro sinais de ouro do monitoramento são: latência, tráfego, erros e saturação.

Latência

O tempo que se leva para atender a uma solicitação. Importante separar a latência das solicitações bem sucedidas, das solicitações com falha.

Tráfego

Medida de quanta demanda está sendo colocada em seu sistema (quantidade de transações, requisições, execuções...)

Erros

Taxa de solicitações que apresentaram falha (erros 4xx/5xx, timeout...)

Saturação

Uma medida da fração do sistema, enfatizando os recursos que são mais restritos. Exemplo, em um sistema com restrição de memória, mostrar a medição da memória.
Quanto tráfego/processamento seu sistema pode lidar, antes de começar a apresentar degradação?
As previsões de saturação iminente (espaço em disco, por exemplo) também são preocupações desse ponto.

Medir os quatros sinais dourados e gerar alertas quando um sinal apresentar problemas (ou quase problema), faz com que seu serviço esteja minimamente coberto pelo monitoramento.

Esse texto foi adaptado do capitulo 6 - Monitoring Distributed Systems - do livro - do livro Site Reliability Engineering

Conheça também as metodologias RED e USE: Monitoring Methodologies: RED and USE

Gerenciando APIs obsoletas do Kubernetes com Pluto

Rafael Conceição — Sun, 12 Mar 2023 20:01:33 +0000

O que é o Pluto

Pluto é uma ferramenta desenvolvida pela FairwindsOps que ajuda na detecção de APIs obsoletas do Kubernetes .

Mas antes de falarmos da ferramenta, vamos entender um pouco sobre as APIs do Kubernetes e porque devemos nos preocupar com elas.

As APIs do Kubernetes

As APIs são a forma que podemos interagir com o cluster. Podemos então manipular e consultar os objetos (Pod, deployment...) através delas. Normalmente utilizamos o kubectl para acessar as APIs, mas também é possível através de chamadas REST.

Substituições ou remoções das APIs do Kubernetes

O Kubernetes está em constante evolução, sendo assim, alguns recursos novos são adicionados e outros precisam ser removidos, o mesmo acontece para as APIs.

Como resultado, as APIs antigas são depreciadas e eventualmente removidas, a depreciação, nesse contexto, significa marcar uma API para eventual remoção.

Para saber mais como o Kubernetes deprecia suas APIs veja na documentação da política de reprovação do Kubernetes.

Porque me preocupar com APIs obsoletas

Ao definir uma configuração de Deployment, você especifica a versão da API (apiVersion) do objeto Kubernetes a ser usado.

Se você atualizar seu cluster, há chances de encontrar APIs do Kubernetes depreciadas se a versão para a qual você atualizou não oferecer suporte a elas.

Nesse caso, provavelmente, seu Deployment pode não funcionar se a API depreciada tiver sido removida na nova versão do cluster.

Para saber todas as APIs depreciadas e/ou removidas veja no guia de depreciação.

Também é possível verificar todos os grupos de API suportados na sua versão através do comando kubectl api-versions

O desafio é como verificar quais APIs estão depreciadas e quais, de todos os recursos em execução no cluster, estão sendo utilizadas. Nesse ponto que o Pluto entra para nos ajudar.

Características do Pluto

Ele lista todas as APIs que foram depreciadas ou removidas, não apenas do Kubernetes, mas também para outras ferramentas como Istio e CertManager.
Detecta APIs depreciadas a partir de arquivos de configuração, helm instalados e/ou em todos os resources do cluster.
Também é possível utilizar num Workflow do Github Actions.

Como instalar

Você pode instalar em sua estação baixando a versão apropriada para seu sistema.

O Pluto possui versão para Windows, Linux e MacOs.

Exemplo de instalação no MacOs:

wget https://github.com/FairwindsOps/pluto/releases/download/v5.15.1/pluto_5.15.1_darwin_amd64.tar.gz -O /tmp/pluto_5.15.1_darwin_amd64.tar.gz tar -zxvf /tmp/pluto_5.15.1_darwin_amd64.tar.gz chmod +x /tmp/pluto cp /tmp/pluto /usr/local/bin

Exemplo de uso

Usando o comando pluto detect-all-in-cluster em um cluster que roda na versão 1.21 do Kubernetes, podemos ver que temos o recurso HPA Operator em uma versão que será removida na próxima versão do Kubernetes.

Como a instalação dele foi através de um Helm, vemos o mesmo através do comando pluto detect-helm.

O comando pluto -h lista todos os comando disponíveis.

Eventos orientados com Amazon EventBridge

Rafael Conceição — Sun, 26 Feb 2023 23:01:23 +0000

Sobre arquiteturas orientadas a eventos

As arquiteturas orientadas a eventos (Event-Driven) são caracterizadas por serviços que se comunicam de forma assíncrona e desacoplado através de eventos.

Os serviços transmitirão eventos (Produtores) que serão consumidos e reagidos por outros serviços (Consumidores).

Uma característica que marca uma Arquitetura orientadas a eventos é que: Produtores e Consumidores estão completamente dissociados, um produtor não deve saber ou se importar com quem está consumindo seus eventos.

Descrição da imagem: Representação o fluxo de uma arquitetura orientada a eventos, do lado esquerdo três retângulos representam os produtores, no meio um retângulo maior representa o roteador e a direita doisretângulos representam os consumidores

O que seria o Amazon EventBridge?

O Amazon EventBridge é um serviço que oferece acesso em tempo real a alterações de dados em serviços da AWS, em suas aplicações e em aplicações de software como serviço (SaaS) sem precisar escrever código. Para começar, você pode escolher uma origem de eventos no console do EventBridge. Em seguida, pode selecionar um destino entre os serviços da AWS, incluindo o AWS Lambda, o Amazon Simple Notification Service (SNS) e o Amazon Kinesis Data Firehose. O EventBridge entregará automaticamente os eventos quase em tempo real.

Em resumo você pode receber, filtrar, transformar, rotear (dos Produtores) e entregar esses eventos a Consumidores.

Trabalhando com o Amazon EventBridge

Para exemplificar o uso do Amazon EventBridge vamos utilizar um caso passei a pouco tempo:

Toda vez que uma instancia de banco de dados, do AWS RDS, fosse criada queríamos que uma AWS Lambda foi executada para adicionar uma determinada tag a instancia.

Utilizaremos então a seguinte arquitetura:

Descrição da imagem: Diagrama representando os serviços utilizados, numerados de um a três

Como Produtor de eventos utilizaremos o CloudTrail.
Como Roteador, que irá tratar os eventos, utilizaremos o EventBridge
Como Consumidor desses eventos utilizaremos a AWS Lambda

O repositório do Github rafaelonline/eventbridge-lambda possui um exemplo de configuração infraestrutura usando Terraform e o script Python utilizado.

Passo 1

Pre-Requisito: É preciso que a conta possua um Trail configurado no CloudTrail, saiba como configurar em Criar uma trilha para a sua conta da AWS

O CloudTrail gera eventos no formato JSON e possui integração nativa com o EventBridge. Ele será nosso Produtor de eventos.

O CloudTrail proporciona visibilidade sobre as atividades de usuários por meio do registro das ações executadas na sua conta. O CloudTrail registra informações importantes sobre cada ação, como quem fez a solicitação, quais serviços foram usados, quais ações foram executadas, quais os parâmetros da ação e quais elementos da resposta foram retornados pelo serviço da AWS

Passo 2

Agora devemos configurar uma regra no EventBridge Rules para monitorar os eventos desejados.

No nosso caso o padrão de evento(event pattern) será a própria AWS tendo como origem o Cloudtrail e nele os eventos relacionados ao rds.amazonaws.com com nome CreateDBInstance.

Exemplo no console da AWS:

Descrição da imagem: Recorte contendo exemplo de configuração da regra no console da AWS

Exemplo de código Terraform para criação da regra:

###### EVENTBRIDGE RULE - CREATED RDS INSTANCE ######
resource "aws_cloudwatch_event_rule" "rds_event_rule" {
  name          = "rule-rds-created"
  description   = "Triggers Lambda when new RDS instance are created"
  is_enabled    = true
  event_pattern = <<EOF
    {
    "source": ["aws.rds"],
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail": {
        "eventSource" : ["rds.amazonaws.com"],
        "eventName": ["CreateDBInstance"]
    }
    }
  EOF
}

Passo 3

Agora precisamos encaminhar nosso evento para o Consumidor (Alvo), que será uma Lambda.

Um Alvo é um recurso ou endpoint que EventBridge envia um evento, quando esse evento corresponde ao padrão definido em uma regra. Essa regra processa os dados do evento e envia as informações pertinentes ao Alvo

Podemos encaminhar esse mesmo evento para até cinco Alvos.
Por exemplo (não abordado nesse tutorial), no caso que tive nós enviamos um e-mail através do AWS SNS informando que uma instancia RDS foi criada, além de executar a Lambda que adiciona a tag.

Inclusive, podemos enviar o evento originalmente como foi gerado, enviar somente uma parte do evento, fazer alguma edição no evento antes de enviar e enviar um json de evento fixo.

Exemplo no console da AWS:

Descrição da imagem: Recorte contendo exemplo de configuração do alvo no console da AWS

Exemplo de código Terraform para criação do Target:

###### EVENTBRIDGE TARGET - CREATED RDS INSTANCE ######
resource "aws_cloudwatch_event_target" "lambda_rule_rds" {
  depends_on = [aws_lambda_function.autotag]
  rule       = aws_cloudwatch_event_rule.rds_event_rule.name
  target_id  = "SendToLambda"
  arn        = aws_lambda_function.autotag.arn
}

Passo 4

Chegamos ao passo final que é termos o nosso Consumidor, para nosso cenário criamos um script Python e uma Lambda para adicionar a Tag a instancia de RDS criada.

Script Python que cria a Tag

"""Add tags on RDS and Aurora."""
import logging
import os
import boto3
from botocore.exceptions import ClientError

# Config Logging.
log = logging.getLogger()
log.setLevel(logging.INFO)

def lambda_handler(event, context):
    """Add tags on RDS and Aurora"""

    # Define the tags to add to the RDS instance
    tag_key = os.environ.get('TAG_KEY')
    tag_value = os.environ.get('TAG_VALUE')
    tags = [
        {
            'Key': tag_key,
            'Value': tag_value
        }
    ]

    # Connect to RDS service
    rds = boto3.client('rds')
    event_name = event.get("detail").get("eventName")

    if event_name == "CreateDBCluster":
        aurora_arn = event.get("detail").get("responseElements").get("dBClusterArn")
    # Add tags to the Regional Cluster
        try:
            rds.add_tags_to_resource(
                ResourceName=aurora_arn,
                Tags=tags
            )
            log.info('Tag adicionda com sucesso ao Cluster Aurora: %s', aurora_arn)
        except ClientError as error:
            log.exception(error)

    else:
    # Add tags to the RDS instance
        rds_arn = event.get("detail").get("responseElements").get("dBInstanceArn")
        try:
            rds.add_tags_to_resource(
                ResourceName=rds_arn,
                Tags=tags
            )
            log.info('Tag adicionda com sucesso ao RDS: %s', rds_arn)
        except ClientError as error:
            log.exception(error)

Exemplo de código Terraform para criação Lambda:

###### GENERATE PACKAGE LAMBDA ###### 
data "archive_file" "lambda_autotag" {
  type        = "zip"
  source_dir  = "${path.module}/code/src"
  output_path = "${path.module}/code/lambda_package.zip"
}

###### LAMBDA FUNCTION ######
resource "aws_lambda_function" "autotag" {
  function_name    = var.autotag_function_name
  role             = aws_iam_role.lambda_exec_role.arn
  filename         = data.archive_file.lambda_autotag.output_path
  source_code_hash = data.archive_file.lambda_autotag.output_base64sha256
  description      = var.autotag_description
  publish          = true

  runtime       = "python3.8"
  handler       = "main.lambda_handler"
  timeout       = 300
  memory_size   = 128
  architectures = ["arm64"]

  environment {
    variables = {
      TAG_KEY   = var.lambda_tag_key
      TAG_VALUE = var.lambda_tag_value
    }
  }
}

Obs.: É necessário ter uma IAM Role que permita adição de tags na instância RDS

Conclusão

Através do Amazon EventBridge conseguimos que um evento de origem aciona-se outros eventos e executa-se uma automação. No nosso exemplo adicionamos uma tag, mas poderia ser qualquer outro processamento ou ação.

Saiba Mais

Event-Driven Architectures vs. Event-Based Compute in Serverless Applications
O que é a Amazon EventBridge?

Escolhendo o Worker Node - Kubernetes Instance Calculator

Rafael Conceição — Sun, 21 Nov 2021 12:08:17 +0000

Estabelecer quais tipos de servidores serão usados no cluster não é uma tarefa muito fácil, podemos errar a mão para baixo ou errar a mão para cima (bye $$$).

Para nos ajudar nessa tarefa vou deixar abaixo dois links do learnk8s.io:

O primeiro é um post em que eles abordam como escolher o tamanho de um Worker Node:

Architecting Kubernetes clusters — choosing a worker node size (learnk8s.io)

O segundo é um utilitário web para ajudar a escolher o melhor tipo de instância para seu cenário, com base no workload que você irá informar:

Kubernetes instance calculator (learnk8s.io)

Espero que essas duas dicas rápidas ajudem nessa tarefa.