在当今数字化时代，企业的应用架构正经历着深刻变革，从传统的单体架构逐渐向微服务架构转型。这种转型带来了诸多优势，如更高的灵活性、可扩展性和可维护性。然而，随着微服务数量的不断增加，应用的部署、管理和运维变得愈发复杂，面临着诸如资源分配、服务发现、负载均衡、故障恢复等一系列挑战。

容器技术的出现为解决这些问题提供了新的思路。容器能够将应用及其依赖项打包成一个独立的、可移植的单元，实现了环境的一致性和隔离性。而 Kubernetes（简称 K8S）作为容器编排领域的佼佼者，应运而生，成为了解决容器化应用管理难题的关键工具。Kubernetes是一款开源的容器编排引擎，在容器化应用的管理领域发挥着核心作用。其主要使命是实现容器化应用的自动化部署、精细扩展以及高效管理，旨在为应用的运行提供一个稳定、可靠且灵活的环境。

一、Kubernetes管理对象

1.1 Kubernetes组件和架构

Kubernetes作为容器编排领域的核心技术，其架构由多个关键组件构成，控制平面与数据平面各司其职，网络及存储组件提供支持，各组件紧密协作，共同构建了强大且可靠的Kubernetes系统。

架构分层	组件	组件功能	在架构中的作用
控制平面（Master Node）	APIServer	提供RESTful接口，用于管理和操作Kubernetes资源，是整个集群的控制中心，负责接收和处理所有来自客户端和其他组件的请求	作为集群的入口，统一管理和协调各组件对资源的操作，确保整个集群状态的一致性和准确性
	ETCD	分布式键值对存储，用于保存集群的所有状态信息，包括资源配置、Pod状态等	为集群提供可靠的数据存储，保证数据的持久性、一致性和高可用性，是整个集群运行的基础支撑
	scheduler	负责将新创建的Pod调度到合适的工作节点上运行，根据资源需求、节点状态等因素进行调度决策	实现资源的合理分配，确保每个Pod都能在满足其运行条件的节点上运行，提高集群整体资源利用率和应用性能
	controller - managers	包含多个控制器，如节点控制器、副本控制器等，负责维护集群中各种资源的状态，确保实际状态与期望状态一致	自动管理和维护集群中资源的状态，通过不断监控和调整，保证集群的稳定性和可靠性
数据平面（Worker Node）	kubelet	每个工作节点上运行的代理，负责与控制平面通信，管理本节点上的Pod生命周期，包括创建、启动、停止等操作	作为工作节点与控制平面的桥梁，负责将控制平面的指令在本地节点上执行，实现对Pod的具体管理
	kube - proxy	实现Kubernetes服务的网络代理和负载均衡功能，通过在节点上维护网络规则，将服务请求转发到后端的Pod实例	确保服务能够被正确访问，通过负载均衡将请求均匀分配到后端Pod，提高服务的可用性和性能
	容器运行时（如Docker、containerd等）	负责运行容器，管理容器的镜像拉取、启动、停止等操作	是容器化应用实际运行的基础，为应用提供隔离的运行环境
网络组件	CNI（Container Network Interface）插件（如Flannel、Calico等）	负责为Pod分配网络地址，实现Pod之间以及Pod与外部网络的通信	构建集群的网络拓扑，确保各个Pod之间能够进行有效的通信，满足不同应用场景下的网络需求
存储组件	CSI（Container Storage Interface）插件（如NFS、Ceph等）	负责管理和提供存储资源，实现容器化应用的数据持久化存储	为应用提供可靠的数据存储解决方案，确保数据在容器生命周期之外的持久性和可用性

1.2 主要管理对象类型

