The Ops Community ⚙️: Rafael Conceição

Explorando o Limit Range no Kubernetes para gerenciar recursos

Rafael Conceição — Sun, 21 May 2023 11:34:33 +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:34:55 +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 Dourados

Os quatro sinais dourados 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:06:02 +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:36:58 +0000

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 Event-Drive é que: Produtores e consumidores estão completamente dissociados, um produtor não deve saber ou se importar com quem está consumindo seus eventos.

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 criar o seguinte cenário:

Toda vez que uma instancia RDS for criada queremos que uma Lambda seja executada. Para nosso exemplo a Lambda irá adicionar uma tag.

Utilizaremos então a seguinte arquitetura:

Como Produtor de eventos utilizaremos o CloudTrail.
Como Broker, que irá tratar os eventos, utilizaremos o EventBridge
Como Consumer 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 Creating a trail

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 event pattern será a própria AWS tendo como origem o Cloudtrail e eventos do rds.amazonaws.com de nome CreateDBInstance.

Exemplo no console da AWS:

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

###### 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 (Target), que será uma Lambda.

Um Target é um recurso ou endpoint que EventBridge envia um evento para quando o evento corresponde ao padrão de evento definido para uma regra. A regra processa os dados do evento e envia as informações pertinentes ao Target

Podemos encaminhar esse mesmo evento para até cinco (5) Targets, por exemplo enviar um SNS informando que um RDS foi criado, além de executar a Lambda.

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

Exemplo 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 usaremos uma Lambda que irá adicionar uma Tag a instancia 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
    }
  }
}

Saiba Mais

Event-Driven Architectures vs. Event-Based Compute in Serverless Applications