Pre-Deployment Checklist
Goal
Verify that your Kubernetes cluster and supporting infrastructure meet all requirements before starting a Keymate platform installation. Completing this checklist prevents the most common deployment failures: insufficient resources, missing credentials, DNS misconfiguration, and TLS provisioning issues.
Audience
Platform engineers and operators responsible for preparing the target environment for a Keymate deployment.
Prerequisites
- A provisioned Kubernetes cluster (managed or self-managed)
kubectlconfigured with administrative access to the target cluster- Access to DNS management for your domain
- Access to credential stores or secrets management
Before You Start
Run through this checklist in order. Each category builds on the previous one. If any item fails, resolve it before proceeding to the installation guides.
Do not skip the resource capacity check. Keymate deploys multiple components across four layers. Clusters that are too small cause pods to remain in Pending state or get evicted under load.
Checklist
1. Kubernetes Cluster
| Item | What to verify | How to check |
|---|---|---|
| Cluster is running and accessible | kubectl can connect and list nodes | kubectl get nodes |
| Kubernetes version is compatible | Cluster runs a supported Kubernetes version | kubectl version --short |
| RBAC enabled | The cluster has Role-Based Access Control active | kubectl auth can-i create deployments |
| Admin access confirmed | Your kubeconfig grants cluster-admin or equivalent privileges | kubectl auth can-i '*' '*' |
| Storage class available | At least one default StorageClass exists for persistent volumes | kubectl get storageclass |
2. Resource Capacity (CPU / Memory / Storage)
Keymate deploys components across four layers. Each layer requires dedicated compute and storage resources.
| Layer | Minimum CPU | Minimum Memory | Persistent Storage |
|---|---|---|---|
| Infrastructure (service mesh, cert-manager, operators) | 2 cores | 4 GB | — |
| Data (databases, caches, message brokers) | 4 cores | 8 GB | 50 GB SSD |
| Application (identity, authorization, gateway, services) | 4 cores | 8 GB | 10 GB |
| Observability (telemetry collector, dashboards) | 2 cores | 4 GB | 50 GB SSD |
| Total minimum | 12 cores | 24 GB | 110 GB SSD |
These are minimum values for a single-environment deployment. Production environments with high availability, multiple replicas, and significant workload need proportionally more resources. Plan for at least 2x the minimums for production.
Verify available cluster capacity:
kubectl top nodes
If the cluster does not have sufficient capacity, add nodes or increase node sizes before proceeding.
3. Networking
| Item | What to verify | How to check |
|---|---|---|
| Ingress controller installed | An ingress controller (reverse proxy or cloud-managed) is running | kubectl get pods -A | grep ingress |
| Load balancer available | The cluster can provision external load balancers (or use NodePort/MetalLB for on-prem) | kubectl get svc -A | grep LoadBalancer |
| Inter-pod communication | Pods can communicate across namespaces | Deploy a test pod and verify connectivity |
| Outbound internet access | Cluster nodes can reach external registries and services (skip for air-gapped) | kubectl run test --image=busybox --rm -it -- wget -qO- https://example.com |
4. DNS
| Item | What to verify | How to check |
|---|---|---|
| Domain configured | You have allocated a domain or subdomain for Keymate services (e.g., keymate.example.com) | Confirm with your DNS administrator |
| Wildcard or individual records | DNS records point to the ingress controller's external IP or load balancer | dig keymate.example.com |
| DNS propagation complete | Records resolve correctly from outside the cluster | nslookup keymate.example.com |
5. TLS Certificates
| Item | What to verify | How to check |
|---|---|---|
| cert-manager installed (automated) | cert-manager is running and can issue certificates | kubectl get pods -n cert-manager |
| ClusterIssuer configured | You have set up a ClusterIssuer for Let's Encrypt or your internal CA | kubectl get clusterissuer |
| OR manual certificates ready | TLS certificate and private key files are available for manual provisioning | Verify files exist and are not expired |
| Certificate covers required domains | The certificate includes all platform endpoint domains | openssl x509 -in cert.pem -noout -text | grep DNS |
6. Credentials and Secrets
| Item | What to verify | Notes |
|---|---|---|
| Database credentials | Username, password, host, port, and database name for all required databases | Required for identity provider and authorization engine |
| Cache credentials | Connection details for the distributed cache | Required for session and token caching |
| SMTP configuration | SMTP server, port, username, and password for email notifications | Required if email-based flows are enabled |
| TLS certificate and key | Certificate chain and private key if not using cert-manager | Required for manual TLS provisioning |
| Container registry access | Credentials for pulling Keymate container images | Required if using a private registry |
Do not store credentials in plain text in Git repositories or Helm values files. Use Kubernetes Secrets, an external secrets operator, or your organization's secrets management solution.
7. Backup Strategy
| Item | What to verify | Notes |
|---|---|---|
| Database backup plan | You have defined a backup schedule and retention policy for persistent databases | Critical for disaster recovery |
| Backup storage configured | The backup destination (object storage, NFS, or cloud-managed backup) accepts writes | Verify write access |
| Restore procedure tested | You have validated at least one restore from backup | Test before going to production |
8. Organizational Readiness
| Item | What to verify | Notes |
|---|---|---|
| Deployment model chosen | Team has decided between Helm-based or GitOps-based installation | See Deployment Models |
| Team access confirmed | All team members who will perform the installation have cluster access | Verify RBAC roles |
| Rollback plan defined | The team knows how to roll back to the previous state if the deployment fails | Document the rollback procedure before starting |
| Maintenance window scheduled | If deploying to a shared cluster, schedule a maintenance window | Reduces blast radius of any issues |
Validation Scenario
Scenario
A platform engineer runs through the complete checklist before starting a Keymate installation on a new AKS cluster.
Expected Result
- All checklist items pass or have documented exceptions
- Cluster has at least 12 cores, 24 GB memory, and 110 GB SSD available
- DNS resolves to the ingress endpoint
- TLS certificates are provisioned or cert-manager is ready
- All credentials reside in Kubernetes Secrets
- The team has documented and tested the backup strategy
How to Verify
- Run each
kubectlcommand listed in the checklist tables - Document any items that require follow-up
- Do not proceed to installation until all required items pass
Troubleshooting
- Insufficient resources. If
kubectl top nodesshows low available capacity, add nodes or increase node sizes. For managed Kubernetes, use the cloud provider's scaling features. - DNS not resolving. Verify that DNS records point to the correct load balancer IP. Check TTL values — propagation can take time.
- cert-manager not issuing certificates. Check cert-manager logs:
kubectl logs -n cert-manager deploy/cert-manager. Common causes: DNS challenge failures and rate limiting from Let's Encrypt. - Cannot pull container images. Verify you have configured registry credentials as an
imagePullSecretin the target namespaces.
Next Steps
After completing the checklist:
- Helm-Based Installation — Install with Helm
- GitOps-Based Installation — Install with ArgoCD
- Deployment Best Practices — Review production recommendations