Kubernetes对象	概念	作用	特点	使用场景	示例
Pod	Kubernetes中最小的可部署和可管理的计算单元，是一个或多个紧密相关容器的集合，共享网络和存储资源	承载容器化应用，实现容器间高效协作	有唯一IP地址，生命周期短暂且动态	各类应用场景，如Web应用等	Web应用中，Nginx容器与基于Node.js或Python Flask的应用容器封装在同一Pod，共享网络命名空间，通过localhost通信，还可挂载共享存储卷
Service	一种抽象层，用于定义一组Pod的访问策略	实现服务发现和负载均衡	通过标签选择器关联Pod，为其提供稳定访问入口	解决Pod IP地址动态变化导致的访问不稳定问题	电商系统中，订单处理服务的多个Pod实例通过Service关联，Service将用户请求分配到不同Pod处理
ClusterIP Service	Service的一种类型	为服务分配仅在集群内部可访问的虚拟IP地址	仅在集群内部可访问	集群内部服务间通信	集群内部服务A调用服务B时，通过ClusterIP Service进行通信
NodePort Service	Service的一种类型	在每个节点上开放指定端口，可从集群外部通过节点IP加端口号访问服务	可从集群外部访问	需要从集群外部访问服务，但不想借助外部负载均衡器的场景	开发测试环境，从本地通过NodePort访问集群内服务
LoadBalancer Service	Service的一种类型	借助云提供商的负载均衡器，为服务分配外部可访问的IP地址	外部可稳定访问	需要将服务暴露给外部互联网的场景	面向公众的Web应用，通过LoadBalancer Service让用户从互联网访问
Deployment	用于管理Pod和ReplicaSet的重要对象，提供声明式方法定义和管理应用程序部署	定义和管理应用程序部署，确保实际运行状态与期望状态一致	可定义Pod副本数量、容器镜像版本、资源请求与限制等，支持滚动更新和回滚	各种应用的部署和管理	在线视频播放服务，通过Deployment设置Pod副本数为10，保障高峰时段服务可用性；版本升级时采用滚动更新
ReplicaSet	负责确保指定数量的Pod副本始终处于运行状态	简单管理Pod副本数量	对比实际与期望副本数，自动创建或删除Pod	对应用程序版本稳定性要求高，且不需要频繁版本更新的场景	一些稳定运行的后台服务，用ReplicaSet维持固定数量的Pod副本
StatefulSet	适用于管理有状态的应用程序	管理有状态应用，保证Pod标识符、存储状态一致性和特定启动顺序	为每个Pod分配唯一、稳定标识符	有状态应用，如数据库、消息队列等	分布式数据库集群，StatefulSet确保每个数据库实例Pod重启后仍能正确访问存储数据，按预定顺序启动和停止
DaemonSet	确保每个节点上都运行一个特定Pod的副本	在每个节点部署和管理系统级服务或守护进程	每个节点运行一个Pod副本	需要在每个节点运行系统级服务的场景	大规模生产集群中，用DaemonSet部署Prometheus Node Exporter监控代理Pod，实时监控每个节点资源使用情况

二、Kubernetes 服务

2.1 服务的作用与原理

在 K8S的生态体系中，服务扮演着极为关键的角色，是实现容器化应用高效管理与稳定运行的核心组件。其核心作用主要体现在为 Pod 提供稳定的网络身份，以及实现精准的服务发现和高效的负载均衡。

在K8S集群中，Pod的IP地址动态分配且生命周期短暂，因节点故障或资源调整被销毁重建时，IP会改变。好比城市中商店位置不断变动，若无稳定标识，客户（其他服务或外部请求）难持续准确找到对应Pod。而服务为一组相同功能的 Pod 提供一个固定的、稳定的网络入口，很好地解决了这一问题。它就像是为这些商店设置了一个统一的、不会变动的招牌地址，无论商店内部如何调整，客户都可以通过这个固定地址找到对应的服务。

服务发现是K8S服务重要功能。复杂K8S集群中，众多服务需相互通信协作，如电商系统里订单处理服务与用户信息、库存管理等服务交互。服务发现机制让服务自动找到彼此，无需手动配置通信地址。新服务实例（Pod）加入集群自动注册到服务目录，下线则自动移除，类似商业中心新店铺自动纳入导航，关闭店铺及时从导航移除。

负载均衡是保障服务高可用和高性能的关键。大量请求发至服务时，它能将请求均匀分发给后端多个Pod实例。如热门在线视频平台黄金时段，海量请求若集中少数Pod易致其响应缓慢或崩溃。通过负载均衡，请求均衡分配到多个视频播放Pod，避免单个Pod过载，确保用户流畅观看。常见负载均衡算法有轮询（按顺序分配请求）、随机（随机选Pod处理请求）、加权轮询（依Pod性能和资源配置设权重，性能好的Pod获更多请求）。

2.2 服务类型

服务类型	描述	应用场景	实现方式	示例
ClusterIP	提供稳定唯一虚拟IP，用于集群内服务通信，此IP仅在集群内可见	适用于集群内服务间调用，如订单管理服务调用用户管理服务验证用户身份	创建Service资源，指定type为ClusterIP，Kubernetes自动分配内部虚拟IP，通过selector连接Pod实例	订单管理服务通过ClusterIP访问用户管理服务，假设用户管理服务的ClusterIP为10.96.0.10，订单管理服务Pod可借此IP通信
NodePort	将集群服务暴露到节点特定端口，供外部访问	适合企业向外部伙伴提供内部服务，如给合作伙伴的API服务	配置Service，指定type为NodePort（可设nodePort，不设则自动分配），在节点开放端口（30000 - 32767 ），映射到集群内Service的port和targetPort	节点IP为192.168.1.100，开放30080端口，外部通过http://192.168.1.100:30080访问，内部请求从30080端口转至port8080，再到Pod的targetPort80
LoadBalancer	借助云提供商负载均衡器，将服务暴露给外部互联网，实现流量均衡与健康监测	适用于电商平台前端、在线支付等需高可用、高并发的关键服务	创建Service，指定type为LoadBalancer，Kubernetes向云提供商请求创建负载均衡器，分配公网IP，均衡分发流量至后端Pod	在AWS上创建LoadBalancer型Service，自动生成ELB负载均衡器，分配公网IP，外部通过此IP访问，流量被分发给3个后端Pod
Ingress	管理外部流量，为集群服务提供统一入口，可按URL等规则转发流量	适用于大型电商等复杂系统，需按URL路径将流量导向不同微服务	部署Ingress Controller，创建Ingress资源定义规则，如host、path及对应的backend，后端常为其他类型Service	通过配置 Ingress 的 TLS 字段，为域名配置 SSL 证书，实现 HTTPS 访问。

三、Kubernetes网络管理

3.1 网络模型与目标

Kubernetes 的容器网络模型，为构建高效、可靠的容器网络提供了明确的准则和方向，可归结为“约法三章“和“四大目标“”。

约法三章内容	具体描述	类比说明
任意两个Pod之间应能直接通信，无需借助显式的NAT进行数据和地址的转换	在Kubernetes集群中，每个Pod都应有独立且可直接访问的IP地址	如同在局域网中，每台设备都有自己的IP，设备之间可直接通信，无需经过额外的地址转换网关
Node与Pod之间同样要实现直接通信，避免使用明显的地址转换	保证节点与Pod之间的通信效率和便捷性，使节点能直接与所承载的Pod交互	像服务器与直接连接的本地设备进行通信一样顺畅
Pod看到自身的IP应与外界看到它的IP保持一致，中间不得进行转换	确保Pod网络地址的一致性和可预测性，避免因地址转换带来网络复杂性和潜在问题	-

网络设计目标	具体描述	示例或类比说明	实现方式
外部世界与Service之间的通信	Service作为Kubernetes中一组Pod的抽象访问入口，外部流量需通过Service连接到容器内部应用	在大型商业综合体中，顾客（外部世界）需通过特定入口（Service）进入各个店铺（Pod）	通过Service连接到容器内部应用
Service与后端Pod的通信	Service需与后端Pod实现高效通信	当用户请求发送到Service，Service依DNS解析找对应Pod，通过负载均衡算法将请求合理分配到后端各Pod，确保服务高可用和高性能	通过Kubernetes的内部DNS解析和负载均衡机制
Pod与Pod之间的通信	每个Pod有独立IP地址，可直接用对方IP地址通信	像局域网中的设备之间通过IP直接通信	直接用对方IP地址通信
Pod内部容器与容器之间的通信	Pod内部容器间通信通常通过localhost进行	如同在同一台主机上的多个进程之间进行通信	利用容器共享网络命名空间的特性

这些约法三章和四大目标对 Kubernetes 网络的设计和实现提出了明确要求，深刻影响着网络插件的选择和配置。例如，在选择网络插件时，需要确保插件能够满足 Pod 之间直接通信的要求，如 Flannel、Calico 等网络插件，它们通过不同的技术手段实现了 Pod 之间的直接通信。Flannel 通过创建一个覆盖网络（Overlay Network），为每个节点分配一个子网，使得不同节点上的 Pod 可以通过这个覆盖网络进行通信；Calico 则基于 BGP（边界网关协议）实现了三层网络的直接通信，为每个容器分配一个唯一的 IP 地址，并通过 BGP 协议进行路由选择，确保 Pod 之间能够直接通信。同时，网络插件还需要满足 Node 与 Pod 之间直接通信以及 Pod IP 地址一致性的要求，以保障整个 Kubernetes 网络的高效、稳定运行。

3.2 网络组件

3.2.1 kube-proxy

kube-proxy是K8S集群关键网络组件，在节点运行，负责实现服务抽象。服务是将一组Pod暴露给其他服务或外部客户端的抽象概念，kube-proxy将其转为具体网络规则，让其他组件能与之通信。

创建Service时，kube-proxy按其配置在节点创建网络规则。如ClusterIP类型的Service，kube-proxy会设置iptables或ipvs规则，将发往服务虚拟IP的流量转至后端Pod实例。Pod与服务通信时，kube-proxy拦截请求，按负载均衡算法选合适Pod处理，实现负载均衡。早期kube-proxy用用户空间模式，有性能低和复杂度高的问题。后iptables模式成主流，kube-proxy监控K8S API服务器变化，动态更新节点的iptables规则，新Service创建、删除或更新时，会相应调整规则。如添加新Pod到服务后端，会在iptables规则添加条目以正确路由流量。

为提升性能和灵活性，K8S引入IPVS模式。IPVS是Linux内核高性能负载均衡模块，基于内核态，性能更高，负载均衡算法更丰富。kube-proxy在IPVS模式下将服务配置转为IPVS规则，将流量快速转发至后端Pod，支持多种算法，用户可按需选择，如在线购物系统用户会话管理，可使用会话亲和性算法保证用户体验一致性。

3.2.2 网络插件

在 Kubernetes 的生态系统中，网络插件是实现其网络模型的关键组件，不同的网络插件通过各自独特的方式，满足了 Kubernetes 对容器网络的严格要求，确保了集群内 Pod 之间的高效通信。Flannel 和 Calico 作为其中的典型代表，具有各自鲜明的特点和适用场景。

网络插件	开发者	设计初衷	网络实现方式	后端实现方式及特点
Flannel	CoreOS	实现容器与主机之间更优的网络连接	创建覆盖网络（Overlay Network），为每个节点分配子网，用于为节点上容器分配IP地址，跨主机Pod通信时，将数据包封装在UDP协议中通过Overlay网络传输，在目标节点解封装后转发到目标Pod	1. UDP：最早实现方式，在用户空间进行数据包封装和解封装，实现基本网络通信功能，但性能有局限 2. VXLAN：利用Linux内核的VXLAN隧道技术，将数据包封装在VXLAN帧中传输，提高网络性能和稳定性 3. host - gateway：适用于对网络性能要求高且所有节点在同一二层网络的场景，通过在节点配置路由规则，直接转发数据包到目标节点，减少封装和解封装开销，提升网络性能
Calico	Tigera（原由Metaswitch开发）	为Kubernetes集群提供高效、灵活且安全的网络解决方案	基于BGP（边界网关协议），提供纯三层网络解决方案，不创建额外Overlay网络，直接利用底层网络IP路由功能，为每个容器分配唯一且在整个集群可路由的IP地址，根据BGP协议计算最佳路由路径，将数据包直接发送到目标Pod的IP地址	无额外特定后端实现方式表述（因其核心基于BGP路由，网络策略是其重要特色功能），特点是基于BGP实现高效路由，结合丰富的网络安全策略，实现细粒度流量控制，保障网络安全

