A maioria dos desenvolvedores conhece Docker Compose. Subir docker compose up e ver a aplicação rodar com banco, cache e API é quase rotina. O problema começa quando alguém pergunta: "E em produção?"

A distância entre um docker-compose.yml funcional e um deploy Kubernetes configurado com Deployments, Services, ConfigMaps, Ingress e health checks é grande. Para muitas equipes, essa lacuna representa semanas de aprendizado de YAML, Helm charts ou Kustomize overlays.

Em janeiro de 2026, a Docker lançou o Kanvas — uma extensão do Docker Desktop que promete eliminar essa fricção. A proposta: transformar o Compose que já funciona no seu laptop em artefatos Kubernetes iniciais prontos para adaptação em produção, sem que você precise escrever manifests manualmente.

O problema: a lacuna entre Compose e Kubernetes

Docker Compose resolve o desenvolvimento local com elegância. Você declara serviços, volumes, redes e variáveis de ambiente num único arquivo YAML. Funciona. Mas Kubernetes opera com conceitos diferentes: Pods, Deployments, ReplicaSets, Services, Ingress, ConfigMaps, Secrets, PersistentVolumeClaims. A tradução não é direta.

Um docker-compose.yml com três serviços pode gerar 15 ou mais manifests Kubernetes. E cada manifest precisa de configuração específica para o ambiente de destino: limites de recursos, réplicas, probes de saúde, políticas de rede.

Historicamente, duas ferramentas dominam esse espaço: Helm e Kustomize. Helm funciona como um gerenciador de pacotes com charts reutilizáveis e valores configuráveis via Go templates. A pesquisa anual da CNCF de 2025 aponta Helm com 75% de adoção entre equipes que usam Kubernetes, e o Artifact Hub lista mais de 10.000 charts públicos.

Kustomize segue outra filosofia: sem templates, você escreve YAML puro como base e aplica patches por ambiente. Está embutido no kubectl desde a versão 1.14, então não exige instalação extra.

As duas ferramentas funcionam. Mas exigem investimento em aprendizado que nem toda equipe tem. Go templates do Helm se tornam difíceis de ler quando crescem. Condicionais aninhadas, loops e helpers que escondem o YAML real. Equipes relatam gastar mais tempo depurando a renderização de templates do que escrevendo os manifests.

O que é o Docker Kanvas

Kanvas é uma extensão do Docker Desktop desenvolvida em parceria com a Layer5, a empresa por trás do Meshery (plataforma de gerenciamento de service meshes e infraestrutura cloud-native). O código é open source e vive no GitHub em layer5io/kanvas-docker-extension.

A ideia por trás do Kanvas é o que a Docker chama de "Infrastructure as Design". Em vez de infraestrutura como código puro, infraestrutura como diagrama visual interativo. Você importa um docker-compose.yml e o Kanvas gera uma topologia mostrando serviços, dependências, volumes, portas e configurações mapeados para equivalentes Kubernetes.

O diagrama não é documentação decorativa. É a fonte visual principal durante o design da infraestrutura. Alterar um nó no diagrama atualiza o manifest gerado.

Além de Kubernetes, o Kanvas também gera configurações para Terraform e Pulumi. O mesmo arquivo Compose pode resultar em deploys para AWS EKS, Azure AKS ou Google GKE, reduzindo significativamente a configuração manual inicial por provedor.

Designer mode e Operator mode

O Kanvas opera em dois modos distintos que refletem dois momentos do ciclo de vida de uma aplicação.

No Designer mode, você cria e configura infraestrutura visualmente. Uma paleta disponibiliza milhares de componentes Kubernetes versionados que podem ser arrastados para o canvas. É possível importar Helm charts existentes do GitHub e escolher entre um catálogo de arquiteturas de referência e templates de infraestrutura. Antes de aplicar qualquer mudança, o dry-run valida a configuração e verifica permissões no cluster.

Na prática, o fluxo no Designer mode funciona assim:

  1. Importe seu docker-compose.yml
  2. O Kanvas renderiza a topologia com serviços e dependências
  3. Ajuste configurações visuais (réplicas, limites de recursos, probes)
  4. Execute dry-run para validar
  5. Exporte para Kubernetes manifests, Terraform ou Pulumi

