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

[dcbouius]

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.0 → 0.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.

[dcbouius]

Review: LGTM — prod-ready with a 3-step pre-flight

The operator/CRD/RBAC changes are sound, and the namespaced-watch scope is preserved correctly (watchAllNamespaces: false default + JOSDK_WATCH_CURRENT in the configmap + the gated RBAC split). One deploy gap found, and the biggest prod risk was checked and cleared.

Prod deploy checklist (existing cluster)

1. Apply 0.4.4 CRDs first, server-side — Helm never upgrades crds/, and the 0.4.4 operator emits fields (e.g. securityContext) the 0.3.0 CRDs don't declare, which stalls reconcile with field not declared in schema:

   kubectl apply --server-side --force-conflicts -f helm/kaap/crds/
   

2. Rebuild the subchart before upgrading — the regenerated Chart.lock / packaged subchart isn't in this PR, so a cached charts/kaap-0.3.0.tgz could silently redeploy the old operator. Run:

   helm dependency update helm/kaap-stack   # and clear any stale charts/kaap-0.3.0.tgz
   

3. Then upgrade, keeping operator.image: datastax/kaap:0.4.4 and operator.watchAllNamespaces: false.

securityContext roll risk — checked, non-issue

The "in-place upgrade may roll the STS on a securityContext diff" caveat was verified empirically against the GKE dev cluster running this 0.4.4 build: the operator generated the ZK and bookkeeper StatefulSets with {fsGroup: 0}, no runAsUser, no container securityContext — byte-identical to what prod runs under 0.3.0 today. The GKE PulsarCluster sets no explicit securityContext (so it's the operator default) and runs the same apachepulsar/pulsar:3.0.12 image as prod, making it a faithful analog.

Consequence: no ownership change, no recursive chown on the large bookie volume, no UID switch, no data-permission risk, and no securityContext-driven roll. Any restart during adoption would be benign template normalization. This downgrades the prod apply from a careful maintenance window to a routine operator upgrade.

Minor (non-blocking)

values.yaml also bumps the default global.image lunastreaming 2.10_3.1 → 4.0_3.6. Prod overrides this with apachepulsar/pulsar:3.0.12, so no prod effect — just noting an unrelated default riding in an operator-upgrade PR.