Guia

Estabeleça o princípio central para uma equipe de plataforma garantir a adoção e reduzir o atrito do desenvolvedor.

→Trate a plataforma interna como um produto. Trate os desenvolvedores internos como clientes, conduza pesquisas de usuário, colete feedback e itere sobre recursos para reduzir sua carga cognitiva.

Por quê: Essa mentalidade muda o foco da construção de infraestrutura para a entrega de valor, garantindo que a plataforma resolva problemas reais dos desenvolvedores e não seja ignorada ("shadow IT").

Estabeleça uma única fonte de verdade para o estado desejado de toda a infraestrutura e aplicações.

→Use repositórios Git como a única fonte de verdade. Implante um agente no cluster (ArgoCD, Flux) que executa um loop de reconciliação contínuo para comparar o estado do cluster com o Git.

Por quê: Isso fornece um rastro de auditoria completo, permite rollbacks fáceis e previne o desvio de configuração, revertendo automaticamente as alterações fora da banda.

Referência↗

Evite o desvio de configuração e garanta a consistência dos artefatos implantados em todos os ambientes.

→Trate a infraestrutura como imutável. Nunca modifique recursos em execução. Em vez disso, crie artefatos novos e versionados (imagens de contêiner, imagens de VM) e substitua os antigos. Force isso com sistemas de arquivos de contêiner somente leitura (`readOnlyRootFilesystem: true`).

Por quê: A imutabilidade elimina o desvio de configuração e torna as implantações previsíveis e repetíveis. "Substitua, não repare."

Escolha um modelo de implantação GitOps seguro, especialmente em ambientes de multi-cluster ou rede restrita.

→Implemente um modelo pull-based. Um agente (ArgoCD, Flux) em execução dentro do cluster puxa os manifestos do Git. Evite modelos push-based onde um sistema CI externo envia para a API do Kubernetes.

Por quê: Os modelos pull-based são mais seguros, pois não exigem a exposição do servidor API do Kubernetes externamente ou o gerenciamento de credenciais para múltiplos clusters no CI.

Acelere o desenvolvimento e garanta as melhores práticas sem restringir excessivamente equipes experientes.

→Defina "golden paths" (ou caminhos pavimentados): modelos e fluxos de trabalho pré-configurados e bem suportados para tarefas comuns (por exemplo, criação de um novo microsserviço).

Por quê: Os golden paths reduzem a carga cognitiva e a fadiga de decisão para 80% dos casos, mas ainda devem permitir "saídas de emergência" para equipes de especialistas com requisitos únicos.

Forneça multi-tenancy em uma plataforma Kubernetes compartilhada com níveis de isolamento apropriados.

→Para o isolamento mais forte, use clusters separados. Para um equilíbrio entre isolamento forte e eficiência, use clusters virtuais (vClusters). Para multi-tenancy básica e suave, use isolamento em nível de namespace com RBAC, NetworkPolicies e ResourceQuotas.

Por quê: A escolha depende do risco de segurança e de "vizinho barulhento". Clusters virtuais fornecem isolamento do plano de controle sem o custo de clusters físicos completos.

Defina o modo de interação primário entre a equipe de plataforma e as equipes alinhadas ao fluxo (de produto).

→A equipe de plataforma deve operar principalmente no modo "X-as-a-Service", fornecendo ferramentas de autoatendimento, APIs e documentação.

Por quê: Em escala, uma equipe de plataforma não pode usar um modelo de colaboração de alto contato com todas as equipes. O modelo as-a-service permite escalabilidade e autonomia do desenvolvedor.

Implemente uma estratégia de observabilidade abrangente para um sistema distribuído.

→Colete e correlacione os três pilares: Métricas (dados numéricos de séries temporais via Prometheus), Logs (eventos estruturados via Fluent Bit) e Traces (fluxos de requisição via OpenTelemetry).

Por quê: Nenhum pilar isolado é suficiente. Correlacioná-los (por exemplo, incorporando IDs de trace em logs) é essencial para diagnosticar rapidamente problemas em arquiteturas de microsserviços complexas.

Aplique políticas de segurança e organizacionais em todos os clusters Kubernetes automaticamente.

→Use um motor de políticas como OPA/Gatekeeper ou Kyverno, integrado como um controlador de admissão de validação/mutação. Armazene as políticas no Git e sincronize-as via GitOps.

Por quê: Isso fornece guardrails automatizados e preventivos, dando aos desenvolvedores feedback rápido em seu pipeline de CI/CD, em vez de portões de revisão lentos e manuais.

Selecione um motor de políticas para Kubernetes com base nas habilidades da equipe e na complexidade da política.

