K8s 平台是怎么处理Pod预授权问题

这篇文章将为大家详细讲解有关K8s 平台是怎么处理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

关于K8s 平台是怎么处理Pod预授权问题就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。