Skip to content

fix(chart): allow kubelet probes on game ports, not just the agent port - #7

Merged
ValgulNecron merged 1 commit into
mainfrom
fix/helm-kubelet-probe-ports
Jun 28, 2026
Merged

ValgulNecron merged 1 commit into
mainfrom
fix/helm-kubelet-probe-ports

Conversation

@ValgulNecron

Copy link
Copy Markdown
Collaborator

Bug 9 from BUG_REPORT.md

The allow-kubelet-probes NetworkPolicy in charts/gameplane/templates/networkpolicies.yaml hardcoded its ingress to TCP 8090 (the agent port). But per-module readiness/liveness probes hit the game/status ports (Valheim 80, Terraria 7777, the Minecraft game port, …). On clusters that enforce NetworkPolicy for node-to-pod probe traffic, those probes were silently blocked even though the chart claims to allow kubelet probes.

Fix

Add networkPolicies.probePorts (default []). When empty, the ports: restriction is omitted entirely, so the kubelet — already scoped to kubeletCIDRs — can reach any port on a game pod. Operators who want to lock it down can set an explicit {protocol, port} list. Empty-means-default mirrors the existing kubeletCIDRs semantics, and the templating matches the gameEgress.ports block.

Verification

helm template renders:

  • default → no ports: field on the kubelet-probe ingress (all ports allowed)
  • --set networkPolicies.probePorts[0]... → a restricted ports: list

Covered by the chart-render CI job.

🤖 Generated with Claude Code

The allow-kubelet-probes NetworkPolicy hardcoded the ingress to TCP 8090
(the agent), but per-module readiness/liveness probes target game/status
ports (Valheim 80, Terraria 7777, the Minecraft game port, etc.), so on
clusters that enforce NetworkPolicy for node-to-pod probe traffic those
probes were blocked. Add networkPolicies.probePorts (default empty): an
empty list omits the ports restriction so the kubelet, already scoped to
kubeletCIDRs, can reach any game port; set it to lock down to a known set.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: valgulnecron <39313199+ValgulNecron@users.noreply.github.com>
@ValgulNecron
ValgulNecron merged commit 73878c3 into main Jun 28, 2026
41 of 44 checks passed
@ValgulNecron
ValgulNecron deleted the fix/helm-kubelet-probe-ports branch June 28, 2026 12:04
@ValgulNecron
ValgulNecron restored the fix/helm-kubelet-probe-ports branch June 28, 2026 12:15
@ValgulNecron
ValgulNecron deleted the fix/helm-kubelet-probe-ports branch June 30, 2026 14:26
ValgulNecron added a commit that referenced this pull request Aug 23, 2026
Fix two critical edge cases in the capture-sidecar:

1. ENOSPC from WritePacket reported as "error" instead of "disk_full" (Z2 #6):
   When a bufio flush inside WritePacket fails with ENOSPC, the error doesn't
   wrap ErrLimitReached, so it falls through to the default case and gets
   reported as a generic "error" reason. This hides the root cause from
   operators investigating truncated captures. Fixed by checking both the
   error chain and the writer's LimitReason field in the default case to
   properly distinguish disk-full from other failures.

   Added TestCaptureENOSPCDuringWritePacketReportsDiskFull to verify ENOSPC
   surfaces as disk_full reason in both the writer and the handler.

2. Process shutdown never finalizes in-flight captures (Z2 #7):
   On SIGTERM, baseCtx is cancelled, causing runCapture to return without
   calling finish(), leaving the PCAPNG writer unflushed and the file
   potentially truncated and unreadable (worst failure mode for a forensic
   tool). Fixed by:
   - Adding Server.FinalizeCurrentCapture() to safely finalize the current
     capture with a timeout, logging if the goroutine doesn't exit in time
   - Calling FinalizeCurrentCapture() in main.go after server.Shutdown()

   This ensures captures are always properly closed before process exit,
   regardless of whether shutdown is graceful or forced by the container
   orchestrator.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016EsywBB1qz8A6F68HPJpxv
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant