Skip to content

chore(kaap): upgrade operator + CRDs to 0.4.4 for modern k8s (1.33+)#7

Open
dcbouius wants to merge 1 commit into
mainfrom
chore/kaap-0.4.4-modern-k8s
Open

chore(kaap): upgrade operator + CRDs to 0.4.4 for modern k8s (1.33+)#7
dcbouius wants to merge 1 commit into
mainfrom
chore/kaap-0.4.4-modern-k8s

Conversation

@dcbouius

Copy link
Copy Markdown

Why

KAAP 0.3.0 cannot reconcile against a Kubernetes 1.33+ API server (incl. GKE 1.35). Its bundled fabric8 kubernetes-client parses the /version response strictly and throws UnrecognizedPropertyException: Unrecognized field "emulationMajor" before creating/reconciling any Pulsar resource. The operator pod stays Ready with 0 restarts but is silently inert — this is why KAAP went dead on upgraded prod EKS, and it blocks the GKE migration.

What

Brings helm/kaap to upstream 0.4.4 (the fork carried no local deltas from 0.3.0):

  • operator image datastax/kaap:0.3.00.4.4 (newer fabric8 client tolerates emulationMajor)
  • refreshed all 8 CRDs to 0.4.4 — they declare securityContext etc. that the 0.4.4 operator emits; stale CRDs stall reconcile with field not declared in schema
  • RBAC split into templates/rbac/{cluster-scoped,namespace-scoped}.yaml, gated on a new operator.watchAllNamespaces flag (default false = namespaced watch, same scope as before). configmap.yaml sets JOSDK_WATCH_CURRENT when namespaced
  • operator template gains nodeSelector/tolerations passthrough
  • bump kaap-stack dependency to 0.4.x; regenerate Chart.lock

helm lint clean; umbrella renders operator 0.4.4 + namespaced Role carrying the kaap.oss.datastax.com CR grants.

Validated

GKE 1.35 dev: 0.4.4 operator + 0.4.4 CRDs stood up a healthy Pulsar (zk+bookie+broker+bastion, pulsar-admin brokers healthcheck = ok), then LangStream + a sample app passed an end-to-end produce→agent→consume test.

⚠️ Deploying to an existing cluster

  1. Helm does not upgrade CRDs (crds/ installs only on first install). Apply the 0.4.4 CRDs manually first — server-side is required (they exceed the client-side annotation limit):
    kubectl apply --server-side --force-conflicts -f helm/kaap/crds/
    
  2. In-place upgrade on a live Pulsar may roll the STS pods — adopting existing zk/bookie/broker StatefulSets, the operator may compute a securityContext diff and trigger a rolling restart. Treat as a maintenance window and let each tier recover before the next. (Not exercised in the demo — fresh cluster.)
  3. Keep operator.watchAllNamespaces: false for prod to preserve the current namespaced watch scope.

KAAP 0.3.0 cannot reconcile on Kubernetes 1.33+ (incl. GKE 1.35): its
bundled fabric8 client fails to parse the API server /version response
(Unrecognized field "emulationMajor"), so the operator throws before
creating any Pulsar resources — silently inert on upgraded clusters.

Brings helm/kaap to upstream 0.4.4 (fork carried no local deltas):
- operator image datastax/kaap:0.3.0 -> 0.4.4 (newer fabric8 client)
- refreshed all 8 CRDs to 0.4.4 (declare securityContext etc. that the
  0.4.4 operator emits; stale CRDs stall reconcile on typed-patch errors)
- split RBAC into cluster-scoped/namespace-scoped, gated on new
  operator.watchAllNamespaces flag (default false = namespaced watch,
  same scope as before). configmap sets JOSDK_WATCH_CURRENT accordingly
- operator template gains nodeSelector/tolerations passthrough
- bump kaap-stack dependency to 0.4.x + regenerate Chart.lock

NOTE: helm does not upgrade CRDs on `helm upgrade` (crds/ only installs
on first install). Existing clusters must `kubectl apply --server-side`
the 0.4.4 CRDs before/with the operator bump.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant