Placement and capacity
Set placement.zones to one through six unique, standard AZ names in storage.region and set azCount to the list length. replicas must be at least azCount. The operator never changes the zone list or reselects zones when capacity disappears; placement is immutable after creation.
spec: replicas: 3 storage: bucket: dedicated-example-bucket region: us-east-1 sizeGiB: 10 placement: azCount: 3 zones: [us-east-1a, us-east-1b, us-east-1c] mode: StrictStrict is the default. It uses hard zone spread (maxSkew 1, DoNotSchedule) and distinct hostnames. With three zones and three replicas, supply an eligible node in each listed zone. More replicas need enough distinct eligible hosts to satisfy anti-affinity; otherwise Pods remain Pending. For Ordered Bucket, a scheduling gate assigns each ordinal its configured zone before launch. PersistentFleet relies on the zone spread; each new volume binds in the zone where its Pod first schedules, and a retained volume keeps its member in that zone. Because the spread counts only Pods on nodes, the operator gives a member a fresh disk only after the scheduler has decided every other member’s Pod, so the new volume goes to the zone the fleet is missing rather than one a pending member’s volume needs. A member whose retained volume leaves it no allowed zone is replaced on a fresh disk after the replacement delay; see a member that cannot be scheduled.
Relaxed keeps the zone allowlist but makes spread and hostname separation preferences. It can place replicas unevenly or on a shared host, reducing fault isolation. Neither mode provisions nodes or fixes a missing zone. Check node labels, taints, capacity and Pod scheduling events before choosing Relaxed.
If you enable a capacity policy, capacity.minReplicas must be at least azCount. The policy can recommend additions and eligible contractions, but the lifecycle rules decide whether a change executes: contraction removes one member per step, only after the previous change has rolled out, and automatic contraction needs survivor-capacity evidence. Manual spec.replicas and capacity policy share the same path. See capacity policy and safety model.
Size each replica before creation
Section titled “Size each replica before creation”Use spec.execution to set CPU and memory requests and limits for the celld container. Defaults are a 250m CPU request with no CPU limit, a 512Mi memory request, and a 1Gi memory limit. Limits must be at least their requests. Optional maxResidentCells and idleEvictSeconds bound resident cells and idle hibernation; neither is a throughput guarantee.
Use spec.lifecycle to set shutdown time: shutdownSeconds defaults to 20 and terminationGraceSeconds to 30. The Pod termination grace must leave at least five seconds beyond the shutdown budget. These values configure celld’s shutdown budget and the Pod’s termination grace. They do not establish that shutdown completed safely.
Both blocks can change after creation; a change rolls the fleet one member at a time, so each Pod restarts with the new values. Choose values using application measurements. See the tuned sample and API fields. Capacity policy thresholds use absolute CPU and memory values, so review them separately when choosing resource sizes.
Experimental software for evaluation.Capabilities and limitations· Contribute