正软商城

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

时间：2026-08-20

前言

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 实现即可，而要做成平台产品化的能力，还需要考虑以下几点：

授权过程产品能力化

业务仅需在平台 WEB 控制台上登记需要的权限资源，配置权限组，关联权限组到 Workload，平台自动进行 init Container 的配置注入，通过 ENV 传递授权配置索引和相关信息，在 Pod 创建时进行授权过程。授权过程涉及的几个组件功能设计如下：

断路器和退避重试机制

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

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自动授权。

为了减少打 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

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

本文转载于：https://apiv1.oschina.net/oschinapi/blog/detail?id=4912370 如有侵犯，请联系zhengruancom@outlook.com删除。
免责声明：正软商城发布此文仅为传递信息，不代表正软商城认同其观点或证实其描述。

同类商品

相关文章

更多