Docs: Kubernetes self-hosting: note which StatefulSets have boundaries/constraints/minimums/maximums and why

(#4147) Feature Open: Under consideration packaging self-hosting

Current problem

Current kubernetes installation (helm chart) uses many StatefulSets (some at default 1 replica), which negate the point of Kubernetes in most cases (resilience against node failure). It is not clear why the StatefulSets are not Deployments with RWO PVCs or otherwise.

Proposed change

Please document, for each StatefulSet:
  1. Why the StatefulSet is a StatefulSet and not a Deployment with other constraints (RWO PVC, Scaling and Upgrade policy [Rolling Update vs Recreate], etc) so the design is clear to operators
  2. What boundaries each StatefulSet has (maximum replicas, minimum replicas, replica counts (odd-number sensitivity?), storage considerations, etc)
  3. How to selectively disable StatefulSet instantiation for StatefulSets that can be swapped-out by the operator, and what (ClusterIP?) service names and ports (+protocols) would need to be exposed as the "interface" in the namespace if an operator replaces a StatefulSet with their own implementation (e.g. postgres with cnpg?)

Platform

Self-hosting

Additional information

Comments

Sign in with Fluxer to comment and vote.

No comments yet.