Calico 的优势不仅在于其高效的路由能力，还在于它提供了丰富的网络安全功能。通过网络策略（Network Policy），Calico 可以对 Pod 之间的网络流量进行细粒度的控制。例如，在一个包含多个微服务的 Kubernetes 集群中，可以使用 Calico 的网络策略来限制用户管理服务的 Pod 只能与订单管理服务的特定端口进行通信，从而提高了整个集群的网络安全性。Calico 的网络策略支持基于标签、IP 地址、端口等多种条件进行流量控制，用户可以根据实际需求灵活配置，满足不同场景下的网络安全需求。

3.3 网络通信流程

以一个典型的 Kubernetes 集群为例，详细剖析从外部请求到容器内部应用的网络通信流程。

解释：

• 首先，用户或客户端向节点 192.168.1.10 的 30008 端口发起请求，该请求会到达该节点的物理网络接口。
• 然后，Kubernetes 通过 iptables 等机制将该请求转发到服务的内部机制。
• 接着，在每个节点上运行的 kube-proxy 收到请求，并根据服务的负载均衡策略（如果配置）将请求转发到后端的 Pod 实例（如 10.244.0.10 或 10.244.0.11）。
• Pod 处理请求后，将响应发送回 kube-proxy，然后 kube-proxy 把响应发回接收请求的节点，最终节点将响应发回客户端。
• 如果集群配置了 Ingress 资源，外部请求会先到达 Ingress Controller，它会根据路由规则将请求转发到对应的服务，服务再根据 selector 转发到相应的 Pod，后续流程与 NodePort 服务的流程类似。

四、Kubernetes 存储管理

4.1 存储类型

4.1.1 本地存储

在 Kubernetes 存储体系中，本地存储至关重要，它将存储卷直接挂载到承载 Pod 的物理节点。

本地存储性能优势独特，在对存储性能要求极高的场景作用关键。如 MySQL、PostgreSQL 等关系型数据库，因数据读写频繁且对响应速度要求高，使用本地存储可减少读写延迟，提升性能。但本地存储在数据持久性上有局限，若节点硬件故障，数据可能丢失。不过在临时数据存储场景，如缓存、日志数据存储中，其性能优势能弥补不足。例如缓存数据，即便丢失也不严重影响系统运行。

Kubernetes 实现本地存储常见方式有emptyDir和hostPath。emptyDir简单，Pod 分配到节点时自动创建空目录存临时数据，Pod 移除，数据永久删除，适用于数据处理任务存中间结果。hostPath将节点文件系统的文件或目录挂载到 Pod，供 Pod 访问本地存储资源，如应用访问节点特定配置文件。但使用hostPath要注意不同节点文件系统差异，确保路径存在且权限正确，同时它可能导致 Pod 与特定节点绑定，影响可移植性和弹性。

4.1.2 网络存储

网络存储在 Kubernetes 的生态系统中扮演着至关重要的角色，它能够为容器化应用提供高效、可靠且可扩展的存储解决方案。NFS（Network File System）和 Ceph 作为两种常见的网络存储技术，各自具有独特的原理和显著的优势。

存储类型	简介	工作原理	在Kubernetes集群中的应用示例	优势	适用场景	支持的存储接口
NFS	成熟的网络文件系统	服务器端共享文件系统，客户端通过网络远程挂载共享目录实现文件访问操作	在Web应用集群中，将静态资源文件存于NFS服务器，挂载其共享目录到各节点，确保应用一致性和稳定性	简单易用，配置相对简单，对网络要求低	对存储性能要求不高但需简单共享文件的场景，如开发和测试环境	文件系统存储
Ceph	分布式存储系统	采用分布式架构，将数据分布在多个存储节点，通过数据冗余和纠删码技术确保数据可靠性	在大数据分析平台中，存储海量原始数据和分析结果，可扩展存储容量，提高读写性能	高性能、高可靠性、高扩展性，支持多种存储接口	大规模数据存储场景，对数据读写性能要求较高的数据库应用场景，需存储大量非结构化数据的应用场景	块存储、对象存储、文件系统存储

