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

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

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

断路器和退避重试机制

可能导致授权过程的异常状况不少，例如权限参数错误的配置，授权 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自动授权。

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

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