大家好，我是飘渺。从今天开始我们将正式开始Kubernetes云原生实战系列，欢迎持续关注。

Kubernets核心组件

Kubernetes中组件众多，要完全介绍清楚估计要写上厚厚一本书，我们实战系列主要记住几个核心组件就行，即两种节点，三种IP，四种资源。

两种节点

两种节点分别为控制平面master节点和工作节点worker节点，其中master节点中又有几个核心组件需要重点关注

• kube-apiserver ： 提供了资源的增、删、改、查等操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制，所有worker节点只能通过apiserver与master节点交互；
• etcd ：分布式KV数据库 ，保存了整个集群的状态；
• kube-scheduler ：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
• kube-controller-manager：负责维护集群的状态，资源对象的自动化控制中心，比如故障检测、自动扩展、滚动更新、服务帐户和令牌控制器等；

worker节点组件：

• kubelet : 负责Pod对应的容器的创建、启停等任务，与Master节点密切协作，实现集群管理的基本功能。
• kube-proxy：负责为Service提供cluster内部的服务发现和负载均衡；
• Container Runtime ：负责镜像管理以及Pod和容器的真正运行（CRI）

三种IP

Node IP ： Node 节点IP地址，Node IP 是Kubernetes集群中每个节点的物理网卡的IP地址
Pod IP : Pod的IP地址 ，是一个虚拟二层网络
Cluster IP： Service的IP地址 ，也是一个虚拟IP。

四种资源

类别	资源对象
资源对象	Pod、ReplicaSet、ReplicationController、Deployment、StatefulSet、DaemonSet、Job、CronJob、HorizontalPodAutoscaling
配置对象	Node、Namespace、Service、Secret、ConfigMap、Ingress、Label、ThirdPartyResource、 ServiceAccount
存储对象	Volume、Persistent Volume
策略对象	SecurityContext、ResourceQuota、LimitRange

虽然这里只说了核心组件，但是数量看起来并不少，一时半会要记住也不是容易事。不过没关系，咱们这里只需要记住有这么些东西即可，在上云实战篇还会反复提到，用着用着就记住了。

接下来，我们看看Kubernetes的高可用架构。

高可用架构

Kubernetes的高可用主要指的是控制平面（Master）的高可用，即指多套Master节点组件和Etcd组件，工作节点通过负载均衡器连接到各Master节点。

HA通常有如下两种架构：

高可用架构一：etcd与Master节点组件混布在一起。

高可用架构二：使用独立的Etcd集群，不与Master节点混布。

两种方式的相同之处在于都提供了控制平面的冗余，实现了集群高可以用，区别在于：

• Etcd混布方式

1. 所需机器资源少
2. 部署简单，利于管理
3. 容易进行横向扩展
4. 风险大，一台宿主机挂了，master和etcd就都少了一套，集群冗余度受到的影响比较大。

• Etcd独立部署方式：

1. 所需机器资源多（按照Etcd集群的奇数原则，这种拓扑的集群关控制平面最少需要6台宿主机了）
2. 部署相对复杂，要独立管理etcd集群和和master集群
3. 解耦了控制平面和Etcd，集群风险小健壮性强，单独挂了一台master或etcd对集群的影响很小

提示：我们使用高可用架构一 实现Kubernetes的高可用。

这里需要特别说明一下，Scheduler 和 Controller-manager 虽然在Master中部署了多个节点，但同时工作的节点只有一个，因为Scheduler 和 Controller-manager属于有状态服务，为了防止重复调度，多个节点的Scheduler 和 Controller-manager进行了选主工作，工作节点信息保存在Scheduler 和 Controller-manager的EndPoint中，可通过kubectl get leases -n kube-system查看。

负载均衡器

不管是方案一还是方案二，都需要一个负载均衡器，负载均衡器可以使用软件负载均衡器Nginx/LVS/HAProxy+KeepAlibed或硬件负载均衡器F5等，通过负载均衡器对Kube-APIServer 提供的VIP即可实现Master节点的高可用，其他组件通过该VIP链接Kube-APIServer。

我们选用的是 HAProxy+KeepAlibed 构建的负载均衡器。

最终的部署架构图如下：

架构说明

1. etcd跟master节点部署在一起，依靠master节点实现高可用
2. 通过keepalived和haproxy实现apiServer的高可用

有了上述的部署架构，接下来我们就可以规划机器了。

机器规划

主机名	IP地址	配置（CPU-内存-硬盘）	系统版本	说明
k8s-slb1	172.30.15.***	2C-4G-50G	Centos7.8	Keepalived & HAProxy
k8s-slb2	172.30.15.***	2C-4G-50G	Centos7.8
k8s-master1	172.30.15.***	8C-32G-150G	Centos7.8	master+etcd
k8s-master2	172.30.15.***	8C-32G-150G	Centos7.8
k8s-master3	172.30.15.***	8C-32G-150G	Centos7.8
k8s-worker1	172.30.15.***	8C-32G-500G	Centos7.8	CICD + 存储
k8s-worker2	172.30.15.***	8C-32G-500G	Centos7.8
k8s-worker3	172.30.15.***	8C-32G-500G	Centos7.8

