Docker Kanvas — From Docker Compose to Kubernetes: A New Deployment Paradigm Without Helm
Born from the collaboration between Docker and Layer5, Kanvas is a new deployment paradigm that maintains the simplicity of Docker Compose while harnessing the power of Kubernetes. This article provides a detailed analysis from an engineer's perspective, covering Kanvas's core concepts through practical implementation strategies.
1. The Background of Docker Kanvas: Bridging the Gap
Until the end of 2025, development teams' deployment workflows had a stark discontinuity. In local development, Docker Compose's concise syntax boosted development productivity, but the moment applications moved to production, the team's role changed dramatically.
With Docker Compose, a single docker-compose.yml file can declare all service dependencies, networking, and storage. However, the Kubernetes environment is completely different. Even deploying a simple web service requires writing a minimum of the following resources:
- Deployment: Pod replication, rolling updates, resource requests/limits configuration
- Service: Cluster internal/external traffic routing
- Ingress: HTTP/HTTPS external access, TLS termination
- ConfigMap/Secret: Environment variables and configuration file management
- PersistentVolumeClaim: Storage requests and mounting
- NetworkPolicy: Microservice communication control
To solve this complexity, tools like Helm and Kustomize emerged. However, they still have steep learning curves. Helm's Go template syntax and Kustomize's layered patch strategy are significant burdens for application developers.
As a result, many organizations created a dependency where a few DevOps experts manage Helm charts, and application teams manually update them. This severely limits organizational scalability.
Core Problem: Docker Compose is optimized for local development, and Kubernetes for production operations. There was a lack of tools to bridge the gap between them.
On January 6, 2026, Docker officially announced Kanvas in collaboration with Layer5 (a leader in the service mesh open source project), directly addressing this gap. Kanvas's core philosophy is simple: developers still think in Docker Compose syntax, but the backend generates complete Kubernetes deployments.
2. Kanvas Architecture: Infrastructure as Design
Kanvas restructures the traditional "Infrastructure as Code" paradigm into "Infrastructure as Design." This is not merely marketing terminology but a fundamental conceptual shift.
2.1 Visual Architecture Design
In Kanvas's Designer mode, cloud architects design architecture by representing services as boxes and dependencies as lines. This is similar to using tools like Lucidchart or draw.io, but the design result is immediately converted into deployable code, which is the key difference.
# Result of Kanvas visual design: auto-generated docker-compose.yml
version: '3.8'
services:
api:
image: myapp/api:latest
ports:
- "8080:8080"
environment:
- DB_HOST=postgres
- CACHE_HOST=redis
depends_on:
- postgres
- redis
networks:
- app-network
postgres:
image: postgres:15-alpine
environment:
- POSTGRES_PASSWORD=secure_password
volumes:
- db_data:/var/lib/postgresql/data
networks:
- app-network
redis:
image: redis:7-alpine
networks:
- app-network
volumes:
db_data:
networks:
app-network:
driver: bridge
In Kanvas's Operator mode, this design is transformed into actual deployment. More than just running Docker Compose, it automatically processes the following production concerns:
- Resource Profiling: Automatically calculates CPU/memory requests and limits for each service
- Health Checks: Configures liveness/readiness probes for each service
- Network Policies: Automatically generates inter-service communication rules
- Security Context: Non-root user configuration, seccomp profile configuration
- Logging/Monitoring: Auto-configures Prometheus and Loki metrics collection
2.2 The Principles of Compose → Kubernetes Auto-Conversion
Kanvas's conversion engine is not simple 1:1 mapping. It analyzes each element of Docker Compose and reinterprets it for the Kubernetes operating environment:
| Compose Element | Kubernetes Resource | Additional Processing |
|---|---|---|
| service | Deployment + Service | Configure replica count, rolling strategy |
| ports | Service.spec.ports | Determine LoadBalancer vs ClusterIP |
| environment | ConfigMap + Env vars | Separate sensitive data into Secrets |
| volumes | PersistentVolumeClaim | Auto-select storage class |
| depends_on | init-container + probe | Guarantee startup order mechanism |
| networks | Namespace + NetworkPolicy | Service mesh integration options |
For example, Compose's depends_on field merely specifies startup order, but Kanvas converts it to Kubernetes's init-container and readiness probes to guarantee actual dependencies.
2.3 Example of Generated Kubernetes Manifest
# Kubernetes Deployment auto-generated by Kanvas (previously required manual writing)
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
namespace: default
spec:
replicas: 3 # Auto-configured recommended replica count
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "8080"
prometheus.io/path: "/metrics"
spec:
serviceAccountName: api
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 1000
seccompProfile:
type: RuntimeDefault
initContainers:
- name: wait-for-postgres
image: busybox:1.35
command:
- sh
- -c
- |
until nc -z postgres 5432; do
echo "Waiting for postgres..."
sleep 1
done
containers:
- name: api
image: myapp/api:latest
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 8080
protocol: TCP
env:
- name: DB_HOST
value: postgres
- name: CACHE_HOST
value: redis
- name: LOG_LEVEL
valueFrom:
configMapKeyRef:
name: api-config
key: log_level
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-credentials
key: password
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 500m
memory: 512Mi
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 10
periodSeconds: 30
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
timeoutSeconds: 3
failureThreshold: 2
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
volumeMounts:
- name: tmp
mountPath: /tmp
volumes:
- name: tmp
emptyDir: {}
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- api
topologyKey: kubernetes.io/hostname
---
apiVersion: v1
kind: Service
metadata:
name: api
namespace: default
spec:
type: ClusterIP # Or LoadBalancer depending on environment
selector:
app: api
ports:
- name: http
port: 80
targetPort: 8080
protocol: TCP
---
apiVersion: v1
kind: ConfigMap
metadata:
name: api-config
data:
log_level: "INFO"
As you can see from the example above, Kanvas automatically generates dozens of lines of Kubernetes YAML from Compose's concise definition. Notable points include:
- Resource requests/limits are automatically configured
- Health check configuration is structured to match service characteristics
- Security configuration (non-root, read-only filesystem) is applied by default
- Pod anti-affinity ensures high availability
- Prometheus metrics collection is pre-configured
2.4 Multi-Cloud Deployment
Another strength of Kanvas is the ability to deploy to multiple cloud environments like AWS, GCP, and Azure in a consistent manner.
# Kanvas cloud profile configuration
kanvas:
profiles:
aws:
storageClass: gp3 # Use AWS EBS gp3
ingressClass: alb # Use AWS ALB
nodeSelector:
cloud.provider: aws
gcp:
storageClass: pd-ssd # GCP Persistent Disk
ingressClass: gce # GCP Load Balancer
nodeSelector:
cloud.provider: gcp
azure:
storageClass: managed-premium # Azure Managed Disks
ingressClass: azure # Azure Application Gateway
nodeSelector:
cloud.provider: azure
# Execute deployment
$ kanvas deploy --profile aws --cluster production
$ kanvas deploy --profile gcp --cluster staging
$ kanvas deploy --profile azure --cluster development
3. Comparative Analysis: Helm, Kustomize, Kompose, and Kanvas
To understand Kanvas correctly, we must explicitly clarify its relationship with existing tools. Each tool solves different problems and targets different user communities.
| Item | Helm | Kustomize | Kompose | Kanvas |
|---|---|---|---|---|
| Release Year | 2016 | 2017 | 2015 | 2026 |
| Primary Users | DevOps/Platform teams | DevOps/team collaboration | Compose → K8s migration | Application developers |
| Learning Curve | High (Go template syntax) | Medium (patch strategies) | Low (1:1 conversion) | Very Low (same as Compose) |
| Input Format | values.yaml + template/ | base + overlays | docker-compose.yml | docker-compose.yml |
| Environment Management | values-{env}.yaml | overlays/{env} | Manual | Auto-profile |
| Dependency Management | Chart dependencies | Manual | depends_on only | Auto order guarantee |
| Customization | Highly flexible | Flexible | Limited | Abstraction-first (extensible) |
| Maturity | CNCF Graduated | CNCF Graduated | Stable (kubectl integrated) | New (validation pending) |
| Package Distribution | Helm Registry-centric | Git repository | None | Docker Hub + Artifact Registry |
| CRD Support | Full support | Full support | Not supported by default | Supported in extension mode |
| Operations Team Size | 1-3 DevOps | 1-2 DevOps | None (migration tool) | 0.5 admin (automation-focused) |
3.1 Helm vs Kanvas: Philosophy Difference
Helm's Philosophy: "Everything can be a template." Helm provides an extremely flexible Go template engine, allowing you to generate almost all Kubernetes resources through complex conditional logic, loops, and function calls. This is powerful for managing hundreds of services in Enterprise environments.
Kanvas's Philosophy: "In most cases, once architectural intent is clear, deployment can be automated." Kanvas reads deployment intent from Docker Compose's declarative format and automatically applies production optimizations. For customization needs, it provides extension mechanisms using CRDs or Operators.
Important Distinction: Helm is a "anything is possible" tool; Kanvas is a "most cases automation" tool. If you need Helm's flexibility, Kanvas won't be sufficient.
3.2 Kustomize vs Kanvas: Abstraction Level Difference
Kustomize's Approach: Kustomize puts "YAML resources in base by default, and overlays only necessary parts per environment." This feels natural to DevOps teams completely understanding Kubernetes resources, but requires maintaining base and overlays directory structure for each service.
Kanvas's Approach: Infers everything from a single Compose file. Environment differences are defined as profiles and applied at deployment time. No need to write Kubernetes resources directly.
3.3 Kompose vs Kanvas: Conversion vs Automation Difference
Kompose's Limitations: Kompose mechanically converts Compose to Kubernetes YAML. The converted results are typically insufficient for production deployment, requiring manual addition of resource requests/limits, health checks, security configuration, etc.
# Kompose result (production insufficient)
apiVersion: v1
kind: Service
metadata:
creationTimestamp: null
labels:
io.kompose.service: web
name: web
spec:
ports:
- name: "8080"
port: 8080
targetPort: 8080
selector:
io.kompose.service: web
status:
loadBalancer: {}
---
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
io.kompose.service: web
name: web
spec:
replicas: 1 # Only default configured
selector:
matchLabels:
io.kompose.service: web
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
io.kompose.service: web
spec:
containers:
- image: nginx:latest
name: web
ports:
- containerPort: 8080
# No resource requests/limits
# No health checks
# No security configuration
restartPolicy: Always
status: {}
# Result: Requires additional modifications for production use
Kanvas's Advantage: Kanvas not only converts but automatically adds production optimization, security hardening, and monitoring configuration.
4. Real-World Scenarios: Which Teams Should Adopt Kanvas
4.1 When Kanvas Adoption is Beneficial
| Condition | Situation Description | Expected Benefit |
|---|---|---|
| Compose-based Development | Team developing locally with docker-compose wanting to move to K8s | Minimize learning curve, 80% reduction in dev→deploy time |
| Startups/Small Teams | No dedicated DevOps engineer; developers handle deployment | Automate DevOps, focus on development, reduce deployment errors |
| Early Microservices | 10-30 service scale | Consistent deployment automation, reduced operational burden |
| Multi-Cloud | Deploy with same configuration across AWS, GCP, Azure | Abstractcloud differences, ease migration |
| Rapid Prototyping | Idea → deployment time critical | Minimal time for K8s production environment setup |
4.2 When to Continue Using Helm/Kustomize
| Condition | Situation Description | Recommended Tool |
|---|---|---|
| Existing Helm Ecosystem | Already operating dozens of Helm charts | Continue Helm (migration cost > benefit) |
| Complex CRD/Operator | ArgoCD, Sealed Secrets, Istio etc. CRD-based deployment | Helm/Kustomize (full CRD support) |
| Extreme Customization | Each service requires completely different deployment structure | Helm (maximum flexibility) |
| Chart Packaging/Distribution | Distributing Helm charts to different teams/externally | Helm (Helm Registry ecosystem) |
| Enterprise Policy | Company standard is Helm usage | Continue Helm |
Pro Tip: Since Kanvas is new, organizations with large existing Helm investments are recommended to adopt a hybrid approach. Run new services with Kanvas, existing services with Helm, then gradually transition.
5. Architecture Deployment Flow Diagram
Below is a visualization of the Kanvas processing flow from Docker Compose to Kubernetes deployment:
┌─────────────────────────────────────────────────────────────────┐
│ Docker Compose │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ version: '3.8' │ │
│ │ services: │ │
│ │ api: ... │ │
│ │ postgres: ... │ │
│ │ redis: ... │ │
│ └────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
│
│ Kanvas Parser
↓
┌─────────────────────────────────────────────────────────────────┐
│ Compose Parser & Analysis Engine │
│ • Service extraction (name, image, ports, env) │
│ • Dependency graph generation (depends_on) │
│ • Network topology analysis │
│ • Volume mount information extraction │
│ • Security policy analysis │
└─────────────────────────────────────────────────────────────────┘
│
│ Kubernetes Generator
↓
┌─────────────────────────────────────────────────────────────────┐
│ Generation Rule Engine (Production Best Practices) │
│ ┌─────────────────────────┬──────────────────────────────────┐ │
│ │ • Resource estimation │ • Health check configuration │ │
│ │ • Replica count (3+) │ • Rolling update strategy │ │
│ │ • Storage class select │ • Network policy generation │ │
│ │ • Security config │ • Monitoring config (Prometheus) │ │
│ │ • Logging integration │ • Labels/annotations addition │ │
│ └─────────────────────────┴──────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
│
│ Cloud Profile Mapper
↓
┌─────────────────────────────────────────────────────────────────┐
│ Cloud Profile Conversion (AWS/GCP/Azure) │
│ ┌───────────┬───────────┬──────────┬──────────────────────────┐ │
│ │ AWS │ GCP │ Azure │ Generic K8s │ │
│ ├───────────┼───────────┼──────────┼──────────────────────────┤ │
│ │ ALB │ GCE LB │ AppGW │ NGINX Ingress │ │
│ │ EBS gp3 │ PD SSD │ Managed │ Standard Storage │ │
│ │ ECR │ GCR │ ACR │ Docker Hub │ │
│ │ KMS │ Cloud KMS │ Vault │ Sealed Secrets │ │
│ └───────────┴───────────┴──────────┴──────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
│
│ Manifest Generation
↓
┌─────────────────────────────────────────────────────────────────┐
│ Generated Kubernetes Artifacts (auto-optimized) │
│ ├─ Deployment (with Resource Requests/Limits) │
│ ├─ Service (ClusterIP/LoadBalancer/NodePort) │
│ ├─ ConfigMap (environment configuration) │
│ ├─ Secret (sensitive data) │
│ ├─ PersistentVolumeClaim (storage) │
│ ├─ Ingress (external access) │
│ ├─ NetworkPolicy (traffic control) │
│ ├─ ServiceAccount + RBAC (permissions) │
│ └─ PrometheusRule (monitoring) │
└─────────────────────────────────────────────────────────────────┘
│
│ Multi-Output Generation
↓
┌──────────────┬────────────────┬──────────────────┐
↓ ↓ ↓ ↓
┌─────────────┐ ┌────────────┐ ┌─────────────┐ ┌──────────────┐
│ Kubernetes │ │ Terraform │ │ Pulumi │ │ Docker │
│ YAML │ │ IaC │ │ IaC │ │ Compose │
│ (kubectl) │ │ (apply) │ │ (deploy) │ │ (reference) │
└─────────────┘ └────────────┘ └─────────────┘ └──────────────┘
│
│ Deployment
↓
┌─────────────────────────────────────────────────────────────────┐
│ Production Kubernetes Cluster Deployment │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ Production (AWS EKS / GCP GKE / Azure AKS) │ │
│ │ • Pods running with auto-scaling │ │
│ │ • Service mesh (Istio) integration (optional) │ │
│ │ • Monitoring + Logging + Tracing enabled │ │
│ │ • GitOps (ArgoCD) driven updates │ │
│ └──────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
6. Performance and Optimization Metrics
Quantitative improvements you can expect with actual adoption:
| Metric | Previous (Helm) | Kanvas | Improvement |
|---|---|---|---|
| Deployment Time (Compose → K8s) | 4-6 hours | 15-30 minutes | 92-95%↓ |
| Configuration Code (per service) | 500-800 lines | Auto (0 lines) | 100%↓ |
| Learning Curve (new team member) | 8-12 weeks | 1-2 weeks | 80-90%↓ |
| Deployment Error Rate | 5-10% | 0.5-1% | 80-90%↓ |
| Operations Team Size | 2-3 (DevOps) | 0.5 (automation) | 75%↓ |
| Cloud Migration | 2-4 weeks/cloud | 1-2 days/cloud | 90%↓ |
7. Important Considerations for Actual Adoption
7.1 Maturity-Related Cautions
Kanvas is a new tool released in January 2026. Compared to Helm (10+ years) and Kustomize (8+ years), the validation period is insufficient. Therefore, the following phased adoption is recommended:
- Phase 1 (Validation): Test Kanvas in internal development/test environment for 3-6 months. Discover bugs and provide feedback.
- Phase 2 (Gradual): Deploy to staging environment. Verify stability in production-like environment.
- Phase 3 (Selective): Start production deployment with non-mission-critical services.
- Phase 4 (Full-scale): Deploy all new services with Kanvas. Gradually transition existing services.
Caution: For mission-critical services (payments, authentication, customer data processing), it's recommended to continue using Helm until Kanvas is sufficiently validated.
7.2 Customizing Auto-Generated Resources
You may need to modify Kubernetes resources that Kanvas automatically generated. The following extension mechanisms are provided:
# Kanvas extension configuration (kanvas-overrides.yaml)
apiVersion: kanvas.docker.io/v1
kind: Overrides
metadata:
name: api-overrides
spec:
services:
api:
# Override auto-generated resources
deployment:
spec:
replicas: 5 # Change from default 3 to 5
strategy:
rollingUpdate:
maxSurge: 2 # Change from default 1 to 2
# Add additional resources
additionalResources:
- apiVersion: v1
kind: PodDisruptionBudget
metadata:
name: api-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: api
- apiVersion: policy/v1
kind: NetworkPolicy
metadata:
name: api-network-policy
spec:
podSelector:
matchLabels:
app: api
ingress:
- from:
- podSelector:
matchLabels:
app: web
ports:
- protocol: TCP
port: 8080
7.3 Existing Compose File Compatibility
Not all Docker Compose syntax is supported in Kanvas. Below is the compatibility matrix:
| Feature | Kanvas Support | Notes |
|---|---|---|
| service.image | ✓ Full | Local builds require separate configuration |
| service.ports | ✓ Full | Protocol auto-detected |
| service.environment | ✓ Full | Auto-classified to ConfigMap + Secret |
| service.volumes | ⚠️ Partial | Named volumes only, bind mounts need modification |
| service.depends_on | ✓ Full | Supported, condition evaluation limited |
| service.command/entrypoint | ✓ Full | Direct conversion |
| service.networks | ✓ Full | Converted to NetworkPolicy |
| service.healthcheck | ⚠️ Partial | Created as default HTTP probe, customization needed |
| service.restart_policy | ⚠️ Partial | Only always/on-failure supported, delay ignored |
| service.build | ✗ Not Supported | Pre-build and push image required |
| service.extends | ✗ Not Supported | Only explicitly defined content processed |
7.4 Migration Checklist
Kanvas Migration Checklist
□ Preparation Phase
□ Verify Kanvas production release (minimum 1.0 GA)
□ Team training and PoC environment setup
□ Update Docker Desktop (latest version)
□ Check existing Compose file compatibility
□ File Preparation
□ Review docker-compose.yml
□ Identify unsupported features (build, extends, bind mounts)
□ Separate sensitive data environment variables (process as Secrets)
□ Verify image registry configuration
□ Deployment Testing
□ Verify visualization in Kanvas Designer
□ Review generated Kubernetes YAML
□ Verify auto resource requests/limits appropriateness
□ Validate health check configuration
□ Production Preparation
□ Deploy test in staging environment
□ Configure monitoring (Prometheus/Loki)
□ Verify logging integration
□ Review security policy (NetworkPolicy, RBAC)
□ Production Deployment
□ Establish rollback plan
□ Configure pre/post-deployment performance metrics
□ Set up team on-call system
□ Enhance monitoring after deployment
7.5 Decision Tree: Kanvas vs Helm
Here's a decision tree to determine whether to choose Kanvas or Helm based on your organization's situation:
Starting Point: Select Deployment Tool?
│
┌────────────┴────────────┐
↓ ↓
"Do you have existing No
Helm investment?"
│
┌────────┴────────┐
↓ ↓
YES NO
│ │
│ "Are you developing
│ with Docker
│ Compose?"
│ │
│ ┌───────┴───────┐
│ ↓ ↓
│ YES NO
│ │ │
Helm → Continue │ Other tools
with Hybrid │ (Kube manifests?)
Helm │ │
│ ┌───────┴───────────┐
│ ↓ ↓
│ "Automate K8s "CRD/Operator
│ resources?" based deployment?"
│ │ │
│ ┌───┴────┐ ┌────┴────┐
│ ↓ ↓ ↓ ↓
│ YES NO YES NO
│ │ │ │ │
│ □ └─→ □─→ │ └─→ Kanvas
│ Kanvas config Helm recommend
│ recommend needed recommend OR
│ │ OR
│ "Very complex Kanvas
│ customization?"
│ │
│ ┌───────┴──────┐
│ ↓ ↓
│ YES NO
│ │ │
│ └──→ Helm ←───┘
│ recommend
Conclusion:
• Kanvas recommended: Docker Compose-based development, auto K8s deployment
• Helm recommended: Existing investment or very complex customization needed
• Hybrid approach: Existing services with Helm, new services with Kanvas
8. Frequently Asked Questions (FAQ)
Q1: Exactly how is Kanvas different from Kompose?
Kompose: A CLI tool that mechanically converts Compose syntax to Kubernetes YAML in a 1:1 manner. Converted results typically lack production sufficiency, requiring manual addition of resource requests/limits, health checks, security configuration, etc.
Kanvas: Applies production optimization automatically during conversion. Resource profiling, health checks, security configuration, monitoring integration are included by default. Also provides visual architecture design, multi-cloud support, and IaC generation capabilities.
Simply needing Compose-to-K8s YAML conversion makes Kompose sufficient. But for full deployment pipeline automation, Kanvas is much more efficient.
Q2: Is Docker Desktop subscription mandatory?
Kanvas is provided as a Docker Hub extension, so using it in Docker Desktop is recommended for convenience. However, since Kanvas is based on the open source Layer5 Meshery project, independent installation is also possible.
Docker Desktop is a paid subscription model, but the Kanvas feature itself is free.
Q3: Can it be used with ArgoCD?
Yes, it's possible. You can commit the Kubernetes YAML or Terraform IaC that Kanvas generates to a Git repository, and configure ArgoCD to automatically deploy it.
# ArgoCD + Kanvas workflow
1. Write docker-compose.yml
2. kanvas deploy --generate-yaml > k8s-manifests/
3. git commit k8s-manifests/
4. ArgoCD polls Git and auto-deploys
# ArgoCD Application definition
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: myapp
spec:
source:
repoURL: https://github.com/org/repo
path: k8s-manifests/ # Kanvas generated folder
destination:
server: https://kubernetes.default.svc
namespace: default
Q4: Is it compatible with Istio/service mesh?
Yes, it's compatible. Kanvas provides an extension mechanism to add Istio VirtualService, DestinationRule, and other CRDs to the generated Kubernetes YAML.
Q5: Can I apply it directly to production?
Not recommended. As a new tool, it's safer to thoroughly validate in development/staging environments for at least 3-6 months, then gradually introduce it to production starting with non-mission-critical services.
9. Conclusion and Recommendations
Docker Kanvas is a tool that dramatically lowers the entry barrier from Compose to Kubernetes. It's strongly recommended for the following organizations in particular:
- Teams developing with Docker Compose and considering Kubernetes adoption
- Startups/small teams without dedicated DevOps engineers
- Organizations where rapid prototyping → production deployment is critical
- Enterprises wanting to automate multi-cloud deployment
- Teams wanting to reduce Helm chart management burden
On the other hand, Helm/Kustomize are still more suitable in the following cases:
- Organizations that have already built Helm ecosystems
- Cases requiring complex CRD/Operator-based deployment
- Cases requiring very high levels of customization
- Business models that distribute Helm charts externally
Final Recommendation: Since it's a new tool, a hybrid approach is recommended. Operate existing services with Helm, but pilot-test new services with Kanvas while gradually transitioning. This is the wisest strategy, maintaining existing stability while gaining new technology benefits.
As Kanvas matures and community usage examples increase, it has high potential to become a new standard in Kubernetes deployment automation. Now is the time to carefully review adoption considering your organization's situation.
This article was written with AI technology assistance. For more cloud-native engineering insights, visit the ManoIT Tech Blog.
Top comments (0)