Aleksei Sviridkin
548d33f01f
A transient proxy.golang.org HTTP/2 stream reset fails an image build outright: Go's default GOPROXY falls back to direct only on a 404 or 410. Image builds now get GOPROXY=https://proxy.golang.org|direct as a build arg from hack/common-envs.mk, declared by every Go builder stage, so any proxy error falls back to fetching from the origin. The value comes from IMAGE_GOPROXY rather than the host's GOPROXY, which may name a mirror that buildkit cannot reach. The alpine golang images carry no git, so in their stages a module hosted on GitHub cannot be fetched directly and the retry is the cover. Explicit `go mod download` steps retry three times with a growing pause. The loop is inline, in one form the contract test pins: the images build from different contexts, so no shared script can be copied in, and a named build context in the shared buildx arguments makes buildx refuse every Dockerfile pinned to a frontend older than dockerfile:1.4. The two alpine stages that left the download to `go build` get the same download step, because without git neither the fallback nor a retry covered them. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <f@lex.la>
lineage-controller-webhook
Cozystack system package for the lineage controller webhook — a mutating
admission webhook that stamps "lineage" labels onto tenant workloads, linking
each resource back to the Cozystack Application that ultimately owns it.
The webhook intercepts CREATE and UPDATE on pods, secrets, services,
persistentvolumeclaims, ingresses.networking.k8s.io, and
workloadmonitors.cozystack.io outside system namespaces. For each request it
walks the ownership graph upward (Kubernetes ownerReferences, then the
HelmRelease Flux installed the resource with, then the Cozystack
Application-derived CRD that produced the HelmRelease) and writes the
discovered application's group, kind and name as labels
(apps.cozystack.io/application.{group,kind,name}) on the incoming object.
Those labels let the aggregated API server, the Cozystack dashboard, and other
lineage-aware consumers reason about which application a resource belongs to.
The webhook serves TLS on port 9443 with a cert-manager issued certificate, and
runs with failurePolicy: Fail — every CREATE/UPDATE on the resources above
is gated on the webhook being reachable.
Topology
The chart ships a single shape, modelled on cozystack-api:
- Deployment with two replicas (override via
replicas). - Soft
nodeAffinitypreferringnode-role.kubernetes.io/control-plane(Exists, so it matches both Talos's empty value and k3s/kubeadm's"true"). Soft means: the pod lands on a control-plane node when one is reachable, and on any worker otherwise — no override needed for managed Kubernetes, Cozy-in-Cozy tenants, or any other cluster where control-plane nodes aren't visible. - Permissive
tolerations([{operator: Exists}]) so the pod can land on tainted control-plane nodes when the soft affinity is satisfiable. - Soft
podAntiAffinityonkubernetes.io/hostnameso replicas spread across nodes when possible (best-effort). PodDisruptionBudgetwithmaxUnavailable: 1, unconditional. Atreplicas: 1it's a useful no-op (allows full drain); atreplicas >= 2it caps disruption to one pod.Servicewithspec.trafficDistribution: PreferCloseso the apiserver prefers a webhook endpoint on its own node when one exists, and transparently falls over to a remote endpoint otherwise. Requires Kubernetes ≥ 1.31; on older clusters the field is silently ignored and traffic uses default cluster-wide distribution.
Parameters
All keys live under the top-level lineageControllerWebhook: map.
| Name | Description | Value |
|---|---|---|
image |
Container image (digest-pinned) | ghcr.io/cozystack/cozystack/lineage-controller-webhook:v1.3.0@sha256:e898…6fb0 |
debug |
Enable --zap-log-level=debug instead of info |
false |
replicas |
Deployment replica count | 2 |
resources |
Container requests/limits; {} renders no key |
{} |
localK8sAPIEndpoint.enabled |
Deprecated. See note below. | false |
localK8sAPIEndpoint.enabled (deprecated)
When enabled, this injects KUBERNETES_SERVICE_HOST=status.hostIP and
KUBERNETES_SERVICE_PORT=6443 so the webhook talks to the kube-apiserver on
its own node. It was originally added to avoid latency on the
webhook-to-apiserver path, but it is only valid when the pod is actually
scheduled on an apiserver-bearing node — which the chart's soft control-plane
affinity no longer guarantees. With this flag enabled and the pod scheduled
off a control-plane node, the controller will crash-loop dialing a non-
apiserver hostIP. Slated for removal once the latency motivation is addressed
in the webhook itself; leave disabled.