K8s 平台可以如何处理 Pod 预授权问题 (2)

平台管控组件,位于集群外,负责权限资源的存储和实际申请。包含一个权限资源中心,存储业务登记的权限详情参数方便复用,提供权限 Set 组管理,简化授权过程中的参数传递;使用生产者/消费者模式,基于 Pipline 实现授权 API 的调用和结果查询。

断路器和退避重试机制

K8s 平台可以如何处理 Pod 预授权问题

可能导致授权过程的异常状况不少,例如权限参数错误的配置,授权 API 服务质量下降或不可用,甚至是网络原因导致的接口错误、超时等。授权 API 往往也并没有设计支持高 QPS,我们采用超时重试,加断路器和指数退避重试去做一个容错性。

超时重试

体现在接口调用和异步任务的超时设置与重试机制,应对瞬时故障,init-action-client 容器非正常退出也会进行重建,每次创建就是新一轮的重试。

断路器

使用一个 Configmap 专门记录集群里 Pod 权限申请的失败次数,3次即断路不给申请。并提供一个重置能力,暴露给前端,让用户和管理员可以便捷进行重试。

指数退避

断路器模式可以阻断用户配置错误这类永远也不可能授权成功的案例,但是无法应对长时间的瞬时故障。比如裁撤期,授权 API 后端可能会有一段时间的拒绝服务,10分钟到几小时,此时会有大量 Pod 授权命中断路器规则无法继续授权,人为处理时效性差也繁琐。我们为每个 Pod 添加了一个带抖动的指数退避器并记录最近的失败时间戳,能够在一段时间后允许尝试一次,如果成功就重置对指定 Pod 的退避,如若不成功更新时间戳重新计时,参数如下,

bk := &PodBreaker{ NamespacePod: namespacePod, LastRequestFailTime: time.Now(), Backoff: wait.Backoff{ Duration: 2 * time.Minute, Factor: 2.0, Jitter: 1.0, Steps: 5, Cap: 1 * time.Hour, }, } Finalizer 收敛权限

权限的收敛问题往往被忽略,但是也是安全需要考虑的,Pod 的销毁重建可能是常态,IP 指不准也动态变化,长时间可能产生大量垃圾权限,或者已经授权过的 IP 分配到别的业务 Pod,产生安全风险。我们做了一个 Finalizer 控制器来在 Pod 销毁前进行权限回收,回收动作是幂等性的,而且是尽力而为的,因为回收的能力也依赖于权限方是否具备回收能力,我们对新对接的权限都会考虑这一点,比如腾讯云 MySQL 的 IP 自动授权。

K8s 平台可以如何处理 Pod 预授权问题

为了减少打 Finalizer 的动作,尽可能不影响非授权关心的 Pod,我们只在 Pod 进行了变更事件时识别有授权 init Container 的 Pod,Patch 上 Finalizer 标记,在这些 Pod 缩容销毁时进行权限的回收并删除 Finalizer,随后 GC 会删除这个 Pod。

kind: Pod metadata: annotations: ~ creationTimestamp: "2020-11-13T09:16:52Z" finalizers: - stke.io/podpermission-protection 总结

本文解决的是业务使用容器平台时,在业务进程启动前的预处理如自动化授权的一类问题。使用 init Container 实现业务容器启动前的预处理,并将授权特性产品能力化让业务能较为方便的管理和申请权限资源,断路器和退避重试机制提供容错性,使用 Finalizer 提供一个回收的能力防止权限扩散。

参考文章

Init Containers
[译] 重试、超时和退避
Using Finalizers

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯,扫码关注同名公众号,及时获取更多干货!!

K8s 平台可以如何处理 Pod 预授权问题

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zyyxyz.html