ApiServer中的限流
max-request-inflight: 总的请求数
max-mutating-request-inflight: 最大的请求修改的请求数
kubernetes支持更细粒度的限流当时,称谓APF(api priority and fairness),不同的请求划分成了不同的优先级,每个优先级有对应不同的flow,每个flow又对应很多queueset,就是避免某个请求持续对apiserver影响造成其他请求的访问
API Priority and Fairness
• APF 的实现依赖两个非常重要的资源 FlowSchema, PriorityLevelConfiguration
• APF 对请求进行更细粒度的分类,每一个请求分类对应一个 FlowSchema (FS)
• FS 内的请求又会根据 distinguisher 进一步划分为不同的 Flow.
• FS 会设置一个优先级 (Priority Level, PL),不同优先级的并发资源是隔的。所以不同优先级的资源不会相互排挤。特定优先级的请求可以被高优处理。
• 一个 PL 可以对应多个 FS,PL 中维护了一个 QueueSet,用于缓存不能及时处理的请求,请求不会因为超出 PL 的并发限
制而被丢弃。
• FS 中的每个 Flow 通过 shuffle sharding 算法从 QueueSet 选取特定的queues 缓存请求。
• 每次从 QueueSet 中取请求执行时,会先应用 fair queuing 算法从 QueueSet 中选中一个 queue,然后从这个 queue 中取出 oldest 请求执行。所以即使是同一个 PL 内的请求,也不会出现一个 Flow 内的请求一占用资源的不公平现象
kubectl get flowschema service-accounts -o yaml
distinguisherMethod表示不同的service account不同的flow,matchingPrecedence 表示优先级,priorityLevelConfiguration表示在个优先级队列,rules表示那些动作属于这个优先级
概念
• 传入的请求通过 FlowSchema 按照其属性分类,并分配优先级。
• 每个优先级维护自定义的并发限制,加强了隔离度,这样不同优先级的请求,就不会相互饿死。
• 在同一个优先级内,公平排队算法可以防止来自不同 flow 的请求相互饿死。
• 该算法将请求排队,通过排队机制,防止在平均负载较低时,通信量突增而导致请求失败。
优先级
• 如果未启用 APF,API 服务器中的整体并发量将受到 kube-apiserver 的参数 --maxrequests-inflight 和 --max-mutating-requests-inflight 的限制。
• 启用 APF 后,将对这些参数定义的并发限制进行求和,然后将总和分配到一组可配置的 优先
级 中。 每个传入的请求都会分配一个优先级;
• 每个优先级都有各自的配置,设定允许分发的并发请求数。
• 例如,默认配置包括针对领导者选举请求、内置控制器请求和 Pod 请求都单独设置优先级。这表示即使异常的 Pod 向 API 服务器发送大量请求,也无法阻止领导者选举或内置控制器的操作执行成功
豁免请求
某些特别重要的请求不受制于此特性施加的任何限制。这些豁免可防止不当的流控配置完全禁用API 服务器。
健康检查的请求具有豁免能力
调试
• /debug/api_priority_and_fairness/dump_priority_levels —— 所有优先级及其当前状态的列表
kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels
• /debug/api_priority_and_fairness/dump_queues —— 所有队列及其当前状态的列表
kubectl get --raw /debug/api_priority_and_fairness/dump_queues
• /debug/api_priority_and_fairness/dump_requests ——当前正在队列中等待的所有请求的列表
kubectl get --raw /debug/api_priority_and_fairness/dump_requests
集群的组件通过下面的svc访问apiserver
apiserver中的每个group内的资源在apiserver连接etcd的时候公用连接,这个是可以调的,我们也可以自定义apiserver然后通过apiserver aggregate加入到主apiserver