K8s 平臺可以如何處理 Pod 預授權問題

騰訊雲原生發表於2021-01-19
K8S

前言

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

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！

相關文章