Resolves each shard topic's replica broker IDs (internal/kafka.Admin.
ReplicaBrokerIDs) to the topology.kubernetes.io/zone labels of the nodes
hosting those brokers (ZoneLocator), and writes the result into
ShardStatus.AvailabilityZones each reconcile. Uses mgr.GetAPIReader()
rather than the cached client for the Pod/Node lookups, since the cached
client would otherwise require cluster-wide list/watch RBAC on Pods just
to serve occasional point Gets.
main.go called Reconcile(ctx, req.Name) without req.Namespace, so the
Get against the namespaced Queue CRD always 404'd and was silently
swallowed as success -- no shard topics or Redis state were ever created.
Separately, ShardStatus.HashRangeStart/End were uint32, but controller-gen
maps that to OpenAPI format:int32, whose max (2147483647) is smaller than
FullHashRangeEnd (0xFFFFFFFF), so the apiserver rejected every status
update with the (misleadingly empty-looking) "must be of type integer with
format int32" error. Widened to int64, regenerated the CRD, and synced the
chart's bundled copy.
The default "longhorn" StorageClass requests 3 replicas, but the homelab
cluster currently has only 2 schedulable nodes, so the 3rd replica could
never be scheduled and volumes stayed permanently degraded. Adds
longhorn-kafka (numberOfReplicas: 2) and reduces broker PVC size so 3 broker
volumes' replicas fit within each node's remaining Longhorn scheduling
headroom. Revert to "longhorn" once a 3rd node joins.
Go's GC doesn't respect cgroup memory limits on its own, risking OOMKill
under load; set GOMEMLIMIT to ~90% of each deployment's resources.limits.memory.
Also switch imagePullPolicy to Always so :latest tags aren't served stale
from node-local cache after a new push.
Cross-file `needs:` across separate nested helmfiles didn't resolve in
Helmfile v1 (releases defined in sibling files weren't visible to each
other's dependency graph) -- confirmed live against the homelab cluster:
kafka-cluster failed with "depend(s) on an undefined release" even though
strimzi-operator had just been installed successfully by a sibling file.
Collapsed releases.d/*.gotmpl into a single helmfile.yaml.gotmpl so the
whole release graph is resolved together.
Also add a second Ingress (management-service-grpc, backend-protocol: GRPC)
scoped to the QueueService gRPC path prefix on the same host/port as the
REST ingress. kmsvc-cli dials --server directly via gRPC (default
kmsvc.homelab.internal:443 per its README), so raw gRPC needs an external
path too, not just REST -- the original "gRPC stays internal" default
didn't account for the CLI's own connection model.
Add Dockerfile.queue-operator (existed for cmd/server only before).
Local charts: kafka-cluster (Strimzi Kafka+KafkaNodePool CRs, 3-replica KRaft
topology, 5Gi memory cap, Longhorn storage, pod anti-affinity), queue-crd
(Queue CRD + queue-operator Deployment/RBAC), management-service
(Deployment/Service/ConfigMap/HPA/Ingress, REST exposed externally via
cert-manager-issued TLS, raw gRPC kept cluster-internal per design.md §7a).
helmfile.yaml.gotmpl + releases.d/*.gotmpl wire strimzi-operator ->
kafka-cluster -> redis -> {queue-crd, management-service} via `needs:`.
Directory is releases.d, not helmfile.d as originally sketched in design.md
section 7b: Helmfile v1 treats a literal "helmfile.d" directory as a special
auto-discovery mode that conflicts with an explicit top-level helmfile.yaml.
Files use .gotmpl (required by Helmfile v1 for {{ }}-templated files) and
each declares its own environments: block, since nested helmfiles don't
inherit the parent's resolved values in this version.
Namespace is sqs throughout. environments/homelab.yaml carries no secrets.
Validated locally via helm lint/helm template (all 3 charts) and
`helmfile -e homelab build` (dependency ordering + value substitution) — no
cluster contact made. Live apply is a separate, explicitly-confirmed step.
riotpiaole