DEV Community: Camila

Understanding Gitaly and Kernel Memory Consumption in Kubernetes on Self-Hosted GitLab

Camila — Tue, 24 Feb 2026 19:26:42 +0000

During the early hours of the morning, I started receiving Gitaly alerts — memory spikes that weren't being released automatically after the daily backup.

This article is about a self-hosted GitLab on EKS and the behavior of some GitLab components in Kubernetes.

If you also run GitLab on Kubernetes, it's worth understanding what's really happening — and why Cgroup v2 is the definitive solution to this kind of problem.

GITALY

Gitaly is the GitLab component responsible for all Git operations: clone, push, pull, merge, diff, and blame. It isolates repository storage from the web application and communicates with other services via gRPC, optimizing performance and concurrency control.

┌─────────────────────┐
│ GitLab Webservice   │
│              │
└──────────┬──────────┘
           │ gRPC
           ↓
┌─────────────────────┐
│ Gitaly              │
│ - Git operations    │
│ - Repository access │
└──────────┬──────────┘
           ↓
┌─────────────────────┐
│ Persistent Volume   │
│ /home/git/repos     │
└─────────────────────┘

GITLAB TOOLBOX BACKUP

It's a GitLab component used to perform backups in Kubernetes environments (specifically deployed using Helm charts). It's a pod/container that contains tools and scripts to execute GitLab backup and restore operations. When does it interact with Gitaly? During repository backups.

Connects to Gitaly via gRPC

Requests a backup of each repository

Receives Git bundles from Gitaly

Processes and compresses the data

Sends everything to object storage (S3, GCS, etc.)

During the execution of the gitlab-toolbox-backup cronjob in the early morning, I observed high memory usage on the Gitaly pod. This consumption is caused by the default behavior of the Linux kernel, which uses RAM as a cache for files read from disk (page cache).

In Kubernetes environments, this behavior can create resource allocation problems, since the kernel is shared across all pods on the node.

Symptoms:

High memory usage

Critical implications:

The kernel is shared across the entire node
Page Cache is global and shared
Cgroups v1 only limits how much each container can use
The kernel has no concept of "pod" or "container" — if the node has plenty of RAM, the kernel considers memory available even when a pod is about to be OOM-killed.

┌─────────────────────────────────────────────────┐
│                     NODE                        │
│                                                 │
│  ┌──────────────────────────────────────────┐   │
│  │         LINUX KERNEL (single)            │   │
│  │  - Manages ALL node RAM                  │   │
│  │  - Page Cache is SHARED                  │   │
│  │  - Has no concept of "pod"               │   │
│  └──────────────────────────────────────────┘   │
│                                                 │
│  ┌────────────┐  ┌────────────┐  ┌──────────┐   │
│  │  Pod A     │  │  Pod B     │  │  Pod C   │   │
│  │  (Gitaly)  │  │  (Redis)   │  │  (Web)   │   │
│  │            │  │            │  │          │   │
│  │  Sees:     │  │  Sees:     │  │  Sees:   │   │
│  │  Limit:8GB │  │  Limit:4GB │  │ Limit:2GB│   │
│  └────────────┘  └────────────┘  └──────────┘   │
│                                                 │
│  Total RAM: 32GB                                │
│  Total Cache: 20GB (visible to ALL)             │
└─────────────────────────────────────────────────┘

Note: Page Cache is the RAM used by the kernel to cache files from disk.

Backup Flow

What happens?

During the backup (1h):

Gitaly reads hundreds of Git repositories
Kernel caches everything: "I'll keep these .git files in RAM"
Backup ends: Gitaly process returns to normal (195MB)
Kernel doesn't clean up: Cache stays marked as "active_file" = 35.6GB
Kubernetes sees: Pod using 37GB → OOM danger!

Why doesn't it clean up automatically?

The cache is marked as "active" (not "inactive"), so the kernel thinks:

"These files were recently used"
"They'll probably be used again soon"
"I'll keep them in RAM"

But since this is a backup that runs once a day, those files won't be accessed again until tomorrow!

Possible solutions evaluated:

Option	Effort	Benefit	Recommendation
Migrate to cgroup v2	High (node reboot)	Definitive fix	Best long-term option
Privileged CronJob to drop cache	Low (15min)	Solves the problem	If you need a quick fix
DaemonSet monitor	Medium (1h)	Automated	Optional
Increase memory limit	Low	Temporary workaround	Emergency only

