fix(kubestellar): stop KubeFlex ControlPlane status hot loop

[castrojo]

Summary

Upgrade the GitOps-managed KubeStellar core chart from 0.29.0 (KubeFlex v0.9.1) to 0.30.0 (KubeFlex v0.9.3) and document the live failure mode and retired nginx endpoint.

Verified causal chain

• kubectl get ingressclass returned no classes; wds1-system/wds1 is an owner-referenced generated Ingress with ingressClassName: nginx, empty status.loadBalancer, and an unchanged resourceVersion during a 10-second loop sample.
• The canonical upstream detector, kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx, returns No resources found; there is no controller to claim this object.
• The live wds1 ControlPlane is nevertheless Ready=True, and its PostCreateHook templates contain only RBAC, ConfigMap, Service, Deployment, and Job resources — no Ingress. KubeFlex creates the endpoint in its type-specific reconciler, outside PostCreateHooks.
• KubeFlex v0.9.1 logs repeatedly ended with failed to update final status: ... object has been modified; this is the observed requeue signal. The sustained ~6.5 Mbps RX is controller status/reconcile traffic, not external ingress traffic.

Upstream networking policy

ADR-0004 says external reachability is unnecessary for this lab. The Kubernetes Steering and Security Response Committees' Ingress NGINX retirement statement says: "There will be no more releases for bug fixes, security patches, or any updates of any kind after the project is retired" and warns that remaining on retired Ingress NGINX leaves users vulnerable. Kubernetes' Ingress Controllers documentation says: "The Kubernetes project recommends using Gateway instead of Ingress. The Ingress API has been frozen." We therefore do not install ingress-nginx, point the object at another IngressClass, or install Gateway API/controller components for an unused endpoint. If external reachability is needed later, use the Gateway API getting-started guidance.

Fix / follow-up

Use the newer core chart/KubeFlex operator release through ArgoCD. The v0.9.3 chart values have no ingress-disable switch; the generated endpoint is upstream KubeFlex behavior. Upstream opt-out request: kubestellar/kubeflex#709. If status conflicts persist after rollout, the remaining code fix belongs upstream rather than in an ingress manifest. External reachability remains off by default.

Validation

• just lint passes.
• helm template ... core-chart --version 0.30.0 passes.
• Live ArgoCD sync and post-rollout log/Prometheus verification remain pending: the live Application is still on 0.29.0 because the local ArgoCD proxy is unavailable.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

[castrojo]

Live verification update

Before the PR can be merged, the live app is still core-chart 0.29.0 (kubectl -n argocd get application kubestellar: Synced/Healthy, targetRevision 0.29.0). just argocd-sync could not connect to the local ArgoCD proxy (localhost:8443).

The baseline Prometheus query returned 816587.7448 bytes/s for kubeflex-controller-manager over [10m] (about 6.53 Mbps), matching the reported 6.5 Mbps. Logs still show the failed to update final status ... object has been modified loop. Post-merge ArgoCD rollout must re-run the log and Prometheus checks.