1.在离线混部-Koordinator Cpu Burst 特性 源码调研
2.在家庭私有云上实现 K8S 部署 kong 网关和 konga 管理后台
3.Kubernetes OOM 和 CPU Throttling 问题
4.开源免费的源码服务网格 Service Mesh
5.k8s-服务网格实战-入门Istio
6.kubernetesç½ç»åCNIç®ä»
在离线混部-Koordinator Cpu Burst 特性 源码调研
在离线混部场景下,Koordinator引入了Cpu Burst特性来优化CPU资源管理。限流这个特性源自Linux内核的源码CPU Burst技术,旨在处理突发的限流CPU使用需求,减少CPU限流带来的源码影响。cgroups的限流conta 源码参数如cpu.share、cpu.cfs_quota_us和cpu.cfs_burst,源码分别控制了CPU使用率、限流配额和突发缓冲效果。源码在Kubernetes中,限流资源请求(requests.cpu)和限制(limits.cpu)通过这些参数来实现动态调整,源码以保证容器间公平的限流CPU分配。
对于资源调度,源码Kubernetes的限流Bandwidth Controller通过时间片限制进程的CPU消耗,针对延迟敏感业务,源码如抖音视频服务,通过设置合理的CPU limits避免服务质量下降,同时也考虑资源的高效利用。然而,常规的限流策略可能导致容器部署密度降低,因为时间片间隔可能不足以应对突发的CPU需求。CPU Burst技术正是为了解决这个问题,通过收集未使用的CPU资源,允许在突发时使用,从而提高CPU利用率并减少throttled_time。
在Koordinator的配置中,通过configMap可以调整CPU Burst的百分比,以及在负载过高时的调整策略。例如,当CPU利用率低于阈值时,允许动态扩展cfs_quota,以应对突发的CPU使用。源码中,会根据节点负载状态和Pod的QoS策略来调整每个容器的CPU Burst和cfs_quota。
总的来说,Cpu Burst特性适用于资源利用率不高且短作业较多的场景,能有效提升核心业务的CPU资源使用效率,同时对相邻容器的影响较小。在某些情况下,结合cpuset的核绑定和NUMA感知调度可以进一步减少CPU竞争。理解并灵活运用这些技术,有助于优化云计算环境中的资源分配和性能管理。
在家庭私有云上实现 K8S 部署 kong 网关和 konga 管理后台
Kong是一个开源的API网关框架,它具备众多高级功能,包括流量控制、API安全、服务发现、熔断、iphone 浏览器 源码限流等,旨在帮助开发者构建可扩展、可靠和安全的微服务应用程序。
以下是Kong的一些主要特点:
简单易用:Kong提供了一个简单的命令行接口和易于使用的配置文件系统,使得部署和管理API网关变得非常简单。
多协议支持:Kong支持多种常见的HTTP/HTTPS协议,如HTTP、HTTPS、WebSocket等。
灵活的配置:Kong允许用户根据需要自定义各种参数,例如限流、熔断、日志记录等。
高度可扩展:Kong可以轻松地集成其他流行的服务发现、负载均衡和监控工具,例如Consul、Eureka和Prometheus等。
社区支持:Kong是由一个活跃的开源社区开发的,这意味着用户可以获得很好的技术支持和文档资源。
在K8S中部署Kong的步骤如下:
1、如果还没有命名空间,先创建。
2、在k8s的master节点进入任意目录新建kong-migrations.yaml、kong.yaml、konga.yaml三个文件,把如下信息粘贴进去:
注意:kong-migrations.yaml这个POD是专门用来初始化数据库的,执行一次之后就可以删除了。
注意:kong.yaml这里需要注意一下,我是把kong的端口映射到宿主机的和,确保你宿主机这两个常用端口没有被占用,还有个问题是k8s的nodePort端口范围为:-,配置文件直接写和,会报错,需要改下配置。
找到kube-apiserver.yaml文件的绝对路径,其路径为"/etc/kubernetes/manifests/kube-apiserver.yaml",并添加参数"- --service-node-port-range=1-",如下所示:
不需要重启,过一会自动就生效了。
注意:konga.yaml这里我使用了NFS把konga的文件映射出来,这样当Pod被销毁或者被调度到其他节点之后数据都不会丢失,你如果还没有安装NFS服务器可以参考我之前写的“在家庭私有云上实现 Docker 部署 NFS 网络文件系统”这篇文章。
执行kubeclt命令。
我们打开k8s-dashboard管理后台瞄一眼:
然后在浏览器输入master节点的ip+端口:打开konga管理后台,输入如下信息,让konga管理kong的长微博转换 源码路由配置:
连接成功:
在konga管理后台验证成功后,如何验证kong网关是否能够正常提供服务呢?首先拿出我的域名,这个域名没有备案,但是我把它解析到k8s的master节点的内网ip,仅仅做内网使用是没问题的。
在konga管理后台点开服务管理,新建服务,填入如下信息:
接着点开Routes选项卡,配置通过 konga.azyu.cc访问:
点击保存,之前我们是通过IP加端口的方式访问konga管理后台,现在可以通过域名,在浏览器输入 konga.azyu.cc,大功告成!
Kubernetes OOM 和 CPU Throttling 问题
使用 Kubernetes 时,内存不足(OOM)错误和 CPU 限制(Throttling)是云应用程序中资源处理的主要难题。为什么会出现这种情况呢?
云应用程序中的 CPU 和内存要求变得越来越重要,因为它们与您的云成本直接相关。
通过配置 limits 和 requests,您可以确定 pod 如何分配内存和 CPU 资源,从而避免资源短缺并调整云成本。
那么,如何监控 Pod 是否快要发生 OOM 或 CPU 被限制了呢?
Pod 中的每个容器都需要内存才能运行。
Kubernetes limits 是在 Pod 定义或 Deployment 定义中为每个容器设置的。
所有现代 Unix 系统都有一种方法可以杀死进程,以此回收内存(当没有空闲内存时,只能杀进程了)。这个错误将被标记为 错误码或 OOMKilled。
退出代码 表示该进程使用的内存超过允许的数量,必须被 OS 终止。
这是 Linux 中的一项功能,内核为系统中运行的进程设置 oom_score 值。此外,它还允许设置一个名为 oom_score_adj 的值,Kubernetes 使用该值来实现服务质量。它还具有 OOM Killer,它将检查进程并终止那些使用过多内存(比如申请了超过 limits 限制的数量的内存)的进程。
请注意,在 Kubernetes 中,进程可能会达到以下任何限制:内存过量分配。
限制(limits)可以高于请求(requests),因此所有限制的总和可以高于节点容量。这称为过量分配,并且很常见。实际上,如果所有容器使用的内存多于 request 的内存,则可能会耗尽节点中的内存。这通常会导致一些 pod 死亡,以释放一些内存。大番薯源码 盘多多
在 Prometheus 生态中,使用 node-exporter 时,有一个名为 node_vmstat_oom_kill 的指标。跟踪 OOM 终止何时发生非常重要,但您可能希望在此类事件发生之前抢占先机并了解其情况。
我们更希望的是,检查进程与 Kubernetes limits 的接近程度:
CPU 限制(throttling)是一种当进程即将达到某些资源限制时减慢速度的行为。与内存情况类似,这些限制可能是:
想想下面的类比。我们有一条高速公路,交通流量如下:
这里的 throttling 被表示为交通拥堵:最终,所有进程都会运行,但一切都会变慢。
CPU 在 Kubernetes 中通过shares 进行处理。每个 CPU 核心被分为 个 shares,然后使用 Linux 内核的 cgroups(control groups)功能在运行的所有进程之间进行划分。
如果 CPU 可以处理当前所有进程,则无需执行任何操作。如果进程使用超过 % 的 CPU,shares 机制就要起作用了。与任何 Linux 内核一样,Kubernetes 使用 CFS(Completely Fair Scheduler)机制,因此拥有更多份额的进程将获得更多的 CPU 时间。
与内存不同,Kubernetes 不会因为限流而杀死 Pod。
You can check CPU stats in /sys/fs/cgroup/cpu/cpu.stat
正如我们在 limits 和 requests 文章中看到的,当我们想要限制进程的资源消耗时,设置 limits 或 requests 非常重要。尽管如此,请注意不要将总 requests 设置为大于实际 CPU 大小,每个容器都应该有保证的 CPU。
您可以检查进程与 Kubernetes limits 的接近程度:
如果我们想要跟踪集群中发生的限制量,cadvisor 提供了 container_cpu_cfs_throttled_periods_total 和 container_cpu_cfs_periods_total 两个指标。通过这两个指标,您可以轻松计算所有 CPU 周期内的限制百分比。
Limits 是在节点中设置资源最大上限的一种方法,但需要谨慎对待,因为您可能最终会受到限制或终止进程。
准备好应对驱逐
通过设置非常低的请求,您可能认为这将为您的进程授予最少的 CPU 或内存。但 kubelet 会首先驱逐那些使用率高于请求的 Pod,因此就相当于您将这些进程标记为最先被杀死的!
如果您需要保护特定 Pod 免遭抢占(当 kube-scheduler 需要分配新 Pod 时),请为最重要的进程分配 Priority Classes。
Throttling 是一个无声的敌人
设置不切实际的 limits 或过度使用,您可能没有意识到您的进程正在受到限制并且性能受到影响。主动监控 CPU 用量,课堂考勤系统jsp源码了解确切的容器和命名空间层面的限制,及时发现问题非常重要。
下面这张图,比较好的解释了 Kubernetes 中 CPU 和内存的限制问题。供参考:
本文翻译自: sysdig.com/blog/trouble...
开源免费的服务网格 Service Mesh
服务网格是一种微服务管理的软件基础设施,旨在简化和提升服务间通信的可靠性和可扩展性。其核心在于Sidecar模式,分离服务的通信功能与应用业务,Sidecar代理负责服务间的通信,业务代码仅与其他进程的代理通信。
Conduit是轻量级、高性能且易于理解和使用的ServiceMesh框架,与Kubernetes集成,提供服务发现、负载均衡、熔断和限流功能。它使用Rust语言开发数据平面,Go语言开发控制平面,内存占用极小。
Consul Connect是基于Consul的服务网格,支持服务注册、发现、负载均衡、路由、熔断等功能,提供应用间双向TLS连接,侧重应用安全。
Envoy是Lyft开发的高性能服务网格框架,适用于大规模应用,作为数据层代理,负责服务网格中应用间流量管理。
Istio是一个强大的开源服务网格,提供统一的路径保护、连接和监控服务,无需修改服务代码即可实现负载平衡、服务间身份验证和监控。
Kuma是Kong开发的开源服务网格框架,提供跨集群全局控制平面、多环境服务网格、安全性和策略等功能,支持Kubernetes和虚拟机。
Linkerd是Kubernetes服务网格的开源解决方案,提供服务间通信、故障处理、负载平衡和安全性功能,以轻量级、安全优先为特点。
Maesh是Containous开发的开源服务网格框架,基于Traefik的反向代理和负载均衡器,提供简单且易于使用的服务网格,增强服务间连通性。
Open Service Mesh由Microsoft开发的开源框架,支持最新服务网格标准SMI,提供简单易用的服务网格功能。
k8s-服务网格实战-入门Istio
进入服务网格系列,前面已讲解基本知识,但企业中存在复杂应用调用关系,需要管理限流、降级、trace、监控、负载均衡等功能。
在kubernetes出现之前,这些问题通常由微服务框架解决,如Dubbo、SpringCloud等。但kubernetes出现后,这些功能应交给专门的云原生组件,即本篇将讲解的Istio,它是目前最广泛使用的服务网格解决方案。
官方对Istio的解释简洁,具体功能包括限流、降级、trace、监控、负载均衡等。Istio分为控制面control plane和数据面data plane,控制面负责Istio自身管理功能,数据面由Envoy代理业务应用,实现流量管理。
首先安装Istio命令行工具,确保有kubernetes运行环境,Linux使用特定命令,Mac使用brew,其他环境下载Istio配置环境变量。
使用install命令安装控制面,默认使用kubectl配置的kubernetes集群,使用demo profile。
为namespace添加label,使得Istio控制面知道哪个namespace下的Pod自动注入sidecar,为default命名空间开启自动注入,部署deployment-istio.yaml。
每个Pod有两个container,其中一个istio-proxy sidecar,进行负载均衡测试,效果相同,说明Istio生效。
观察sidecar日志,看到所发出和接收到的流量。
本期内容简单,主要涉及安装配置,下期将更新内部服务调用的超时、限流等功能配置。
大部分操作偏运维,后续功能配置只需编写yaml资源。
生产使用时,提供管理台可视化页面,方便开发者灵活配置功能。
各大云平台厂商提供类似能力,如阿里云的EDAS等。
本文源码可访问github.com/crossoverJie...
kubernetesç½ç»åCNIç®ä»
对äºä»»ä½kubernetesç½ç»æ¹æ¡ï¼é½éè¦æ»¡è¶³ä»¥ä¸éæ±ï¼å®¹å¨éè¿ä½¿ç¨linuxå æ ¸æä¾çCgroupsåNamespacesææ¯å®ç°äºç¸äºä¹é´çç½ç»ãåå¨çèµæºçé离ä¸éå¶ã对äºç½ç»ï¼kubernetes项ç®ä¸çPodåéè¿è®©ä¸ç»ç¨æ·å®¹å¨åpause容å¨/infra容å¨å ±äº«ä¸ä¸ªnetwork namespaceçæ¹å¼ï¼ä½¿ä¸ä¸ªPodå ç容å¨é½ä½¿ç¨äºä¸ä¸ªç½ç»æ ãèä¸ä¸ª Network Namespace çç½ç»æ å æ¬ï¼ç½å¡ï¼Network Interfaceï¼ãåç¯è®¾å¤ï¼Loopback Deviceï¼ãè·¯ç±è¡¨ï¼Routing Tableï¼å iptables è§åãæ以ï¼ä¸é¾æ³è±¡ï¼Podçç½ç»åä¸å°èææºçç½ç»æ é 置起æ¥å®é ä¸æ¯ç±»ä¼¼çï¼æ¯å¦åæ ·éè¦èæç½å¡ï¼IPãMACå°åçï¼å¹¶ä¸æ¯ä¸ªPodé½æèªå·±å¯ä¸çç½ç»æ ãå½ææçPodé½æäºèªå·±çç½ç»æ åï¼å¦ææ³è¦è¿æ¥ä¸¤ä¸ªPodè¿è¡éä¿¡ï¼å类似äºå ¶ä»ä»»ä½ç½ç»æ¶æï¼éè¦é 置交æ¢æºãè·¯ç±å¨çï¼å¹¶ä¸ºå ¶è§åIPï¼è·¯ç±çä¿¡æ¯ãå¦ææ¯å¯¹äºç©çæºï¼æ们å¯ä»¥ä½¿ç¨ç½çº¿ã交æ¢æºãè·¯ç±å¨è¿äºè®¾å¤è¿è¡è¿æ¥ï¼ä½å¨Podä¸æ¾ç¶éè¦å ¶ä»æ¹å¼ã
kubernetes Podçç½ç»æ¹æ¡æå¾å¤ï¼æå ¸åçå°±æ¯Flannelçä¸ç§å端å®ç°æ¹å¼äºï¼UDPãVxLanãhost-gwï¼ï¼è®¨è®ºè¿äºå主è¦æ¯å¨å ³æ³¨å®¹å¨è·¨ä¸»æºéä¿¡çé®é¢ãèè¿é主è¦è®¨è®ºçåæ¯Podçå é¨çç½å¡å¦ä½å建ï¼åå¦ä½å°ç½ç»æ°æ®å å¨å®¿ä¸»æºå容å¨ä¹é´ä¼ éã
å¾çæ¥èª è¿é
CNIæ¯Container Network Interfaceç缩åï¼å®æ¯ä¸ä¸ªéç¨ç容å¨ç½ç»æ件çk8sç½ç»æ¥å£ï¼å¼æºç¤¾åºéå·²ç»æäºå¾å¤å®ç°å®¹å¨ç½ç»çæ¹æ¡ï¼ä¸åçç½ç»å®ç°æ¹æ¡å¨k8så é½æ¯ä»¥æ件è°ç¨çå½¢å¼å·¥ä½ï¼æ以è¿ééè¦ä¸ä¸ªç»ä¸çæ åæ¥å£ãå¦æå°k8sçPodè§ä¸ºä¸å°âèææºâï¼é£ä¹ç½ç»æ件çå·¥ä½å°±æ¯ç®¡çè¿å°èææºçç½ç»æ ï¼å æ¬ç»è¿å°èææºæå ¥ç½å¡ãé 置路ç±ãIPçï¼èCNIçå·¥ä½åæ¯å¯¹æ¥ç½ç»æ件åkubelet容å¨è¿è¡æ¶ç®¡çå·¥å ·ï¼å¯¹äºdocker容å¨è¿è¡æ¶æ¥è¯´å®é ä¸æ¯dockershimï¼ï¼ä¸»è¦ä½ç°å¨Podçå建åå é¤è¿ç¨ï¼
CNI é ç½®æ件ï¼ç»CRI使ç¨çï¼æ¯å¦dockershim
CNIå®æ¹ç»´æ¤çæ件å æ¬ä»¥ä¸å 个ï¼å¯¹äºå·²ç»æ建好çk8sï¼cniæ件å¯ä»¥å¨ /opt/cni/bin/ æ件夹ä¸æ¥çï¼
CNIçåºç¡å¯æ§è¡æ件æç §åè½å¯ä»¥åå为ä¸ç±»ï¼
Mainæ件ï¼åå»ºå ·ä½ç½ç»è®¾å¤
bridge ï¼ç½æ¡¥è®¾å¤ï¼è¿æ¥containeråhost
ipvlan ï¼ä¸ºå®¹å¨å¢å ipvlanç½å¡
loopback ï¼lo设å¤
macvlan ï¼ä¸ºå®¹å¨å建ä¸ä¸ªMACå°å
ptp ï¼å建ä¸å¯¹Veth Pair
vlan ï¼åé ä¸ä¸ªvlan设å¤
host-device ï¼å°å·²åå¨ç设å¤ç§»å ¥å®¹å¨å
IPAMæ件ï¼è´è´£åé IPå°å
dhcp ï¼å®¹å¨åDHCPæå¡å¨å起请æ±ï¼ç»Podåæ¾æåæ¶IPå°å
host-local ï¼ä½¿ç¨é¢å é ç½®çIPå°å段æ¥è¿è¡åé
static ï¼ä¸ºå®¹å¨åé ä¸ä¸ªéæIPv4/IPv6å°åï¼ä¸»è¦ç¨äºdebug
metaæ件ï¼å¹¶éåç¬ä½¿ç¨
bandwidth ï¼ä½¿ç¨Token Bucket Filterï¼TBFï¼æ¥éæµçæ件
flannel ï¼flannelç½ç»æ¹æ¡çCNIæ件ï¼å¯¹åºäºflannelé ç½®æ件
portmap ï¼éè¿iptablesé 置端å£æ å°
sbr ï¼ä¸ºç½å¡è®¾ç½®source based routing
tuning ï¼éè¿sysctlè°æ´ç½ç»è®¾å¤åæ°
firewall ï¼éè¿iptablesç»å®¹å¨ç½ç»çè¿åºæµéè¿è¡ä¸ç³»åéå¶
å®éªå 容ï¼goå®è£ 社åºç»´æ¤çCNIç¸å ³æ件ï¼å¨linux主æºä¸å建ä¸ä¸ªnetwork namespaceï¼åå©ç¨å®è£ çç½ç»æ件ç»è¿ä¸ªlinux network namespaceé 置好ç½ç»ãå®éªæ¹æ³æç¨åèçæ¯ è¿é
å®è£ cniæ件ï¼
linuxä¸å建ä¸ä¸ªnetwork namespaceï¼
设置ç½ç»åæ°ï¼
vi /etc/cni/net.d/-myptp.conf
模æç»å®¹å¨é ç½®ç½ç»ï¼
è¿åå¼
æµè¯ç½ç»æ¯å¦å¯ç¨ï¼
è¿å ¥namespaceï¼pingä¸ä¸ç¾åº¦çDNS
æ¸ é¤ï¼
æåå¤è¯´ä¸å¥ï¼æè°çäºæå¡å ¶å®å°±æ¯åºäºç½ç»çæå¡ï¼å¥½å¥½è§åç½ç»å¯ä»¥å åå©ç¨æ°æ®ä¸å¿çèµæºï¼åªæå åå©ç¨æ°æ®ä¸å¿çèµæºï¼æè½ç§°ä¹ä¸ºäºè®¡ç®ã
在 EKS 集群中使用 Traefik 管理4/7层流量
王跃祖和张杰合作的文章指出,在国内知名人工智能企业的业务容器化部署中,亚马逊云科技 Amazon Elastic Kubernetes Service (EKS) 采用了AWS Load Balancer Controller来管理4/7层服务流量。然而,考虑到客户业务的复杂性和对认证系统的需求,他们发现Traefik是一个更合适的选择。
Traefik作为一款开源的负载均衡和反向代理工具,具有高效资源管理、动态配置、丰富中间件支持以及自动发现容器变化等特点。它能够简化配置,自动调整路由规则,支持多种负载均衡算法,并且能通过中间件实现认证、限流等功能。在EKS环境中,通过Helm部署Traefik 2.7.0版本,配合EKS v1..9-eks,可以有效替代原有的ALB和NLB,节省资源并提高管理效率。
具体应用上,Traefik可以创建nginx应用和IngressRoute资源,提供HTTPS支持,实现路径重写、流量复制和身份验证。例如,通过HTTP跳转至HTTPS中间件,确保访问安全;使用IPWhiteList中间件,实现访问控制。Traefik的流量镜像功能,如将%流量镜像到测试版本,有助于业务测试和故障排查。
最终,通过将+个负载均衡器简化为Traefik服务,不仅降低了成本,还增强了系统的安全性和灵活性。可视化的Traefik Dashboard提供了更好的监控和管理体验。综上,Traefik的引入带来了显著的收益和提升。
KubeVela 1.7 版本解读:接管你的已有工作负载
接管工作负载
KubeVela 1.7 版本发布,引入了工作负载接管功能,让已有工作负载能自然迁移到标准化体系中,被统一管理。接管提供两种模式:“只读”与“接管”。前者适用于内部已有平台,能以只读方式统一观测应用。后者适用于直接迁移场景,自动接管工作负载,实现统一管理。
使用策略(policy)体系定义接管规则,选择器区分资源类型,确保应用创建时可纳入管理,复用配置。在“只读”策略中,资源如“Deployment”是只读的,运维特征创建和修改“Ingress”、“Service”不受影响。在“接管”策略中,资源可控,应用创建时能将已有资源纳入管理,仅将对“scaler”运维特征的实例数修改作为配置。
通过命令行一键接管工作负载,方便快捷。使用`vela adopt`命令,指定资源类型、命名空间与名称,自动生成接管的`Application`对象。命令默认使用“只读”模式,支持原生资源、Helm应用及批量接管命名空间下全部工作负载。
接管规则灵活定义,基于可扩展设计原则,使用CUE定义配置转换规则。命令行一键接管是规则的一种特例,适用于高阶用户,更多细节可参考官方文档。
大幅性能优化
性能优化是1.7版本亮点之一,整体性能、单应用容量、应用处理吞吐量提升5到倍,涉及资源配额调整、压缩功能、应用与组件版本记录上限降低、参数调整等。
通过ztsd压缩功能,默认开启,资源大小压缩近倍,单个KubeVela Application资源容量扩大倍。应用版本记录上限从个减少到2个,组件版本默认关闭,控制器内存消耗缩小1/3。定义历史版本记录从个减少到2个,Kubernetes API交互限流QPS从提升到。
易用性提升
客户端支持多环境资源渲染,实现策略(policy)和工作流(workflow)根据不同环境自定义生成不同实际资源。应用删除功能增强,交互式删除资源,保留下层资源或保留应用元数据。插件安装后自定义输出,允许制作者动态输出安装提示。工作流能力增强,支持更多细粒度操作,包括在工作流中构建镜像并推送到镜像仓库。
VelaUX控制台增强功能,包括用户界面和操作优化。KubeVela 1.8版本预计在3月底发布,规划包括进一步增强功能。社区欢迎参与讨论,成为贡献者或合作伙伴,详情可访问GitHub社区页面。
kube-apiserver限流机制原理
本文分享自华为云社区《kube-apiserver限流机制原理》,作者:可以交个朋友。
背景:apiserver在Kubernetes中扮演核心角色,一旦遭遇恶意刷接口或请求量超负荷,apiserver服务可能崩溃,影响整个Kubernetes集群的可用性。因此,实现apiserver限流是提升Kubernetes健壮性的关键。
k8s-apiserver限流能力演进:限流能力经历了两个阶段。在kubernetes 1.版本之前,限流主要分为变更和非变更请求类型,并通过配置参数设定最大并发数,但这限制了处理能力。随后,引入了APF(APIPriorityAndFairness)作为默认限流方式,以更细粒度分类和隔离请求,结合优先级和公平性策略处理。
两个阶段对比显示了APF在分类颗粒度和隔离性方面的显著提升。老版本限流方法在处理大规模请求时,易导致性能瓶颈,影响其他客户端请求。而APF通过更精细的资源管理和策略配置,实现更高效、灵活的限流控制。
APF关键资源介绍:APF包含FlowSchema和PriorityLevelConfiguration两个核心资源。FlowSchema解决分类颗粒度粗的问题,通过规则匹配请求,覆盖资源类型、操作类型、请求者身份和命名空间等维度。PriorityLevelConfiguration则解决隔离性差和优先级问题,定义限流细节,如队列数量、队列长度和是否可排队。关联规则匹配的请求,实现精细化管理。
处理过程:请求与集群中的FlowSchema列表匹配,优先级较低的规则先进行匹配。匹配规则后,请求关联到指定的PriorityLevelConfiguration资源。资源中包含多个队列,根据请求分组分配队列数量,实现请求隔离。每个PriorityLevelConfiguration资源具备独立并发上限,确保公平性处理请求,避免恶意用户影响系统整体性能。
实战示例:通过查看Kubernetes原生规则,创建自定义规则以限流特定资源。通过在不同命名空间中创建测试实例,模拟请求,分析apiserver日志信息,验证限流效果。实现对特定请求的限制,确保系统稳定运行。
总结:通过深入了解kube-apiserver限流机制原理,掌握APF的分类、优先级管理和队列分配策略,可以有效提升Kubernetes集群的稳定性,防范大规模请求带来的风险,确保服务持续可用。