As we can see, there are workarounds — but the best long-term option is Cgroup v2. It requires a bit more effort to implement, but the benefits make it stand out.

Current Cgroup v1 data:

cache: 38829035520           # 36.2 GB !!!!!
rss: 204779520               # 195 MB
inactive_file: 568246272     # 542 MB
active_file: 38260654080     # 35.6 GB !!!!!


**35.6GB of `active_file`** = actively cached files (page cache)!

Breakdown:
- Gitaly process (RSS): 195 MB
- Active file cache: 35.6 GB  ← HERE!
- Inactive file cache: 542 MB
- Total cache: 36.2 GB
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Total pod usage: ~37 GB

Cgroup v2

Cgroup v2 has a feature called PSI that detects when there is memory "pressure":

# cgroup v2 exposes:
/sys/fs/cgroup/memory.pressure
# Content:
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

When pressure is detected, the kernel automatically releases cache even if it's marked as "active"!

Cgroup v2 is the second generation of the Linux kernel's control groups system, with significant improvements over v1. Our GitLab EKS cluster is currently running Cgroup v1.

Cgroup v1 has multiple independent hierarchies (memory, cpu, io), which can cause inconsistencies. Cgroup v2 uses a single unified tree:

That's it! I had the chance to dig into this topic this week and wanted to share what I learned.

Docs: backup-restore
Kernel Tuning and Optimization for Kubernetes: A Guide
Linux Kernel Version Requirements

Entendendo o consumo de memória do Gitaly e Kernel no Kubernetes em Gitlab self-hosted

Camila — Fri, 07 Nov 2025 20:38:53 +0000

Durante uma madrugada, comecei a receber alertas do Gitaly, o mesmo estava com picos de uso de memória que não eram liberados automaticamente após Backup diário.

Esse artigo se trata de um GitLab self hosted no EKS e o comportamento de alguns componentes do gitlab no Kubernetes.

Se você também roda GitLab em Kubernetes, vale entender o que realmente acontece — e por que o Cgroup v2 é a solução definitiva pra esse tipo de problema.

GITALY

O Gitaly é o componente do GitLab responsável por todas as operações Git, como clone, push, pull, merge, diff e blame. Ele isola o armazenamento dos repositórios da aplicação web e se comunica com os demais serviços via gRPC, otimizando a performance e o controle de concorrência.

┌─────────────────────┐
│ GitLab Webservice   │
│              │
└──────────┬──────────┘
           │ gRPC
           ↓
┌─────────────────────┐
│ Gitaly              │
│ - Git operations    │
│ - Repository access │
└──────────┬──────────┘
           ↓
┌─────────────────────┐
│ Persistent Volume   │
│ /home/git/repos     │
└─────────────────────┘

GITLAB TOOLBOX BACKUP

É um componente do Gitlab usado para realizar backups em ambientes Kubernetes (especificamente deployado usando helm charts). É um pod/container que contém ferramentas e scripts para executar operações de backup e restore do Gitlab. E quando ele aciona o Gitaly? durante o Backup dos repositórios.

-Conecta ao Gitaly via gRPC

-Solicita backup de cada repositório

-Recebe bundles Git do Gitaly

-Processa e comprime os dados

-Envia para algum object storage (S3, GCS, etc)

Durante a execução do cronjob gitlab-toolbox-backup na madrugada, observei um uso elevado de memória no pod do Gitaly. Esse consumo é causado pelo comportamento padrão do kernel Linux, que utiliza a RAM como cache de arquivos lidos do disco (page cache).

Em ambientes Kubernetes, esse comportamento pode gerar problemas de alocação de recursos, pois o kernel é compartilhado entre todos os pods do node.

Sintomas:

Alto uso de memória

Implicações críticas:

O kernel é único para todo o node
O Page Cache é global e compartilhado
CgroupsV1 apenas limitam quanto cada container pode usar
** O kernel não sabe o que é um "pod" ou "container" então se o Node tiver muita memória o Kernel vai considerar que tem memória disponível mesmo o pod estourando, pedindo pra morrer. **

