這篇文章將為大家詳細(xì)講解有關(guān)K8s 平臺(tái)是怎么處理Pod預(yù)授權(quán)問(wèn)題，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)！專(zhuān)注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、微信小程序定制開(kāi)發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶(hù)創(chuàng)新互聯(lián)還提供了臺(tái)州免費(fèi)建站歡迎大家使用！

背景

**新部署業(yè)務(wù)或者擴(kuò)容，如何對(duì)新設(shè)備進(jìn)行預(yù)授權(quán)？**相信大家對(duì)這個(gè)問(wèn)題并不陌生，基于安全考慮，公司內(nèi)部往往重要組件、存儲(chǔ)都會(huì)對(duì)訪(fǎng)問(wèn)請(qǐng)求進(jìn)行來(lái)源控制，常見(jiàn)的如 CDB 的 IP 訪(fǎng)問(wèn)授權(quán)，OIDB、VASKEY 命令字的模塊授權(quán)等。它們或者有自己的授權(quán) WEB 可以讓用戶(hù)提單申請(qǐng)，或者提供授權(quán) API 可以讓運(yùn)維平臺(tái)調(diào)用。而路由系統(tǒng)往往在發(fā)現(xiàn)注冊(cè)時(shí)需要準(zhǔn)確獲取 IP 設(shè)備的地域信息以提供就近訪(fǎng)問(wèn)的能力，這就需要預(yù)注冊(cè) CMDB。

在以前使用 CVM/TVM 部署業(yè)務(wù)時(shí)，這個(gè)問(wèn)題可以較容易的處理，因?yàn)槲覀兪穷A(yù)先拿到了一臺(tái)虛擬機(jī)，已經(jīng)分配好了 IP 注冊(cè)好了 CMDB，業(yè)務(wù)要做的就是用這個(gè) IP 去提單授權(quán)，部署業(yè)務(wù)程序，在一切完備后加上路由上線(xiàn)，這個(gè)過(guò)程是可以用運(yùn)維平臺(tái)的流水線(xiàn)能力做成自動(dòng)化。

區(qū)別于 VM 的拿到可用設(shè)備后的步驟型過(guò)程化部署，Kubernetes管理的是 Pod 從生產(chǎn)、IP 分配、業(yè)務(wù)容器啟動(dòng)、路由維護(hù)的整個(gè)生命周期，由多個(gè)系統(tǒng) Controller 的 Control Loop 做自動(dòng)化的管理，基于鏡像的部署提供了業(yè)務(wù)實(shí)例的伸縮一致性保障，Pod 的銷(xiāo)毀重建變成常態(tài)，IP 也并非能固定下來(lái)。

業(yè)務(wù)往往面對(duì)多種預(yù)授權(quán)的需要，授權(quán)均值時(shí)間從秒級(jí)到幾分鐘不等，授權(quán) API 大多并沒(méi)有設(shè)計(jì)為承載高 QPS，有一定的復(fù)雜性。我們需要能找到一種方法，在 Pod IP 分配后，業(yè)務(wù)容器起來(lái)前處理授權(quán)，阻塞住并保障成功后再進(jìn)行后續(xù)過(guò)程，并且控制重建過(guò)程對(duì)授權(quán)API的壓力。

經(jīng)過(guò)設(shè)計(jì)與迭代優(yōu)化，TKEx-CSIG 平臺(tái)提供給了業(yè)務(wù)易用的產(chǎn)品能力化的授權(quán)能力，方便應(yīng)對(duì)這類(lèi) Pod 預(yù)授權(quán)的問(wèn)題。

架構(gòu)和能力解析

架構(gòu)

上圖所示是授權(quán)系統(tǒng)的架構(gòu)，核心思路是使用 init Container 先于業(yè)務(wù)容器執(zhí)行的特性，實(shí)現(xiàn)在業(yè)務(wù) Pod 啟動(dòng)前進(jìn)行復(fù)雜的邏輯預(yù)處理。官方對(duì) 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

如果是小規(guī)?；騿蝹€(gè)業(yè)務(wù)的解決方案，我們是可以做的很簡(jiǎn)單，在業(yè)務(wù) Worklooad yaml 中注入 init Container，調(diào)用需要的授權(quán) API 實(shí)現(xiàn)即可，而要做成平臺(tái)產(chǎn)品化的能力，還需要考慮以下幾點(diǎn)：

• 易用與可維護(hù)

  需要充分考慮業(yè)務(wù)使用上的效率和可管理性，將權(quán)限作為一項(xiàng)資源由平臺(tái)記錄管理，減小變更對(duì)業(yè)務(wù)的侵入性影響。

• 限頻與自愈

  權(quán)限 API 往往并沒(méi)有對(duì)高 QPS 的設(shè)計(jì)，需要限制調(diào)用保護(hù)下游。

• 權(quán)限收斂

  安全性，Pod 的銷(xiāo)毀重建可能導(dǎo)致 IP 變化，考慮主動(dòng)回收已經(jīng)過(guò)期的權(quán)限

授權(quán)過(guò)程產(chǎn)品能力化

業(yè)務(wù)僅需在平臺(tái) WEB 控制臺(tái)上登記需要的權(quán)限資源，配置權(quán)限組，關(guān)聯(lián)權(quán)限組到 Workload，平臺(tái)自動(dòng)進(jìn)行 init Container 的配置注入，通過(guò) ENV 傳遞授權(quán)配置索引和相關(guān)信息，在 Pod 創(chuàng)建時(shí)進(jìn)行授權(quán)過(guò)程。授權(quán)過(guò)程涉及的幾個(gè)組件功能設(shè)計(jì)如下：

