一篇從應用部署/服務管治/集羣配置三個方便來check你的K8S使用姿勢是否正確,包含單不限於服務監控檢查/資源使用/標籤/HPA，VPA/安全策略/RBAC/日誌/監控是否爲最佳實踐的check list。
一 應用部署
1.1 健康檢查
readiness probe確定容器何時可以接收流量。
Kubelet執行檢查並確定應用程序是否可以接收流量。
liveness probe確定何時應重新啓動容器。
kubelet執行檢查並確定是否應重新啓動容器。
1.1.1 容器就緒性探針
就緒性和存活性探針沒有默認值，如果您未設置就緒探針，則kubelet會假定該應用程序已準備就緒，可以在容器啓動後立即接收流量。
1.1.2 發生致命錯誤時容器崩潰
如果應用程序遇到不可恢復的錯誤，則應使其崩潰，例如：
- 未捕獲的異常
- 代碼中的錯字（用於動態語言）
- 無法加載標頭或依賴項
請注意，您不應發信號通知Liveness探針失敗，相反，您應該立即退出該過程，並讓kubelet重新啓動容器。
1.1.3 配置被動的存活性探針
Liveness探針旨在在卡住容器時重新啓動容器，例如：
如果您的應用程序正在處理無限循環，則無法退出或尋求幫助。
當該進程消耗100％的CPU時，將沒有時間回覆（其他）Readiness探針檢查，並且最終將其從服務中刪除。但是，該Pod仍被註冊爲當前Deployment的活動副本。如果沒有Liveness探針，它將保持運行狀態，但與服務分離。換句話說，該過程不僅不處理任何請求，而且還消耗資源。
此時應該怎麼辦：
- 從您的應用程序公開端點
- 端點總是回覆成功響應
- 使用“活力”探針獲取端點
請注意，您不應該使用Liveness探針來處理應用程序中的致命錯誤，並要求Kubernetes重新啓動應用程序。相反，您應該讓應用程序崩潰。
僅在過程無響應的情況下，才應將“活動性”探針用作恢復機制。
1.1.4 存活性探針與就緒性探針的區別
當“活力”和“就緒”探針指向相同的端點時，探針的作用會合併在一起。
當應用程序發出信號表明尚未準備就緒或尚待運行時，kubelet會將容器與服務分離並同時將其刪除。
您可能會注意到連接斷開，因爲容器沒有足夠的時間耗盡當前連接或處理傳入的連接。
可以參考：article that discussed graceful shutdown.
1.2 應用的獨立性
如果應用程序連接到數據庫，也許你認爲如果數據庫爲就緒就返回一個失敗的就緒就ok了，但是事實並非如此，例如您有一個依賴於後端API的前端應用程序。如果該API不穩定（例如由於錯誤而有時不可用），則就緒探測器將失敗，並且前端應用程序中的相關就緒也將失敗。這就會導致停機時間。更一般而言，下游依賴項的故障可能會傳播到上游的所有應用程序，並最終也降低前端面層
1.2.1 就緒性探針應該獨立
就緒性探針不應該依以下服務：
- 數據庫
- 數據庫遷移
- APIs
- 第三方服務
詳細可參考：explore what happens when there’re dependencies in the readiness probes in this essay.
1.2.2 應用程序重連到依賴服務
應用啓動時，它不應該因爲數據庫等依賴項尚未就緒就崩潰，而是，應用程序應繼續嘗試重新連接數據庫，直到成功爲止。
Kubernetes希望可以以任何順序啓動應用程序組件。當您確保您的應用程序可以重新連接到諸如數據庫之類的依賴項時，這樣可以大大提升服務的健壯性。
1.3 優雅的關機
您應該等待現有連接耗盡並停止處理新連接。請注意，當Pod終止時，該Pod的端點將從服務中刪除。
但是，可能需要一些時間才能將諸如kube-proxy或Ingress控制器之類的組件通知更改。
詳細可參考：handling client requests correctly with Kubernetes.
正確的優雅停止順序
- 在收到SIGTERM後
- 服務器停止接受新的鏈接
- 完成現有所有的請求
- 然後殺死所有的keepalive鏈接
- 進程退出
可以利用工具測試：test that your app gracefully shuts down with this tool: kube-sigterm-test.
1.3.1 應用程序未通過SIGTERM信號關閉，但它已經終止了鏈接
可能需要一些時間才能將諸如kube-proxy或Ingress控制器之類的組件通知端點更改。
因此，儘管標記爲已終止，但流量仍可能流向Pod。
該應用程序應停止接受所有剩餘連接上的新請求，並在耗盡傳出隊列後將其關閉。
1.3.2 應用程序仍在寬限期處理請求
您可能要考慮使用容器生命週期事件，例如 the preStop handler自定義pod刪除之前的動作
1.3.3 Dockerfile中的CMD將SIGTERM轉發到進程
通過在應用中捕獲SIGTERM信號，可以在Pod即將終止時收到通知。
你應該注意：forwarding the signal to the right process in your container.
1.3.4 關閉所有空閒的保持活動套接字
如果調用方應用未關閉TCP連接（例如使用TCP保持活動狀態或連接池），它將連接到一個Pod，而不使用該服務中的其他Pod。
當時當pod刪除的時候會發生什麼呢，理想狀態請求應該使用其他POD，但是，調用方應用程序與即將終止的Pod的連接壽命很長，它將繼續使用它。
另一方面，你不應該突然終止一個長鏈接，相反，您應該先關閉它們，然後再關閉應用程序。
您可以在有關以下內容的文章中閱讀有關保持活動連接的信息：gracefully shutting down a Nodejs HTTP server.
1.4 容錯能力
- 物理機硬件故障
- 雲供應商或管理程序
- kernel恐慌
pod部署在這些節點上也將丟失
在以下情況下可以刪除pod
- 直接刪除一個pod
- draining一個node
- 從節點上刪除Pod，以允許另一個Pod適合該節點
以上任何情況都可能影響您的應用程序的可用性，並可能導致停機。
您應該避免所有Pod都無法使用並且無法提供實時流量的情況。
1.4.1 部署運行多個副本
永遠不要僅運行一個pod
利用控制器Deployment, DaemonSet, ReplicaSet or StatefulSet.來運行pod，不應該將應用運行爲自主式pod
1.4.2 避免將Pod放置在單個節點中
即使您運行Pod的多個副本，也無法保證丟失節點不會破壞您的服務。
如果你在單一node上運行一個11個副本集的pod，如果這個node故障，這個服務也一樣會停機
詳細可以參考： inter-pod affinity and anti-affinity
1.4.3 設置Pod中斷預算
當一個node被打上污點，pod是要被刪除並且重新調度
但是如果你的系統壓力很大，不能接受丟失50%的pod這時候改怎麼辦呢，驅逐pod可能會影響你的服務
爲了保護部署免受可能同時摧毀多個Pod的意外事件的影響，可以定義Pod中斷預算。
想象一下：“ Kubernetes，請確保我的應用始終至少有5個Pod在運行”。
如果最終狀態導致該部署的Pod少於5個，Kubernetes將阻止耗盡事件。
官網參考文檔： Pod Disruption Budgets.
1.5 資源使用
爲了最大化調度程序的效率，您應該與Kubernetes共享詳細信息，例如資源利用，工作負載優先級和開銷。
1.5.1 設置所有容器的內存限制和請求
資源限制用於限制容器可以使用多少CPU和內存，並使用containerSpec的resources屬性設置。調度程序將這些用作度量標準之一，以確定哪個節點最適合當前Pod。根據調度程序，沒有內存限制的容器的內存利用率爲零。如果可調度在任何節點上的Pod數量不受限制，則會導致資源超額使用，並可能導致節點（和kubelet）崩潰。
同用的可以適用於CPU限制
但是，您是否應該始終設置內存和CPU的限制和要求？
如果您的進程超出內存限制，則該進程將終止。由於CPU是可壓縮的資源，因此如果您的容器超出限制，則將限制該過程。
如果您想更深入地研究CPU和內存限制，則應查看以下文章：
- Understanding resource limits in kubernetes: memory
- Understanding resource limits in kubernetes: cpu time
請注意，如果不確定什麼是正確的CPU或內存限制，則可以在建議模式打開的情況下使用Kubernetes中的Vertical Pod Autoscaler。自動縮放器會分析您的應用並建議限制。
1.5.2 將CPU請求設置爲1個CPU或以下
除非你有計算類型的實例類型job
it is recommended to set the request to 1 CPU or below.
1.5.3 禁用CPU限制—除非您有很好的用例
CPU以每個時間單位的CPU時間單位來度量。
cpu：1表示每秒1個CPU秒。
如果您有1個線程，則每秒消耗的CPU時間不能超過1秒。
如果您有2個線程，則可以在0.5秒內消耗1個CPU秒。
8個線程可以在0.125秒內消耗1個CPU秒。之後，您的過程將受到限制。
如果不確定您的應用程序的最佳設置是什麼，最好不要設置CPU限制。
深入研究可參考：this article digs deeper in CPU requests and limits.
1.5.4 命名空間具有LimitRange
如果您認爲可能忘記設置內存和CPU限制，則應考慮使用LimitRange對象爲當前名稱空間中部署的容器定義標準大小。
可參考：The official documentation about LimitRange
1.5.5 爲Pod設置適當的服務質量（QoS）
當一個節點進入過量使用狀態（即使用過多資源）時，Kubernetes試圖驅逐該節點中的某些Pod。Kubernetes根據定義明確的邏輯對Pod進行排名和逐出。
參考： configuring the quality of service for your Pods
1.6 標記資源
1.6.1 資源已定義技術標籤
你能通過以下tag標記pod
名稱，應用程序的名稱，例如“用戶API”
實例，標識應用程序實例的唯一名稱（您可以使用容器圖像標籤）
版本，應用程序的當前版本（增量計數器）
組件，架構中的組件，例如“ API”或“數據庫”
部分，該應用程序所屬的更高級別應用程序的名稱，例如“支付網關”由…
管理，用於管理應用程序（例如“ kubectl”或“ Helm”）的操作的工具
標籤可參考：recommended by the official documentation.
建議不要標記所有資源。
1.6.2 資源已定義業務標籤
您可以使用以下標籤標記Pod：
- owner：標示改資源的負責人
- project：聲明資源所屬的項目
- business-unit：用於標識與資源關聯的成本中心或業務部門；通常用於成本分配和跟蹤
1.6.3 資源定義安全等級標籤
tag pod通過以下label
- confidentiality：資源支持的特定數據保密級別的標識符
- compliance：an identifier for workloads designed to adhere to specific compliance requirements
1.7 日誌
日誌對於調試問題和監視應用程序活動特別有用。
1.7.1 應用程序記錄到stdout和stderr
有兩種日誌策略，主動方式與被動方式
使用被動方式日誌記錄的應用程序不需要了解了解日誌記錄基礎結構，而是將消息記錄到標準輸出中。
主動方式，該應用程序與中間聚合器建立了網絡連接，將數據發送到第三方日誌記錄服務，或直接寫入數據庫或索引。
最佳實踐：the twelve-factor app.
1.7.2 避免日誌使用sidecars模式
如果希望將日誌轉換應用於具有非標準日誌事件模型的應用程序，則可能需要使用sidecar容器。
使用Sidecar容器，您可以在將日誌條目運送到其他地方之前對其進行規範化。
例如，您可能需要先將Apache日誌轉換爲Logstash JSON格式，然後再將其發送到日誌基礎結構。
但是，如果您可以控制應用程序，則可以從一開始就輸出正確的格式。
sidecares啓動需要時間，您可以節省爲羣集中的每個Pod運行額外的容器的時間。
1.8 伸縮
容器具有本地文件系統，您可能會想使用它來持久化數據。
但是，將持久性數據存儲在容器的本地文件系統中會阻止包圍的Pod進行水平縮放（即通過添加或刪除Pod的副本）。
這是因爲，通過使用本地文件系統，每個容器都維護自己的“狀態”，這意味着Pod副本的狀態可能會隨時間而變化。從用戶的角度來看，這會導致行爲不一致（例如，當請求命中一個Pod時，特定的用戶信息可用，但當請求命中另一個Pod時，則不可用）。
相反，任何持久性信息都應保存在Pod外部的中央位置。例如，在集羣中的PersistentVolume中，或者在集羣外部的某些存儲服務中甚至更好。
1.8.1 容器在其本地文件系統中不存儲任何狀態
容器具有本地文件系統，您可能會想使用它來持久化數據。
但是，將持久性數據存儲在容器的本地文件系統中會阻止包圍的Pod進行水平縮放（即通過添加或刪除Pod的副本）。
這是因爲，通過使用本地文件系統，每個容器都維護自己的“狀態”，這意味着Pod副本的狀態可能會隨時間而變化。從用戶的角度來看，這會導致行爲不一致（例如，當請求命中一個Pod時，特定的用戶信息可用，但當請求命中另一個Pod時，則不可用）。
相反，任何持久性信息都應保存在Pod外部的中央位置。例如，在集羣中的PersistentVolume中，或者在集羣外部的某些存儲服務中甚至更好。
1.8.2 對於可變使用模式的應用應該使用HPA
HPA是kubernetes內置的一個特性它能夠監控當前的應用和根據當前的使用率自動添加及刪除POD副本
通過配置HPA來保障你的應用在任何情況下包括（異常流量峯值）能夠保存可用及正常響應
配置HPA自動伸縮你的應用，需要去創建一個HPA的資源對象，該對象定義了監控你應用的什麼指標
HPA也能夠健康k8s內置的資源指標（POD的CPU/MEM資源使用率）或者自定義指標，對於自定義指標，你需要去收集和暴露這些指標，例如你可用使用Prometheus/Prometheus Adapter
1.8.3 不要使用VPA，因爲改特性還在測試中
當POD需要更多資源時，VPA能夠通過自動的調整你的POD的資源請求和限制，
VPA非常適用於單體應用無法進行橫向副本數的擴張
但是目前VPA仍然處於測試階段，垂直方向調整POD資源需要重啓POD
考慮到這些限制，更多的應用在k8s中可用橫行擴張，因此不要在生產環境中使用VPA
1.8.4 如果有很高的工作負載，可以使用集羣自動伸縮
集羣伸縮是區別於（HPA/VPA）的另一種伸縮類型
集羣自動伸縮能夠通過增加或移除node節點來自動縮放集羣的大小
當由於現有一個node節點的資源不足導致pod調度失敗時，此刻集羣會進行擴增操作，集羣會增加一個work node來保證pod能夠正常調度，相似的，如果一個worker node資源使用率低，那麼集羣自動伸縮會先驅逐這個worker node上面的pod，最終去移除此node
對於集羣工作負載很高的應用場景下，就去自動伸縮非常有用，集羣自動縮分可以讓你滿足需求高峯，而不會通過過度陪你走工作節點來浪費資源。
對於工作負載不大的應用場景，可以不用去設置集羣自動伸縮，因爲可能永遠都使用不到改規則，如果你的集羣工作負載緩慢增長，可以通過監控系統來手動添加worker node
1.9 配置和密鑰
1.9.1 外部化所有配置
配置應該在應用之外的代碼維護，這有一些好處
- 更改配置不用重新編譯代碼
- 當應用程序正在運行，配置文件可以單獨被更新
- 相同的代碼能夠被用於不同的環境
在Kubernetes中，可以將配置保存在ConfigMaps中，然後可以在將卷作爲環境變量傳入時將其安裝到容器中。
在ConfigMap中僅保存非敏感配置。對於敏感信息（例如憑據），請使用Secret資源。
1.9.2 將Secrets作爲卷而不是環境變量
Secret資源的內容應作爲卷掛載到容器中，而不是作爲環境變量傳遞。
這是爲了防止祕密值出現在用於啓動容器的命令中，該命令可能由不應該訪問祕密值的人員檢查
二 管治
2.1 名稱空間限制
您不應允許用戶使用比您事先同意的資源更多的資源。
羣集管理員可以設置約束，以使用配額和限制範圍限制項目中使用的對象數量或計算資源數量。
詳細可參考；limit ranges
2.1.1 名稱空間限制範圍
如果爲設置容器資源消耗限制，那麼會出現容器資源爭搶導致其他容器異常狀況發生，
k8s有兩個特性來約束資源使用：ResourceQuota 和 LimitRange.
使用LimitRange對象，您可以定義資源請求的默認值和名稱空間內單個容器的限制。
在該命名空間內創建的任何容器（未明確指定請求和限制值）都將分配默認值。
2.1.2 名稱控制資源配額
你能夠在名稱空間中通過資源配額限制所有容器資源的總消耗量
定義名稱空間的資源配額會限制屬於該名稱空間的所有容器可以消耗的CPU，內存或存儲資源的總量。
您還可以爲其他Kubernetes對象設置配額，例如當前名稱空間中的Pod數量。
如果您認爲有人可以利用您的集羣並創建20000 ConfigMap，則可以使用LimitRange來防止這種情況。
2.2 POD安全策略
遭到破壞的容器
容器使用節點上不允許的資源，例如進程，網絡或文件系統
一般來說，應該將Pod的功能限制在最低限度。
2.2.1 啓用POD安全策略
例如，您可以使用Kubernetes Pod安全策略來限制：
- 訪問主機進程或者網絡名稱空間
- 運行授權的容器
- 容器運行時的用戶
- 訪問主機的文件系統
- linux能力，Seccomp or SELinux profiles
選擇正確的策略依賴於集羣原生的特性，可以參考： Kubernetes Pod Security Policy best practices
2.2.2 禁用特權容器
在一個POD中，容器能夠作爲特權模式容器運行來不受限制訪問主機系統的資源
通常這樣是危險的，你應該給有必要的制定容器可以訪問的等級，
特權Pod的有效使用案例包括在節點上使用硬件，例如GPU。
可以參考：learn more about security contexts and privileges containers from this article.
2.2.3 容器使用只讀文件系統
容器中使用只讀文件系統來強制保障容器的無狀態話
這種方式不僅能減輕風險例如熱補丁，而且可以避免避免惡意程序在容器內存儲或者操作數據的風險。
使用只讀文件系統聽起來很簡單，但是實際還是有一些複雜
如果你需要寫日誌或者存儲一些臨時文件在一個臨時目錄該怎麼辦呢，可以參考： running containers securely in production.
2.2.4 避免利用root用戶啓動容器
在容器中運行一個進程與主機上運行一個進程沒有太大區別，只不過一些很小的元數據在容器中聲明
因此容器中的uid爲0的用戶與主機上的root用戶相同
如果用戶設法脫離了以root用戶身份在容器中運行的應用程序，則他們可以使用同一root用戶獲得對主機的訪問權限。
配置容器以使用非特權用戶是防止特權升級攻擊的最佳方法。
2.2.5 限制能力
Linux功能使進程能夠執行許多特權操作，其中只有root用戶默認可以執行。
例如，CAP_CHOWN允許進程“對文件UID和GID進行任意更改”。
即使您的進程不是以root身份運行，進程也有可能通過提升特權來使用那些類似root的功能。
最佳實踐：
2.2.6 防止特權升級
您應該在關閉特權升級的情況下運行容器，以防止使用setuid或setgid二進制文件提升特權。
2.3 網絡策略
- 容器可以在與其他容器進行網絡通訊，不需要進行地址轉換
- 集羣中的node節點可以與其他節點進行網絡通訊
- 一個容器的IP地址始終是相同的，從另一個容器或其本身看時是獨立的。
如果您打算將羣集分成較小的塊並在名稱空間之間進行隔離，則第一條規則無濟於事。
想象一下您的集羣中的用戶是否能夠使用集羣中的任何其他服務。
現在，想象一下如果集羣中的惡意用戶要獲得對集羣的訪問權限，他們可以向整個集羣發出請求。
要解決此問題，您可以定義如何使用網絡策略允許Pods在當前名稱空間和跨名稱空間中進行通信。
2.3.1 啓用網絡策略
Kubernetes網絡策略指定Pod組的訪問權限，就像雲中的安全組用於控制對VM實例的訪問一樣。
換句話說，它在Kubernetes集羣上運行的Pod之間創建了防火牆。
可參考：Securing Kubernetes Cluster Networking.
2.3.2 每個命名空間中都有一個保守的NetworkPolicy
該存儲庫包含Kubernetes網絡策略的各種用例和示例YAML文件，以在您的設置中利用。如果你想知道
how to drop/restrict traffic to applications running on Kubernetes
2.4 基於角色的訪問控制RBAC
放棄所需的最小權限是一種常見的做法，但是實際操作又如何量化最小權限？
細粒度的策略提供了更高的安全性，但是需要更多的精力來進行管理。
更大範圍的授權可以使不必要的API訪問服務帳戶，但更易於控制。
2.4.1 禁用默認服務帳戶的自動掛載
請注意，默認的ServiceAccount將自動安裝到所有Pod的文件系統中。您可能要禁用它並提供更詳細的策略。
可以參考：the default ServiceAccount is automatically mounted into the file system of all Pods.
2.4.2 RBAC策略設置爲所需的最少特權
尋找有關如何設置RBAC規則的好的建議是一項挑戰。在Kubernetes RBAC的3種現實方法中，您可以找到三種實用場景和有關如何入門的實用建議。
參考；3 realistic approaches to Kubernetes RBAC
2.4.3 RBAC策略是精細的，不能共享
需求：
- 允許用戶可以部署，但是不允許去讀secrets
- admin應該可以訪問所有資源
- 默認情況下，應用程序不應獲得對Kubernetes API的寫訪問權限
- 對於某些用途，應該可以寫入Kubernetes API。
四個要求轉化爲五個單獨的角色：
- ReadOnly
- PowerUser
- Operator
- Controller
- Admin
2.5 自定義策略
例如，您可能要避免從公共互聯網下載容器，而希望首先批准這些容器。
也許您有一個內部註冊表，並且只有此註冊表中的映像可以部署在您的羣集中。
您如何強制只能在羣集中部署受信任的容器？沒有針對此的RBAC政策。
2.5.1 僅允許從已知註冊表部署容器
您可能要考慮的最常見的自定義策略之一是限制可以在羣集中部署的映像。
2.5.2 強制Ingress主機名唯一
用戶創建Ingress清單時，可以使用其中的任何主機名。
但是，您可能希望阻止用戶多次使用相同的主機名並互相覆蓋。Open Policy Agent的官方文檔包含有關如何在驗證Webhook中檢查Ingress資源的教程。
a tutorial on how to check Ingress resources as part of the validation webhook.
2.5.3 僅在Ingress主機名中使用批准的域名
用戶創建Ingress清單時，可以使用其中的任何主機名。一種
但是，您可能希望阻止用戶使用無效的主機名。Open Policy Agent的官方文檔包含有關如何在驗證Webhook中檢查Ingress資源的教程。
三 集羣配置
最好的選擇是將羣集與標準參考進行比較。
對於Kubernetes，參考是Internet安全中心（CIS）基準。
3.1 批准的Kubernetes配置
3.1.1 集羣通過CIS基準測試
Internet安全中心提供了一些準則和基準測試，以確保代碼安全的最佳實踐。
他們還維護了Kubernetes的基準，您可以download from the official website.
kube-bench是一種工具，用於自動執行CIS Kubernetes基準測試並報告集羣中的錯誤配置。
[INFO] 1 Master Node Security Configuration
[INFO] 1.1 API Server
[WARN] 1.1.1 Ensure that the --anonymous-auth argument is set to false (Not Scored)
[PASS] 1.1.2 Ensure that the --basic-auth-file argument is not set (Scored)
[PASS] 1.1.3 Ensure that the --insecure-allow-any-token argument is not set (Not Scored)
[PASS] 1.1.4 Ensure that the --kubelet-https argument is set to true (Scored)
[PASS] 1.1.5 Ensure that the --insecure-bind-address argument is not set (Scored)
[PASS] 1.1.6 Ensure that the --insecure-port argument is set to 0 (Scored)
[PASS] 1.1.7 Ensure that the --secure-port argument is not set to 0 (Scored)
[FAIL] 1.1.8 Ensure that the --profiling argument is set to false (Scored)
請注意，無法使用kube-bench檢查託管集羣（例如GKE，EKS和AKS）的主節點。主節點由雲提供商控制。
3.1.2 禁用元數據雲提供程序元數據API
雲平臺（AWS，Azure，GCE等）通常將本地元數據服務公開給實例。
默認情況下，實例上運行的Pod可以訪問這些API，並且可以包含該節點的雲憑據或諸如kubelet憑據之類的置備數據。
這些憑據可用於在羣集內升級或升級到同一帳戶下的其他雲服務。
3.1.3 限制對Alpha或Beta功能的訪問
Alpha和Beta Kubernetes功能正在積極開發中，並且可能會存在限制或錯誤，從而導致安全漏洞。
始終評估Alpha或Beta功能可能提供的價值，以防對您的安全狀況造成潛在風險。
如有疑問，請禁用不使用的功能。
3.2 認證
kubernetes提供了不同的認證策略
- Static Tokens:很難使之無效，應避免
- Bootstrap Tokens：與上面的靜態令牌相同
- Basic Authentication：通過網絡以明文形式傳輸憑據
- X509 client certs：需要定期更新和重新分發客戶端證書
- Service Account Tokens：是集羣中運行的應用程序和工作負載的首選身份驗證策略
- OpenID Connect (OIDC) Tokens：OIDC與您的身份提供商（例如AD，AWS IAM，GCP IAM等）集成後，爲最終用戶提供了最佳的身份驗證策略。
更多詳細策略可參考：in the official documentation.
3.2.1 使用OpenID（OIDC）令牌作爲用戶身份驗證策略
Kubernetes支持各種身份驗證方法，包括OpenID Connect（OIDC）。
OpenID Connect允許單點登錄（SSO）（例如您的Google身份）連接到Kubernetes集羣和其他開發工具。
你不用分別取記憶和管理認證，您可能有多個羣集連接到同一OpenID提供程序。
詳細可以參考：learn more about the OpenID connect in Kubernetes
3.3 RBAC
3.3.1 ServiceAccount令牌僅適用於應用程序和控制器
服務帳戶令牌不應該用於嘗試與Kubernetes羣集進行交互的最終用戶，但對於在Kubernetes上運行的應用程序和工作負載，它們是首選的身份驗證策略。
3.4 日誌設定
3.4.1 有一個日誌保留和歸檔策略
您應該保留30-45天的歷史日誌。
3.4.2 從節點，控制平面，審覈中收集日誌
從那收集日誌?
- Nodes（kubelet，container runtime）
- 控制平面（API server，scheduler，controller manager）
- k8s 審計（對API服務器的所有請求）
應該收集什麼?
- 應用名稱
- 應用實例
- 應用版本
- 集羣ID
- 容器名稱
- 容器運行在集羣的那個node節點上
- 容器運行在那個pod內
- 名稱空間
3.4.3 在每個節點上最好使用守護程序來收集日誌，而不是在每個中運行sidecars
應用程序應該登錄到標準輸出，而不是文件。
每個節點上的守護程序可以從容器運行時收集日誌（如果記錄到文件，則可能需要每個pod的sidecar容器）。
3.4.4 提供日誌聚合工具
使用日誌聚合工具，例如EFK堆棧（Elasticsearch，Fluentd，Kibana），DataDog，Sumo Logic，Sysdig，GCP Stackdriver，Azure Monitor，AWS CloudWatch。
自己整理了k8s學習筆記，有興起的可以一快學習交流：https://github.com/redhatxl/awesome-kubernetes-notes
支持國產容器管理平臺KubeSphere,爲社區儘自己的一份綿薄之力。
參考資料
- https://learnk8s.io/production-best-practices
- configure Liveness, Readiness and Startup Probes.
- Liveness probes are dangerous
