Niklas Ye
6a699d4341
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.
32 lines
1.6 KiB
Markdown
32 lines
1.6 KiB
Markdown
# Exposing a TerdutServer
|
|
|
|
This operator never manages external exposure/ingress for `TerdutServer`,
|
|
in any form — a permanent non-goal (`DESIGN.md` §1), not a missing
|
|
feature. Some installs won't expose it outside the cluster at all (see
|
|
`examples/demo`, which just port-forwards); others will put it behind
|
|
whatever their cluster already uses. That choice is entirely yours, not
|
|
the operator's.
|
|
|
|
The only contract the operator gives you to build on: a plain `ClusterIP`
|
|
Service, named after the `TerdutServer` CR (same name, same namespace),
|
|
with a port named `http` (`spec.networking.servicePort`, default `8080`).
|
|
Everything here targets exactly that Service — none of it is applied by
|
|
`examples/demo`'s `kustomization.yaml`, and none of it depends on anything
|
|
the operator creates beyond that one Service.
|
|
|
|
Pick whichever matches your cluster:
|
|
|
|
- **`httproute.yaml`** — a [Gateway API](https://gateway-api.sigs.k8s.io/)
|
|
`HTTPRoute`, attached to a `Gateway` you already have.
|
|
- **`istio-virtualservice.yaml`** — an Istio `VirtualService`, attached to
|
|
a `Gateway` (Istio's own CRD, not Gateway API's) you already have.
|
|
- **A plain `Ingress`** needs no example here — it's the same idea with
|
|
one fewer layer of indirection: an `Ingress` with a single rule whose
|
|
`backend.service.name`/`port.name` point at the `TerdutServer`'s Service
|
|
and `http` port.
|
|
|
|
Remember to set `spec.networking.hostname` on the `TerdutServer` itself to
|
|
whatever hostname you expose it on — that's not read by the operator for
|
|
any of this, but terdut-server uses it for its own absolute links
|
|
(notifications, OIDC redirect URIs).
|