「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】