Entenda Kubernetes: control plane, Pods, Deployments, rede, storage persistente, segurança, alta disponibilidade e critérios de projeto corporativo.
Confira!
Kubernetes é uma plataforma open source de orquestração que mantém aplicações containerizadas em execução de acordo com uma configuração declarativa. Em vez de administrar manualmente cada container, a equipe define workloads, recursos, políticas e comportamento desejado. Os controladores reconciliam continuamente o estado observado com o estado especificado, distribuindo aplicações entre nós do cluster e substituindo instâncias quando necessário.
A utilização de Kubernetes precisa ser justificada por requisitos de escala, disponibilidade, automação, segregação de equipes e operação. Uma arquitetura de cluster mal dimensionada pode acrescentar pontos de falha, custo e complexidade. Para sistemas críticos, a implantação exige projeto de engenharia, governança de mudanças, redes, armazenamento persistente, segurança, observabilidade e testes de recuperação.
O que é Kubernetes e quando faz sentido utilizá-lo?
O Kubernetes organiza containers e serviços usando uma API que descreve objetos como Pods, Deployments, Services, ConfigMaps e PersistentVolumeClaims. A automação não representa um operador humano tomando decisões técnicas; são controladores que aplicam regras previamente definidas. Se um Pod deixa de existir, um controlador pode solicitar outro. Se a aplicação não consegue acessar seu banco de dados, entretanto, o simples reinício pode não resolver a falha funcional.
A plataforma se torna atraente quando muitos serviços exigem releases coordenados, descoberta de serviços, isolamento, distribuição entre servidores, escalabilidade sob demanda e recuperação padronizada. Organizações que operam dezenas de aplicações com equipes distintas podem ganhar consistência ao declarar limites de recursos, políticas e modelos de implantação em repositórios sujeitos a revisão.
Para ambientes pequenos, aplicações monolíticas ou equipes sem competência de administração de clusters, uma arquitetura baseada em máquinas virtuais ou um runtime de containers mais simples pode ser superior. Adotar Kubernetes somente por tendência transforma o ambiente em uma nova dependência operacional sem entregar benefício equivalente. O critério deve ser a capacidade de cumprir níveis de serviço com custo e risco conhecidos.
O artigo sobre Virtualização e Containers estabelece as diferenças entre os modelos de execução. O conteúdo sobre Docker detalha imagens, runtimes e volumes; aqui o foco é a orquestração e a engenharia da plataforma.
Arquitetura de um cluster: control plane e worker nodes
Um cluster Kubernetes possui um control plane responsável por expor a API, manter informações de estado, planejar a alocação de Pods e executar controladores. Os worker nodes executam as aplicações, por meio de kubelet, runtime de containers e componentes de rede. Em instalações gerenciadas por um provedor, determinadas responsabilidades de operação do control plane podem estar delegadas, sem eliminar os deveres sobre workloads e dados.
O kube-apiserver recebe as operações realizadas por clientes e componentes; etcd mantém dados de estado do cluster; kube-scheduler escolhe nós para novos Pods; kube-controller-manager executa loops de reconciliação. O cloud-controller-manager, quando aplicável, integra recursos do provedor. Essa divisão é importante para dimensionar disponibilidade e identificar o impacto de falhas de dependências.
O control plane não equivale à aplicação do usuário. É possível que workloads existentes permaneçam executando durante uma interrupção temporária de componentes de controle, mas novas operações de agendamento, reconciliação ou alteração ficam prejudicadas. Por isso, o desenho de alta disponibilidade deve considerar quórum, conectividade, backup e recuperação de etcd, além das condições dos worker nodes.
O diagrama representa relações conceituais: o scheduler determina vínculos para Pods, mas são os kubelets dos nós que supervisionam sua execução. A rede dos Pods depende de implementação compatível com o modelo CNI, e políticas de comunicação precisam ser verificadas conforme o plugin utilizado. A arquitetura deve ainda prever DNS interno, registry, identidade, storage e integração com o sistema corporativo de observabilidade.
Ao especificar servidores físicos ou VMs para o cluster, defina perfil de CPU, memória, disco, latência de rede e margens para perda de nó. Separar control plane e workloads críticos pode facilitar governança, mas a topologia deve considerar tamanho, custo e resiliência. A plataforma deve ser dimensionada para o pior cenário de operação definido, não apenas para um benchmark sem falhas.
Pods, Deployments, StatefulSets e Jobs: diferenças práticas
O Pod é a menor unidade implantável do Kubernetes. Um Pod pode conter um ou mais containers que compartilham recursos de rede e determinados volumes; containers do mesmo Pod são programados juntos e possuem ciclo de vida associado. Isso não significa que cada microsserviço precise de múltiplos containers. Sidecars podem ser úteis, mas acrescentam dependências e devem ser justificados pela função.
Deployment é um controlador comum para aplicações stateless. Ele gerencia ReplicaSets e atualizações de versões, podendo substituir gradualmente Pods. Para aplicações que precisam de identidade de rede estável, ordenação de implantação ou volumes persistentes associados a instâncias específicas, StatefulSet pode ser mais adequado. DaemonSet, por sua vez, agenda agentes em nós selecionados, sendo comum em observabilidade e componentes de infraestrutura.
Jobs executam atividades que precisam terminar, enquanto CronJobs criam execuções programadas. A escolha do objeto deve refletir a semântica do processo. Um pipeline noturno de integração não deve ser tratado como serviço sempre ligado apenas porque utiliza containers. Da mesma forma, um banco com estado não se torna stateless porque foi colocado em um Deployment.
| Recurso | Função típica | Cuidados de projeto |
| Pod | Unidade de execução | Reinício, probes e limites |
| Deployment | Serviço com réplicas substituíveis | Rolling update e rollback |
| StatefulSet | Instâncias com identidade e estado | Volumes, recuperação e ordem |
| DaemonSet | Agente por nó elegível | Capacidade e permissões |
| Job e CronJob | Processos finitos ou programados | Idempotência e reexecução |
| Namespace | Escopo lógico de recursos | RBAC, quotas e políticas |
Esses recursos não substituem análise de arquitetura da aplicação. Se um serviço mantém sessões apenas na memória de uma instância, a expansão horizontal pode produzir inconsistências. Se um job não é idempotente, uma nova execução após falha pode duplicar transações. A equipe deve preparar o software para as garantias reais fornecidas pela plataforma.
Em aplicações corporativas, é necessário documentar readiness, tratamento de sinais de encerramento e tempo de finalização. Um Pod pode sair do pool de atendimento antes de ter suas transações encerradas. O aceite deve demonstrar que uma atualização normal não perde requisições, que as dependências críticas ficam acessíveis e que o serviço se recupera de falhas conhecidas.
Scheduler, requests, limits e planejamento de capacidade
O scheduler considera restrições e recursos declarados para escolher um nó elegível. Requests influenciam a reserva considerada no agendamento; limits restringem o uso de determinados recursos durante a execução. Definir todos os limites com valores arbitrários, sem conhecer o perfil de carga, pode causar throttling de CPU ou encerramentos por falta de memória. O correto é medir o comportamento real e separar consumo sustentado, pico e margem operacional.
O planejamento começa com o inventário de workloads e seus perfis: usuários simultâneos, transações, CPU, memory working set, conexões a banco, IOPS, consumo de rede e crescimento de dados. Acrescente recursos utilizados pelo sistema operacional, agentes, rede e componentes de cluster. A capacidade nominal de um servidor não equivale integralmente à capacidade disponível para Pods.
Afinidades, anti-affinity e topology spread constraints ajudam a distribuir réplicas entre nós e domínios de falha. Entretanto, um spread mal especificado pode impedir agendamentos quando a infraestrutura está degradada. É necessário decidir se a prioridade, em cada cenário, é preservar segregação, reduzir latência ou admitir temporariamente concentração de cargas.
Horizontal Pod Autoscaler ajusta réplicas conforme métricas e configuração, mas sua utilidade depende da arquitetura do serviço. Aumentar Pods não resolve banco saturado, gargalo em API externa ou limitações de licença. O Vertical Pod Autoscaler, quando utilizado, também exige análise do impacto de alterações nas reservas e no ciclo de vida das instâncias.
| Indicador | O que observar | Ação de engenharia |
| CPU throttling | Restrições sob pico | Rever limites e perfil de carga |
| OOMKilled | Falha por memória | Identificar vazamento e sizing |
| Pending Pods | Falta de recursos ou restrições | Conferir scheduler e quotas |
| Tempo de resposta p95/p99 | Latência percebida | Localizar gargalo por dependência |
| Saturação do storage | IOPS, throughput e latência | Adequar classe e capacidade |
| Disponibilidade por serviço | Resultado real para usuários | Testar falhas e redundância |
O teste de capacidade deve incluir perda de nó, upgrades e crescimento. Um cluster com recursos suficientes apenas em condições normais pode não absorver as réplicas durante manutenção. A análise de N+1 ou outra reserva definida pelo negócio precisa ser refletida nos requests e no planejamento físico dos hosts.
Kubernetes Networking: Services, DNS, Ingress e NetworkPolicy
Os Pods recebem endereços de rede sujeitos a mudanças ao longo do ciclo de vida. Services fornecem uma abstração para acesso a grupos de Pods; o DNS interno permite descoberta por nomes estáveis. Ingress ou Gateway API, conforme a arquitetura adotada e seus controladores disponíveis, podem estruturar entrada de tráfego HTTP e HTTPS. A implementação exige verificação dos recursos suportados pelo ambiente escolhido.
A arquitetura deve distinguir tráfego norte-sul, entre usuários e aplicações, do tráfego leste-oeste, entre serviços. É necessário mapear origens, destinos, portas, protocolos, certificados, balanceamento, MTU, NAT e requisitos de latência. Um diagrama que apresenta apenas um Ingress e um banco não revela quais políticas de comunicação são efetivamente necessárias.
NetworkPolicy permite especificar restrições para tráfego de Pods quando o plugin de rede implementa a funcionalidade requerida. Criar um objeto de política não garante isolamento se o CNI não aplicar essas regras. O comissionamento deve testar conectividade permitida e negada, inclusive egress para serviços externos, DNS e dependências administrativas.
O desenho pode incluir segregação entre ambientes de desenvolvimento, homologação e produção e entre equipes. Namespaces ajudam a organizar recursos, mas não substituem fronteiras de segurança com isolamento comprovado. Para sistemas sensíveis, avalie clusters separados, identidades de serviço e políticas específicas, de acordo com o modelo de ameaça.
Em integração com redes de TI e OT e zonas DMZ, também é necessário considerar roteamento corporativo, firewalls de perímetro, gestão de certificados e acesso remoto administrativo. Kubernetes não deve abrir caminhos imprevistos para sistemas industriais, segurança eletrônica ou bases de dados de produção.
Storage persistente, volumes e backup
A persistência é uma das questões mais críticas em produção. PersistentVolume representa recurso de armazenamento; PersistentVolumeClaim declara uma solicitação de capacidade e características. StorageClasses e drivers CSI podem automatizar provisionamento, mas seu comportamento depende da implementação e das funcionalidades suportadas. Montar um volume não resolve sozinho consistência transacional, retenção, proteção contra corrupção ou disaster recovery.
Para bancos de dados e aplicações stateful, avalie modo de acesso, desempenho, replicação, topologia, snapshots, expansão e tolerância a falhas. Um volume preso a determinada zona pode impedir que uma réplica reinicie em outra. Um provisionador com capacidade insuficiente pode deixar Pods em estado Pending. As decisões precisam estar documentadas e testadas com carga real.
Kubernetes não é sistema de backup. Exportar manifestos não preserva automaticamente o conteúdo de volumes nem o estado externo de bancos e serviços gerenciados. A estratégia deve abranger estado da aplicação, dados persistentes, secrets necessários à recuperação e configurações de infraestrutura, com proteção independente e controle de acesso.
Uma rotina de backup confiável registra janela, retenção, consistência, criptografia, destino, responsabilidades e testes de restore. Para workloads críticos, executar restauração em ambiente isolado permite aferir RTO e RPO. A integração entre backup e orquestração deve garantir ordem de recuperação e reconexão dos serviços, evitando novas corrupções ou processamento duplicado.
| Camada | Evidência de continuidade | Limitação frequente |
| Manifestos e configurações | Recriação controlada | Não contêm dados de negócio |
| etcd | Backup e restauração testados | Não substitui backup de volumes |
| PersistentVolumes | Integridade e restauração | Depende de driver e consistência |
| Banco externo | Restore e reconciliação | Exige credenciais e endpoints |
| Registry | Imagens versionadas disponíveis | Tags móveis podem divergir |
Uma solução resiliente precisa recuperar o serviço completo. Restaurar a API de Kubernetes sem recuperar volumes ou certificados produz um cluster que pode estar operacional administrativamente e indisponível para o negócio.
Deployments, rolling updates, probes e rollback
Uma das vantagens de uma plataforma declarativa é controlar releases. Em um Deployment, rolling update substitui gradualmente as réplicas existentes, conforme parâmetros como maxSurge e maxUnavailable. Isso não garante zero downtime automaticamente: o comportamento depende de capacidade disponível, readiness, encerramento gracioso, sessão, conexões e compatibilidade entre versões.
Liveness probe detecta situações em que um container precisa ser reiniciado; readiness probe indica se a instância deve receber tráfego; startup probe oferece janela adequada a aplicações que inicializam lentamente. Usar liveness para verificar dependências externas com instabilidade temporária pode provocar reinícios desnecessários e amplificar incidentes.
A aplicação também deve responder corretamente à finalização. É recomendável tratar o sinal de encerramento, concluir requisições em andamento e evitar que tarefas sejam interrompidas sem consistência. Em sistemas com fila de eventos, a capacidade de reprocessar mensagens sem duplicidade é tão importante quanto substituir um Pod rapidamente.
A estratégia de rollback precisa considerar dados e esquemas. Reverter a imagem não resolve migrações irreversíveis de banco ou alterações de contratos de API. O projeto de release deve estabelecer compatibilidade temporária entre versões, janelas de mudança, plano de reversão e critérios de aceitação.
Um rollout deve ser acompanhado por métricas de erro, saturação e latência, não somente por contagem de Pods disponíveis. Testes de ponta a ponta, validação de dependências e aprovação operacional completam o processo. A ferramenta automatiza a entrega; a organização continua responsável por decidir quando ela é segura.
Segurança: RBAC, Secrets, supply chain e políticas
A superfície de ataque inclui API Server, identidades, nós, imagens, runtime, rede e componentes de terceiros. RBAC deve aplicar mínimo privilégio para usuários e service accounts. Credenciais administrativas compartilhadas, permissões de cluster-admin para aplicações comuns e tokens com validade inadequada aumentam o impacto potencial de comprometimento.
Secrets são objetos destinados ao armazenamento de dados sensíveis, mas seu uso não significa proteção suficiente em qualquer configuração. É necessário avaliar criptografia em repouso, controle de acesso ao etcd, integração com serviços de gestão de segredos, políticas de rotação e exposição indireta em logs ou pipelines. Montar um secret no Pod não elimina a necessidade de governar quem pode lê-lo.
A proteção de imagens envolve procedência, versionamento, verificação de dependências, identificação de vulnerabilidades relevantes, assinatura quando aplicável e execução sem privilégios desnecessários. Políticas de segurança de Pods, admission controllers e recursos do ecossistema podem restringir configurações incompatíveis com o padrão corporativo.
Não se recomenda expor o endpoint administrativo diretamente à internet sem arquitetura e controles específicos. Operação remota deve considerar autenticação forte, segregação de redes, logging, credenciais de curta duração, trilha de auditoria e procedimentos de resposta. Atualizações do cluster e de seus addons exigem análise de compatibilidade e janela controlada.
O NIST SP 800-190 apresenta preocupações relacionadas a segurança de containers. A aplicação desses princípios em Kubernetes precisa incluir componentes de orquestração e de administração, não apenas as imagens das aplicações.
Observabilidade, incidentes e responsabilidades
Uma plataforma de produção necessita métricas, logs, traces e eventos correlacionados. Logs de um container são insuficientes para investigar uma transação que atravessa API, fila, banco e autenticação. A instrumentação deve permitir identificar a causa da degradação e separar problemas da aplicação de incidentes de infraestrutura.
Sinais operacionais incluem reinícios, Pending Pods, throttling, esgotamento de memória, latência de chamadas, saturação de conexões e indisponibilidade do storage. Os alertas devem ser baseados no impacto ao serviço, com destinatários e instruções de atendimento. Um alerta para cada reinício isolado pode gerar ruído e reduzir a capacidade da equipe de responder a falhas relevantes.
Defina ownership por camada. Plataforma e SRE podem responder pelo cluster e ferramentas, enquanto equipes de aplicações respondem por código, requisições, padrões de erro, readiness e integridade do processamento. Fornecedores de cloud ou serviços gerenciados devem possuir responsabilidades contratualmente claras, com métricas, escalonamento e evidências.
As ações de resposta precisam ser treinadas. Simulações podem incluir indisponibilidade de DNS, perda de nó, indisponibilidade de registro de imagens, volumes cheios, expiração de certificado e falha de atualização de controlador. Após cada incidente, registre causa raiz, condições contribuintes, medidas de prevenção e verificação da eficácia.
Uma plataforma é operável quando equipes conseguem diagnosticar e recuperar serviços sem depender exclusivamente de especialistas responsáveis pela implantação inicial. Inventário, runbooks, dashboards e trilha de mudanças compõem o conjunto de evidências de prontidão.
Kubernetes on-premises, gerenciado e ambientes híbridos
O cluster pode ser instalado em infraestrutura própria, fornecido como serviço gerenciado ou distribuído em arquiteturas híbridas. Em instalações on-premises, a organização assume grande parte da administração de control plane, etcd, nós, rede, storage, upgrades e disaster recovery. Isso oferece determinadas opções de controle, mas exige equipe, procedimentos e infraestrutura de suporte.
Em serviços gerenciados, parte da operação é transferida ao provedor, enquanto responsabilidades por aplicações, segurança das configurações, dados, política de acesso e continuidade permanecem compartilhadas segundo o contrato. A escolha deve ser validada pela matriz de responsabilidade e não pela crença de que o provedor gerencia tudo.
Arquiteturas híbridas precisam considerar conectividade, identidade, segregação de dados e latência. Rodar componentes distribuídos em domínios geográficos distintos pode aumentar o tempo de resposta ou comprometer quórum, dependendo da topologia. Não é correto assumir que qualquer cluster sobreviverá a particionamentos de rede sem analisar os mecanismos de consistência e disponibilização.
Em ambientes de edge computing, aplicações locais podem precisar continuar funcionando durante perda de conectividade com a matriz. A distribuição de workloads deve contemplar limitações de processamento, energia, armazenamento, suporte remoto e atualização segura. Kubernetes pode participar dessa arquitetura, mas nem sempre é a alternativa mais eficiente.
| Abordagem | Principal responsabilidade interna | Risco a verificar |
| On-premises | Operação completa da plataforma | Equipe, capacidade e recuperação |
| Gerenciado | Workloads e configuração do ambiente | Limites de responsabilidade do provedor |
| Híbrido | Integração de domínios distintos | Rede, identidade e consistência |
| Edge distribuído | Operação remota e autonomia | Conectividade e manutenção |
A contratação deve especificar desempenho, disponibilidade, observabilidade, suporte, ferramentas de atualização, portabilidade de workloads e condições de saída. O custo total não pode ignorar serviços acessórios nem o trabalho de administração.
Projeto, implantação e comissionamento: do requisito ao aceite
O projeto deve começar por inventário de aplicações e classificação de dados. Em seguida, formalize disponibilidade desejada, capacidade, crescimento, requisitos de rede, persistência, recuperação, identidade e segregação. Esses elementos orientam escolha de plataforma, topologia, armazenamento, CNI, política de acesso e limites de recursos.
O projeto executivo deve documentar estrutura de clusters, namespaces, node pools, endereçamento, DNS, portas, certificados, balanceadores, quotas e topologia de volumes. Acrescente políticas de versionamento, CI/CD, acesso administrativo, observabilidade e backup. Esses documentos são necessários para contratação, operação e auditoria.
A implantação em homologação precisa reproduzir os principais riscos de produção. Valide agendamento, failover, rollout, DNS, rede entre namespaces, persistência, autenticação, gestão de secrets e recuperação após falha. A aceitação não pode ser baseada exclusivamente em prints do dashboard; deve conter evidências de transações completas e tempos medidos.
Uma matriz de testes pode contemplar perda de um nó, saturação de CPU, exaustão de memória, interrupção de storage, falha de DNS, atualização de aplicação, restauração de volumes, queda de conectividade e recuperação de credenciais. Para cada cenário, registre pré-condições, resultado esperado, método de execução, impacto medido, responsável e parecer de aceite.
O plano de transição estabelece como migrar workloads, preservar dados, comunicar janelas, reverter versões e transferir o suporte. O go-live é um marco, não o fim da engenharia. Durante operação assistida, a equipe confirma estabilidade, corrige parâmetros de capacidade e encerra pendências com evidências documentadas.
A arquitetura deve conversar com o projeto de infraestrutura de Data Center para compatibilizar servidores, storage, redes, energia, refrigeração e segurança física, especialmente em ambientes de alta disponibilidade.
Exemplo aplicado: plataforma corporativa de integração e analytics
Considere uma empresa que utiliza APIs para conectar controle de acesso, eventos de CFTV, dados de operação e dashboards. A equipe quer implantar versões com frequência sem interromper serviços. Uma análise inicial identifica componentes stateless que podem ser replicados, além de bancos e sistemas externos que permanecem fora do cluster.
O desenho propõe Deployments para APIs e workers adequados, Services para descoberta e políticas para controlar fluxos. A ingestão de eventos usa mecanismos que toleram reexecução, com idempotência e rastreabilidade. O banco é protegido por estratégia de backup própria, enquanto as imagens das aplicações permanecem disponíveis em registro controlado.
A equipe testa aumento de carga, interrupção de nós e atualização simultânea de serviços. Se a capacidade do banco for o gargalo, adicionar réplicas às APIs não produz melhoria relevante; torna-se necessário avaliar conexões, queries, índices e throughput de armazenamento. Essa evidência impede que a decisão sobre capacidade se concentre incorretamente no orquestrador.
Na implantação, serviços críticos devem ter matriz de dependências, quotas, gestão de certificados e comunicação com segurança e operação. A entrega inclui pipelines versionados, plano de rollback, documentação de rede e evidências de recuperação. O valor de Kubernetes está em tornar esses processos repetíveis, não em substituir a análise de engenharia sobre os sistemas integrados.
Considerações finais
Kubernetes automatiza distribuição e manutenção do estado desejado de aplicações containerizadas, mas não resolve sozinho arquitetura de software, disponibilidade de dados ou maturidade operacional. A decisão de adotá-lo deve partir de requisitos verificáveis de escala, resiliência, segurança, operação e custos.
Uma implantação profissional precisa integrar control plane, workers, recursos de aplicação, rede, storage, monitoramento, backup, governança e testes. Quando essas camadas são dimensionadas e comissionadas de forma coerente, o orquestrador pode oferecer agilidade sem comprometer a previsibilidade dos serviços.
Referências técnicas
[1] The Kubernetes Authors. Kubernetes Components. Disponível em: https://kubernetes.io/docs/concepts/overview/components/.
[2] The Kubernetes Authors. Deployments. Disponível em: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/.
[3] The Kubernetes Authors. Persistent Volumes. Disponível em: https://kubernetes.io/docs/concepts/storage/persistent-volumes/.
[4] The Kubernetes Authors. Configure Liveness, Readiness and Startup Probes. Disponível em: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/.
[5] NIST. Application Container Security Guide — NIST SP 800-190. Disponível em: https://csrc.nist.gov/pubs/sp/800/190/final.
Perguntas frequentes
Não. Containers são unidades de execução; Kubernetes orquestra workloads distribuídos. O runtime usado pelos nós deve ser compatível com a plataforma.
É a menor unidade implantável do Kubernetes, que agrupa um ou mais containers com ciclo de vida e recursos de rede compartilhados.
É o conjunto de componentes que expõe a API, mantém estado, realiza agendamento e executa controladores do cluster.
Não. Pode operar em máquinas físicas ou virtuais conforme a arquitetura e o ambiente de infraestrutura.
Deployment atende com frequência workloads replicáveis; StatefulSet oferece identidade estável e gerenciamento ordenado apropriados a certas aplicações stateful.
Não. Backups de etcd, configurações, volumes e dados externos exigem política e testes específicos.
Em geral, significa que o Pod ainda não pôde ser agendado ou preparado, por recursos, restrições, volumes ou outras condições.
O controlador substitui gradualmente réplicas conforme a estratégia configurada e a disponibilidade indicada pelos mecanismos de readiness.
Não necessariamente. A aplicação das políticas depende de suporte e configuração do plugin de rede utilizado.
Quando complexidade e custo de operação superam os benefícios e os requisitos podem ser atendidos com infraestrutura mais simples.
Falhas de nó, rede e storage, segurança, desempenho, deploy, rollback, recuperação de dados e operação do serviço completo.
