K8S 生態週報| Ingress NGINX 專案暫停接收新功能將專注於穩定性提升

張晉濤 發表於 2022-07-04
k8s
「K8S 生態週報」內容主要包含我所接觸到的 K8S 生態相關的每週值得推薦的一些資訊。歡迎訂閱專欄「k8s生態」

題外話

大家好,我是張晉濤。

本次我將這個部分放在開頭。聊聊最近的一些情況。

「K8S 生態週報」暫停了 2 個多月的時間,期間也有小夥伴來催更,感謝大家的持續關注!!!

主要有兩方面的原因,一是我近期確實比較忙,另一方面是我進行了一些思考和總結,分享給大家。

「K8S 生態週報」從 2019 年的 3 月開始,到現在已經是第四年了,我也一直在思考,它能為我,還有關注我的讀者小夥伴們帶來什麼。

對我而言,這是一個總結歸檔,分享反饋的過程,在此期間我也成長了很多。

我比較開心的事情是,相比於其他人/其他社群發的日報,週報等,「K8S 生態週報」並不單純的是在搬運連結,或者搬運 ChangeLog,
在每期的內容中,除去資訊本身外,我也會增加我的一些個人看法,還有我所瞭解到的一些其他內容,包括一些背景知識等。
此外,還會包括一些程式碼的分析/功能的實踐和對比等。可以說「K8S 生態週報」是更有技術性的內容。

基於以上的一些分析和個人的一些思考,我決定後續「K8S 生態週報」中將加入更多我個人的思考的理解,
在提供這些有價值的資訊的同時,與小夥伴們增加更多的交流和溝通。

Ingress NGINX 專案暫停接收新功能將專注於穩定性提升

熟悉我的小夥伴可能知道,我是 Kubernetes Ingress NGINX 專案的 maintainer 。

經過我們開發團隊的長時間討論,我們發現 Kubernetes Ingress NGINX 專案自 2016 年到現在已經走過了 6 年時間,
在這 6 年的時間裡,在 GitHub 上達到了 13K star,同時也有 800+ 位 Contributor 參與貢獻此專案,
同時也收到了 4000+ 的 Issue 反饋,以及 4000+ 的 PR 。

在這個過程中,Ingress NGINX 專案的功能得到了極大的豐富,但作為一個軟體,不可避免的也會有各種 bug,漏洞等存在。
目前對於此專案來說,大家會在需要某些功能的時候快速的去實現它(感謝大家貢獻的 PR),但是當出現 bug 或漏洞的時候,卻很少有人
來修正它。(在開源專案中,這是一個普遍情況,修正 bug 或漏洞,相比於增加新功能,需要對專案自身更加的熟悉)

這種情況實際上為維護者們增加了很多負擔,我們需要把時間放在處理 issue,新增和 review 新功能的 PR,以及進行 bug 和漏洞修正,以及考慮
新功能是否可能會帶來一些連鎖反應等。

在上面的資料中,可以看到此專案和社群都是比較活躍的,我們在業餘時間進行此專案的維護和開發,整體上壓力是比較大的,而且無法做到非常及時的響應。

近期 Ingress NGINX 專案中報告了一些安全漏洞(已經進行了修復),但在修正過程中,我們發現要完美的修正這些漏洞是比較難的,而且任意的改動都
有可能會引起其他的連鎖反應,包括引入其他的漏洞,或者影響使用者的某些功能/行為等。

基於以上的考慮,我們一致達成了決定, 暫停接收新功能,並專注於修復和提升 Ingress NGINX 專案的穩定性 。可能你有新的 PR 正在等待合併,
但是很抱歉,希望你能夠理解,在我們提升了此專案的穩定性後,我們可以迭代的更快!

目前我們的計劃是用 6 個月的時間來完成此目標,並且我們已經確定了一些具體需要做的事情,你可以通過以下連結瞭解我們的進度:
https://github.com/kubernetes...

同時,我們也正式發出了一項社群調查,用於幫助我們決定在此凍結期後,我們應該發展的方向。如果你是 Ingress NGINX 的使用者,請填寫此表單,謝謝!

https://www.surveymonkey.com/...

上游進展

為 kubectl 引入 kuberc 配置檔案

KEP-3104 這個 KEP 旨在為 kubectl 引入一個新的配置檔案 kuberc,用來配置一些使用者的自定義配置。這在很多的專案,或者工具中都有類似的用法。比如 Vim 中可以通過 -u 指定使用者自己的配置檔案,或者使用預設的 ~/.vimrc 來完成自定義配置。

這樣做的好處就在於可以讓 kubeconfig 更加的專注,僅僅需要保留和叢集、使用者憑證相關的資訊即可,對於使用者的自定義配置則分離開來。具體而言,這個配置檔案看起來就會是這樣:

apiVersion: v1alpha1
kind: Preferences

command:
  aliases:
    - alias: getdbprod
      command: get pods -l what=database --namespace us-2-production
      
  overrides:
    - command: apply
      flags:
        - name: server-side
          default: "true"
    - command: delete
      flags:
        - name: confirm
          default: "true"
    - command: "*"
      flags:
        - name: exec-auth-allowlist
          default: /var/kubectl/exec/...

看起來也比較直觀,可以用來增加一些 alias 和覆蓋一些預設的配置,這樣大家不再需要定義很多的 alias,以後使用 kubectl 的時候敲的命令也能少很多。
此特性未實現之前,
在這裡順便推薦另一個專案 kubectl-aliases,此專案中包含了很多 alias,可以讓使用 kubectl 的過程更加簡單。

但也有一些弊端,就像是每個 Vim 使用者都要有自己的 vimrc 配置檔案一樣,這會養成一定的習慣。在一些沒有自己自定義配置的機器上使用時,會有些不習慣。
同時,這在排查問題時,也可能增加排查的鏈路(比如 kuberc 中增加了一個錯誤的配置之類的)。

舉例來說,我在排查 Vim 的問題時候,通常會直接 vim -u /dev/null 這樣,以防使用了任何自定義配置造成影響。那麼後續如果這個功能完全實現了,那麼大家在
排查問題的時候,需要注意使用 kubectl --kuberc /dev/null 類似這樣的方式來避免本地自定義配置造成影響。

PodSecurity 特性達到 GA

近期在 #110459 · kubernetes/kubernetes 中正式將 PodSecurity 特性升級到 GA 。如果我沒有記錯,這個
特性應該是從引入到 GA 最快的特性之一了。

PodSecurity 是自 Kubernetes v1.22 引入的 alpha 特性,作為 PodSecurityPolicy 的一個替代。在 v1.23 達到 beta 級別,通過上述 PR,在 v1.25 正式 GA ,並且預設啟用,可以看到
整個發展過程還是很快的。

PodSecurity 定義了 3 種級別:

  • Enforce:如果 Pod 違反策略,則不會被建立;
  • Audit:如果 Pod 違反策略,則在審計日誌中會被記錄,但是 Pod 仍將正常建立;
  • Warn:如果 Pod 違反策略,則會在 console 中列印 warning 資訊,Pod 仍將正常建立;

使用起來也很簡單,只需要給 namespace 新增 pod-security.kubernetes.io/<mode>=<standard> 標籤即可。

但是如果你的叢集版本較低,並且還希望能有一個相對通用的方法,我建議你可以看看我之前寫的文章。《理清 Kubernetes 中的准入控制(Admission Controller)》
《雲原生策略引擎 Kyverno (上)》
通過使用 Admission controller 、OPA/GateKeeper、Kyverno 等來完成統一配置。


歡迎訂閱我的文章公眾號【MoeLove】