Helm – Operator Pod https://operatorpod.net Wed, 09 Sep 2026 09:22:05 +0000 en-US hourly 1 https://wordpress.org/?v=7.1.3 257694118 Writing Production-Ready Helm Values for Kubernetes Controllers https://operatorpod.net/writing-production-ready-helm-values/ https://operatorpod.net/writing-production-ready-helm-values/#respond Wed, 09 Sep 2026 09:22:05 +0000 https://operatorpod.net/writing-production-ready-helm-values/ Packaging Kubernetes operator controllers with Helm requires careful consideration of security, high availability, and upgrade safety. A robust values.yaml design pattern ensures that production clusters remain resilient across multi-zone outages.

1. Enforcing Pod Anti-Affinity

If an operator controller runs with multiple replicas for active-passive leader election, scheduling both replicas on the same physical Kubernetes worker node creates a single point of failure. Use preferredDuringSchedulingIgnoredDuringExecution to spread replicas across failure domains.

2. Dropping Linux Capabilities

Most operator pods only interact with the Kubernetes apiserver over HTTPS. They do not require elevated Linux capabilities like NET_ADMIN or SYS_PTRACE. Dropping all capabilities and mounting the root filesystem as read-only satisfies the highest compliance tier of the Kubernetes Pod Security Standards.

]]> https://operatorpod.net/writing-production-ready-helm-values/feed/ 0 16