4.1.3 持久化存储卷

持久化存储卷（PersistentVolume，简称 PV）是 Kubernetes 中用于实现数据持久化存储和管理的关键资源对象，它为容器化应用提供了一种独立于 Pod 生命周期的存储解决方案。在 Kubernetes 的存储体系中，PV 充当着底层存储资源的抽象层，它可以代表各种不同类型的存储介质，如本地磁盘、网络存储（NFS、Ceph 等），甚至是云存储服务（如 AWS EBS、Google Cloud Persistent Disk 等）。通过 PV，用户可以将存储资源的配置和管理与应用程序的部署和管理分离开来，实现了存储资源的集中化管理和高效利用。

4.2 存储资源管理

在 Kubernetes 的生态系统中，存储编排与管理是确保应用程序数据安全、可靠存储和高效访问的核心环节。在存储管理方面，Kubernetes 提供了丰富的功能。

管理员可以通过配置存储类（StorageClass）来定义不同的存储策略，如存储的性能级别、回收策略等。对于一些对性能要求较高的应用场景，可以创建高性能的存储类，使用高速的存储介质；而对于一些临时数据或不重要的数据，可以创建具有较低性能但成本也较低的存储类。

同时，Kubernetes 还支持对存储资源的动态供应，当 PVC 请求存储资源时，系统可以根据存储类的定义，自动创建相应的 PV，极大地提高了存储资源的管理效率和灵活性。例如，在电商业务快速发展的过程中，可能会突然增加大量的商品数据，需要扩展存储容量。通过配置好的存储类和动态供应机制，Kubernetes 可以自动创建新的 PV 来满足 PVC 对存储容量的需求，确保电商应用的正常运行，而无需管理员手动进行复杂的存储配置和管理操作。

五、Kubernetes服务质量

5.1 服务质量分级

在 K8S的生态体系中，服务质量（Quality of Service，QoS）分级机制对于确保不同类型的应用在共享集群资源时能够获得恰当的资源分配和保障，具有至关重要的意义。通过精细的 QoS 分级，K8S 能够根据应用的特性和需求，实现资源的合理调度与管理，从而提升整个集群的运行效率和稳定性。

K8S 的服务质量分级主要包括 BestEffort、Burstable 和 Guaranteed 三个级别 ，每个级别都有其独特的定义和特性，适用于不同类型的应用场景。

服务质量等级	特点	判定条件	资源分配情况	示例
BestEffort	服务质量等级中最低的一级，Pod中的容器既未设置CPU和内存的请求（requests），也未设置限制（limits）	Pod中的容器无CPU和内存的requests与limits设置	容器在资源分配上处于底层，仅在集群有大量空闲资源时可能获取资源，资源紧张时最先被驱逐	日志分析系统中用于临时处理和分析日志数据的容器，处理具有时效性，部分数据处理中断不影响核心业务
Burstable	服务质量等级处于中间位置	Pod中至少有一个容器设置了CPU或内存的请求（requests），且请求值小于限制（limits）	正常情况下，容器按请求资源量获取资源；资源紧张时，若实际使用量超请求量但未达限制量，仍可能继续运行，但可能受资源限制	在线游戏后台服务器的核心业务逻辑容器，平时资源需求稳定，特殊活动期间可能有短暂资源使用高峰
Guaranteed	服务质量等级中最高的一级	Pod中的每个容器都必须设置CPU和内存的请求（requests），且请求值与限制（limits）相等	为容器提供最强资源保障，Pod调度到节点后，所请求资源完全保证，除非节点故障，否则Pod稳定运行	电商系统订单数据库这类关键数据库服务的容器，保障数据完整性和一致性，避免业务损失

