StatefulSet [page]deterministic

`apiVersion: apps/v1`

`import "k8s.io/api/apps/v1"`

## StatefulSet {#StatefulSet}

StatefulSet represents a set of pods with consistent identities. Identities are defined as: - Network: A single stable DNS and hostname. - Storage: As many VolumeClaims as requested.

The StatefulSet guarantees that a given network identity will always map to the same storage identity.

<hr>

<table> <thead><tr><th>Field</th><th>Description</th></tr></thead> <tbody> <tr> <td><code>apiVersion</code><br/><em>string</em></td> <td>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</td> </tr> <tr> <td><code>kind</code><br/><em>string</em></td> <td>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</td> </tr> <tr> <td><code>metadata</code><br/><em><a href="">ObjectMeta</a></em></td> <td>Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</td> </tr> <tr> <td><code>spec</code><br/><em><a href="">StatefulSetSpec</a></em></td> <td>Spec defines the desired identities of pods in this set.</td> </tr> <tr> <td><code>status</code><br/><em><a href="">StatefulSetStatus</a></em></td> <td>Status is the current status of Pods in this StatefulSet. This data may be out of date by some window of time.</td> </tr> </tbody> </table>

## StatefulSetSpec {#StatefulSetSpec}

A StatefulSetSpec is the specification of a StatefulSet.

<hr>

<table> <thead><tr><th>Field</th><th>Description</th></tr></thead> <tbody> <tr> <td><code>minReadySeconds</code><br/><em>integer</em></td> <td>Minimum number of seconds for which a newly created pod should be ready without any of its container crashing for it to be considered available. Defaults to 0 (pod will be considered available as soon as it is ready)</td> </tr> <tr> <td><code>ordinals</code><br/><em><a href="">StatefulSetOrdinals</a></em></td> <td>ordinals controls the numbering of replica indices in a StatefulSet. The default ordinals behavior assigns a "0" index to the first replica and increments the index by one for each additional replica requested.</td> </tr> <tr> <td><code>persistentVolumeClaimRetentionPolicy</code><br/><em><a href="">StatefulSetPersistentVolumeClaimRetentionPolicy</a></em></td> <td>persistentVolumeClaimRetentionPolicy describes the lifecycle of persistent volume claims created from volumeClaimTemplates. By default, all persistent volume claims are created as needed and retained until manually deleted. This policy allows the lifecycle to be altered, for example by deleting persistent volume claims when their stateful set is deleted, or when their pod is scaled down.</td> </tr> <tr> <td><code>podManagementPolicy</code><br/><em>string</em></td> <td>podManagementPolicy controls how pods are created during initial scale up, when replacing pods on nodes, or when scaling down. The default policy is `OrderedReady`, where pods are created in increasing order (pod-0, then pod-1, etc) and the controller will wait until each pod is ready before continuing. When scaling down, the pods are removed in the opposite order. The alternative policy is `Parallel` which will create pods in parallel to match the desired scale without waiting, and on scale down will delete all pods at once.<br/><br/>Possible enum values:<br/> - `"OrderedReady"` will create pods in strictly increasing order on …(trimmed)