O Operator mode lida com o runtime. Nele você faz deploy de designs, gerencia Deployments e Services ativos, e se conecta interativamente a Pods e containers para debug. Logs, métricas e tráfego ficam acessíveis numa interface unificada.

Essa separação faz sentido: desenvolvedores usam o Designer mode para desenhar a arquitetura, engenheiros de plataforma usam o Operator mode para operar o cluster. A mesma configuração serve para ambos.

Kanvas vs Helm vs Kustomize

Comparar as três ferramentas exige entender que elas resolvem problemas adjacentes, não idênticos.

Helm é um gerenciador de pacotes. Sua força está na distribuição. Se você precisa instalar Prometheus, Redis ou NGINX Ingress Controller no cluster, provavelmente vai usar helm install. Charts reutilizáveis economizam tempo em configurações comuns. O problema aparece quando você precisa personalizar além do previsto pelo chart: os templates Go ficam densos e difíceis de manter.

helm install my-release bitnami/redis --set replica.replicaCount=3

Kustomize é uma ferramenta de patching. Não distribui pacotes, mas permite manter YAML limpo com overlays por ambiente. Se você quer que staging use 1 réplica e produção use 5, um patch de duas linhas resolve. A vantagem: nenhuma abstração entre você e o manifest final. A desvantagem: sem mecanismo de distribuição.

# kustomization.yaml
resources:
  - deployment.yaml
patches:
  - target:
      kind: Deployment
      name: api
    patch: |-
      - op: replace
        path: /spec/replicas
        value: 5

Kanvas entra por outro ângulo. Não substitui Helm para instalação de pacotes de terceiros, nem compete com Kustomize para patching granular. O que faz é eliminar o passo manual de traduzir Compose para Kubernetes. Para equipes que já têm Docker Compose funcionando e precisam ir para produção em Kubernetes, o ganho é direto: reduzem a necessidade imediata de aprender Helm templates nem montar overlays Kustomize do zero.

Na prática, equipes maduras vão combinar ferramentas. Kanvas para gerar a base a partir do Compose, Helm para instalar dependências de infraestrutura (cert-manager, ingress controllers), Kustomize para ajustes finos por ambiente. Não é excludente.

Quando faz sentido usar o Kanvas

Kanvas resolve um problema específico: a transição de Compose para Kubernetes. Se a sua equipe está numa destas situações, vale experimentar:

  • Time pequeno que domina Docker Compose mas não tem experiência com Kubernetes manifests
  • Projetos que funcionam em Compose localmente e precisam de um caminho para produção em Kubernetes
  • Equipes que querem visualizar a topologia de serviços antes de fazer deploy
  • Ambientes multi-cloud onde gerar configs para Terraform e Pulumi a partir de um único Compose economiza trabalho

Por outro lado, não faz sentido quando:

  • Você já tem um pipeline Helm e Kustomize maduro e estável
  • O projeto não usa Docker Compose como ponto de partida
  • Você precisa de customização granular de manifests que vai além do que o Kanvas gera

Uma limitação que merece atenção: o Kanvas é uma extensão do Docker Desktop. Equipes que usam Docker Engine em servidores Linux sem interface gráfica precisam avaliar se o fluxo visual se encaixa. A documentação da Layer5 indica que o Meshery CLI pode servir como alternativa para pipelines de CI, mas a experiência principal é visual e interativa.

Conclusão

Kanvas não mata Helm nem Kustomize. As três ferramentas ocupam espaços complementares no ecossistema Kubernetes. O que o Kanvas traz de novo é atacar o ponto exato onde a maioria dos desenvolvedores trava: a tradução entre o que funciona na máquina local e o que precisa rodar em produção.

Se você está nessa lacuna, vale 30 minutos de exploração. Instale a extensão no Docker Desktop, importe seu docker-compose.yml e veja o que sai do outro lado. O código está em layer5io/kanvas-docker-extension no GitHub, e a documentação técnica completa fica em docs.layer5.io/kanvas.

Referências pesquisadas nesta publicação