Neste documento você vai encontrar as seguintes seções:
Agradecimentos
Introdução
Premissas
- Ambiente e Ferramentas
- Conhecimento Técnico
- Swap
Avisos
- Riscos
- Monitoramento
Isenção de Responsabilidade
Ajustes e Informações para Sistema Operacional Linux
1. Otimização de Rede
- net.core.somaxconn (Fila de Conexões Pendentes)
- net.ipv4.tcp_max_syn_backlog (Fila de Conexões Incompletas)
- net.ipv4.icmp_echo_ignore_broadcasts
- net.ipv4.tcp_tw_reuse
- net.ipv4.tcp_fin_timeout
2. Gerenciamento de Memória
- vm.overcommit_memory (Política de Alocação de Memória)
- vm.dirty_ratio e vm.dirty_background_ratio (Escrita de Dados em Disco)
3. Outros Ajustes Importantes
- fs.file-max (Número Máximo de Arquivos Abertos)
- fs.inotify.max_user_watches (Monitoramento de Eventos em Arquivos)
4. Observação
Ajustes e Informações para Kubernetes
- Gerenciamento de Recursos (Pods e Containers)
- Agendamento (Scheduler)
- Otimização e Escalabilidade do Cluster
Ajustes e Informações para Rancher
- Otimização do Servidor Rancher
- Otimização dos Clusters Gerenciados
Otimização Avançada e Segurança
- Aprimorando a Observabilidade com SUSE Observability
- Garantindo a Segurança com NeuVector
- Validação de Conformidade e Segurança com CIS Benchmarks
- Integração com o Rancher
Referências Adicionais
Log de Alterações
Agradecimentos
Um agradecimento especial aos amigos por suas valiosas contribuições e dedicação. A qualidade e a profundidade deste guia foram significativamente aprimoradas pelas ideias, sugestões de conteúdo e tempo dedicado por Erico Mascarenhas Mendonça, Mauricio Alves da Silva Perez e Robson Dobzinski. O conhecimento e a disponibilidade de vocês foram fundamentais para a criação de um documento robusto e preciso, que servirá como uma ferramenta essencial para a comunidade.
Introdução
Ajustes de performance em ambientes Kubernetes são cruciais para garantir a estabilidade, eficiência e o uso otimizado dos recursos. A otimização do Kubernets pode ser dividida em três áreas principais: gerenciamento de recursos, agendamento de pods e otimização do cluster. A documentação oficial do Kubernetes é a fonte mais confiável para entender como otimizar cada um dos componentes. Este guia aborda não apenas os ajustes específicos do Kubernetes e Rancher, mas também a otimização do kernel Linux, a camada fundamental que suporta toda a infraestrutura.
Premissas
Ambiente e Ferramentas: Este guia assume a utilização de servidores com sistema operacional Linux, utilizando Kubernetes e a plataforma Rancher.
Conhecimento Técnico: O guia é destinado a usuários com conhecimento prévio em administração de sistemas Linux e Kubernetes. É fundamental que o leitor entenda a importância de monitorar o sistema para validar os efeitos das mudanças propostas, especialmente as que envolvem a infraestrutura subjacente, Linux.
Swap: É uma premissa fundamental que a swap esteja desativada nos nodos Kubernetes para garantir a previsibilidade e a correta alocação de recursos.
Avisos
Riscos: A modificação de parâmetros do kernel pode levar à instabilidade do sistema se não for feita com cautela e conhecimento. As configurações ideais variam muito dependendo da carga de trabalho específica de cada aplicação.
Monitoramento: Antes e depois de cada ajuste, é essencial monitorar o comportamento dos clusters para identificar gargalos e validar as mudanças.
Isenção de Responsabilidade
Este guia de ajustes e otimizações é fornecido apenas para fins informativos e educacionais. As informações contidas aqui são baseadas em boas práticas e documentação disponível publicamente, mas não constituem uma garantia de resultados específicos. A aplicação de qualquer um dos ajustes propostos pode impactar o desempenho, a segurança e a estabilidade do seu ambiente. Tais modificações devem ser realizadas por profissionais qualificados, que compreendam completamente os riscos e as consequências. O autor e os contribuidores deste guia não se responsabilizam por quaisquer danos, perdas de dados, interrupções de serviço ou quaisquer outros problemas que possam surgir como resultado da aplicação dessas informações. É sua responsabilidade total validar, testar e monitorar quaisquer alterações em um ambiente de não-produção antes de implementá-las em produção.
Ajustes e Informações para Sistema Operacional Linux
1. Otimização de Rede: Esses ajustes ajudam o sistema a lidar com um grande número de conexões simultâneas e picos de tráfego, essenciais para a comunicação entre pods e serviços.
net.core.somaxconn (Fila de Conexões Pendentes): Define o número máximo de conexões em espera que o sistema pode enfileirar em um soquete. O valor padrão costuma ser baixo (128). Em ambientes com alto tráfego de rede, aumentar esse valor evita que novas conexões sejam recusadas por falta de espaço na fila.
sysctl -w net.core.somaxconn=65535Os valores atuais podem ser observados das seguintes formas:
sysctl net.core.somaxconnou
cat /proc/sys/net/core/somaxconnnet.ipv4.tcp_max_syn_backlog (Fila de Conexões Incompletas): Define o número máximo de solicitações de conexão TCP que ainda não concluíram o handshake de três vias (estado SYN_RECV). Um valor maior é essencial para mitigar ataques de SYN flood e para garantir que o servidor possa processar um grande número de novas conexões de forma eficiente.
sysctl -w net.ipv4.tcp_max_syn_backlog=65535Os valores atuais podem ser observados das seguintes formas:
sysctl net.ipv4.tcp_max_syn_backlognet.ipv4.icmp_echo_ignore_broadcasts: Este ajuste é uma prática padrão de segurança. Ao ignorar pacotes de eco ICMP (ping) enviados para endereços de broadcast, o sistema se protege contra ataques de Smurf e reduz a probabilidade de se tornar um "amplificador" de ataques de negação de serviço (DoS). Desabilitar a resposta a pings de broadcast não afeta a funcionalidade de ping de endereços IP individuais e é considerado uma prática de segurança robusta. Apenas em ambientes de rede muito específicos que dependem de pings de broadcast para monitoramento isso poderia ser um problema, mas esses casos são incomuns.
sysctl -w net.ipv4.icmp_echo_ignore_broadcasts = 1Os valores atuais podem ser observados das seguintes formas:
sysctl net.ipv4.icmp_echo_ignore_broadcastsnet.ipv4.tcp_tw_reuse: O parâmetro permite que um socket em estado TIME_WAIT seja reutilizado para uma nova conexão de saída. Isso é particularmente útil em servidores proxy, balanceadores de carga e outros sistemas que realizam um grande número de conexões de saída rapidamente. Ele evita o esgotamento de portas efêmeras, que poderia levar a erros de "conexão recusada" ou "endereço já em uso".
sysctl -w net.ipv4.tcp_tw_reuse = 1Os valores atuais podem ser observados das seguintes formas:
sysctl net.ipv4.tcp_tw_reusenet.ipv4.tcp_fin_timeout: Este parâmetro controla o tempo que um socket TCP fica no estado FIN-WAIT-2 quando a conexão está sendo encerrada. O valor padrão é 60 segundos. Reduzir esse tempo para 30 segundos (ou até menos, dependendo do ambiente) pode liberar sockets e recursos do sistema mais rapidamente. Geralmente, não causa problemas se o ambiente for estável. No entanto, em redes com alta latência ou com perda de pacotes, reduzir esse timeout pode fazer com que a conexão seja encerrada prematuramente, resultando em dados não entregues. A recomendação padrão é geralmente de 30 segundos, mas o ajuste deve ser feito com base no monitoramento do tráfego da rede.
sysctl -w net.ipv4.tcp_fin_timeout = 30Os valores atuais podem ser observados das seguintes formas:
sysctl net.ipv4.tcp_fin_timeout2. Gerenciamento de Memória
Com a swap desativada, a otimização de memória se concentra em como o kernel lida com a escrita de dados para o disco, uma vez que a memória virtual é limitada pela RAM física.
vm.overcommit_memory (Política de Alocação de Memória): Controla a maneira como o kernel lida com a alocação de memória. Um valor de 1 permite que o kernel "superaloque" memória, prometendo mais do que realmente tem, esperando que nem todos os processos a usem. No Kubernetes, que já tem seus próprios mecanismos de alocação de recursos, este ajuste pode ser útil para evitar que a alocação de memória falhe em processos que solicitam uma grande quantidade de memória, mas que não a utilizam imediatamente.
sysctl -w vm.overcommit_memory=1Os valores atuais podem ser observados das seguintes formas:
sysctl vm.overcommit_memoryvm.dirty_ratio e vm.dirty_background_ratio (Escrita de Dados em Disco): Controlam o percentual de memória que pode ser usada para dados "sujos" (modificados) antes que o kernel comece a escrevê-los para o disco. O valor dirty_background_ratio (5% da RAM) define quando o kernel inicia a escrita em segundo plano. O dirty_ratio (10% da RAM) define um limite rígido onde o processo que está gerando a escrita será bloqueado até que os dados sejam liberados.
Exemplo: Em um nó com 16GB de RAM, dirty_background_ratio de 5% equivale a 800MB. O dirty_ratio de 10% equivale a 1.6GB.
sysctl -w vm.dirty_background_ratio=5sysctl -w vm.dirty_ratio=10Os valores atuais podem ser observados das seguintes formas:
sysctl vm.dirty_background_ratio sysctl vm.dirty_ratioou
cat /proc/sys/vm/dirty_ratio3. Outros Ajustes Importantes
fs.file-max (Número Máximo de Arquivos Abertos): Define o limite máximo de descritores de arquivo que o sistema pode alocar para todos os processos. É um ajuste fundamental para servidores, pois cada conexão de rede, arquivo e soquete consome um descritor de arquivo. Aumentar esse limite evita erros de "too many open files".
sysctl -w fs.file-max=65535 # (ou um valor mais alto, dependendo da necessidade).Os valores atuais podem ser observados das seguintes formas:
sysctl fs.file-maxfs.inotify.max_user_watches (Monitoramento de Eventos em Arquivos): Limita o número de arquivos que um usuário pode "observar" para eventos (como mudanças, criações, etc.). Ferramentas de desenvolvimento e monitoramento em contêineres que dependem de inotify podem falhar se esse limite for atingido, então é uma boa prática aumentá-lo.
sysctl -w fs.inotify.max_user_watches=524288 # (ou um valor superior, se necessário).Os valores atuais podem ser observados das seguintes formas:
sysctl fs.inotify.max_user_watches4. Observação:
A modificação de parâmetros do kernel feita diretamente com sysctl -w é temporária e não sobrevive a um reboot. Para que as configurações persistam, é necessário registrá-las em um arquivo de configuração.
Por que as Alterações Não Persistem
Quando você usa sudo sysctl -w <parâmetro>=<valor>, o comando altera o valor em tempo de execução na memória do kernel. No entanto, essa mudança não é salva em nenhum arquivo de configuração. Assim que o sistema é reiniciado, ele carrega os valores padrão ou aqueles definidos nos arquivos de configuração do sistema, perdendo as alterações que você fez manualmente.
Como Fazer os Ajustes Persistirem
A maneira padrão de garantir que as configurações do sysctl persistam após a reinicialização é editando o arquivo /etc/sysctl.conf ou criando arquivos de configuração específicos dentro do diretório /etc/sysctl.d/.
Opção 1: Editando /etc/sysctl.conf (Recomendado para poucas alterações): Este é o método mais comum para configurações simples. Você pode adicionar os parâmetros e seus valores diretamente ao final do arquivo:
- Abra o arquivo com um editor de texto, como o vim:
vim /etc/sysctl.conf- Adicione as linhas dos seus ajustes no final do arquivo:
# Otimização de Rede
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Gerenciamento de Memória
vm.overcommit_memory = 1
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
# Outros Ajustes Importantes
fs.file-max = 65535
fs.inotify.max_user_watches = 524288- Salve e feche o arquivo.
Opção 2: Criando um Arquivo em /etc/sysctl.d/ (Recomendado para clusters Kubernetes): Criar um arquivo dedicado no diretório /etc/sysctl.d/ é uma abordagem mais organizada, especialmente em ambientes automatizados ou de produção, pois evita modificar arquivos de sistema existentes.
- Crie um novo arquivo com um nome descritivo (ex: 99-kubernetes.conf):
vim /etc/sysctl.d/99-kubernetes.confO prefixo 99- garante que o arquivo seja lido por último, caso haja alguma sobreposição de valores.
- Adicione os parâmetros e seus valores ao arquivo:
# Otimização de Rede
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Gerenciamento de Memória
vm.overcommit_memory = 1
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
# Outros Ajustes Importantes
fs.file-max = 65535
fs.inotify.max_user_watches = 524288- Salve e feche o arquivo.
Aplicando as Mudanças Permanentemente
Depois de salvar o arquivo de configuração, você deve aplicar as mudanças imediatamente sem precisar reiniciar o sistema. Para isso, use o comando sysctl -p:
sysctl -p /etc/sysctl.d/99-kubernetes.confou
sysctl -pO comando sysctl -p (sem especificar o arquivo) carregará todas as configurações dos arquivos em /etc/sysctl.d/ e /etc/sysctl.conf. Isso garante que suas alterações sejam aplicadas e permaneçam ativas mesmo após um reinício futuro do servidor.
5. Referências Adicionais:
Documentação oficial do Kubernetes sobre Requisitos de Runtime
https://kubernetes.io/docs/setup/production-environment/container-runtimes/
Ajustes e Informações para Kubernetes
1. Gerenciamento de Recursos (Pods e Containers)
Esta é a área mais crítica para o tuning de aplicações. A configuração correta de requests e limits evita a subutilização ou a sobrecarga dos nós.
Requests e Limits de CPU e Memória:requests: Define a quantidade de recursos (CPU e memória) que um contêiner necessita. O agendador do Kubernetes usa esses valores para decidir em qual nó o pod será executado. Se um nó não tiver recursos suficientes para atender ao request de um pod, o pod permanecerá no estado Pending.limits: Define o limite máximo de recursos que um contêiner pode usar. Se um contêiner tentar usar mais memória do que o seu limit, ele será encerrado pelo sistema (OOMKill). Se ele exceder o limit de CPU, o uso será "limitado" ou "throttled", o que pode impactar a performance.
Fonte Oficial: Gerenciamento de Recursos para Pods e Containers
https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
2. Agendamento (Scheduler)
O kube-scheduler é o componente responsável por atribuir pods a nós. Seu desempenho pode ser ajustado em clusters muito grandes. Para clusters com milhares de nós, você pode ajustar o parâmetro percentageOfNodesToScore. Ele controla a porcentagem de nós que o agendador irá analisar antes de parar e escolher o melhor nó. O valor padrão é calculado com base no tamanho do cluster, mas pode ser ajustado.
Fonte Oficial: Tuning de Performance do Agendador
https://kubernetes.io/docs/concepts/scheduling-eviction/scheduler-perf-tuning/
3. Otimização e Escalabilidade do Cluster
Esses ajustes visam garantir que o cluster responda dinamicamente às demandas de workload. Horizontal Pod Autoscaling (HPA): O HPA automaticamente escala o número de réplicas de um pod (deployments, replica sets) com base no uso de CPU, memória ou métricas personalizadas.
Fonte Oficial: Horizontal Pod Autoscaling
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
Cluster Autoscaler: O Cluster Autoscaler ajusta o número de nós do cluster com base na demanda de recursos dos pods pendentes. Ele adiciona mais nós quando o agendador não consegue alocar pods e os remove quando os nós estão subutilizados.
Disruption Budgets (PDB): Os PDBs garantem que um número mínimo ou uma porcentagem de réplicas de uma aplicação esteja disponível durante interrupções voluntárias, como atualizações de nós ou manutenções.
Fonte Oficial: Configurando Pod Disruption Budgetshttps://kubernetes.io/docs/concepts/workloads/pods/disruptions/
Probes (Liveness e Readiness):Liveness Probe: Verifica se o contêiner está em execução. Se falhar, o kubelet reinicia o contêiner.
Readiness Probe: Determina se o contêiner está pronto para receber tráfego. O serviço só direciona tráfego para os pods que estão Ready.
Fonte Oficial: Configurar Liveness, Readiness e Startup Probes
Ajustes e Informações para Rancher
O Rancher é uma plataforma de gerenciamento de Kubernetes que simplifica a operação de múltiplos clusters. O tuning do Rancher se concentra em otimizar o próprio servidor Rancher e a comunicação com os clusters gerenciados.
1. Otimização do Servidor Rancher
O desempenho do Rancher Server (o painel de controle) depende de alguns fatores.
Requisitos de Recursos: A documentação oficial do Rancher oferece diretrizes para os requisitos de CPU e memória do servidor, que variam com o número de clusters, usuários e projetos.
Latência de Rede: Reduzir a latência entre o servidor Rancher e os clusters gerenciados é crucial. Para ambientes distribuídos globalmente, pode ser mais eficiente ter múltiplas instalações do Rancher Server.
Fonte Oficial: Tuning e Boas Práticas para Rancher em Escala
2. Otimização dos Clusters Gerenciados
Embora o Rancher simplifique a instalação e gerenciamento, os ajustes de tuning do próprio Kubernetes ainda se aplicam.
Manter a Versão Atualizada: A Rancher Labs lança constantemente novas versões com melhorias de performance e segurança. Manter o Rancher e o Kubernetes nos clusters gerenciados atualizados é uma boa prática.
Monitoramento e Observabilidade: Use as ferramentas de monitoramento integradas ao Rancher (como Prometheus e Grafana) para observar o comportamento dos clusters e identificar gargalos. Isso é essencial para guiar qualquer estratégia de tuning.
Otimização Avançada e Segurança
1. Aprimorando a Observabilidade com SUSE Observability
A capacidade de monitorar o ambiente é crucial para qualquer estratégia de tuning. O SUSE Observability, que inclui o Prometheus e Grafana, fornece as ferramentas necessárias para visualizar o comportamento do seu cluster em tempo real. Com ele, você pode:
- Monitorar o consumo de recursos dos pods e nodos para validar os requests e limits de forma precisa.
- Identificar gargalos de I/O de disco e de rede para otimizar os ajustes de kernel.
- Analisar a performance do kube-scheduler e o comportamento do Cluster Autoscaler para ajustar o escalonamento de forma mais eficaz.
2. Garantindo a Segurança com NeuVector
A segurança é uma premissa fundamental em ambientes de produção. O NeuVector é uma plataforma de segurança de contêineres que oferece uma proteção completa, desde a fase de build até a execução. O NeuVector complementa essas medidas ao fornecer:
- Visibilidade em tempo real do tráfego de rede e do comportamento dos contêineres.
- Prevenção de intrusões e de ataques, detectando e bloqueando atividades suspeitas na rede do cluster.
- Análise de vulnerabilidades em imagens de contêiner e no ambiente de execução."
3. Validação de Conformidade e Segurança com CIS Benchmarks
O Center for Internet Security (CIS) é uma organização globalmente reconhecida que fornece benchmarks de segurança, que são um conjunto de diretrizes de configuração para endurecer sistemas de TI contra ameaças cibernéticas. A conformidade com o CIS é uma premissa fundamental em ambientes de produção. As soluções da SUSE ajudam a validar e manter essa conformidade.
O CIS Benchmark é uma lista de verificações e recomendações de configuração que ajudam a proteger clusters Kubernetes e seus componentes contra as vulnerabilidades de segurança mais comuns. O endurecimento (hardening) de um cluster envolve a configuração de vários parâmetros para limitar o acesso e o comportamento de componentes, como a API do Kubernetes e os kubelets nos nós.
O guia de hardening do RKE2, por exemplo, é baseado nos padrões do CIS. Ferramentas como o Rancher e o RKE2 oferecem guias de autoavaliação (self-assessment) que permitem validar se a sua instalação está em conformidade com as diretrizes do CIS.
4. Integração com o Rancher:
Ao criar um novo cluster no Rancher, é possível selecionar um perfil de CIS para aplicá-lo automaticamente, garantindo que o cluster já nasça com uma postura de segurança reforçada desde o início da implantação.
Para um guia visual de como proceder com essa configuração no Rancher, você pode assistir ao vídeo [ https://youtu.be/0uMbGO6ApGc ] "CIS Benchmarks para Kubernetes com SUSE Rancher e NeuVector", no canal Cowmeleon, no YouTube. O vídeo criado por Erico Mascarenhas Mendonça, arquiteto de soluções na SUSE, e explica o que são os CIS Benchmarks para Kubernetes e demonstra como usar um plugin do Rancher, que utiliza o projeto Cube Bench, para rodar scans de conformidade. Ele também mostra como os resultados dos testes de conformidade são exibidos na interface do Rancher e do SUSE NeuVector, facilitando a identificação de pontos de melhoria na segurança.
Os clusters gerenciados pelo Rancher, especialmente os baseados em RKE2, são projetados para simplificar a conformidade com o CIS. Os guias de hardening e autoavaliação do CIS para RKE2 fornecem um checklist para auditar e garantir a segurança do seu ambiente.
Enquanto o CIS foca na conformidade da infraestrutura, o NeuVector complementa essa abordagem oferecendo uma segurança de tempo de execução, monitorando o comportamento do tráfego de rede e detectando atividades maliciosas em tempo real. Juntos, eles fornecem uma postura de segurança robusta, cobrindo tanto a configuração estática (CIS) quanto a segurança dinâmica (NeuVector).
Maiores detalhes podem ser vistos em:
https://docs.rke2.io/security/cis_self_assessment19
https://docs.rke2.io/security/cis_self_assessment18
https://docs.rke2.io/security/cis_self_assessment17
Referências Adicionais
Kubernetes Blog: Tuning Linux Swap for Kubernetes: A Deep Dive
Este artigo aprofunda a discussão sobre a desativação do swap em ambientes Kubernetes, explicando as razões técnicas por trás da recomendação e como ela impacta o agendamento de pods e a alocação de recursos.
https://kubernetes.io/blog/2025/08/19/tuning-linux-swap-for-kubernetes-a-deep-dive/
Rancher Manager Docs: Tuning and Best Practices for Rancher at Scale
Um guia oficial que oferece diretrizes detalhadas e boas práticas para otimizar o desempenho do servidor Rancher em larga escala, abordando requisitos de recursos, latência de rede e configurações avançadas.
SUSE Rancher Docs: Tuning etcd for Large Installations
Este documento foca na otimização do etcd, o banco de dados de chave-valor do Kubernetes. Ele é essencial para clusters grandes, pois um etcd otimizado melhora a performance e a estabilidade geral do cluster.
RKE2 Docs: Installation Configuration
A documentação de configuração de instalação do RKE2, útil para entender os parâmetros e as opções disponíveis durante a instalação e configuração de um cluster RKE2.
https://docs.rke2.io/install/configuration
RKE2 Docs: Server Configuration
Uma referência detalhada de todos os parâmetros de configuração do servidor RKE2, crucial para a customização e o tuning do cluster.
https://docs.rke2.io/reference/server_config
RKE2 Docs: Installation Requirements
Documento que lista todos os requisitos de sistema e hardware para uma instalação bem-sucedida do RKE2.
https://docs.rke2.io/install/requirements
RKE2 Docs: Basic Network Options
Um guia para configurar as opções de rede básica no RKE2, incluindo a escolha e a configuração de plugins de rede de contêiner (CNIs).
https://docs.rke2.io/networking/basic_network_options
RKE2 Docs: SELinux
Documento que explica como o RKE2 interage com o SELinux e fornece orientações para a configuração correta, garantindo a segurança sem comprometer o funcionamento do cluster.
https://docs.rke2.io/security/selinux
RKE2 Docs: Hardening Guide
Um guia de hardening de segurança que detalha as melhores práticas para reforçar a segurança de um cluster RKE2.
https://docs.rke2.io/security/hardening_guide
RKE2 Docs: CIS Self-Assessment
Documento de autoavaliação com base no CIS Benchmark, útil para validar se a sua instalação RKE2 está em conformidade com as diretrizes de segurança.
https://docs.rke2.io/security/cis_self_assessment19
RKE2 Docs: CIS Self-Assessment (versões 1.8 e 1.7)
Versões mais antigas dos guias de autoavaliação do CIS, que podem ser úteis para validar clusters que ainda rodam em versões mais antigas do Kubernetes.
https://docs.rke2.io/security/cis_self_assessment18
e
https://docs.rke2.io/security/cis_self_assessment17
Criado em: 26/08/2025
Atualizado em: 02/09/2025