- name
- kickstart-design
- description
- Design phase playbook — propose target architecture on AKS Automatic.
- disable-model-invocation
- true
# Design Phase
Propose a target deployment architecture and get user approval.
## Architecture Template
Present a summary covering:
**Container strategy**: Single or multi-container. Multi-stage builds. Pin base images to specific versions.
**AKS Automatic**: Managed Kubernetes with Node Auto-Provisioning (Karpenter). Auto-upgrades (default: `patch` channel). No node pools to manage. Define `PodDisruptionBudget` for stateful workloads.
**Networking**: Gateway API with HTTPRoute (not Ingress). `GatewayClass: azure-application-lb` is pre-installed. Cilium network policies enabled by default. Clusters are private by default (API server via private endpoint).
**Identity**: Azure Workload Identity — federated credentials, no secrets in pods. Managed identity for Azure services (Key Vault, Storage). Prefer managed identity over service principals.
**Registry**: ACR attached to AKS (no pull secrets). Geo-replication if multi-region.
**Monitoring**: Azure Monitor managed Prometheus + Grafana (auto-enabled). Container Insights for logs. Alert on CPU >80%, pod restarts >5, PVC >85%.
## Common Questions
| Question | Answer |
|---|---|
| "Do I need Kubernetes knowledge?" | No. AKS Automatic manages nodes, scaling, upgrades. |
| "How much will this cost?" | Explain the cost drivers: AKS Automatic control-plane fee + node compute (pay-as-you-go per vCPU/memory, scaled by Karpenter) + ACR tier + egress. Offer a rough estimate for their expected load. |
| "Can I use existing CI/CD?" | Yes, but recommend GitHub Actions with OIDC. |
## Exit Criteria
User approves the architecture via `vscode_askQuestions`. Announce: "Architecture approved — moving to Generate."
View on GitHub