→Use Kyverno para políticas que podem ser expressas em YAML no estilo Kubernetes. Use OPA/Gatekeeper para políticas complexas que exigem uma linguagem mais poderosa e construída para fins específicos (Rego) e integração de dados externos.

Por quê: Kyverno tem uma curva de aprendizado menor para profissionais de Kubernetes. OPA/Rego é mais poderoso, mas exige aprender uma nova linguagem.

Garanta a integridade e autenticidade das imagens de contêiner implantadas em produção.

→Implemente a assinatura de imagens no pipeline de CI usando Sigstore/Cosign. Use um controlador de políticas (Kyverno, Gatekeeper) para criar uma política de admissão que verifica as assinaturas das imagens antes de permitir a criação de um pod.

Por quê: Isso garante que apenas imagens construídas por pipelines de CI confiáveis e que não foram adulteradas possam ser executadas no cluster, prevenindo a execução não autorizada de código.

Referência↗

Proteja toda a comunicação serviço-a-serviço dentro do cluster com uma abordagem de confiança zero.

→Implante uma service mesh (por exemplo, Istio, Linkerd) e habilite o mutual TLS (mTLS) estrito para todo o tráfego na malha.

Por quê: mTLS fornece tanto criptografia em trânsito quanto uma identidade forte e criptograficamente verificável para cliente e servidor, prevenindo spoofing e ataques man-in-the-middle dentro do cluster.

Aplique as melhores práticas de segurança para todas as cargas de trabalho em execução no cluster.

→Habilite o controlador de admissão de segurança de Pod (Pod Security Admission) integrado. Configure namespaces para impor o perfil `restricted` para cargas de trabalho e `baseline` para componentes da plataforma.

Por quê: O perfil `restricted` impõe endurecimento de segurança crítico (por exemplo, execução como não-root, descarte de todas as capacidades, não permissão de escalonamento de privilégios) e é uma medida de segurança fundamental.

Referência↗

Detecte comportamento anômalo ou malicioso dentro de contêineres em execução no nível do sistema operacional.

→Implante uma ferramenta de segurança de tempo de execução que usa eBPF, como Falco ou Tetragon. Defina regras para detectar chamadas de sistema suspeitas, acesso a arquivos e execução de processos.

Por quê: Ferramentas de segurança tradicionais são cegas para atividades dentro de contêineres. eBPF fornece visibilidade profunda e de baixa sobrecarga em eventos de nível de kernel, permitindo a detecção de ameaças que outras ferramentas perdem.

Construa um pipeline de dados de observabilidade escalável e resiliente.

→Use o OpenTelemetry (OTel) Collector. Encadeie processadores para transformar dados (por exemplo, processador `attributes` para remover PII, processador `batch` para eficiência). Use o processador `memory_limiter` no início do pipeline para prevenir OOMs.

Por quê: O Collector desacopla a instrumentação dos backends e fornece uma maneira flexível e agnóstica de fornecedor para processar, filtrar e rotear dados de telemetria antes da exportação.

Referência↗

Implante novas versões de aplicações em produção minimizando o risco e o raio de impacto.

→Implemente implantações canary automatizadas usando uma ferramenta como Flagger ou Argo Rollouts. Desloque gradualmente o tráfego para a nova versão enquanto analisa automaticamente as métricas chave (taxa de sucesso, latência). Faça rollback automaticamente em caso de violação de SLO.

Por quê: A análise canary automatizada valida novas versões com tráfego de produção real, fornecendo um grau de segurança muito maior do que simples atualizações contínuas.

Implante uma nova versão de uma aplicação com a capacidade de realizar um rollback instantâneo.

→Mantenha dois ambientes de produção idênticos ("azul" e "verde"). Implante a nova versão no ambiente inativo (verde). Após a validação, alterne o balanceador de carga para rotear todo o tráfego para o verde. Mantenha o azul ocioso para um rollback instantâneo.

Por quê: Este padrão fornece implantações sem tempo de inatividade e o rollback mais rápido possível, mas geralmente requer o dobro dos recursos de infraestrutura.

Gerencie segredos de forma declarativa em um fluxo de trabalho GitOps sem armazenar credenciais em texto claro no Git.

→Use um operador de segredos dedicado. Ou criptografe os segredos antes de commitar (Bitnami Sealed Secrets, Mozilla SOPS) ou referencie segredos de um vault externo (External Secrets Operator).

Por quê: Isso mantém dados sensíveis fora do Git, ao mesmo tempo que permite que os segredos sejam gerenciados declarativamente junto com a configuração da aplicação, mantendo o fluxo de trabalho GitOps.

Gerencie configurações de aplicações em múltiplos ambientes (dev, staging, prod) sem duplicação.

→Use uma ferramenta como Kustomize com uma estrutura de base e overlay, ou Helm com arquivos de valores específicos do ambiente. Promova as alterações atualizando as tags de imagem ou a configuração no arquivo de overlay/valores do ambiente de destino, geralmente via pull request.

