一、前言¶
本文主要介绍一下二进制安装k8s集群。同时在此之前浅谈一下k8s高可用架构，介绍一下各组件作用。
声明:以下过程都是本人自己亲自部署验证!
二、k8s高可用架构¶
2.1 k8s高可用架构图¶
k8s分为Master节点和Node节点，Master节点是控制节点，Node节点是工作节点。其中，Master节点包含kube-apiserver、kube-scheduler、kube-controller-manager、etcd、kubelet、kube-proxy；Node节点包含kubelet、kube-proxy。
关于Master节点和Node节点介绍如下:
1.Master节点-控制节点
指容器编排层，它暴露 API 和接口来定义、 部署容器和管理容器的生命周期。管理集群中的工作节点和 Pod。在生产环境中，控制平面通常跨多台计算机运行， 一个集群通常运行多个节点，提供容错性和高可用性。
2.Node节点-工作节点
托管 Pod，而 Pod 就是作为应用负载的组件,是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。每个集群至少有一个工作节点。
下面根据Kubernetes 组件进行介绍:
1.Master组件
(1)kube-apiserver
API 服务器是 Kubernetes 控制平面的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。
Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。
(2)etcd
一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。一般可以安装在Master节点上，如果资源充足，也可安装到单独的服务器上。
(3)kube-scheduler
kube-scheduler 是控制平面的组件， 负责监视新创建的、未指定运行节点node的 Pods， 并选择节点来让 Pod 在上面运行。
调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。
(4)kube-controller-manager
kube-controller-manager 是控制平面的组件， 负责运行控制器进程。
从逻辑上讲， 每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。
这些控制器包括：
- 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
- 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
- 端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）。
- 服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）
(5)kubelet
kubelet 会在集群中每个节点(node)上运行。 它保证容器containers都运行在 Pod 中。这里之所以放在Master节点组件里面，客观上说Master也属于node。
kubelet 接收一组通过各类机制提供给它的 PodSpecs， 确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。
(6)kube-proxy
kube-proxy是集群中每个节点(node)上所运行的网络代理， 实现 Kubernetes 服务(Service)概念的一部分。
kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。
如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。
2.Node组件
(1)kubelet
kubelet 会在集群中每个节点(node)上运行。 它保证容器containers都运行在 Pod 中。这里之所以放在Master节点组件里面，客观上说Master也属于node。
kubelet 接收一组通过各类机制提供给它的 PodSpecs， 确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。
(2)kube-proxy
kube-proxy是集群中每个节点(node)上所运行的网络代理， 实现 Kubernetes 服务(Service)概念的一部分。
kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。
如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。
2.2 k8s高可用架构分析¶
这里负载均衡采用KeepAlived和HAProxy实现高可用，当然了，你也可以使用公有云的负载均衡和F5实现高可用。当采用KeepAlived和HAProxy实现高可用时，会虚拟出一个VIP，用于组件之间的交互。
当kube-scheduler、kube-controller-manager、kubelet、kube-proxy组件想访问kube-apiserver时，必须要经过负载均衡再进行访问kube-apiserver，从而实现了高可用。
针对etcd组件，只有kube-apiserver组件才能与其进行交互，kube-scheduler、kube-controller-manager、kubelet、kube-proxy组件不能直接与etcd组件进行交互。
三、k8s集群安装方式对比¶
一般我们可以使用两种方式来安装k8s集群:Kubeadm方式和二进制方式。
关于二者区别说明如下:
1.安装方式不同：使用 kubeadm 创建的 Kubernetes 集群是使用预先打包好的二进制文件安装的，而使用二进制安装则需要手动下载和安装二进制文件。
2.部署步骤不同：使用 kubeadm 部署 Kubernetes 集群可以更加自动化，且容易维护，而使用二进制安装则需要手动配置一些组件，需要更多的部署步骤。
3.可维护性不同：使用 kubeadm 部署的 Kubernetes 集群可以使用 kubeadm 工具进行维护，如升级和添加节点，更加方便，而使用二进制安装则需要手动管理和维护。
4.社区支持不同：kubeadm 是 Kubernetes 的官方工具，有更好的社区支持，可以获得更多的文档和帮助，而使用二进制安装则需要更多的自学和实践。