TKEx-CSIG 是基于腾讯公有云 TKE 和 EKS 容器服务开发的内部上云容器服务平台，为解决公司内部容器上云提供云原生平台，以兼容云原生、适配自研业务、开源协同为最大特点。
业务容器上云过程中，会遇到一些问题，有的需要业务进行容器化改造，有的需要平台赋能。平台赋能的部分，有一类问题是 CVM 场景下已经有解决方案的，而因运维方式不同在 Kubernetes 平台上不兼容的，比如 Pod 预授权的问题。我们希望用云原生的方式解决这一类问题并提供平台化的能力，让每一位用户都能够在平台上便捷的部署和管理自己的业务。
背景新部署业务或者扩容，如何对新设备进行预授权？相信大家对这个问题并不陌生，基于安全考虑，公司内部往往重要组件、存储都会对访问请求进行来源控制，常见的如 CDB 的 IP 访问授权，OIDB、VASKEY 命令字的模块授权等。它们或者有自己的授权 WEB 可以让用户提单申请，或者提供授权 API 可以让运维平台调用。而路由系统往往在发现注册时需要准确获取 IP 设备的地域信息以提供就近访问的能力，这就需要预注册 CMDB。
在以前使用 CVM/TVM 部署业务时，这个问题可以较容易的处理，因为我们是预先拿到了一台虚拟机，已经分配好了 IP 注册好了 CMDB，业务要做的就是用这个 IP 去提单授权，部署业务程序，在一切完备后加上路由上线，这个过程是可以用运维平台的流水线能力做成自动化。
区别于 VM 的拿到可用设备后的步骤型过程化部署，Kubernetes管理的是 Pod 从生产、IP 分配、业务容器启动、路由维护的整个生命周期，由多个系统 Controller 的 Control Loop 做自动化的管理，基于镜像的部署提供了业务实例的伸缩一致性保障，Pod 的销毁重建变成常态，IP 也并非能固定下来。
业务往往面对多种预授权的需要，授权均值时间从秒级到几分钟不等，授权 API 大多并没有设计为承载高 QPS，有一定的复杂性。我们需要能找到一种方法，在 Pod IP 分配后，业务容器起来前处理授权，阻塞住并保障成功后再进行后续过程，并且控制重建过程对授权API的压力。
经过设计与迭代优化，TKEx-CSIG 平台提供给了业务易用的产品能力化的授权能力，方便应对这类 Pod 预授权的问题。
架构和能力解析 架构上图所示是授权系统的架构，核心思路是使用 init Container 先于业务容器执行的特性，实现在业务 Pod 启动前进行复杂的逻辑预处理。官方对 init Container 的定义如下
This page provides an overview of init containers: specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image如果是小规模或单个业务的解决方案，我们是可以做的很简单，在业务 Worklooad yaml 中注入 init Container，调用需要的授权 API 实现即可，而要做成平台产品化的能力，还需要考虑以下几点：
易用与可维护
需要充分考虑业务使用上的效率和可管理性，将权限作为一项资源由平台记录管理，减小变更对业务的侵入性影响。
限频与自愈
权限 API 往往并没有对高 QPS 的设计，需要限制调用保护下游。
权限收敛
安全性，Pod 的销毁重建可能导致 IP 变化，考虑主动回收已经过期的权限
授权过程产品能力化业务仅需在平台 WEB 控制台上登记需要的权限资源，配置权限组，关联权限组到 Workload，平台自动进行 init Container 的配置注入，通过 ENV 传递授权配置索引和相关信息，在 Pod 创建时进行授权过程。授权过程涉及的几个组件功能设计如下：
init-action-client
init Container，仅作一个触发装置，仅做一件事，就是发起 HTTP 调用请求，保持不可变，这样当功能迭代时不必修改业务的 yaml，主逻辑后移处理
init-action-server
deployment 部署可横向扩展，执行预处理逻辑，预注册 CMDB 等操作，并发起流水线调用，启动权限的申请过程并轮询查询，将过程信息关联 POD 暴露出来方便业务自查和管理员定位问题。后文提到的退避重试和断路器逻辑也在这里实现。
PermissionCenter