Por quê: Esta abordagem "Não se Repita" (DRY) previne o desvio de configuração entre ambientes e torna as diferenças explícitas e auditáveis.

Gerencie implantações da mesma aplicação em uma frota grande e dinâmica de clusters.

→Use ArgoCD ApplicationSets com um gerador de cluster. O gerador descobre dinamicamente clusters com base em rótulos e usa um template para gerar um recurso Application para cada cluster correspondente.

Por quê: Isso automatiza o bootstrapping de aplicações para novos clusters e gerencia a configuração em escala, evitando a necessidade de criar manualmente centenas de recursos Application.

Referência↗

Habilite a implantação contínua em produção enquanto controla o lançamento de novos recursos para os usuários.

→Integre um sistema de feature flagging. Implante novo código em produção por trás de uma feature flag desabilitada. Libere o recurso habilitando a flag para segmentos de usuários específicos, desacoplando a implantação do lançamento.

Por quê: Isso separa o risco técnico (implantação) do risco de negócio (lançamento), permitindo implantações de alta velocidade, testes A/B e capacidades de "kill switch".

Implante automaticamente novas imagens de contêiner assim que forem enviadas para um registro.

→Use os componentes de Automação de Imagem do FluxCD. O `ImageRepository` escaneia o registro, o `ImagePolicy` seleciona a nova tag (por exemplo, com base em semver), e o `ImageUpdateAutomation` commita a mudança da tag de volta para o repositório Git.

Por quê: Isso fecha o ciclo do CI (push de imagem) para o CD (implantação) para um fluxo de trabalho GitOps totalmente automatizado, sem que o sistema de CI precise de acesso ao cluster.

Forneça uma API unificada e declarativa para que os desenvolvedores possam provisionar self-service tanto recursos de infraestrutura Kubernetes quanto de nuvem (por exemplo, bancos de dados, filas de mensagens).

→Use Crossplane. Instale plugins de provedores de nuvem e defina CompositeResourceDefinitions (XRDs) de alto nível para desenvolvedores (por exemplo, `kind: PostgresSQLInstance`). Mapeie-os para os recursos de nuvem subjacentes usando Compositions.

Por quê: Isso estende o plano de controle do Kubernetes para gerenciar recursos externos, permitindo que os desenvolvedores usem fluxos de trabalho `kubectl` e GitOps familiares para todas as suas dependências de aplicação, governados por padrões definidos pela plataforma.

Referência↗

Automatize o gerenciamento complexo do ciclo de vida de aplicações stateful (por exemplo, instalação, atualizações, backups, recuperação de falhas) de forma nativa do Kubernetes.

→Construa um Operador Kubernetes. Defina um Custom Resource Definition (CRD) para sua aplicação e implemente um controlador customizado que executa um loop de reconciliação para gerenciar o estado da aplicação.

Por quê: Operadores codificam o conhecimento operacional humano em software, permitindo automação robusta e tratando aplicações complexas como recursos Kubernetes de primeira classe.

Garanta que um operador possa realizar a limpeza de recursos externos (por exemplo, um balanceador de carga de nuvem) antes que seu Custom Resource associado seja excluído do Kubernetes.

→Adicione um finalizador aos metadados do Custom Resource. Quando um usuário exclui o CR, ele entra em um estado `Terminating`. A lógica de reconciliação do operador detecta isso, realiza a limpeza e então remove o finalizador, permitindo que o servidor API do K8s complete a exclusão.

Por quê: Sem um finalizador, o CR poderia ser excluído antes que o operador tivesse tempo de limpar recursos externos, levando a infraestrutura órfã e cara.

Gerencie o ciclo de vida de uma frota de clusters Kubernetes usando ferramentas declarativas e amigáveis ao GitOps.

→Use Cluster API (CAPI). Um cluster de gerenciamento executa controladores CAPI que reconciliam recursos `Cluster` e `Machine` para provisionar e configurar clusters de carga de trabalho em vários provedores de nuvem.

Por quê: CAPI transforma o gerenciamento de clusters em um fluxo de trabalho Kubernetes declarativo, permitindo o provisionamento e as atualizações consistentes, automatizadas e controladas por versão de clusters inteiros.

Referência↗

Evolua as APIs da plataforma (definidas como CRDs) sem quebrar usuários existentes ou exigir uma migração "big bang".

→Suporte múltiplas versões na definição do CRD (por exemplo, v1beta1, v1). Implemente um webhook de conversão para traduzir entre as versões, permitindo que novos clientes usem v1 enquanto clientes antigos continuam a usar v1beta1 contra o mesmo objeto armazenado.

