|
| 1 | +# Karpenter OCI GitOps Deployment Guide |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +This guide documents the GitOps deployment architecture for Karpenter NodePool manifests and the resolution of deployment issues encountered during the OCI 429 rate limiting solution implementation. |
| 6 | + |
| 7 | +## GitOps Architecture |
| 8 | + |
| 9 | +### Repository Structure |
| 10 | +``` |
| 11 | +karpenter/ |
| 12 | +├── manifests/ |
| 13 | +│ ├── nodepool-production.yaml # Production workload NodePool |
| 14 | +│ ├── nodepool-default.yaml # Default/test workload NodePool |
| 15 | +│ ├── nodepool-kafka.yaml # Kafka workload NodePool |
| 16 | +│ ├── service-account.yaml # Karpenter service account |
| 17 | +│ └── kustomization.yaml # Manifest selection for OCI compatibility |
| 18 | +├── helm/karpenter-oci/ # Helm chart for Karpenter controller |
| 19 | +└── karpenter-nodepools-kustomization.yaml # Flux kustomization definition |
| 20 | +``` |
| 21 | + |
| 22 | +### Deployment Flow |
| 23 | +``` |
| 24 | +Git Repository (start-io branch) |
| 25 | + ↓ |
| 26 | +Flux GitRepository Source |
| 27 | + ↓ |
| 28 | +Flux Kustomization (karpenter-nodepools) |
| 29 | + ↓ |
| 30 | +Kubernetes NodePool Resources |
| 31 | + ↓ |
| 32 | +Karpenter Controller |
| 33 | +``` |
| 34 | + |
| 35 | +## Flux Configuration |
| 36 | + |
| 37 | +### GitRepository Source |
| 38 | +```yaml |
| 39 | +apiVersion: source.toolkit.fluxcd.io/v1 |
| 40 | +kind: GitRepository |
| 41 | +metadata: |
| 42 | + name: karpenter |
| 43 | + namespace: flux-system |
| 44 | +spec: |
| 45 | + interval: 1m |
| 46 | + ref: |
| 47 | + branch: start-io |
| 48 | + url: https://github.com/startappdev/karpenter |
| 49 | +``` |
| 50 | +
|
| 51 | +### Kustomization Resource |
| 52 | +```yaml |
| 53 | +apiVersion: kustomize.toolkit.fluxcd.io/v1 |
| 54 | +kind: Kustomization |
| 55 | +metadata: |
| 56 | + name: karpenter-nodepools |
| 57 | + namespace: flux-system |
| 58 | +spec: |
| 59 | + interval: 5m |
| 60 | + path: ./manifests |
| 61 | + prune: true |
| 62 | + sourceRef: |
| 63 | + kind: GitRepository |
| 64 | + name: karpenter |
| 65 | + namespace: flux-system |
| 66 | + targetNamespace: karpenter |
| 67 | + timeout: 2m |
| 68 | +``` |
| 69 | +
|
| 70 | +## Deployment Issues Resolved |
| 71 | +
|
| 72 | +### Issue 1: EC2NodeClass Compatibility |
| 73 | +**Problem**: Kustomization failed with "no matches for kind EC2NodeClass" error |
| 74 | +**Root Cause**: Manifests directory contained AWS-specific NodePool definitions |
| 75 | +**Solution**: Created `manifests/kustomization.yaml` to include only OCI-compatible resources: |
| 76 | + |
| 77 | +```yaml |
| 78 | +apiVersion: kustomize.config.k8s.io/v1beta1 |
| 79 | +kind: Kustomization |
| 80 | +
|
| 81 | +resources: |
| 82 | +- nodepool-default.yaml |
| 83 | +- nodepool-kafka.yaml |
| 84 | +- nodepool-production.yaml |
| 85 | +- service-account.yaml |
| 86 | +
|
| 87 | +namespace: karpenter |
| 88 | +``` |
| 89 | + |
| 90 | +### Issue 2: Missing Service Account |
| 91 | +**Problem**: Kustomization failed looking for `service-account.yaml` |
| 92 | +**Root Cause**: Service account managed by Helm chart, not available as standalone manifest |
| 93 | +**Solution**: Created dedicated `manifests/service-account.yaml`: |
| 94 | + |
| 95 | +```yaml |
| 96 | +apiVersion: v1 |
| 97 | +kind: ServiceAccount |
| 98 | +metadata: |
| 99 | + name: karpenter |
| 100 | + namespace: karpenter |
| 101 | + labels: |
| 102 | + app.kubernetes.io/name: karpenter |
| 103 | + app.kubernetes.io/component: controller |
| 104 | +automountServiceAccountToken: true |
| 105 | +``` |
| 106 | + |
| 107 | +### Issue 3: Branch Mismatch |
| 108 | +**Problem**: Existing kustomization referenced master branch instead of start-io |
| 109 | +**Root Cause**: Legacy kustomization `oci-ash-stg-apps` used wrong Git source |
| 110 | +**Solution**: Created dedicated kustomization targeting correct repository and branch |
| 111 | + |
| 112 | +## Best Practices |
| 113 | + |
| 114 | +### GitOps Compliance |
| 115 | +- ✅ All changes via Git commits |
| 116 | +- ✅ Flux reconciliation for deployments |
| 117 | +- ✅ No manual `kubectl apply` commands |
| 118 | +- ✅ Version controlled configuration |
| 119 | + |
| 120 | +### Kustomization Design |
| 121 | +- Separate kustomizations for different resource types |
| 122 | +- Explicit resource inclusion (avoid wildcards) |
| 123 | +- Proper namespace targeting |
| 124 | +- Cloud provider compatibility validation |
| 125 | + |
| 126 | +### Deployment Validation |
| 127 | +```bash |
| 128 | +# Check kustomization status |
| 129 | +flux get kustomizations -A |
| 130 | +
|
| 131 | +# Verify resource application |
| 132 | +kubectl get nodepool -n karpenter -o yaml |
| 133 | +
|
| 134 | +# Monitor deployment logs |
| 135 | +flux logs --kind=Kustomization --name=karpenter-nodepools |
| 136 | +``` |
| 137 | + |
| 138 | +## Troubleshooting Commands |
| 139 | + |
| 140 | +```bash |
| 141 | +# Force reconciliation |
| 142 | +flux reconcile kustomization karpenter-nodepools -n flux-system |
| 143 | +
|
| 144 | +# Check Git source status |
| 145 | +flux get sources git -A |
| 146 | +
|
| 147 | +# View kustomization events |
| 148 | +kubectl describe kustomization karpenter-nodepools -n flux-system |
| 149 | +
|
| 150 | +# Validate resource deployment |
| 151 | +kubectl get nodepool -n karpenter -o json | jq '.items[] | {name: .metadata.name, disruption: .spec.disruption}' |
| 152 | +``` |
| 153 | + |
| 154 | +## Success Metrics |
| 155 | + |
| 156 | +### Deployment Success |
| 157 | +- ✅ Kustomization status: Applied revision start-io@de5aca8a |
| 158 | +- ✅ All NodePools updated with disruption configuration |
| 159 | +- ✅ Zero manual interventions required |
| 160 | + |
| 161 | +### Configuration Validation |
| 162 | +- ✅ production-pool: consolidateAfter=Never, budgets="0" |
| 163 | +- ✅ default-pool: consolidateAfter=Never, budgets="0" |
| 164 | +- ✅ kafka-pool: consolidateAfter=Never, budgets="0" |
| 165 | + |
| 166 | +This GitOps architecture enables reliable, version-controlled deployment of Karpenter NodePool configurations while maintaining cloud provider compatibility and operational best practices. |
0 commit comments