xref etcd-io/etcd#13766

announcement of the bug's impact at k-dev:
https://groups.google.com/a/kubernetes.io/d/msgid/dev/CAJs3Yt0WKgyUFL%3D1V13ojZPvV9_Qsa8WXLeohUxhRjEK07P25g%40mail.gmail.com?utm_medium=email&utm_source=footer

With recent reproduction of data inconsistency issues in #13766, etcd maintainers are no longer recommending v3.5 releases for production. In our testing we have found that if the etcd process is killed under high load, occasionally some committed transactions are not reflected on all the members. The problem affects versions v3.5.0, v3.5.1, v3.5.2.

(note: the bug in question in relatively rare)

add the etcd flag --experimental-initial-corrupt-check to all kubeadm versions that use etcd 3.5.x by default.
1.24 (master), 1.23, 1.22.

--experimental-initial-corrupt-check 'false'
  Enable to check data corruption before serving any client/peer traffic.

1.24 timeframe

add the --experimental-initial-corrupt-check flag to versions of kubeadm that use etcd 3.5.[0-2]

• 1.24 kubeadm: add etcd flag for member data consistency kubernetes#109074
• 1.23 Automated cherry pick of #109074: kubeadm: add etcd flag for member data consistency kubernetes#109075
• 1.22 Automated cherry pick of #109074: kubeadm: add etcd flag for member data consistency kubernetes#109076

1.25 timeframe

backport a 3.5.3+ bump to kubeadm versions in support.
aligns with #2567 too.

• Automated cherry pick of #110033: etcd: Updated to v3.5.4 kubernetes#110377
• Automated cherry pick of #110033: etcd: Updated to v3.5.4 kubernetes#110376
• Automated cherry pick of #110033: etcd: Updated to v3.5.4 kubernetes#110375

** future work **

etcd 3.6 (or 4.0?) may graduate the flag / feature to --initial-corrupt-check, thus once we upgrade kubeadm to that etcd version we should switch to the new flag as well.

• wait for graduation of the flag to stable:
  • Stabilize experimental corruption check etcd-io/etcd#9190