┌─────────────────────────────────────────────────┐
│                     NODE       
│                                                 │
│  ┌──────────────────────────────────────────┐   │
│  │         KERNEL LINUX (único)             │   │
│  │  - Gerencia TODA a RAM do node           │   │
│  │  - Page Cache é COMPARTILHADO            │   │
│  │  - Não sabe o que é "pod"                │   │
│  └──────────────────────────────────────────┘   │
│                                                 │
│  ┌────────────┐  ┌────────────┐  ┌──────────┐   │
│  │  Pod A     │  │  Pod B     │  │  Pod C   │   │
│  │  (Gitaly)  │  │  (Redis)   │  │  (Web)   │   │
│  │            │  │            │  │          │   │
│  │  Vê:       │  │  Vê:       │  │  Vê:     │   │
│  │  Limit:8GB │  │  Limit:4GB │  │ Limit:2GB│   │
│  └────────────┘  └────────────┘  └──────────┘   │
│                                                 │
│  RAM Total: 32GB                                │
│  Cache Total: 20GB (visível para TODOS)         │
└─────────────────────────────────────────────────┘

Obs: Page Cache é a RAM usada pelo kernel para cachear arquivos do disco.

Fluxo de Backup

O que acontece?

Durante o backup (1h):

Gitaly lê centenas de repositórios Git
Kernel cacheia tudo: "Vou guardar esses arquivos .git na RAM"
Backup termina: Processo Gitaly volta ao normal (195MB)
Kernel não limpa: Cache fica marcado como "active_file" = 35.6GB
Kubernetes vê: Pod usando 37GB → perigo de OOM!

Por que não limpa automaticamente?

O cache está marcado como "active" (não "inactive"), então o kernel pensa:

"Esses arquivos foram usados recentemente"
"Provavelmente vão ser usados de novo em breve"
"Vou manter eles na RAM"
Mas como é um backup que roda 1x por dia, esses arquivos não vão ser usados de novo até amanhã!

Possíveis soluções estudadas:

Opção	Esforço	Benefício	Recomendação
Migrar para cgroup v2	Alto (reboot nodes)	Solução definitiva	A melhor opção
CronJob privilegiado	Baixo (15min)	Resolve o problema	se estiver com pressa
DaemonSet monitor	Médio (1h)	Automático	Opcional
Aumentar limite	Baixo	Paliativo	Só em emergência

Como podemos ver existem paliativos, porém a melhor opção a longo prazo é Cgroup V2. Só tem um pouco de complexidade para aplicar, mas mesmo assim se destaca pelos benefícios.

Dados do Cgroup V1 atual:

cache: 38829035520           # 36.2 GB !!!!!
rss: 204779520               # 195 MB
inactive_file: 568246272     # 542 MB
active_file: 38260654080     # 35.6 GB !!!!!


**35.6GB de `active_file`** = arquivos em cache ativo (page cache)!

Breakdown:
- Processo Gitaly (RSS): 195 MB
- Cache de arquivos ativos: 35.6 GB  ← AQUI!
- Cache de arquivos inativos: 542 MB
- Total cache: 36.2 GB
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Total do pod: ~37 GB

Cgroup V2

Cgroup V2 tem um recurso chamado PSI que detecta quando há "pressão" de memória:

# cgroup v2 expõe:
/sys/fs/cgroup/memory.pressure
# Conteúdo:
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

Quando há pressão, o kernel automaticamente libera cache mesmo que seja "active"!

Cgroup v2 é a segunda geração do sistema de control groups do kernel Linux, com melhorias significativas sobre o v1, atualmente o EKS do Gitlab está com Cgroup V1.

Cgroup v1 tem múltiplas hierarquias independentes (memory, cpu, io), causando inconsistências. Cgroup v2 usa uma única árvore:

Bom, é isso... tive a oportunidade de estudar sobre essa semana e quis compartilhar o conhecimento.

Docs: backup-restore
Kernel Tuning and Optimization for Kubernetes: A Guide
Linux Kernel Version Requirements

#DevOps para noobs - 3 Boas Práticas de Bancos de Dados para compartilhar com os Devs (AWS RDS)

Camila — Thu, 20 Feb 2025 20:51:20 +0000

Como evitar noites sem dormir, garantir que seu time consiga respirar durante incidentes e deixar o SRE do seu time feliz!

Conteúdo:

Índices com Concorrência: Seu SRE vai te amar <3!
Performance Insights: O "Raio-X" das Queries Lentas
Não use o Root: A arte de não ficar refém

1. Índices com Concorrência: Seu SRE vai te amar <3!

O Problema:

Imagine criar um índice em uma tabela de 500 GB em pleno horário de pico. O banco trava, as requisições começam a falhar, e o celular do SRE vibra sem parar com alertas de downtime. Ninguém quer ser essa pessoa.

