Kubernetes云原生实战01 Kubernetes高可用部署架构
大家好，我是飘渺。从今天开始我们将正式开始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混布方式
- 所需机器资源少
- 部署简单，利于管理
- 容易进行横向扩展
- 风险大，一台宿主机挂了，master和etcd就都少了一套，集群冗余度受到的影响比较大。
- Etcd独立部署方式：
- 所需机器资源多（按照Etcd集群的奇数原则，这种拓扑的集群关控制平面最少需要6台宿主机了）
- 部署相对复杂，要独立管理etcd集群和和master集群
- 解耦了控制平面和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 构建的负载均衡器。
最终的部署架构图如下：
架构说明
- etcd跟master节点部署在一起，依靠master节点实现高可用
- 通过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
选型理由：
- 可以通过ROOK快速构建Ceph高可用集群，使用者众多
- 支持多种存储类型，块存储、文件存储、对象存储，非常方便
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高可用环境，如果你喜欢这个系列，请不要吝啬你的一键三连。同时也欢迎你把这个系列分享给你的朋友，我们一起进步。。。好了，我们下期再见。