Por quê: Webhooks de conversão são o mecanismo nativo do Kubernetes para permitir a evolução não disruptiva da API, o que é crítico para um produto de plataforma estável.

Reduza a carga cognitiva do desenvolvedor e melhore a descoberta centralizando ferramentas, documentação e ativos de software.

→Implemente um Portal Interno do Desenvolvedor (IDP) usando um framework como o CNCF Backstage. Popule seu Catálogo de Software, forneça Software Templates para o scaffolding de novos serviços e integre o TechDocs para "docs-as-code".

Por quê: Um IDP atua como um "único painel de controle" para desenvolvedores, fornecendo golden paths e capacidades de autoatendimento que abstraem a complexidade da plataforma e aceleram o onboarding e o desenvolvimento.

Referência↗

Forneça um inventário único e confiável de todo o software na organização, incluindo propriedade, dependências e status operacional.

→Implemente um catálogo de software (por exemplo, Backstage Software Catalog) populado via arquivos `catalog-info.yaml` em repositórios Git. Isso cria um registro central e pesquisável de serviços, bibliotecas, APIs, etc.

Por quê: Um catálogo resolve a descoberta ("quais serviços existem?") e a propriedade ("com quem falo sobre este serviço?"), o que é crítico para escalar arquiteturas de microsserviços.

Capacite os desenvolvedores a criar novos serviços prontos para produção que aderem aos padrões organizacionais em minutos.

→Use uma ferramenta de scaffolding como Backstage Software Templates. Defina templates que geram um novo repositório Git com estrutura de projeto padrão, configuração de pipeline CI/CD, dashboards de observabilidade e `catalog-info.yaml`.

Por quê: Templates codificam as melhores práticas e fornecem um "caminho pavimentado" para os desenvolvedores, reduzindo drasticamente o tempo até o primeiro commit e garantindo que novos serviços sejam criados com segurança, observabilidade e conformidade incorporadas.

Garanta que a documentação técnica esteja atualizada, versionada e co-localizada com o software que descreve.

→Adote uma abordagem "docs-as-code". Armazene a documentação em arquivos Markdown dentro do repositório Git do serviço. Use uma ferramenta como Backstage TechDocs para construir e renderizar automaticamente esta documentação no IDP.

Por quê: Este modelo trata a documentação como código — pode ser revisada em pull requests e é versionada junto com a funcionalidade que descreve, prevenindo documentos obsoletos ou desatualizados.

Meça a eficácia da plataforma e seu impacto no desempenho da entrega de software.

→Acompanhe as quatro métricas DORA: Frequência de Implantação (velocidade), Tempo de Lead para Alterações (velocidade), Taxa de Falha de Mudança (estabilidade) e Tempo para Restaurar o Serviço (MTTR, estabilidade).

Por quê: As métricas DORA são medidas padrão da indústria, orientadas a resultados, comprovadamente correlacionadas com o desempenho organizacional. Elas fornecem uma visão equilibrada tanto da velocidade quanto da estabilidade.

Referência↗

Forneça visibilidade de custos precisa e granular para as equipes que usam uma plataforma Kubernetes compartilhada.

→Implante uma ferramenta FinOps como OpenCost ou Kubecost. Atribua custos às cargas de trabalho com base no seu consumo real de recursos ao longo do tempo. Aloque os custos de cluster compartilhados (por exemplo, componentes do sistema, overhead de nó) proporcionalmente.

Por quê: A atribuição de custos precisa (chargeback/showback) impulsiona a responsabilidade e encoraja as equipes a otimizar o uso de recursos. Sem isso, os custos da plataforma compartilhada são opacos e difíceis de gerenciar.

Meça se a plataforma está realmente fornecendo valor e sendo usada pelas equipes de desenvolvimento.

→Acompanhe a taxa de adoção dos principais recursos da plataforma, especialmente os templates de golden path e os pipelines de CI/CD compartilhados. Complemente com pesquisas de satisfação do desenvolvedor (estilo NPS).

Por quê: A alta adoção de recursos de plataforma opcionais e opinativos é um forte sinal de que a plataforma está resolvendo problemas reais. A baixa adoção indica uma incompatibilidade com as necessidades do desenvolvedor.

Avalie o estado atual da plataforma e crie um roadmap para melhoria.

→Use um Modelo de Maturidade da Plataforma para avaliar as capacidades em múltiplas dimensões: por exemplo, Autoatendimento, Observabilidade, Segurança, Confiabilidade e Governança. Defina níveis de ad-hoc/manual para totalmente automatizado e otimizado.

Por quê: Um modelo de maturidade fornece uma estrutura estruturada para autoavaliação, ajuda a identificar pontos fracos e alinha a equipe em uma visão estratégica para a evolução da plataforma.