Kuberntes云原生实战一 高可用部署架构

本文涉及的产品
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
简介: 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混布方式
  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高可用环境,如果你喜欢这个系列,请不要吝啬你的一键三连。同时也欢迎你把这个系列分享给你的朋友,我们一起进步。。。好了,我们下期再见。

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
1月前
|
消息中间件 Java Kafka
Java 事件驱动架构设计实战与 Kafka 生态系统组件实操全流程指南
本指南详解Java事件驱动架构与Kafka生态实操,涵盖环境搭建、事件模型定义、生产者与消费者实现、事件测试及高级特性,助你快速构建高可扩展分布式系统。
155 7
|
2月前
|
存储 SQL 监控
数据中台架构解析:湖仓一体的实战设计
在数据量激增的数字化时代,企业面临数据分散、使用效率低等问题。数据中台作为统一管理与应用数据的核心平台,结合湖仓一体架构,打通数据壁垒,实现高效流转与分析。本文详解湖仓一体的设计与落地实践,助力企业构建统一、灵活的数据底座,驱动业务决策与创新。
|
2月前
|
存储 设计模式 人工智能
AI Agent安全架构实战:基于LangGraph的Human-in-the-Loop系统设计​
本文深入解析Human-in-the-Loop(HIL)架构在AI Agent中的核心应用,探讨其在高风险场景下的断点控制、状态恢复与安全管控机制,并结合LangGraph的创新设计与金融交易实战案例,展示如何实现效率与安全的平衡。
372 0
|
1月前
|
运维 Dubbo Cloud Native
Dubbo 云原生重构出击:更快部署、更强控制台、更智能运维
Apache Dubbo 最新升级支持云原生,提供一键部署微服务集群与全新可视化控制台,提升全生命周期管理体验,助力企业高效构建云原生应用。
210 25
|
2月前
|
人工智能 监控 数据可视化
企业级LLMOps落地指南:蜂巢架构×可视化编排实战
本文将基础的单应用扩展成多应用,并实现工作流组件,包括:多应用模块设计、工作流模块设计、LangGraph实现图应用、前端Vue-Flow组件使用、工作流转LLM工具设计思路、关联工作流登技巧。
174 3
企业级LLMOps落地指南:蜂巢架构×可视化编排实战
|
2月前
|
文字识别 运维 监控
架构解密|一步步打造高可用的 JOCR OCR 识别服务
本文深入解析了JOCR OCR识别服务的高可用架构设计,涵盖从用户上传、智能调度、核心识别到容错监控的完整链路,助力打造高性能、低成本的工业级OCR服务。
135 0
架构解密|一步步打造高可用的 JOCR OCR 识别服务
|
2月前
|
缓存 人工智能 监控
1688 平台商品详情接口技术揭秘:架构演进与实战优化
本文深入解析了1688商品详情接口的技术架构与核心实现,涵盖微服务拆分、多级缓存、数据聚合及高可用策略,展示了如何构建高性能电商接口系统,并展望AI技术在商品展示中的应用。
|
2月前
|
缓存 监控 数据安全/隐私保护
京东平台商品详情接口技术解密:高性能架构与实战经验
本文深入解析京东商品详情接口技术架构,涵盖微服务设计、多级缓存、异步加载及数据一致性保障等关键策略,分享高并发场景下的性能优化实践,助力电商系统稳定高效运行。
|
2月前
|
消息中间件 人工智能 安全
企业级AI应用需要系统工程支撑,如何通过MCP大模型架构实现全链路实战解构?
本文三桥君深入探讨了MCP大模型架构在企业级AI应用中的全链路实战解构。从事件驱动、统一中台、多端接入、API网关、AI Agent核心引擎等九个核心模块出发,系统阐述了该架构如何实现低耦合高弹性的智能系统构建。AI专家三桥君提出从技术、内容、业务三个维度构建评估体系,为企业级AI应用提供了从架构设计到落地优化的完整解决方案。
189 0