A Solução:

Use CREATE INDEX CONCURRENTLY (PostgreSQL) ou ferramentas como pt-online-schema-change (MySQL). Isso permite criar índices sem bloquear operações de escrita.

-- Exemplo no PostgreSQL: o SRE continua dormindo  
CREATE INDEX CONCURRENTLY idx_pedidos_cliente ON pedidos (cliente_id);

2. Performance Insights: O "Raio-X" das Queries Lentas <3!

O Problema:

Uma query mal otimizada consome 90% da CPU do banco. O time de desenvolvimento não sabe por onde começar, e o SRE fica no escuro, tentando adivinhar o culpado.

A Solução:

Ative o Performance Insights no RDS. Ele mostra em tempo real:

Queries que consomem mais CPU.

Eventos de espera (ex: I/O, locks).

Queries com maior latência.

Como isso Ajuda o SRE?

Diagnóstico Rápido: Identifique o problema em minutos, não em horas.

Prevenção: Antecipa gargalos antes que virmem incidentes.

Colaboração com Devs: Mostra dados concretos facilitando melhorias em conjunto.

3. Não use o Root: A arte de não ficar refém

O Problema:

A aplicação está usando o usuário root e, durante um pico de tráfego, a CPU chega a 100%. Agora, ninguém consegue conectar ao banco para investigar… e o caos se instala.

O RDS tem um número máximo de conexões permitidas, definido pelo parâmetro max_connections (ex: PostgreSQL) ou max_user_connections (MySQL).
Se a aplicação já está usando todas as conexões disponíveis (ou a maioria), novas tentativas de login são bloqueadas — inclusive as do SRE. Ou seja, o usuário root é para privilégios maiores e emergências.

A Solução:

Crie um usuário dedicado para a aplicação, com permissões mínimas:

-- Exemplo no PostgreSQL:  
CREATE USER app_user WITH PASSWORD 'senhaSuperF0rt3!';  
GRANT SELECT, INSERT ON tabela_principal TO app_user;

Como isso Ajuda o SRE?

Acesso Garantido em Crise: Mesmo se a aplicação derrubar o banco, o SRE pode conectar com uma conta privilegiada para mitigar o problema.

Segurança sem Sacrifício: Reduza o risco de ataques e de acidentes (ex: DROP TABLE acidental por um microsserviço com privilégios demais).

Essas são as dicas de hoje, são apenas 3 mas quebram MUITO o galho!

well-architected
Site Reliability Engineering (Google Livro)

DynamoDB: Query x Scan! Para de torrar dinheiro usando Scan em produção

Camila — Mon, 28 Oct 2024 20:38:00 +0000

Como Economizei 50 mil dólares com DynamoDB!

Eu já consegui economizar 50 mil dólares, só mudando o tipo de leitura no DynamoDB. Mas antes de explicar como eu fiz isso, vamos aos conceitos!

Conteúdo:

O que é um DynamoDB?
Query: Procurando um Problema em um Servidor Específico
Scan: Procurando Problemas em Todos os Servidores?
Tipos de Leitura no DynamoDB
Custo de Leitura no DynamoDB
Resumo

O que é um DynamoDB?

O DynamoDB é um banco de dados NoSQL (chave-valor) da AWS. Quando você precisa buscar informações nele, existem duas maneiras principais de fazer isso: Query e Scan.

Imagine que sua empresa está usando o DynamoDB para armazenar informações de eventos de monitoramento dos servidores. Cada evento contém um ID de servidor, um timestamp e mensagens de log.

Query: Procurando um Problema em um Servidor Específico

O que é?
O Query funciona como uma busca direcionada. Você já sabe qual servidor e qual período precisa analisar, então faz uma busca direta por esses critérios.

Características:

Rápido e eficiente para buscas específicas.
Precisa de um ID de servidor (chave primária) e pode filtrar por timestamp (chave de classificação).

Exemplo de Query:
Imagine que você precisa verificar erros ocorridos no servidor ID_123 na última hora. Você faz a seguinte consulta:


Servidor: ID_123
Horário: Entre 10:00 e 11:00

O DynamoDB retorna apenas os eventos para o servidor específico no intervalo de tempo definido. Você lê apenas as linhas que interessam.

Scan: Procurando Problemas em Todos os Servidores

O que é?
O Scan é como uma varredura completa de todos os eventos. Se você quer procurar problemas gerais ou eventos de todos os servidores, precisa varrer a tabela inteira.

