Kubernetes架构原理详解

简介: Kubernetes架构原理详解


Kubernetes是什么,为什么上手这么难?

Kubernetes是一个基于容器技术的分布式集群管理系统。它是谷歌在大规模应用容器技术方面数十年经验的实际成果。因此,支持大规模的集群管理承载着非常多的组件,分布式本身的复杂度非常高。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

Kubernetes到底有什么?

接下来我们一步步来看看Kubernetes到底有什么?

首先,既然是分布式系统,那么肯定有多个Node节点(物理主机或者虚拟机),它们共同构成了一个分布式集群,而这些节点之间会有一个Master节点,统一管理Node节点。如图所示:

问题1:Master节点和Worker节点如何通信?

首先,当Master节点启动时,会运行一个Kube-apiserver进程,它提供了集群管理的API接口,是集群中各个功能模块之间进行数据交互和通信的中心枢纽,同时也提供了一个完善的集群安全机制。

在Node节点上,利用Kubernetes中的kubelet组件,每个Node节点上都会运行一个kubelet进程,负责向Master汇报本节点的运行状态,如Node节点注册、终止、定期健康报告等等,并接收来自Master的命令并创建相应的Pod。

在Kubernetes中,Pod是最基本的运行单元。它与Docker容器略有不同,因为Pod中可能包含一个或多个容器(可以是Docker容器),这些容器内部共享网络资源,即可以通过localhost相互访问。

关于如何在Pod中实现网络共享,每个Pod启动,内部都会启动一个pause容器(谷歌的image)。它使用默认的网络模式,其他容器的网络设置为它,完成网络共享问题。

如图所示:

问题2:Master如何将Pod调度到指定的Node上?

这项工作由Kube-scheduler完成。整个调度过程通过执行一系列复杂的算法,最终为每个Pod计算出一个最优的目标Node,这是由Kube-scheduler进程自动完成的。

最常见的是循环调度(RR)。当然也有可能我们需要将Pod调度到指定的Node上。我们可以通过将节点的标签(Label)与Pod的节点选择器属性进行匹配来达到指定的效果。

如图所示:

问题3:各个节点和Pod的信息统一在哪里维护,谁来维护?

从上面的Pod调度来看,我们必须有一个存储中心来存储每个节点的每个Pod的资源使用情况、健康状态和基本信息,这样Pod调度才能正常进行。

在Kubernetes中,etcd组件被用作高可用和一致的存储库。该组件可以内置在Kubernetes中,也可以外部构建供Kubernetes使用。

集群上的所有配置信息都存储在etcd中。考虑到各个组件的相对独立性和整体的可维护性,这些存储的数据的增删改查都是统一由Kube-apiserver来调用的,并且apiserver还提供了REST支持,不仅为各个内部组件提供服务但也向集群外的用户公开服务。

外部用户可以通过REST接口或kubectl命令行工具管理集群,该工具内部与apiserver通信。

如图所示:

问题4:外部用户如何访问集群中运行的Pod?

前面我们讲了外部用户如何管理Kubernetes,但我们更关心的是内部运行的Pod如何对外访问。

用过Docker的同学应该都知道,如果使用bridge模式,在创建容器的时候会分配一个虚拟IP,外部无法访问该IP。我们需要做一层端口映射,将容器中的端口映射到宿主机的端口Map并绑定,这样外部就可以通过访问宿主机的指定端口来访问容器内部的端口。

那么,Kubernetes的外部访问也是这样实现的吗?答案是否定的,Kubernetes中的情况更加复杂。因为上面说的Docker是单机模式,一个容器对外暴露一个服务。在分布式集群中,服务往往由多个应用提供,以分担访问压力,而这些应用可能分布在多个节点上,这就涉及到跨主机通信。

这里Kubernetes引入了Service的概念,将多个相同的Pod包装成一个完整的服务,对外提供服务。至于获取这些相同的Pod,每个Pod在启动时都会设置labels为attribute。

在服务中,我们传递选择器Selector,选择与整体服务具有相同Name标签属性的Pod,将服务信息通过Apiserver存储到etcd中,由Service Controller完成。同时在每个节点上启动一个kube-proxy进程,负责从服务地址到Pod地址的代理和负载均衡。

如图所示:

问题5:Pod如何动态扩容和伸缩?

既然我们知道服务是由Pod组成的,那么服务的扩展也意味着Pod的扩展。通俗地说,就是在需要的时候将Pod做多个副本,在不需要的时候将Pod缩减到指定的副本数。

在Kubernetes中,使用Replication Controller进行管理,为每个Pod设置一个预期的副本数。当实际副本数量不符合预期时,动态调整数量以达到预期值。所需值可以由我们手动更新,也可以由自动缩放代理更新。如图所示:

问题6:各个组件如何协同工作?

最后说一下Kube-controller-manager进程的作用。我们知道ectd是作为集群数据的存储中心,而apiserver是用来管理数据中心,充当其他进程与数据中心通信的桥梁。

