- Kubeadm: modified the etcd static Pod `liveness` and `readiness` probes to use a new etcd `v3.5.3+` HTTP(s) health check endpoint `/health?serializable=true` that allows to track the health of individual etcd members and not fail all members if a single member is not healthy in the etcd cluster. ([#110072](https://github.com/kubernetes/kubernetes/pull/110072), [@neolit123](https://github.com/neolit123))

}

// Type and constants for component health validation.
type ComponentConditionType string

// These are the valid conditions for the component.
const (
	ComponentHealthy ComponentConditionType = "Healthy"
)

// Information about the condition of a component.
type ComponentCondition struct {
	// Type of condition for a component.
	// Valid value: "Healthy"

message ComponentCondition {
  // Type of condition for a component.
  // Valid value: "Healthy"
  optional string type = 1;

  // Status of the condition for a component.
  // Valid values for "Healthy": "True", "False", or "Unknown".
  optional string status = 2;

  // Message about the condition for a component.
  // For example, information about a health check.
  // +optional
  optional string message = 3;

	"type":    "Type of condition for a component. Valid value: \"Healthy\"",
	"status":  "Status of the condition for a component. Valid values for \"Healthy\": \"True\", \"False\", or \"Unknown\".",
	"message": "Message about the condition for a component. For example, information about a health check.",
	"error":   "Condition error code for a component. For example, a health check error code.",
}

## Changelog since v1.18.18

## Changes by Kind

### API Change

- We have added a new Priority & Fairness rule that exempts all probes (/readyz, /healthz, /livez) to prevent 
  restarting of "healthy" kube-apiserver instance(s) by kubelet. ([#101114](https://github.com/kubernetes/kubernetes/pull/101114), [@tkashem](https://github.com/tkashem)) [SIG API Machinery]

### Bug or Regression

message ComponentCondition {
  // Type of condition for a component.
  // Valid value: "Healthy"
  optional string type = 1;

  // Status of the condition for a component.
  // Valid values for "Healthy": "True", "False", or "Unknown".
  optional string status = 2;

  // Message about the condition for a component.
  // For example, information about a health check.
  // +optional
  optional string message = 3;

components, but only worked when those components were local to the API server, and when kube-scheduler and kube-controller-manager exposed unsecured health endpoints. Instead of this API, etcd health is included in the kube-apiserver health check and kube-scheduler/kube-controller-manager health checks can be made directly against those components' health endpoints. ([#93570](https://github.com/kubernetes/kubernetes/pull/93570), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Cluster...

During server startup, prior to the server reporting healthy (via `/healthz`), not all API groups may be reported.
Wait for the server to report healthy (via `/healthz`) before depending on the information provided by the discovery APIs.

- We have added a new Priority & Fairness rule that exempts all probes (/readyz, /healthz, /livez) to prevent 
  restarting of "healthy" kube-apiserver instance(s) by kubelet. ([#101111](https://github.com/kubernetes/kubernetes/pull/101111), [@tkashem](https://github.com/tkashem)) [SIG API Machinery]

### Feature

- A new API server flag `--encryption-provider-config-automatic-reload` was added to control when the encryption config should be automatically reloaded without needing to restart the server.  All KMS plugins are now merged into a single healthz check at `/healthz/kms-providers` when reload is enabled, or when only KMS v2 plugins are used. ([#113529](https://github.com/kubernetes/kubernetes/pull/113529), [@enj](https://github.com/enj))