这些服务质量分级的实现原理基于 K8S 的资源调度和管理机制。当一个 Pod 被创建时，K8S 会根据其容器的资源请求和限制设置，为其分配相应的 QoS 等级。在资源调度过程中，K8S 的调度器会优先考虑 Guaranteed 级别的 Pod，确保它们能够获得所需的资源。对于 Burstable 级别的 Pod，调度器会根据节点的资源剩余情况进行合理分配。而 BestEffort 级别的 Pod 则只能在资源有剩余的情况下获取资源。在资源紧张时，K8S 会根据 QoS 等级的优先级，优先驱逐 BestEffort 级别的 Pod，然后是 Burstable 级别的 Pod，以保障 Guaranteed 级别的 Pod 能够持续稳定运行。

5.2 服务质量保障措施

5.2.1 资源调度策略

在 Kubernetes（K8S）的服务质量保障体系中，资源调度策略扮演着核心角色，其关键在于根据服务质量等级，精准且高效地分配集群资源，以确保各类应用的稳定运行。

服务质量级别	资源调度策略	具体调度过程	示例	资源调度特点
Guaranteed	优先保障资源需求	新Pod调度时，调度器先检查集群资源能否满足Guaranteed级Pod需求，遍历节点找可用CPU核心数≥Pod请求数且可用内存≥Pod请求数的节点，满足条件才调度	关键数据库服务设为Guaranteed级别，每个容器请求并限制使用2个CPU核心和4GB内存，调度器找相应资源满足的节点调度	优先满足资源需求，确保核心业务稳定，不受其他应用资源竞争影响
Burstable	相对灵活调度	正常时按Pod资源请求量分配资源；资源紧张时，调度器依节点资源剩余和其他Pod需求，动态调整Burstable级Pod资源分配，只要其使用不超限制仍能运行	在线视频转码服务设为Burstable级别，容器请求1个CPU核心和2GB内存，资源充足按请求分配，如节点CPU使用率80%且有新Guaranteed级Pod需调度，可能限制其CPU使用量	兼顾高优先级应用需求，同时利用剩余资源，提高资源整体利用率
BestEffort	资源剩余时分配	在Guaranteed和Burstable级Pod满足资源需求后，若还有剩余资源才分配给BestEffort级Pod，资源紧张时可能被优先驱逐	用于数据分析的临时任务，计算结果非实时关键，任务因资源不足中断可在资源充足时重启	对资源需求弹性大，资源紧张时可牺牲，保障高优先级应用资源

5.2.2 弹性伸缩机制

在Kubernetes（K8S）服务质量保障中，弹性伸缩机制至关重要。它能依据应用负载变化，智能自动调整应用实例数量，确保应用在不同业务场景维持良好服务质量。

K8S里弹性伸缩主要靠Horizontal Pod Autoscaler（HPA）。HPA实时监控应用负载，按预设规则增减Pod副本数。如电商平台商品展示服务，促销时负载剧增，HPA按设定的CPU利用率阈值（如80%）判断，当Pod平均CPU利用率持续超80%，触发扩容，可能从3个副本增至10个甚至更多，保证用户体验。促销结束，负载降低，当Pod平均CPU利用率持续低于某阈值（如30%），触发缩容，如从10个减到5个或更少，避免资源浪费。借此动态机制，商品展示服务能在不同负载下保持稳定服务质量并优化资源利用。

此外，K8S不仅支持基于CPU利用率伸缩，还支持内存使用率、请求并发数等指标。像实时消息处理系统，可依消息队列积压量或每秒处理消息数配置HPA伸缩。积压消息超阈值，增加Pod副本加快处理；积压量减少，相应减少副本。基于多样指标的伸缩机制，让K8S更适配不同应用的负载变化，精准高效保障服务质量。

六、Kubernetes 资源管理

6.1 K8S资源模型

6.1.1 Node资源

在K8S的大家庭里，每个Node就好比是一台实实在在的物理电脑或者虚拟主机。它们都带着自己的“资源宝藏”，像CPU、内存、存储还有网络资源等。不过，这些资源可不是全部都能给咱们的应用程序用哦。就像家里的房子，一部分得留给自己住，Node的资源也有一部分要被操作系统和系统级别的服务占用。剩下的那些，才是能分给运行在这个节点上的Pods的“可分配资源”。K8S就像个精打细算的管家，会根据每个Node的可分配资源，来决定能在这个节点上安排多少个Pod，以及给每个Pod分配多少资源。