说明：由于有些应用或中间件有持久化数据的需求，上表中也将存储考虑进去了，跟worker节点放在一起，后面会单独讲存储。

看到这里不要紧张，觉得一下子需要用这么多机器，等你的应用上云以后这些机器完全是可以节省下来的。

框架选型

接下来我们看看整体的框架选型，包含容器平台、存储、Kubernetes搭建工具。

前期我们做技术选型的时候花了很多精力来调研，调研过程就不展示了，直接放结论。

容器平台

容器平台方案	优点	缺点	说明
KubeSphere	代码全开源、社区活跃、UI 体验 较好、背后是青云上市公司团队支持	多集群管理不完善 使用过程中还是有些小bug	学习材料有视频+文档形式，适合团队快速学习上手，同时官方有固定的双周会，可以参与了解项目发展情况
Kuboard	相关文档较较细致、可以作为学 习材料使用	个人开源项目， 文档开 源，代码不开源	文档写的较全，适合通过该项目 初步了解 k8s，是一个不错的搭 建 k8s 的学习材料平台， 不建议生产使用。
Rancher	开发团队强大、社区活跃、强项 整合云平台资源、老外公司	文档英文为主、WebUI 使用起来总有种卡顿的 感觉	国内有部分公司在用，主要反馈产品体验不好，技术团队实力较强，中文文档滞后。

入选者：KubeSphere

选型理由： 安装简单，使用简单

• 具备构建一站式企业级的 DevOps 架构与可视化运维能力 (省去自己用开源工具手工搭建积木)
• 提供从平台到应用维度的日志、监控、事件、审计、告警与通知，实现集中式与多租户 隔离的可观测性
• 简化应用的持续集成、测试、审核、发布、升级与弹性扩缩容
• 为云原生应用提供基于微服务的灰度发布、流量管理、网络拓扑与追踪 提供易用的界面命令终端与图形化操作面板，满足不同使用习惯的运维人员
• 可轻松解耦，避免厂商绑定

存储选型

这里只考虑了分布式的存储组件，如本地存储OpenEBS我们直接pass了。

存储方案	优点	缺点	说明
Ceph	资源多，大多容器平台都有支持 Ceph。	运维成本较高，都说没有 Ceph 集群故障处理能 力，最好不要碰	曾经，经历过 3 副本全部损坏 数据丢失的惨痛经历，因此没有能力处理各种故障之前不会再 轻易选择（来源于社区人员的反馈）.
GlusterFS	部署维护简单、多副本高可用	资料相对较少；很久都不更新升级了	部署和维护简单，出了问题找回数据的可能性大一些
NFS	使用广泛	单点网络抖动	不建议您在生产环境中使用 NFS 存 储 （ 尤 其 是 在 Kubernetes 1.20 或 以 上 版 本）， 这可能会引起 failed to obtain lock 和 input/output error 等 问 题 ， 从 而 导 致 Pod CrashLoopBackOff 。 此 外，部分应用不兼容 NFS，例 如 Prometheus 等

入选者：Ceph

选型理由：

1. 可以通过ROOK快速构建Ceph高可用集群，使用者众多
2. 支持多种存储类型，块存储、文件存储、对象存储，非常方便

K8S搭建工具

存储方案	优点	缺点
Kubeadm	K8s 官方推荐的集群搭建工具	需要手动续期 k8s 集 群证书
Kubekey	在更方便、快速、高效和灵活地安 装 Kubernetes 与 KubeSphere。 支持单独 Kubernetes 或整体安 装 KubeSphere。自动续期 k8s 集 群证书	不是 k8s 官方工具
二进制安装	满足个人学习需要	部署复杂

入选者：Kubekey

选型理由：

简单易用，是在 kubeadm 基础上诞生的工具，主要看重 k8s 集群证书自动续期功能，不用运维到期前手动续期。该工具虽然不是 k8s 官方提供的工具，但是是通过 CNCF 验证的工具，CNCF kubernetes conformance verification。

软件版本

软件名称	软件版本	说明
操作系统	centos7.8	注意操作系统内核 3.10 内核在大规模集群具有不 稳定性，内核升级到 4.19+ # 查看内核版本 uname -sr 目前以 3.10
KubeSphere	3.2.1	截止发文时最新版本
Kubekey	v2.0.0	截止发文时最新版本
Docker	20.10.9	求稳
Kubernetes	1.21.5	Kubekey2.0.0支持的最高版本

小结

今天主要简单介绍了一下Kubernetes的核心组件和Kubernetes高可用部署方案以及相关技术选型。Kubernetes很难，要学会Kubernetes完全通过看书是不现实的，必须要反复实践，有条件的同学建议跟着本系列课程实操一遍。

下一节课我们正式安装Kubernetes高可用环境，如果你喜欢这个系列，请不要吝啬你的一键三连。同时也欢迎你把这个系列分享给你的朋友，我们一起进步。。。好了，我们下期再见。