• init-action-client

  init Container，僅作一個(gè)觸發(fā)裝置，僅做一件事，就是發(fā)起 HTTP 調(diào)用請(qǐng)求，保持不可變，這樣當(dāng)功能迭代時(shí)不必修改業(yè)務(wù)的 yaml，主邏輯后移處理

• init-action-server

  deployment 部署可橫向擴(kuò)展，執(zhí)行預(yù)處理邏輯，預(yù)注冊(cè) CMDB 等操作，并發(fā)起流水線(xiàn)調(diào)用，啟動(dòng)權(quán)限的申請(qǐng)過(guò)程并輪詢(xún)查詢(xún)，將過(guò)程信息關(guān)聯(lián) POD 暴露出來(lái)方便業(yè)務(wù)自查和管理員定位問(wèn)題。后文提到的退避重試和斷路器邏輯也在這里實(shí)現(xiàn)。

• PermissionCenter

  平臺(tái)管控組件，位于集群外，負(fù)責(zé)權(quán)限資源的存儲(chǔ)和實(shí)際申請(qǐng)。包含一個(gè)權(quán)限資源中心，存儲(chǔ)業(yè)務(wù)登記的權(quán)限詳情參數(shù)方便復(fù)用，提供權(quán)限 Set 組管理，簡(jiǎn)化授權(quán)過(guò)程中的參數(shù)傳遞；使用生產(chǎn)者/消費(fèi)者模式，基于 Pipline 實(shí)現(xiàn)授權(quán) API 的調(diào)用和結(jié)果查詢(xún)。

斷路器和退避重試機(jī)制

可能導(dǎo)致授權(quán)過(guò)程的異常狀況不少，例如權(quán)限參數(shù)錯(cuò)誤的配置，授權(quán) API 服務(wù)質(zhì)量下降或不可用，甚至是網(wǎng)絡(luò)原因?qū)е碌慕涌阱e(cuò)誤、超時(shí)等。授權(quán) API 往往也并沒(méi)有設(shè)計(jì)支持高 QPS，我們采用超時(shí)重試，加斷路器和指數(shù)退避重試去做一個(gè)容錯(cuò)性。

• 超時(shí)重試

  體現(xiàn)在接口調(diào)用和異步任務(wù)的超時(shí)設(shè)置與重試機(jī)制，應(yīng)對(duì)瞬時(shí)故障，init-action-client 容器非正常退出也會(huì)進(jìn)行重建，每次創(chuàng)建就是新一輪的重試。

• 斷路器

  使用一個(gè) Configmap 專(zhuān)門(mén)記錄集群里 Pod 權(quán)限申請(qǐng)的失敗次數(shù)，3次即斷路不給申請(qǐng)。并提供一個(gè)重置能力，暴露給前端，讓用戶(hù)和管理員可以便捷進(jìn)行重試。

• 指數(shù)退避

  斷路器模式可以阻斷用戶(hù)配置錯(cuò)誤這類(lèi)永遠(yuǎn)也不可能授權(quán)成功的案例，但是無(wú)法應(yīng)對(duì)長(zhǎng)時(shí)間的瞬時(shí)故障。比如裁撤期，授權(quán) API 后端可能會(huì)有一段時(shí)間的拒絕服務(wù)，10分鐘到幾小時(shí)，此時(shí)會(huì)有大量 Pod 授權(quán)命中斷路器規(guī)則無(wú)法繼續(xù)授權(quán)，人為處理時(shí)效性差也繁瑣。我們?yōu)槊總€(gè) Pod 添加了一個(gè)帶抖動(dòng)的指數(shù)退避器并記錄最近的失敗時(shí)間戳，能夠在一段時(shí)間后允許嘗試一次，如果成功就重置對(duì)指定 Pod 的退避，如若不成功更新時(shí)間戳重新計(jì)時(shí)，參數(shù)如下，

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 收斂權(quán)限

權(quán)限的收斂問(wèn)題往往被忽略，但是也是安全需要考慮的，Pod 的銷(xiāo)毀重建可能是常態(tài)，IP 指不準(zhǔn)也動(dòng)態(tài)變化，長(zhǎng)時(shí)間可能產(chǎn)生大量垃圾權(quán)限，或者已經(jīng)授權(quán)過(guò)的 IP 分配到別的業(yè)務(wù) Pod，產(chǎn)生安全風(fēng)險(xiǎn)。我們做了一個(gè) Finalizer 控制器來(lái)在 Pod 銷(xiāo)毀前進(jìn)行權(quán)限回收，回收動(dòng)作是冪等性的，而且是盡力而為的，因?yàn)榛厥盏哪芰σ惨蕾?lài)于權(quán)限方是否具備回收能力，我們對(duì)新對(duì)接的權(quán)限都會(huì)考慮這一點(diǎn)，比如騰訊云 MySQL 的 IP 自動(dòng)授權(quán)。

為了減少打 Finalizer 的動(dòng)作，盡可能不影響非授權(quán)關(guān)心的 Pod，我們只在 Pod 進(jìn)行了變更事件時(shí)識(shí)別有授權(quán) init Container 的 Pod，Patch 上 Finalizer 標(biāo)記，在這些 Pod 縮容銷(xiāo)毀時(shí)進(jìn)行權(quán)限的回收并刪除 Finalizer，隨后 GC 會(huì)刪除這個(gè) Pod。

kind: Pod
metadata:
  annotations:
~
  creationTimestamp: "2020-11-13T09:16:52Z"
  finalizers:
  - stke.io/podpermission-protection

關(guān)于K8s 平臺(tái)是怎么處理Pod預(yù)授權(quán)問(wèn)題就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。