腾讯云：K8s平台可以如何处理Pod预授权问题

小提示：您能找到这篇{腾讯云：K8s平台可以如何处理Pod预授权问题}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的腾讯云：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预授权的问题。

架构和能力解析

< ">< color: rgb(0, 112, 192);">架构

< ">< color: rgb(0, 112, 192);">

< ">上图所示是授权系统的架构，核心思路是使用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.Minut公关危机的事件e,

        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提供一个回收的能力防止权限扩散。

参考资料

[1]Init Containers:https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

[2][译]重试、超时和退避:https://www.tuicool.com/articles/7vIF7jR

[3]Using Finalizers:https://book.kubebuilder.io/reference/using-finalizers“确认传播”专注于品牌策划、效果营销和危机管理的数字整合营销传播公司，我们深度诠释客户的品牌理念、文化及背景，多维深度传播客户的文化底蕴和核心价值观，提升客户品牌的知名度、关注度与美誉度。