论坛
潜水/灌水快乐,沉淀知识,认识更多同行。
ToB圈子
加入IT圈,遇到更多同好之人。
朋友圈
看朋友圈动态,了解ToB世界。
ToB门户
了解全球最新的ToB事件
博客
Blog
排行榜
Ranklist
文库
业界最专业的IT文库,上传资料也可以赚钱
下载
分享
Share
导读
Guide
相册
Album
记录
Doing
搜索
本版
文章
帖子
ToB圈子
用户
免费入驻
产品入驻
解决方案入驻
公司入驻
案例入驻
登录
·
注册
只需一步,快速开始
账号登录
立即注册
找回密码
用户名
Email
自动登录
找回密码
密码
登录
立即注册
首页
找靠谱产品
找解决方案
找靠谱公司
找案例
找对的人
专家智库
悬赏任务
圈子
SAAS
ToB企服应用市场:ToB评测及商务社交产业平台
»
论坛
›
容器及微服务
›
容器及微服务
›
kube-apiserver限流机制原理
kube-apiserver限流机制原理
宝塔山
金牌会员
|
2024-5-16 16:02:50
|
显示全部楼层
|
阅读模式
楼主
主题
807
|
帖子
807
|
积分
2421
本文分享自华为云社区《
kube-apiserver限流机制原理
》,作者:可以交个朋友。
背景
apiserver是kubernetes中最告急的组件,一旦遇到恶意刷接口或请求量凌驾承载范围,apiserver服务可能会崩溃,导致整个kubernetes集群不可用。所以我们必要对apiserver做限流处理来提升kubernetes的健壮性。
k8s-apiserver限流能力发展过程
apiserver限流能力的发展分为两个阶段:
kubernetes 1.18版本之前kube-apiserver只是将请求分成了变更类型(create、update、delete、patch)和非变更类型(get、list、watch),并通过启动参数设置了两种类型的最大并发数。
--max-requests-inflight ## 限制同时运行的非变更类型请求的个数上限,0表示无限制。
--max-mutating-requests-inflight ## 限制同时运行的变更类型请求的个数上限。0 表示无限制。
复制代码
此时的apiserver限流能力较弱,若某个客户端错误的向kube-apiserver发起大量的请求时,必然会壅闭kube-apiserver,影响其他客户端的请求,因此高阶的限流APF就诞生了。
kubernetes1.18版本之后APF( APIPriorityAndFairness )成为kubernetes的默认限流方式。 APF以更细粒度的方式对请求进行分类和隔离,根据优先级和公平性进行处理。
--enable-priority-and-fairness ## 该值作为APF特性开关,默认为true
--max-requests-inflight、--max-mutating-requests-inflight ## 当开启APF时,俩值相加确定kube-apiserver的总并发上限
复制代码
两个阶段限流能力对比
限流能力1.18版本前1.18版本后(APF)颗粒度仅根据是否变更做分类可以根据请求对象、请求者身份、命名空间等做分类隔离性一个坏用户可能堵塞整个系统为请求分配固定队列,坏请求只能撑爆其使用的队列公平性会出现饿死用公平性算法从队列中取出请求优先级无有特权级别,可让告急请求不被限制
APF关键资源介绍
APF通过FlowSchema 和 PriorityLevelConfiguration两个资源配置限流策略。
FlowSchema:办理老版本分类颗粒度粗的问题。根据rules字段匹配请求,匹配规则包含:请求对象、实行操作、请求者身份和命名空间
apiVersion: flowcontrol.apiserver.k8s.io/v1beta2
kind: FlowSchema # 一个kubernetes集群中可以定义多个FlowSchema
metadata:
name: myfl
spec:
distinguisherMethod: # 可选值为:ByNamespace或ByUser,用于把请求分组。属于同组的请求会分配到固定的queue中,如果省略该参数,则该FlowSchema匹配的所有请求都将视为同一个分组。
type: ByUser
matchingPrecedence: 90 # 数字越小代表FlowSchema的匹配顺序越在前,取值范围:1~10000。
priorityLevelConfiguration: # FlowSchema关联的priorityLevelConfiguration
name: mypl
rules:
- nonResourceRules: # 匹配非资源型:匹配接口URL
- nonResourceURLs:
- '*'
resourceRules: # 匹配资源型:匹配apigroup、namespace、resources、verbs
- apiGroups:
- '*'
namespaces:
- '*'
resources:
- '*'
verbs:
- get
- create
- list
- update
subjects: # 匹配请求者主体:可选Group、User、ServiceAccount
- group:
name: '*'
kind: Group
- kind: User
user:
name: '*'
- kind: ServiceAccount
serviceAccount:
name: myserviceaccount
namespace: demo
复制代码
PriorityLevelConfiguration:办理老版本隔离性差的问题和优先级问题,并定义了限流细节(总队列数、队列长度、是否可排队)。当请求与某个FlowSchema匹配后,该请求会关联FlowSchema中指定的PriorityLevelConfiguration资源,每个PriorityLevelConfiguration相互隔离,且能遭受的并发请求数也不一样
apiVersion: flowcontrol.apiserver.k8s.io/v1beta2
kind: PriorityLevelConfiguration ## 每个PriorityLevelConfiguration有自己独立的限流配置, PriorityLevelConfiguration之间是完全隔离的。
metadata:
name: mypl
spec:
type: Limited # 设置是否为特权级别,如果为Exempt则不进行限流,如果为Limited则进行限流
limited:
assuredConcurrencyShares: 2 # 值越大,PriorityLevelConfiguration的并发上限越高。若当前并发执行数未达到并发上限,则PL处于空闲状态。
limitResponse: # 定义如何处理当前无法被处理的请求
type: Queue # 类型,Queue或者Reject,Reject直接返回429并拒绝,Queue将请求加入队列
queuing:
handSize: 1 # 根据ByNamespace或ByUser对请求分组,每个分组对应queues的数量,
queueLengthLimit: 20 # 此PriorityLevelConfiguration中每个队列的长度
queues: 2 # 此PriorityLevelConfiguration中的队列数
复制代码
一个FlowSchema只能关联一个priorityLevelConfiguration,多个FlowSchema可以关联同一个priorityLevelConfiguration
PriorityLevelConfiguration并发上限 = assuredConcurrencyShares / 所有assuredConcurrencyShares之和 * apiserver总并发数
APF处理过程
请求与集群中的FlowSchema列表按照次序依次匹配,每个FlowSchema的matchingPrecedence字段决定其在列表中的次序,matchingPrecedence字段值越小,越靠前,越先进行匹配请求。
根据FlowSchema资源中的rules规则进行匹配,匹配方式可以是 “请求的资源类型”、“请求的动作类型”、“请求者的身份”、“请求的命名空间” 等多个维度。
若请求与某个FlowSchema乐成匹配,匹配就会竣事。FlowSchema关联着一个PriorityLevelConfiguration,每个PriorityLevelConfiguration中包含许多queue,根据FlowSchema.spec.Distinguisher字段将请求进行"分组",根据分组来分配queue,分配queue数量由PriorityLevelConfiguration资源的handSize字段决定,假如省略该参数,则该FlowSchema匹配的所有请求都将视为同一个"分组"。
每个PriorityLevelConfiguration资源都有独立的并发上限,assuredConcurrencyShares字段为apiserver总并发数的权重占比,值越大分配的并发上限就越高,当PriorityLevelConfiguration达到并发上限后,请求会根据所属的"分组"写入固定的queue中,请求被壅闭等待。请求与queue的固定关联可以让恶意用户只影响其使用的queue,而不会影响同PriorityLevelConfiguration中的其他queue。
当PriorityLevelConfiguration未达到并发上限时,fair queuing算法从所有queue中选择一个合适的queue取出请求,解除请求的壅闭,实行这个请求。fair queuing算法能包管同一个 PriorityLevelConfiguration 中的所有queue被处理机会平等。
APF实战
kubernetes原生自带了一些FlowSchema和PriorityLevelConfiguration规则,我们选择一个检察,如下图:
下面我们创建新的APF规则:当请求对象是apf命名空间中的deployment,则进行"apfpl"限流规则。
apiVersion: flowcontrol.apiserver.k8s.io/v1beta2
kind: FlowSchema
metadata:
name: apffl
spec:
matchingPrecedence: 150
priorityLevelConfiguration:
name: apfpl ## 关联名为apfpl的PriorityLevelConfiguration
rules:
- resourceRules:
- apiGroups:
- apps
clusterScope: true
namespaces:
- apf ## 匹配apf命名空间
resources:
- deployments ## 匹配操作deployment的请求
verbs:
- '*' ## 匹配任意操作类型
subjects:
- kind: Group
group:
name: '*' ## 匹配任意组身份
---
apiVersion: flowcontrol.apiserver.k8s.io/v1beta2
kind: PriorityLevelConfiguration
metadata:
name: apfpl
spec:
limited:
assuredConcurrencyShares: 2
limitResponse: ## 设置限流处理细节
queuing:
handSize: 1
queueLengthLimit: 20
queues: 2
type: Queue
type: Limited ## 对请求做限流处理
复制代码
接着在apf命名空间和default命名空间分别创建deployment进行测试。apf_fs为请求被分类到的 FlowSchema 的名称,apf_pl为该请求的优先级名称。检察apiserver日志信息,见下图:
循环操作deployment,我们可以使用命令检察是否触发限流等待
kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels
复制代码
返回waitingRequests非0,则代表触发最大并发数,有请求被限流进入等待队列。PriorityLevelConfiguration资源不为空闲表示已达到并发上限
点击关注,第一时间了解华为云新鲜技术~
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
本帖子中包含更多资源
您需要
登录
才可以下载或查看,没有账号?
立即注册
x
回复
使用道具
举报
0 个回复
倒序浏览
返回列表
快速回复
高级模式
B
Color
Image
Link
Quote
Code
Smilies
您需要登录后才可以回帖
登录
or
立即注册
本版积分规则
发表回复
回帖并转播
回帖后跳转到最后一页
发新帖
回复
宝塔山
金牌会员
这个人很懒什么都没写!
楼主热帖
分布式事务 | 使用DTM 的Saga 模式 ...
WebLogic JNDI注入(CVE-2021-2109) ...
Sqlserver2012卸载
【K哥爬虫普法】你很会写爬虫吗?10秒 ...
php微信自定义分享链接,标题,描述, ...
轻量级CI/CD发布部署环境搭建及使用_03 ...
JVM中的编译器
Redis监控指标
SQL Server实例间同步登录用户 ...
哈工大信息安全概论期末复习 ...
标签云
挺好的
服务器
快速回复
返回顶部
返回列表