Kuberntes云原生实战一 高可用部署架构
Posted 飘渺Jam
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Kuberntes云原生实战一 高可用部署架构相关的知识,希望对你有一定的参考价值。
大家好,我是飘渺。从今天开始我们将正式开始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、HorizontalPodAutoscaling |
配置对象 | Node、Namespace、Service、Secret、ConfigMap、Ingress、Label、 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高可用环境,如果你喜欢这个系列,请不要吝啬你的一键三连。同时也欢迎你把这个系列分享给你的朋友,我们一起进步。。。好了,我们下期再见。
插个小广告,博主最近开通了知识星球,星球会员可以免费获取相关收费资料、课程代码以及赠书资格(现在加入可享受早鸟价,几杯咖啡钱)。
加入方式,长按下方二维码,如果你是苹果用户建议直接联系我~
以上是关于Kuberntes云原生实战一 高可用部署架构的主要内容,如果未能解决你的问题,请参考以下文章
Kubernetes云原生实战01 Kubernetes高可用部署架构
Kubernetes云原生实战01 Kubernetes高可用部署架构
Kubernetes云原生实战01 Kubernetes高可用部署架构