ps企业网站模板免费下载,如何制作营销网站,wordpress显示文章阅读数,如何修改网站元素Kubernetes容器编排引擎 一、Kubernetes管理对象1.1 Kubernetes组件和架构1.2 主要管理对象类型 二、Kubernetes 服务2.1 服务的作用与原理2.2 服务类型 三、Kubernetes网络管理3.1 网络模型与目标3.2 网络组件3.2.1 kube-proxy3.2.2 网络插件 3.3 网络通信流程 四、Kubernetes… Kubernetes容器编排引擎 一、Kubernetes管理对象1.1 Kubernetes组件和架构1.2 主要管理对象类型 二、Kubernetes 服务2.1 服务的作用与原理2.2 服务类型 三、Kubernetes网络管理3.1 网络模型与目标3.2 网络组件3.2.1 kube-proxy3.2.2 网络插件 3.3 网络通信流程 四、Kubernetes 存储管理4.1 存储类型4.1.1 本地存储4.1.2 网络存储4.1.3 持久化存储卷 4.2 存储资源管理 五、Kubernetes服务质量5.1 服务质量分级5.2 服务质量保障措施5.2.1 资源调度策略5.2.2 弹性伸缩机制 六、Kubernetes 资源管理6.1 K8S资源模型6.1.1 Node资源6.1.2 Pod资源6.1.3 Namespace资源 6.2 资源请求和限制6.2.1 资源请求Requests6.1.2 资源限制 在当今数字化时代企业的应用架构正经历着深刻变革从传统的单体架构逐渐向微服务架构转型。这种转型带来了诸多优势如更高的灵活性、可扩展性和可维护性。然而随着微服务数量的不断增加应用的部署、管理和运维变得愈发复杂面临着诸如资源分配、服务发现、负载均衡、故障恢复等一系列挑战。
容器技术的出现为解决这些问题提供了新的思路。容器能够将应用及其依赖项打包成一个独立的、可移植的单元实现了环境的一致性和隔离性。而 Kubernetes简称 K8S作为容器编排领域的佼佼者应运而生成为了解决容器化应用管理难题的关键工具。Kubernetes是一款开源的容器编排引擎在容器化应用的管理领域发挥着核心作用。其主要使命是实现容器化应用的自动化部署、精细扩展以及高效管理旨在为应用的运行提供一个稳定、可靠且灵活的环境。 一、Kubernetes管理对象
1.1 Kubernetes组件和架构
Kubernetes作为容器编排领域的核心技术其架构由多个关键组件构成控制平面与数据平面各司其职网络及存储组件提供支持各组件紧密协作共同构建了强大且可靠的Kubernetes系统。 架构分层组件组件功能在架构中的作用控制平面Master NodeAPIServer提供RESTful接口用于管理和操作Kubernetes资源是整个集群的控制中心负责接收和处理所有来自客户端和其他组件的请求作为集群的入口统一管理和协调各组件对资源的操作确保整个集群状态的一致性和准确性ETCD分布式键值对存储用于保存集群的所有状态信息包括资源配置、Pod状态等为集群提供可靠的数据存储保证数据的持久性、一致性和高可用性是整个集群运行的基础支撑scheduler负责将新创建的Pod调度到合适的工作节点上运行根据资源需求、节点状态等因素进行调度决策实现资源的合理分配确保每个Pod都能在满足其运行条件的节点上运行提高集群整体资源利用率和应用性能controller - managers包含多个控制器如节点控制器、副本控制器等负责维护集群中各种资源的状态确保实际状态与期望状态一致自动管理和维护集群中资源的状态通过不断监控和调整保证集群的稳定性和可靠性数据平面Worker Nodekubelet每个工作节点上运行的代理负责与控制平面通信管理本节点上的Pod生命周期包括创建、启动、停止等操作作为工作节点与控制平面的桥梁负责将控制平面的指令在本地节点上执行实现对Pod的具体管理kube - proxy实现Kubernetes服务的网络代理和负载均衡功能通过在节点上维护网络规则将服务请求转发到后端的Pod实例确保服务能够被正确访问通过负载均衡将请求均匀分配到后端Pod提高服务的可用性和性能容器运行时如Docker、containerd等负责运行容器管理容器的镜像拉取、启动、停止等操作是容器化应用实际运行的基础为应用提供隔离的运行环境网络组件CNIContainer Network Interface插件如Flannel、Calico等负责为Pod分配网络地址实现Pod之间以及Pod与外部网络的通信构建集群的网络拓扑确保各个Pod之间能够进行有效的通信满足不同应用场景下的网络需求存储组件CSIContainer Storage Interface插件如NFS、Ceph等负责管理和提供存储资源实现容器化应用的数据持久化存储为应用提供可靠的数据存储解决方案确保数据在容器生命周期之外的持久性和可用性
1.2 主要管理对象类型 Kubernetes对象概念作用特点使用场景示例PodKubernetes中最小的可部署和可管理的计算单元是一个或多个紧密相关容器的集合共享网络和存储资源承载容器化应用实现容器间高效协作有唯一IP地址生命周期短暂且动态各类应用场景如Web应用等Web应用中Nginx容器与基于Node.js或Python Flask的应用容器封装在同一Pod共享网络命名空间通过localhost通信还可挂载共享存储卷Service一种抽象层用于定义一组Pod的访问策略实现服务发现和负载均衡通过标签选择器关联Pod为其提供稳定访问入口解决Pod IP地址动态变化导致的访问不稳定问题电商系统中订单处理服务的多个Pod实例通过Service关联Service将用户请求分配到不同Pod处理ClusterIP ServiceService的一种类型为服务分配仅在集群内部可访问的虚拟IP地址仅在集群内部可访问集群内部服务间通信集群内部服务A调用服务B时通过ClusterIP Service进行通信NodePort ServiceService的一种类型在每个节点上开放指定端口可从集群外部通过节点IP加端口号访问服务可从集群外部访问需要从集群外部访问服务但不想借助外部负载均衡器的场景开发测试环境从本地通过NodePort访问集群内服务LoadBalancer ServiceService的一种类型借助云提供商的负载均衡器为服务分配外部可访问的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为ClusterIPKubernetes自动分配内部虚拟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的targetPort80LoadBalancer借助云提供商负载均衡器将服务暴露给外部互联网实现流量均衡与健康监测适用于电商平台前端、在线支付等需高可用、高并发的关键服务创建Service指定type为LoadBalancerKubernetes向云提供商请求创建负载均衡器分配公网IP均衡分发流量至后端Pod在AWS上创建LoadBalancer型Service自动生成ELB负载均衡器分配公网IP外部通过此IP访问流量被分发给3个后端PodIngress管理外部流量为集群服务提供统一入口可按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实现高效通信当用户请求发送到ServiceService依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类型的Servicekube-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 作为其中的典型代表具有各自鲜明的特点和适用场景。
网络插件开发者设计初衷网络实现方式后端实现方式及特点FlannelCoreOS实现容器与主机之间更优的网络连接创建覆盖网络Overlay Network为每个节点分配子网用于为节点上容器分配IP地址跨主机Pod通信时将数据包封装在UDP协议中通过Overlay网络传输在目标节点解封装后转发到目标Pod1. UDP最早实现方式在用户空间进行数据包封装和解封装实现基本网络通信功能但性能有局限2. VXLAN利用Linux内核的VXLAN隧道技术将数据包封装在VXLAN帧中传输提高网络性能和稳定性3. host - gateway适用于对网络性能要求高且所有节点在同一二层网络的场景通过在节点配置路由规则直接转发数据包到目标节点减少封装和解封装开销提升网络性能CalicoTigera原由Metaswitch开发为Kubernetes集群提供高效、灵活且安全的网络解决方案基于BGP边界网关协议提供纯三层网络解决方案不创建额外Overlay网络直接利用底层网络IP路由功能为每个容器分配唯一且在整个集群可路由的IP地址根据BGP协议计算最佳路由路径将数据包直接发送到目标Pod的IP地址无额外特定后端实现方式表述因其核心基于BGP路由网络策略是其重要特色功能特点是基于BGP实现高效路由结合丰富的网络安全策略实现细粒度流量控制保障网络安全
Calico 的优势不仅在于其高效的路由能力还在于它提供了丰富的网络安全功能。通过网络策略Network PolicyCalico 可以对 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 的生态系统中扮演着至关重要的角色它能够为容器化应用提供高效、可靠且可扩展的存储解决方案。NFSNetwork 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 ServiceQoS分级机制对于确保不同类型的应用在共享集群资源时能够获得恰当的资源分配和保障具有至关重要的意义。通过精细的 QoS 分级K8S 能够根据应用的特性和需求实现资源的合理调度与管理从而提升整个集群的运行效率和稳定性。
K8S 的服务质量分级主要包括 BestEffort、Burstable 和 Guaranteed 三个级别 每个级别都有其独特的定义和特性适用于不同类型的应用场景。
服务质量等级特点判定条件资源分配情况示例BestEffort服务质量等级中最低的一级Pod中的容器既未设置CPU和内存的请求requests也未设置限制limitsPod中的容器无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 资源调度策略
在 KubernetesK8S的服务质量保障体系中资源调度策略扮演着核心角色其关键在于根据服务质量等级精准且高效地分配集群资源以确保各类应用的稳定运行。
服务质量级别资源调度策略具体调度过程示例资源调度特点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 弹性伸缩机制
在KubernetesK8S服务质量保障中弹性伸缩机制至关重要。它能依据应用负载变化智能自动调整应用实例数量确保应用在不同业务场景维持良好服务质量。
K8S里弹性伸缩主要靠Horizontal Pod AutoscalerHPA。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实现了对集群资源的高效管理和合理分配确保了在多租户、多应用场景下各个应用都能稳定、可靠地运行。