Características:

Lento e consome mais recursos, pois lê toda a tabela.
Ideal para buscas gerais, onde você não tem um ID específico.

Exemplo de Scan:
Agora, imagine que você precisa buscar erros de alta gravidade em todos os servidores ocorridos nas últimas 24 horas. Como não tem um ID de servidor específico, é necessário fazer um Scan com filtro:

Filtro: Gravidade do erro >= "Alto" e Horário >= "10:00 de ontem"

O DynamoDB varre todos os eventos de um em um de todos os servidores para aplicar o filtro e trazer os resultados.

Tipos de Leitura no DynamoDB

O DynamoDB cobra com base em unidades de leitura (RCU) e unidades de escrita (WCU) que você usa. Para entender os custos, é preciso conhecer:

RCU (Read Capacity Unit): Medida de capacidade de leitura. 1 RCU = 1 leitura eventual de até 4 KB por segundo.

Leitura Consistente:
1 unidade de leitura é suficiente para ler até 4 KB de dados com total precisão.
Sempre retorna dados mais recentes, bom para aplicações que não podem tolerar inconsistência.
Leitura Eventual:
1 unidade de leitura pode cobrir até 8 KB de dados, mas com uma chance de a informação estar ligeiramente desatualizada, o que consome menos RCU.

Custo de Leitura no DynamoDB

Agora a parte legal! 🎉

Obs: Os valores e informações a seguir são fictícios! 🚨

Observando o cenário da imagem abaixo:

Cenário Atual: Scan Completo

Quantidade de Itens na Tabela: 200.547 itens armazenados.
Tamanho da Tabela: 254,1 MB (convertido para 254.100 KB).
RCU (Unidade de Capacidade de Leitura): Cada unidade de leitura consegue processar 4 KB de dados.
ReadRequestUnits (Solicitações de Leitura): 64.483.473.398,00, que representa a quantidade de unidades de leitura necessárias. OBS: A cada 1 milhão de RRU's é consumida 1 RCU.

Resultado:
O custo total de leitura de toda a tabela foi de $15.650,87 no mês!

Mudança para Query: Cenário Otimizado

Antes, toda vez que a aplicação precisava consultar algo, ela consultava 100% da tabela usando Scan, percorrendo todos os itens até encontrar o que precisava.

Quando mudamos para Query, o cenário mudou. Agora, veja na tabela abaixo o impacto:

Se a consulta for feita em 10% da tabela, já há uma economia de $14.085,78.
Agora, imagine cenários em que as consultas são feitas em 1% da tabela ou até menos! É babado!

Resumo:

Query é como pedir uma lista específica de itens. Você paga apenas pelos dados que realmente lê.

Scan é como vasculhar uma caixa inteira para encontrar itens específicos. Você paga por todo o conteúdo da caixa, mesmo que precise de apenas algumas coisas.

Então, foi assim que consegui economizar 50 mil dólares mudando apenas a estratégia de leitura no DynamoDB! 😎

E aí, o que achou?

#Devops para noobs - Conhecendo Boto3 na prática

Camila — Fri, 26 Apr 2024 23:01:08 +0000

Ta, mas o que é o Boto3?

Boto3 é a biblioteca oficial da AWS (Amazon Web Services) para Python, que permite aos desenvolvedores interagir e acessar os serviços da AWS de forma programática.

É uma lib assistente que faz o trabalho de se comunicar com os serviços da AWS para você.

Na prática!

Em casos raros mas não impossíveis pode acontecer de você precisar recuperar um arquivo dentro de um Pod e enviar para um S3, aqui te ensino como fazer isso com o Boto3!

Bora lá!

Pré-requisitos
Antes de começar, certifique-se de que:

Você tem acesso ao cluster Kubernetes onde seu Pod está implantado.
Possui as credenciais de acesso válidas para interagir com o Amazon S3.

Passo 1:
Instalar o Boto3 no pod. Se não estiver instalado, você pode instalar utilizando o pip:

pip install boto3

Passo 2:
Importe a biblioteca do Boto3 e configure as credenciais AWS.

import boto3

from botocore.exceptions import NoCredentialsError
s3 = boto3.client('s3',
                  aws_access_key_id='YOUR_ACCESS_KEY_ID',
                  aws_secret_access_key='YOUR_SECRET_ACCESS_KEY')

