Kubernetes to Azure Container Apps - Assessment Guide
Compatibility Matrix
Kubernetes → Container Apps Resource Mapping
| Kubernetes Concept | Container Apps Equivalent | Supported | Notes |
|---|---|---|---|
| Deployment | Container App | ✅ Yes | One-to-one mapping for stateless workloads |
| Service (ClusterIP) | Internal ingress | ✅ Yes | Set ingress.external: false |
| Service (LoadBalancer) | External ingress | ✅ Yes | Set ingress.external: true |
| Ingress | Built-in ingress with custom domain | ✅ Yes | Supports TLS, traffic splitting |
| ConfigMap | Environment variables | ✅ Yes | Inline or from secrets |
| Secret | Secrets (Key Vault refs preferred) | ✅ Yes | Use managed identity for Key Vault |
| CronJob | Container Apps Job (scheduled) | ✅ Yes | Cron expression syntax |
| Job | Container Apps Job (manual/event) | ✅ Yes | One-time or event-triggered |
| HPA | Built-in scaling rules | ✅ Yes | HTTP, TCP, KEDA-compatible scalers |
| PersistentVolumeClaim | Azure Files mount | ⚠️ Limited | EmptyDir and Azure Files only; no block storage |
| DaemonSet | N/A | ❌ No | Consider sidecar containers or external agents |
| StatefulSet | N/A | ❌ No | Use external state (Cosmos DB, Redis, SQL) |
| Custom CRDs / Operators | N/A | ❌ No | Evaluate if Dapr components can replace |
| NetworkPolicy | VNet NSG rules | ⚠️ Limited | Configure at Environment subnet level |
Resource Limits
| Resource | Kubernetes (typical) | Container Apps Maximum | Migration Impact |
|---|---|---|---|
| CPU per container | Up to 64+ vCPU | 4 vCPU | Split large containers |
| Memory per container | Up to 256+ GiB | 8 GiB | Redesign memory-intensive workloads |
| Replicas per app | 1000+ | 300 per revision | Validate scale requirements |
| Request timeout | Configurable (hours+) | 240 seconds default | Redesign long-running requests |
| Startup probe timeout | Configurable | 240 seconds | Optimize startup time |
| Containers per pod/app | 10+ | Up to 10 sidecars | Init + sidecar containers supported |
Unsupported Patterns
Critical Blockers
- StatefulSets with persistent storage
- Why: Container Apps is designed for stateless workloads
- Alternative: Migrate state to Azure Cosmos DB, Azure SQL, Redis, or Storage
- DaemonSets for node-level agents
- Why: No node-level access in managed environment
- Alternative: Use Azure Monitor agents, Dapr components, or sidecar containers
- Privileged containers or host networking
- Why: Security isolation in managed platform
- Alternative: Redesign to avoid host-level access
- Custom CRDs and Operators
- Why: No Kubernetes API server access
- Alternative: Use Dapr state management, bindings, or Azure PaaS services
- Direct Kubernetes API calls from apps
- Why: Kubernetes API not exposed
- Alternative: Use environment variables, service discovery via DNS, or Dapr
Storage Considerations
- EmptyDir: Supported (ephemeral storage)
- Azure Files: Supported via volume mounts
- Persistent Block Storage: Not supported (migrate to Azure Blob, SQL, Cosmos DB)
Assessment Checklist
1. Workload Inventory
- List all Deployments, StatefulSets, DaemonSets in target namespaces
- Identify workload types: API, background worker, CronJob, StatefulSet
- Document current resource requests/limits (CPU, memory)
- Note replica counts (min, max, typical)
2. Network Configuration
- Service Types: ClusterIP (internal) vs LoadBalancer (external)
- Ingress: Document hostnames, TLS certificates, path routing rules
- Service Mesh: Document if using Istio, Linkerd (consider migrating to Dapr)
- NetworkPolicies: List egress/ingress rules (map to NSG rules or VNet integration)
3. Storage and State
- PersistentVolumeClaims: List volumes, sizes, access modes (ReadWriteOnce, ReadWriteMany)
- StatefulSets: Document state storage patterns (candidates for external state migration)
- EmptyDir/Temp Storage: Note usage patterns (supported in Container Apps)
- ConfigMaps/Secrets: Count and categorize (migrate inline or to Key Vault)
4. Scaling and Performance
- HPA: Document scaling metrics (CPU, memory, custom metrics)
- Min/Max Replicas: Verify within Container Apps limits (0-300)
- Startup Time: Measure pod startup latency (must be <240s)
- Request Patterns: Long-running requests (>240s) need redesign
5. Dependencies
- Internal Services: List service-to-service calls (use internal DNS in Container Apps)
- External Services: Databases, APIs, message queues, storage
- Authentication: Service accounts, RBAC roles (map to managed identities)
- Observability: Logging, metrics, tracing (migrate to Azure Monitor, App Insights)
6. CI/CD and Deployment
- Pipeline Tools: kubectl, Helm, Kustomize, ArgoCD, Flux
- Image Registries: Docker Hub, GCR, ECR, private registries (migrate to ACR)
- Deployment Strategy: Rolling update, blue/green, canary (Container Apps supports traffic splitting)
Complexity Assessment Guidelines
Low Complexity
- Stateless Deployments with ClusterIP or LoadBalancer Services
- Simple environment variables (no complex ConfigMaps)
- No persistent storage or external state already in use
- Standard HTTP/gRPC ingress
- No service mesh dependencies
Medium Complexity
- Multiple Deployments with inter-service communication
- ConfigMaps and Secrets requiring Key Vault migration
- HPA with custom metrics (need KEDA scaler mapping)
- CronJobs (map to Container Apps Jobs)
- Ingress with TLS and custom domains
High Complexity
- StatefulSets requiring state migration to external services
- Service mesh (Istio/Linkerd) requiring Dapr migration
- Custom CRDs or Operators (need redesign)
- NetworkPolicies requiring VNet/NSG configuration
- Large-scale deployments (>100 replicas, need architecture review)
- Workloads exceeding Container Apps resource limits (>4 vCPU, >8 GiB)
Assessment Report Structure
Generate k8s-migration-assessment.md with:
- Executive Summary: Cluster name, namespace(s), workload count, complexity (Low/Medium/High), estimated timeline, Azure cost
- Current State: Deployment inventory, resource usage, scaling config, storage usage, networking topology
- Compatibility Analysis: Supported workloads, blockers, redesign requirements (StatefulSets, DaemonSets, CRDs)
- Azure Target: Required resources (resource group, Container Apps Environment, ACR, Key Vault, Log Analytics, VNet if needed)
- Migration Plan:
- State migration strategy (databases, caches, storage)
- Image migration approach (ACR import, rebuild)
- IaC generation plan (Bicep templates per Deployment)
- Deployment sequence (dependencies first, then consumers)
- Risk Assessment: Blockers, feature gaps, performance considerations, downtime estimate
- Validation Tests: Smoke tests, integration tests, performance benchmarks