Major, as every chart in this rollout is: networkPolicy.enabled defaults to
true, so the object reaches running releases on the next upgrade.
The simplest policy of the sweep, and the one to read first. CyberChef is a
static web app - nginx serves files, the recipes run in the visitor's browser,
the pod holds no state and calls nothing - so what the policy buys is the two
CEILINGS rather than any source restriction: inbound is capped at 8080, the
single port the pod declares, and outbound at DNS, which is as tight as the
object goes without breaking name resolution.
The 8080 rule carries no source selector by default, and that is deliberate
rather than an oversight: 8080 is the port all three probes address, and the
kubelet probes from the IP of the worker node running the pod, which no chart
can know. Guessing it wrong leaves the pod permanently un-Ready, a symptom that
reads as a broken application. Narrowing it is networkPolicy.probeSources, and
the restricted branch then also carries the ingress controller - measured as
the rke2-traefik DaemonSet in kube-system, which serves this chart's HTTPRoute
as well, since the same Traefik backs the Gateway API here.
Part of #5
The Gateway-API pilot of Gitea #114: one chart, the convention, the CI that
holds it. The remaining 20 charts follow in their own PRs.
The form, additive and off by default:
httpRoute:
enabled: false # counterpart to ingress.enabled
parentRefs: [] # the Gateway - a platform object
hostnames: [] # empty = [ingress.domain]
Only HTTPRoute with parentRefs is rendered: no Gateway, no gatewayClassName,
no Certificate, and no implementation-specific policy object. That subset is
identical on nginx-gateway-fabric, Cilium, Envoy Gateway and Istio, which is
what lets the implementation be chosen later without touching the charts
again. Class and certificate move to the platform.
Four guards, all against silent failures:
- mutually exclusive with ingress.enabled, with a render abort naming BOTH
value paths. A migration runs over a second hostname, not in parallel.
- parentRefs mandatory in Gateway mode, render abort on the empty list: a
route without a parent is created, is schema-valid, and routes nothing.
- hostnames empty means [ingress.domain], so the hostname has one source.
- the mode is a VALUE, not auto-detection: .Capabilities.APIVersions is
unreliable at template time and a missing CRD fails at install time.
ingress.clusterIssuer was already only read inside the Ingress template, so
the "conditionally required" half of #114 needed no change in this chart -
checked rather than assumed, and it has to be re-checked per chart in the
sweep.
CI, both halves, because neither covers the other:
- the install-test installs cyberchef in GATEWAY mode against the REAL
Gateway-API CRDs (standard channel v1.6.3, pinned and Renovate-tracked,
applied --server-side). A schema-less stub would accept a malformed route
and prove only that something was created. The Ingress path of this one
chart is no longer installed; it is a built-in type that never routed in
k3d anyway, and helm lint renders this chart's defaults - Ingress mode -
on every PR.
- ci/run-httproute-match-test.sh, over every chart on every PR: every
backendRefs entry must name a Service, on a port, that the SAME render
creates, and parentRefs must not be empty. The CRDs accept both of those
mistakes, so the schema cannot catch them, and the only report would be a
route status no controller writes in CI.
What stays unprovable, and is written down instead of implied: that traffic
flows. No Gateway controller runs in k3d.
Minor: additive with unchanged defaults, proven by an empty helm template
diff against origin/main for the default values.
Part of #114
Three changes, all about values that do not do what they promise:
1. Ingress gate (#93): the Ingress template is wrapped in
{{- if .Values.ingress.enabled }}. The key already existed in
values.yaml with default true but was never read, so switching it off
did nothing. Both required() calls for domain and clusterIssuer live
inside the Ingress file, so gating also removes the contradiction that
one had to supply a domain and issuer in order to turn off an Ingress
one does not want.
2. Null-safety for hardening, probes and resources (#99): an override
written without children is YAML null and erased the whole default
sub-tree, rendering "securityContext: null" - an unhardened container
that starts and reports healthy.
3. values.schema.json types (#68 + #99): the blocks covered by the
null-safety accept null. This is load-bearing only for keys that have
no chart default (e.g. resources.limits): there Helm has nothing to
delete, so the null survives into schema validation and a strict
"object" type rejected it outright.
Rendering with normal values is byte-identical to 7.0.0.
additionalProperties: false on every chart-owned object level, so a key
the chart does not read is rejected at render time instead of being
silently ignored. Objects passed verbatim into the pod spec (probes,
securityContext, global) stay open - Kubernetes owns their schema there.
Major bump: a schema can break existing deployments that carry dead keys.
Refs #68
jklein