Passo 3:
Defina o caminho do arquivo dentro do Pod que você deseja enviar para o S3.

local_file = 'caminho/do/seu/arquivo.txt'

Passo 4:
Especifique o nome do bucket no Amazon S3 onde você deseja enviar o arquivo e o nome que ele terá no bucket.


# Nome do bucket s3 de destino 
bucket = 'nome-do-seu-bucket'

# Nome do arquivo que irá para o bucket de destino
s3_file = 'nome-do-seu-arquivo.txt'

Passo 5:

Use o método upload_file para enviar o arquivo para o bucket especificado no passo 4.

try:
    s3.upload_file(local_file, bucket, s3_file)
    print("Upload do arquivo para o Amazon S3 realizado com sucesso!")
except FileNotFoundError:
    print("Arquivo não encontrado.")
except NoCredentialsError:
    print("Credenciais AWS inválidas.")

Para mais detalhes sobre o Boto3: Doc oficial

Por hoje é isso! beijos de luz

#DevOps para noobs - Proxy Reverso

Camila — Sat, 17 Feb 2024 18:37:10 +0000

Já ouviu falar de proxy reverso? Vem cá que eu vou tentar te explicar!

Conteúdo:

O que é Proxy?
Exemplo: Proxy anônimo
Proxy Reverso
Exemplo: Proxy Reverso
Segurança
Conclusão

O que é Proxy?

Um proxy é como um intermediário entre o seu computador e a internet. Quando você quer acessar algo na internet, em vez de se conectar diretamente, você se conecta através do proxy, que então faz a solicitação em seu nome. Quando a resposta é recebida, o proxy a envia de volta para você.

Existem diversos tipos de Proxy!

Exemplo: proxy anônimo

Suponha que você queira acessar o google, mas não quer que o site saiba o seu endereço IP real. Em vez de se conectar diretamente ao site, você pode usar um proxy anônimo.

Então, um proxy basicamente age como um "intermediário" entre você e a internet, sendo usado por razões como segurança, controle de acesso ou anonimato.

Proxy Reverso

Suponha que uma empresa tenha três servidores internos, cada um hospedando um site diferente: "site1.com", "site2.com" e "site3.com". Eles configuram um servidor proxy reverso para lidar com o tráfego externo.

Exemplo:

Um cliente externo tenta acessar "site1.com" digitando o endereço no navegador.
A solicitação do cliente é recebida pelo servidor proxy reverso.
O servidor proxy reverso encaminha a solicitação para o servidor interno que hospeda "site1.com".
O servidor interno processa a solicitação e envia a resposta de volta para o servidor proxy reverso.
O servidor proxy reverso recebe a resposta do servidor interno e a envia de volta para o cliente externo.

Essa configuração permite que a empresa hospede vários sites em servidores internos e forneça acesso externo a eles através de um único ponto de entrada (o proxy reverso).

Segurança:

Um proxy reverso está localizado do lado do servidor diferente do proxy normal que está do lado do cliente. Isso significa que ele fica entre os servidores e a internet, protegendo os servidores internos.

Além disso, o proxy reverso pode ser configurado para oferecer recursos adicionais, como balanceamento de carga, cache de conteúdo, criptografia SSL e filtragem de solicitações para melhorar a segurança e o desempenho.

Conclusão:

O proxy é tipo um guardião da internet, protegendo você de sites perigosos, escondendo sua identidade online, e até mesmo driblando bloqueios de sites. Além disso, ele pode acelerar o carregamento de páginas que você visita com frequência e manter um olho nas atividades online dos funcionários em empresas.

Ah, e tem também o proxy reverso, que ajuda a equilibrar o tráfego entre diferentes servidores e a manter seus sites funcionando rápido e seguro.

The end.

Obrigada quem leu até aqui <3 beijos de luz

#DevOps para noobs - Requests x limits no Kubernetes

Camila — Mon, 05 Feb 2024 23:34:53 +0000

No universo do Kubernetes, é essencial não apenas implantar suas aplicações, mas também gerenciar eficientemente os recursos que elas consomem.

Para isso, o Kubernetes oferece recursos como limits (limites) e requests (requisições), que permitem especificar tanto o mínimo quanto o máximo de recursos que uma aplicação pode utilizar. Vamos explorar esses conceitos neste artigo.

O que são Limits e Requests?

Em termos simples, os limits representam a quantidade máxima de recursos, como CPU e memória, que um container pode consumir. Por outro lado, as requests indicam a quantidade mínima de recursos que devem ser reservados para o container.

