Make an option to create PDB for cluster

[sircthulhu]

I think we should add an option to create PDB for cluster.

 ---
 apiVersion: etcd.aenix.io/v1alpha1
 kind: EtcdCluster
 metadata:
   name: test
   namespace: ns1
 spec:
   image: "quay.io/coreos/etcd:v3.5.12"
   replicas: 3
  storage:
    persistence: true # default: true, immutable
    storageClass: local-path
    size: 10Gi
+ enablePDB:  true
 status:
   conditions:
   - lastProbeTime: null
 	lastTransitionTime: "2024-03-06T18:39:45Z"
 	status: "True"
 	type: Ready

By default it should be true meaning that PDB resource will be created with maxUnavailable field equal to the maximum number of members can die without losing quorum

[kvaps]

Shouldn't it be created automatically?

[AlexGluck]

Should we focus on the alpha2 version of the specification and stop expanding alpha1? Writing and rewriting code can be uncomfortable for developers.

[kvaps]

@AlexGluck We need to create next API version only in case if some field get removed or renamed

[sircthulhu]

@AlexGluck Creating next api version will force us to update both old and new CRD leading to even more uncomfortable development :)

See kubebuilder docs

In Kubernetes, all versions must be safely round-tripable through each other. This means that if we convert from version 1 to version 2, and then back to version 1, we must not lose information. Thus, any change we make to our API must be compatible with whatever we supported in v1, and also need to make sure anything we add in v2 is supported in v1. In some cases, this means we need to add new fields to v1, but in our case, we won’t have to, since we’re not adding new functionality.

[AlexGluck]

While we don't accepted PR #63 we can be on time move key.

[sergeyshevch]

For now we can use this specification #62 (comment) for PDB and extend it later if required