Use MaxUnavailable for PDB

[mrkm4ntr]

We should use MaxUnavailable for simplicity.

// MaxUnavailable can only be used if the selector matches a builtin controller selector
// (eg. Deployments, StatefulSets, etc.). We cannot use it with our own cluster-name selector.

This comment was written by this reason. According to this, maxUnavailable can be used only when selected pods are managed by only 1 StatefulSet. But it's not true. We can use maxUnavailable for the case multiple StatefulSets are managing selected pods. See here.

If this change is valid, I will change the document as well.

[barkbay]

Interesting, thanks for your suggestion! While I think you're right, I'm a bit on the fence with that change for the following reasons:

• I'm wondering if we want to keep that idea that Elasticsearch Pods are actually controlled by the ECK operator, and using StatefulSets should be an implementation detail which may change in the future.
• Do we know if that case (1 pdb with several built-in controllers) is covered by some unit tests in the pdb controller? You mentioned a comment, but I would like to know if we have any guarantee that this logic is not going to change (The K8s documentation is not really clear, so I'm trying to understand if we are not in a corner case that may no longer be supported at some point).

[mrkm4ntr]

I'm wondering if we want to keep that idea that Elasticsearch Pods are actually controlled by the ECK operator, and using StatefulSets should be an implementation detail which may change in the future.

If ECK will stop to use StatefulSet, I think we will create new CRD for managing each NodeSet like current StatefulSet does. If so, that CRD can have scale subresource then we can use maxUnavailable.

Do we know if that case (1 pdb with several built-in controllers) is covered by some unit tests in the pdb controller? You mentioned a comment, but I would like to know if we have any guarantee that this logic is not going to change (The K8s documentation is not really clear, so I'm trying to understand if we are not in a corner case that may no longer be supported at some point).

Unfortunately no. But I feel current implementation is really straightforward. I hope they won't introduce a breaking change in this...