Let TerdutServer customize its pod, and never manage its own ingress

spec.pod (api/v1alpha1/terdutserver_types.go): annotations, nodeSelector, tolerations, affinity, topologySpreadConstraints, resources, pod and container securityContext, serviceAccountName, extraEnv/extraEnvFrom, extraVolumes/extraVolumeMounts, imagePullSecrets, and an optional disruptionBudget. All direct corev1 passthrough -- no wrapper types buy anything for any of these, matching how CloudNativePG and the Zalando postgres-operator both expose the same knobs, and matching this repo's own SweeperSpec precedent ("wrap only when a round-trip through a different type buys something"). affinity is pure user-supplied passthrough, not a toggle-plus-generated-default the way a multi-replica cluster operator's pod anti-affinity usually is: this operator never auto-generates one, since spec.replicas above 1 isn't a supported topology (the sweeper/notifier singleton constraint). Considered and declined for this round: priorityClassName, pod labels beyond annotations, and a HorizontalPodAutoscaler -- the last of those would directly contradict the singleton constraint above. disruptionBudget is the one field here that isn't a plain PodTemplateSpec knob: when set, the controller now reconciles a PodDisruptionBudget selecting the TerdutServer's own pods (new terdutserver_pdb.go); clearing it deletes any it previously created. New RBAC marker on poddisruptionbudgets to match. Driven by a public-release pass: looking past this project's own use case at what a mature, general-purpose operator CRD exposes here (researched against Zalando postgres-operator and CloudNativePG specifically), not just the fields this install happened to need. Separately, and found while answering a question about exposing TerdutServer through Istio instead of Gateway API: spec.networking's own doc comment quietly promised a Gateway API HTTPRoute this operator would build eventually ("a near-term follow-up, not deferred"). That promise is wrong for a public release -- an operator managing someone's ingress mechanism for them is a worse default than not touching it at all, and a surprise HTTPRoute appearing once that follow-up eventually landed would have been exactly backwards for an Istio (or plain-Ingress, or intentionally-unexposed) install. Made the non-goal explicit and permanent instead (DESIGN.md §1), removed the dead `gatewayListener` field it was the only consumer of (zero runtime call sites anywhere -- setting it already had no effect, so this is a schema cleanup, not a behavior change), and corrected ROADMAP.md's framing. hostname/servicePort stay: both are live (TERDUT_PUBLIC_URL, container/Service port), this operator just never acts on hostname for exposure. Added examples/networking (Gateway API HTTPRoute, Istio VirtualService) showing how to expose the plain ClusterIP Service the operator already creates -- outside the operator itself, as illustrations, not as something examples/demo applies automatically. No new terdut-server version requirement: both changes are CRD/controller- only, nothing about the API this operator's bootstrap flow depends on changed.
2026-10-02 18:50:38 +02:00
parent d9315322fc
commit 6a699d4341
20 changed files with 8631 additions and 96 deletions
@@ -2,11 +2,11 @@
 # this directory (teams, escalation rules, dead man's switches, alert
 # sources) references it by name.
 #
-# networking.hostname is accepted but not yet acted on: creating the
-# HTTPRoute for it isn't implemented yet (api/v1alpha1/terdutserver_types.go,
-# NetworkingSpec's own doc comment) -- this TerdutServer is reachable from
-# outside the cluster only by port-forwarding its Service, same name as
-# this object (see README.md).
+# The operator never creates any ingress/HTTPRoute for this TerdutServer --
+# that's a permanent non-goal (DESIGN.md §1, NetworkingSpec's own doc
+# comment), not a missing feature. This demo reaches it only by
+# port-forwarding its Service, same name as this object (see README.md);
+# see ../networking for worked examples of exposing it yourself instead.
 apiVersion: terdut.ryuvia.com/v1alpha1
 kind: TerdutServer
 metadata:
@@ -59,15 +59,16 @@ of it should settle within a reconcile interval or two.

 ## See the web UI

-The operator doesn't create any external exposure yet
-(`NetworkingSpec`'s own doc comment in `api/v1alpha1/terdutserver_types.go`
-— `spec.networking.hostname` is accepted but nothing acts on it), so:
+The operator never creates any external exposure for a `TerdutServer` --
+that's a permanent non-goal (DESIGN.md §1), not a missing feature, so this
+demo just reaches it the simplest way there is:

 ```sh
 kubectl -n terdut-operator-demo port-forward svc/terdut-operator-demo 8080:8080
 ```

-and open http://localhost:8080.
+and open http://localhost:8080. See `../networking` for worked examples of
+exposing it for real (Gateway API, Istio, or a plain `Ingress`) instead.

 ### First login