Service Controller和Replication Controller由Kube-controller-manager管理。作为一个守护进程,每个Controller都是一个控制回路,通过apiserver监控集群的共享状态,并尝试将实际状态中不符合预期的变化。关于Controller,管理器还包括Node Controller、ResourceQuota Controller、Namespace Controller等。

如图所示:

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

总结

本文通过问答的方式不涉及任何深入的实现细节。从整体的角度,从概念上介绍了Kubernetes涉及的基本概念。相关用途包括:

  • Node
  • Pod
  • Label
  • Selector
  • Replication Controller
  • Service Controller
  • ResourceQuota Controller
  • Namespace Controller
  • Node Controller

与运行过程相关的是:

  • kube-apiserver
  • kube-controller-manager
  • kube-scheduler
  • kubelet
  • kube-proxy
  • pause


相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
6月前
|
运维 Kubernetes Cloud Native
智联招聘 × 阿里云 ACK One:云端弹性算力颠覆传统 IDC 架构,打造春招技术新范式
在 2025 年春季招聘季的激战中,智联招聘凭借阿里云 ACK One 注册集群与弹性 ACS 算力的深度融合,成功突破传统 IDC 机房的算力瓶颈,以云上弹性架构支撑千万级用户的高并发访问,实现招聘服务效率与稳定性的双重跃升。
|
5月前
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
4月前
|
机器学习/深度学习 算法 文件存储
神经架构搜索NAS详解:三种核心算法原理与Python实战代码
神经架构搜索(NAS)正被广泛应用于大模型及语言/视觉模型设计,如LangVision-LoRA-NAS、Jet-Nemotron等。本文回顾NAS核心技术,解析其自动化设计原理,探讨强化学习、进化算法与梯度方法的应用与差异,揭示NAS在大模型时代的潜力与挑战。
1107 6
神经架构搜索NAS详解:三种核心算法原理与Python实战代码
|
3月前
|
Kubernetes Devops API
从零到面试高手:每个 DevOps 专业人士都必须知道的 20 个 Kubernetes 架构问答
Kubernetes 是当前 DevOps、云原生和 SRE 领域的关键技能。本文总结了 20 个高频面试问题,涵盖架构组件、工作原理及核心概念,助你轻松掌握 Kubernetes 基础,提升面试与实战能力。
261 2
|
2月前
|
机器学习/深度学习 自然语言处理 监控
23_Transformer架构详解:从原理到PyTorch实现
Transformer架构自2017年Google发表的论文《Attention Is All You Need》中提出以来,彻底改变了深度学习特别是自然语言处理领域的格局。在短短几年内,Transformer已成为几乎所有现代大型语言模型(LLM)的基础架构,包括BERT、GPT系列、T5等革命性模型。与传统的RNN和LSTM相比,Transformer通过自注意力机制实现了并行化训练,极大提高了模型的训练效率和性能。
|
边缘计算 Kubernetes 物联网
Kubernetes 赋能边缘计算:架构解析、挑战突破与实践方案
在物联网和工业互联网快速发展的背景下,边缘计算凭借就近处理数据的优势,成为解决云计算延迟高、带宽成本高的关键技术。而 Kubernetes 凭借统一管理、容器化适配和强大生态扩展性,正逐步成为边缘计算的核心编排平台。本文系统解析 Kubernetes 适配边缘环境的架构分层、核心挑战与新兴解决方案,为企业落地边缘项目提供实践参考。
370 0
|
5月前
|
存储 监控 算法
园区导航系统技术架构实现与原理解构
本文聚焦园区导航场景中室内外定位精度不足、车辆调度路径规划低效、数据孤岛难以支撑决策等技术痛点,从架构设计到技术原理,对该系统从定位到数据中台进行技术拆解。
244 0
园区导航系统技术架构实现与原理解构
|
7月前
|
存储 人工智能 自然语言处理
为什么混合专家模型(MoE)如此高效:从架构原理到技术实现全解析
本文深入探讨了混合专家(MoE)架构在大型语言模型中的应用与技术原理。MoE通过稀疏激活机制,在保持模型高效性的同时实现参数规模的大幅扩展,已成为LLM发展的关键趋势。文章分析了MoE的核心组件,包括专家网络与路由机制,并对比了密集与稀疏MoE的特点。同时,详细介绍了Mixtral、Grok、DBRX和DeepSeek等代表性模型的技术特点及创新。MoE不仅解决了传统模型扩展成本高昂的问题,还展现出专业化与适应性强的优势,未来有望推动AI工具更广泛的应用。
4302 4
为什么混合专家模型(MoE)如此高效:从架构原理到技术实现全解析
|
6月前
|
存储 消息中间件 canal
zk基础—2.架构原理和使用场景
ZooKeeper(ZK)是一个分布式协调服务,广泛应用于分布式系统中。它提供了分布式锁、元数据管理、Master选举及分布式协调等功能,适用于如Kafka、HDFS、Canal等开源分布式系统。ZK集群采用主从架构,具有顺序一致性、高性能、高可用和高并发等特点。其核心机制包括ZAB协议(保证数据一致性)、Watcher监听回调机制(实现通知功能)、以及基于临时顺序节点的分布式锁实现。ZK适合小规模集群部署,主要用于读多写少的场景。