In Kubernetes (K8s for short), there are different mechanisms for different components in order to achieve high availability (HA):

kube-apiserver High Availability Principles:

Load balancing: In a cluster, multiple instances of kube-apiserver are usually deployed and a unified entry point is provided externally through a load balancer (e.g., a cloud provider's load balancing service or a hardware load balancer, or internal software such as NGINX, etc.). This ensures that even if a single API server fails, other healthy API servers will still be able to process requests, ensuring service continuity.

Shared storage: All API server instances are typically connected to the same highly available ETCD cluster, which persists the state information of the entire Kubernetes cluster. Therefore, no matter which API server responds to a client request, the data it reads and writes is consistent.

Health check and auto-recovery: Operations staff will configure the monitoring system to perform health checks on each API server, and will be able to restart or replace the failed node in time when an anomaly is detected.

kube-scheduler high availability principle:

Leader Election: The kube-scheduler component also supports leader election, i.e., set the startup parameter --leader-election=true. when this option is enabled, the scheduler processes will try to elect a leader between them, and the other schedulers as standby. Only the scheduler elected as leader will perform the actual scheduling tasks.

Listening to etcd state changes: all scheduler instances listen to the leader election lock in etcd to determine if there is an active scheduler leader, and once the current leader fails, the rest of the schedulers will initiate a new round of election to determine a new leader.

Fast switching: When the leader scheduler fails, the other schedulers can quickly sense it and reelect it, which makes the scheduling service almost uninterrupted.

In summary, both kube-apiserver and kube-scheduler of Kubernetes achieve high availability by means of a distributed system, which ensures that the core control plane services of the cluster can still run stably even if some components fail.