No YAML de um Pod, podemos definir esses valores da seguinte forma:

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
   ** resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"**

Neste exemplo, especificamos que nossa aplicação requer no mínimo 64 megabytes de memória e 250 milicores de CPU, enquanto o limite máximo é de 128 megabytes de memória e 500 milicores de CPU, ou seja no limit deixamos uma "brecha" caso ultrapassemos a quantidade de consumo definida no request.

Por que são importantes?

Ao definir esses valores, estamos dando informações valiosas ao Kubernetes Scheduler, que utiliza esses dados para decidir em qual nó do cluster a aplicação será implantada. Isso garante que a aplicação tenha os recursos necessários para funcionar adequadamente.

Kubernetes Scheduler

Sua função principal é selecionar os nós (nodes) do cluster nos quais os pods serão implantados. Isso é feito com base nos requisitos de recursos dos pods, como CPU e memória.

Gerenciando Recursos Excedentes

Mas e se nossa aplicação exceder os limites definidos?

Throttling (Estrangulamento):
O Kubernetes pode limitar a quantidade de recursos disponíveis para o container, o que pode resultar em um desempenho reduzido ou mais lento para a aplicação.
Termino do Container: Em situações extremas, se uma aplicação consistentemente consome mais recursos do que o especificado em seus limites, o Kubernetes pode decidir terminar ou reiniciar o container. Isso é feito para proteger a integridade do cluster e garantir que outras aplicações tenham acesso aos recursos necessários.

Conclusão

Estabelecer limites e requisitos adequados para suas aplicações Kubernetes é crucial para garantir um desempenho eficiente e estável do cluster. Ao entender e utilizar corretamente esses recursos, você pode maximizar a utilização dos recursos disponíveis e garantir uma operação tranquila das suas aplicações no Kubernetes.

Referências:

Dicas que usei para conseguir o primeiro emprego em T.I!

Camila — Mon, 17 Oct 2022 17:44:36 +0000

Oie! Eu sou a Camila, sou trainee SRE/DevOps e trabalho na área da tecnologia há dois anos! O meu grande aliado no primeiro emprego foi o Linkedin, então fique aqui para entender como a plataforma me ajudou no meu primeiro emprego e no atual!

1 - Coloque os cursos que você está estudando, poste certificados, projetos finalizados etc! isso é o básico, você precisa ser visto!

2 - Palavras-Chaves: Recrutadores estão muito ocupados tentando preencher vagas e não vão ler textões, eles querem ir direto ao ponto!

No seu perfil você precisa colocar a stack que está estudando ou atuando, mas lembre-se das palavras-chaves!

Alguns exemplos:

3 - Bio: Resuma! Qual stack você estuda? Quais projetos e skills você possui? Exemplo:

4 - Networking! Você precisa adicionar pessoas, Tech recruiters, influencers da área, lembrem-se você precisa ser visto ou seja, entra em contato com pessoas da área, você quer entrar em alguma empresa? Já pensou em entrar em contato com funcionários dessa empresa pra pedir dicas de processo seletivo ou como se preparar? Existem muitas pessoas dispostas a te ajudar! Eu juro!

Eu tenho mais de +500 pessoas adicionadas, eu conheço tudo isso? Não! mas adicionar tech recruiters, pessoas da área ajudou e ajuda meu perfil a ter mais visibilidade!

5 - Currículo: Tenha um currículo! Aí meu deus mas não tenho experiência o que eu coloco? O que você estuda, seus projetos, github!!!!!
Meu primeiro currículo em T.I:

Como eu consegui meu primeiro estágio com esse currículo? NETWORKINNNNNNNG!
SIM! Eu postei esse currículo no linkedin com a legenda descrevendo que eu estava a procura de uma primeira oportunidade e sabe o que aconteceu? Uma moça X que tinha bastante visibilidade no linkedin com conteúdos tech compartilhou, fazendo chegar em diversos perfis! Na mesma semana 3 empresas entraram em contato comigo e consegui meu primeiro estágio!

Linkedin Premium para estudantes: aqui!

Links de artigos maneiros que podem te ajudar no seu processo inicial no mercado de T.I:
Programaria: Processos Seletivos
Programaria: Comunicação

Participe da He4rt! Comunidade gigante, com pessoas incríveis e muito conteúdo para te ajudar a entrar no mercado e aprender conteúdos tech!