6.1.2 Pod资源

Pod是K8S里最小的“建筑单元”，能部署也能管理，更是资源分配的基础。一个Pod可以想象成一个小房子，里面能住一个或好几个关系紧密的“容器小伙伴”。当我们给Pod分配资源的时候，其实就是给房子里所有的小伙伴一起分配资源。这些住在同一个Pod里的容器小伙伴们，它们共用Pod的网络和存储资源，而且都在Pod设定好的资源约束范围内活动。这就好比大家住在同一个宿舍，资源大家一起用，但也不能想用多少就用多少，这样既保证了它们能高效地交流合作，又能让它们的资源使用规规矩矩。

6.1.3 Namespace资源

Namespace就像是给K8S集群画了一个个虚拟的“小格子”，每个“小格子”里的资源都是相互隔开的。不同“小格子”里的东西可以叫一样的名字，但不会互相干扰。比如说，不同的团队、项目或者环境，都可以有自己独立的Namespace“小天地”。每个“小天地”都能按照自己的需求去申请和限制资源。而且，K8S还能给每个Namespace设定一个“资源口袋”，规定好里面能装多少CPU、内存、存储卷等资源。这样一来，每个Namespace里的Pods就没办法无节制地消耗集群的资源啦，保证了整个集群资源的合理分配和有序管理。

6.2 资源请求和限制

6.2.1 资源请求（Requests）

资源请求就是Pod告诉K8S集群：“我运行的时候至少得要这么多资源哦！”这里面主要说的就是CPU和内存。就好像你要出门旅行，得先准备好至少够你维持基本生活的钱一样。Pod明确了自己需要的资源量，K8S的调度器就能像个聪明的导航，准确地把Pod送到有足够资源的节点上。比如说，有个Pod说它要0.5个CPU核心和1GB内存，调度器就会去找那些CPU可用量大于等于0.5个核心，内存可用量大于等于1GB的节点，把这个Pod稳稳当当地放上去。

资源请求可是调度器安排Pod的重要参考呢。要是集群里的资源有限，调度器就会优先照顾那些资源请求能得到满足的Pod。要是剩下的资源不够所有Pod的请求，调度器就得挑挑拣拣，先把资源分给更需要的Pod，那些资源请求没被满足的Pod，就只能先等着，等有资源空出来了再安排。

6.1.2 资源限制

资源限制就是给Pod或者容器能使用的资源量“封顶”，同样也是针对CPU和内存这些。为啥要这么做呢？想象一下，如果有个容器像个调皮的孩子，因为程序出了问题，比如内存泄漏或者CPU任务疯长，就开始无节制地占用资源，那其他的Pod可就遭殃了。所以，给容器设置资源限制，就像给它戴上了“紧箍咒”，比如限制它只能用1个CPU核心和2GB内存，就算它再调皮，也不能超过这个范围。

资源限制就像是给不同的Pod之间砌了一堵墙，保证每个Pod都不会去抢别人的资源，大家都能在自己的小空间里好好运行。这对那些对资源要求很严格的应用，像数据库服务，就特别重要。给它们设置好合理的资源限制，就能让它们在一个稳定的资源环境里工作，不会因为资源竞争而闹脾气。

K8S还通过一种叫cgroups的技术来实现这个资源限制。同时，它还配了一些监控工具，就像一双眼睛，能随时盯着Pod和容器的资源使用情况。要是发现哪个容器快把资源用光了，或者已经超过限制了，管理员就可以赶紧想想办法，比如调整一下资源限制，或者看看是不是应用程序哪里出问题了，得优化优化。

通过这么一套清晰的资源模型，再加上严格的资源请求和限制机制，K8S就把集群资源管理得井井有条，不管有多少应用程序，都能在这个大舞台上稳定、可靠地展示自己的风采。

通过清晰的资源模型定义和严格的资源请求与限制机制，K8S实现了对集群资源的高效管理和合理分配，确保了在多租户、多应用场景下，各个应用都能稳定、可靠地运行。