kubernetes生產(chǎn)環(huán)境最佳實(shí)踐

本文僅提供在kubernetes上部署安全、可擴(kuò)展和彈性服務(wù)的可行性最佳實(shí)踐。僅供參考。

精選的最佳實(shí)踐清單，旨在幫助您發(fā)布到生產(chǎn)環(huán)境。

應(yīng)用開(kāi)發(fā)

健康檢查

• 容器要有就緒探針
• 注意：readiness probe（就緒探針） 和 liveness probe（存活探針） 沒(méi)有默認(rèn)值。
• 如果您沒(méi)有設(shè)置就緒探測(cè)，kubelet 會(huì)假定應(yīng)用程序已準(zhǔn)備好在容器啟動(dòng)后立即接收流量。
• 如果容器需要 2 分鐘才能啟動(dòng)，那么在這 2 分鐘內(nèi)對(duì)它的所有請(qǐng)求都將失敗。
• 發(fā)生不可恢復(fù)錯(cuò)誤（致命錯(cuò)誤）時(shí)讓容器崩潰
• 如果應(yīng)用程序遇到不可恢復(fù)的錯(cuò)誤，您應(yīng)該讓它崩潰。
• 此類不可恢復(fù)錯(cuò)誤的示例如下：
• 未捕獲的異常
• 代碼中的錯(cuò)字（對(duì)于動(dòng)態(tài)語(yǔ)言）
• 無(wú)法加載標(biāo)頭或依賴項(xiàng)
• 請(qǐng)注意，您不應(yīng)發(fā)出失敗的 Liveness 探測(cè)信號(hào)。
• 相反，您應(yīng)該立即退出進(jìn)程并讓 kubelet 重新啟動(dòng)容器。
• 配置被動(dòng)liveness探測(cè)
• Liveness 探針旨在在容器卡住時(shí)重新啟動(dòng)容器。
• 考慮以下場(chǎng)景：如果您的應(yīng)用程序正在處理無(wú)限循環(huán)，則無(wú)法退出或?qū)で髱椭?/li>
• 當(dāng)進(jìn)程消耗 100% CPU 時(shí)，它沒(méi)有時(shí)間回復(fù)（其他）Readiness 探測(cè)檢查，最終會(huì)從 Service 中刪除。
• 但是，Pod 仍然注冊(cè)為當(dāng)前 Deployment 的活動(dòng)副本。
• 如果您沒(méi)有 Liveness 探針，它會(huì)保持運(yùn)行但與服務(wù)分離。
• 換句話說(shuō)，該進(jìn)程不僅不服務(wù)任何請(qǐng)求，而且還在消耗資源。
• 你該怎么辦？
• 從您的應(yīng)用程序公開(kāi)端點(diǎn)
• 端點(diǎn)始終回復(fù)成功響應(yīng)
• 使用 Liveness 探針中的端點(diǎn)
• 請(qǐng)注意，您不應(yīng)使用 Liveness 探針來(lái)處理應(yīng)用程序中的致命錯(cuò)誤并請(qǐng)求 Kubernetes 重新啟動(dòng)應(yīng)用程序。
• 相反，您應(yīng)該讓應(yīng)用程序崩潰。
• 只有在進(jìn)程沒(méi)有響應(yīng)的情況下，才應(yīng)將 Liveness 探針用作恢復(fù)機(jī)制。
• readiness probe（就緒探針） 和 liveness probe（存活探針）的值要確保不相同
• 如果Liveness和Readiness值相同時(shí)，如果應(yīng)用程序發(fā)出未準(zhǔn)備好或未上線的信號(hào)時(shí)，kubelet會(huì)將容器從服務(wù)中分離并刪除，可能會(huì)導(dǎo)致連接丟失。因?yàn)槿萜鳑](méi)有足夠的時(shí)間來(lái)處理傳入的連接。

應(yīng)用程序獨(dú)立部署

readiness probe（就緒探針）是獨(dú)立的

就緒探測(cè)不包括對(duì)服務(wù)的依賴，例如：

• databases
• database migrations
• APIs
• 第三方服務(wù)

參考鏈接：https://blog.colinbreck.com/kubernetes-liveness-and-readiness-probes-how-to-avoid-shooting-yourself-in-the-foot/#shootingyourselfinthefootwithreadinessprobes

應(yīng)用程序的重連機(jī)制

當(dāng)應(yīng)用程序啟動(dòng)時(shí)，它不應(yīng)該因?yàn)閿?shù)據(jù)庫(kù)等依賴項(xiàng)尚未準(zhǔn)備好而崩潰。

相反，應(yīng)用程序應(yīng)該不斷重試連接到數(shù)據(jù)庫(kù)，直到成功。

Kubernetes 期望應(yīng)用程序組件可以以任何順序啟動(dòng)。

當(dāng)您確保您的應(yīng)用程序可以重新連接到依賴項(xiàng)（例如數(shù)據(jù)庫(kù)）時(shí)，您就知道您可以提供更強(qiáng)大和更有彈性的服務(wù)。

優(yōu)雅關(guān)閉應(yīng)用程序

應(yīng)用程序不會(huì)再接收到SIGTERM后立即關(guān)閉，等待一段時(shí)間后，優(yōu)雅終止連接

pod即使在收到終止信號(hào)后，可能也需要繼續(xù)接受連接，直到所有的kube-proxy完成對(duì)iptables規(guī)則或ipvs規(guī)則的更新。

可能ingress-controller以及Loadblance也會(huì)將連接轉(zhuǎn)發(fā)到POD。

為確保所有客戶端都不會(huì)遇到斷開(kāi)連接，您必須等到所有客戶端都以某種方式通知您他們將不再將連接轉(zhuǎn)發(fā)到 pod。

但是顯然，這是不可能的，因?yàn)樗羞@些組件都分布在許多不同的計(jì)算機(jī)上。如果有一個(gè)沒(méi)有寫響應(yīng)，都會(huì)導(dǎo)致應(yīng)用無(wú)法關(guān)閉。

一般情況下我們會(huì)配置一個(gè)預(yù)停止的hook：

lifecycle: preStop: exec: command: – sh – c – “sleep 5”

將SIGTERM信號(hào)轉(zhuǎn)發(fā)給進(jìn)程

當(dāng)pod即將終止時(shí)，可以通過(guò)在應(yīng)用程序中捕獲SIGTERM信號(hào)?？梢允褂胻ini。tini項(xiàng)目地址：https://github.com/krallin/tini

關(guān)閉所有的空閑的kaap-alive套接字

如果調(diào)用應(yīng)用程序沒(méi)有關(guān)閉TCP連接；當(dāng)pod被刪除時(shí)；理想情況下，請(qǐng)求應(yīng)該發(fā)送到另一個(gè) Pod；但是，調(diào)用應(yīng)用程序與即將終止的 Pod 建立了長(zhǎng)期連接，并將繼續(xù)使用它；不應(yīng)該突然終止長(zhǎng)期連接；您應(yīng)該在關(guān)閉應(yīng)用程序之前終止它們。

容錯(cuò)機(jī)制

為部署的POD運(yùn)行多個(gè)副本

永遠(yuǎn)不要單獨(dú)運(yùn)行單個(gè) Pod。

而是考慮將 Pod 部署為 Deployment、DaemonSet、ReplicaSet 或 StatefulSet 的一部分。

運(yùn)行多個(gè) Pod 實(shí)例可確保刪除單個(gè) Pod 不會(huì)導(dǎo)致停機(jī)。

避免將 Pod 放置到單個(gè)節(jié)點(diǎn)中

考慮以下場(chǎng)景：?jiǎn)蝹€(gè)集群節(jié)點(diǎn)上有 11 個(gè)副本。

如果節(jié)點(diǎn)不可用，則 11 個(gè)副本將丟失，并且您有停機(jī)時(shí)間。

您應(yīng)該將反關(guān)聯(lián)規(guī)則應(yīng)用于您的部署，以便 Pod 分布在集群的所有節(jié)點(diǎn)中。

pod間親和性和反親和性文檔描述了如何將 Pod 更改為位于（或不在）同一節(jié)點(diǎn)中。

設(shè)置 Pod 中斷預(yù)算

Set Pod disruption budgets

翻譯過(guò)來(lái)就是配置POD干擾預(yù)算；通過(guò)設(shè)置應(yīng)用 Pod 處于正常狀態(tài)的最低個(gè)數(shù)或最低百分比，這樣可以保證在主動(dòng)銷毀 Pod 的時(shí)候，不會(huì)銷毀太多的 Pod 導(dǎo)致業(yè)務(wù)異常中斷，從而提高業(yè)務(wù)的可用性。

參考鏈接：https://zhuanlan.zhihu.com/p/367827614

官方文檔是了解Pod Disruption Budgetshttps://kubernetes.io/docs/concepts/workloads/pods/disruptions/

資源利用

為所有的容器設(shè)置內(nèi)存限制和請(qǐng)求

資源限制用于限制您的容器可以使用多少 CPU 和內(nèi)存，并使用containerSpec 字段進(jìn)行配置。

調(diào)度程序使用這些作為指標(biāo)之一來(lái)決定哪個(gè)節(jié)點(diǎn)最適合當(dāng)前 Pod。

沒(méi)有做資源限制的容器調(diào)度優(yōu)先級(jí)為0.即當(dāng)發(fā)生OOM時(shí)，會(huì)先停掉此類容器。

由于 CPU 是一種可壓縮資源，因此如果您的容器超出限制，則進(jìn)程會(huì)受到限制。

請(qǐng)注意，如果您不確定正確的CPU 或內(nèi)存限制應(yīng)該是多少，您可以在 Kubernetes 中使用Vertical Pod Autoscaler并打開(kāi)推薦模式。自動(dòng)縮放器會(huì)分析您的應(yīng)用并為其推薦限制。

將 CPU 請(qǐng)求設(shè)置為 1 個(gè) CPU 或以下

除非您有計(jì)算密集型作業(yè)，否則建議將請(qǐng)求設(shè)置為 1 CPU 或以下。

禁用CPU限制

如果您不確定應(yīng)用程序的最佳設(shè)置是什么，最好不要設(shè)置 CPU 限制。

如果您想了解更多信息，本文將深入探討 CPU 請(qǐng)求和限制。https://medium.com/@betz.mark/understanding-resource-limits-in-kubernetes-cpu-time-9eff74d3161b

為namesapce（名稱空間）設(shè)置LimitRange

如果您認(rèn)為您可能忘記設(shè)置內(nèi)存和 CPU 限制，您應(yīng)該考慮使用 LimitRange 對(duì)象來(lái)定義部署在當(dāng)前命名空間中的容器的標(biāo)準(zhǔn)大小。

LimitRange 的官方文檔https://kubernetes.io/docs/concepts/policy/limit-range/

為Pod設(shè)置適當(dāng)?shù)腝os（服務(wù)質(zhì)量）

當(dāng)一個(gè)節(jié)點(diǎn)資源使用率過(guò)高時(shí)，kubernetes會(huì)嘗試驅(qū)驅(qū)逐該節(jié)點(diǎn)中的一些pod。

kubernetes會(huì)根據(jù)定義的優(yōu)先級(jí)以及Qos對(duì)pod進(jìn)行排名和驅(qū)逐。

關(guān)于如何配置Qos可參考官方文檔 :https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/

資源標(biāo)記

定義技術(shù)相關(guān)標(biāo)簽

下面是官方推薦的相關(guān)技術(shù)的標(biāo)簽：

官方文檔：https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

• name, 應(yīng)用程序的名稱，例如“用戶 API”
• instance，標(biāo)識(shí)應(yīng)用程序?qū)嵗奈ㄒ幻Q（您可以使用容器image標(biāo)簽）
• version，應(yīng)用程序的當(dāng)前版本（增量計(jì)數(shù)器）
• component，架構(gòu)內(nèi)的組件，例如“API”或“數(shù)據(jù)庫(kù)”
• part-of, 一個(gè)更高級(jí)別的應(yīng)用程序的名稱，這是“支付網(wǎng)關(guān)”的一部分
• managed-by，用于管理應(yīng)用程序操作的工具，例如“kubectl”或“Helm”

示例：

apiVersion: apps/v1 kind: Deployment metadata: name: deployment labels: app.kubernetes.io/name: user-api app.kubernetes.io/instance: user-api-5fa65d2 app.kubernetes.io/version: “42” app.kubernetes.io/component: api app.kubernetes.io/part-of: payment-gateway app.kubernetes.io/managed-by: kubectl spec: replicas: 3 selector: matchLabels: application: my-app template: metadata: labels: app.kubernetes.io/name: user-api app.kubernetes.io/instance: user-api-5fa65d2 app.kubernetes.io/version: “42” app.kubernetes.io/component: api app.kubernetes.io/part-of: payment-gateway spec: containers: – name: app image: myapp

定義業(yè)務(wù)標(biāo)簽

您可以使用以下標(biāo)簽標(biāo)記您的 Pod：

• owner，用于標(biāo)識(shí)誰(shuí)負(fù)責(zé)該資源
• project，用于確定資源所屬的項(xiàng)目
• business-unit，用于標(biāo)識(shí)與資源關(guān)聯(lián)的成本中心或業(yè)務(wù)單位；通常用于成本分配和跟蹤。

示例

apiVersion: apps/v1 kind: Deployment metadata: name: deployment labels: owner: payment-team project: fraud-detection business-unit: “80432” spec: replicas: 3 selector: matchLabels: application: my-app template: metadata: labels: owner: payment-team project: fraud-detection business-unit: “80432” spec: containers: – name: app image: myapp

定義安全標(biāo)簽

您可以使用以下標(biāo)簽標(biāo)記您的 Pod：

• confidentiality，資源支持的特定數(shù)據(jù)機(jī)密級(jí)別的標(biāo)識(shí)符
• compliance，旨在遵守特定合規(guī)性要求的工作負(fù)載標(biāo)識(shí)符

示例：

apiVersion: apps/v1 kind: Deployment metadata: name: deployment labels: confidentiality: official compliance: pci spec: replicas: 3 selector: matchLabels: application: my-app template: metadata: labels: confidentiality: official compliance: pci spec: containers: – name: app image: myapp

日志記錄

應(yīng)用程序日志輸出到stdout和stderr

有兩種日志記錄策略：passive（被動(dòng)） 和 active（主動(dòng)）

使用被動(dòng)策略的應(yīng)用程序?qū)⑷罩鞠⒂涗浀綐?biāo)準(zhǔn)輸出。

此最佳實(shí)踐是十二因素應(yīng)用程序的一部分。

在主動(dòng)日志記錄中，應(yīng)用程序與中間聚合器建立網(wǎng)絡(luò)連接，將數(shù)據(jù)發(fā)送到第三方日志記錄服務(wù)，或直接寫入數(shù)據(jù)庫(kù)或索引。

主動(dòng)日志記錄被認(rèn)為是一種反模式，應(yīng)該避免。

避免使用sidecar進(jìn)行日志記錄（如果可以的話）

如果您希望將日志轉(zhuǎn)換應(yīng)用于具有非標(biāo)準(zhǔn)日志事件模型的應(yīng)用程序，您可能需要使用邊車容器。

使用 sidecar 容器，您可以在將日志條目發(fā)送到其他地方之前對(duì)其進(jìn)行規(guī)范化。

例如，您可能希望在將 Apache 日志傳送到日志基礎(chǔ)設(shè)施之前將其轉(zhuǎn)換為 Logstash JSON 格式。

但是，如果您可以控制應(yīng)用程序，則可以首先輸出正確的格式。

您可以節(jié)省為集群中的每個(gè) Pod 運(yùn)行一個(gè)額外的容器。

縮放

容器不會(huì)在其本地文件系統(tǒng)中存儲(chǔ)任何狀態(tài)

容器有一個(gè)本地文件系統(tǒng)，你可能會(huì)想用它來(lái)持久化數(shù)據(jù)。

但是，將持久數(shù)據(jù)存儲(chǔ)在容器的本地文件系統(tǒng)中會(huì)阻止包含的 Pod 水平擴(kuò)展（即，通過(guò)添加或刪除 Pod 的副本）。

這是因?yàn)?，通過(guò)使用本地文件系統(tǒng)，每個(gè)容器都維護(hù)自己的“狀態(tài)”，這意味著 Pod 副本的狀態(tài)可能會(huì)隨著時(shí)間的推移而發(fā)散。這會(huì)導(dǎo)致從用戶的角度來(lái)看不一致的行為（例如，當(dāng)請(qǐng)求命中一個(gè) Pod 時(shí)，一條特定的用戶信息可用，但當(dāng)請(qǐng)求命中另一個(gè) Pod 時(shí)則不可用）。

相反，任何持久性信息都應(yīng)該保存在 Pod 之外的中心位置。例如，在集群中的一個(gè) PersistentVolume 中，甚至在集群外的一些存儲(chǔ)服務(wù)中更好。

將 Horizontal Pod Autoscaler 用于具有可變使用模式的應(yīng)用程序

Horizontal Pod Autoscaler (HPA)是一個(gè)內(nèi)置的 Kubernetes 功能，可以監(jiān)控您的應(yīng)用程序并根據(jù)當(dāng)前使用情況自動(dòng)添加或刪除 Pod 副本。

配置 HPA 可讓您的應(yīng)用在任何流量條件下（包括意外高峰）保持可用和響應(yīng)。

要將 HPA 配置為自動(dòng)縮放您的應(yīng)用程序，您必須創(chuàng)建一個(gè)HorizontalPodAutoscaler資源，該資源定義了要為您的應(yīng)用程序監(jiān)控的指標(biāo)。

HPA 可以監(jiān)控內(nèi)置資源指標(biāo)（Pod 的 CPU 和內(nèi)存使用情況）或自定義指標(biāo)。在自定義指標(biāo)的情況下，您還負(fù)責(zé)收集和公開(kāi)這些指標(biāo)，例如，您可以使用Prometheus和Prometheus Adapter來(lái)做到這一點(diǎn)。

請(qǐng)勿在 Vertical Pod Autoscaler 仍處于測(cè)試階段時(shí)使用它

與Horizontal Pod Autoscaler (HPA)類似， Vertical Pod Autoscaler (VPA)也存在。

VPA 可以自動(dòng)適應(yīng)你 Pod 的資源請(qǐng)求和限制，這樣當(dāng)一個(gè) Pod 需要更多資源時(shí)，它可以得到它們（增加/減少單個(gè) Pod 的資源稱為垂直擴(kuò)展，而不是水平擴(kuò)展，這意味著增加/減少 Pod 的副本數(shù)）。

這對(duì)于擴(kuò)展無(wú)法水平擴(kuò)展的應(yīng)用程序很有用。

然而，VPA 目前處于 beta 階段，它有一些已知的限制（例如，通過(guò)改變 Pod 的資源需求來(lái)擴(kuò)展 Pod，需要?dú)⑺啦⒅匦聠?dòng) Pod）。

鑒于這些限制，以及 Kubernetes 上的大多數(shù)應(yīng)用程序無(wú)論如何都可以水平擴(kuò)展的事實(shí)，建議不要在生產(chǎn)中使用 VPA（至少在有穩(wěn)定版本之前）。

如果您有高度變化的工作負(fù)載，請(qǐng)使用 Cluster Autoscaler

Cluster Autoscaler是另一種類型的“autoscaler”（除了Horizo ntal Pod Autoscaler和Vertical Pod Autoscaler）。

Cluster Autoscaler 可以通過(guò)添加或刪除工作節(jié)點(diǎn)來(lái)自動(dòng)擴(kuò)展集群的大小。

當(dāng) Pod 由于現(xiàn)有工作節(jié)點(diǎn)上的資源不足而無(wú)法調(diào)度時(shí)，就會(huì)發(fā)生擴(kuò)展操作。在這種情況下，Cluster Autoscaler 會(huì)創(chuàng)建一個(gè)新的工作節(jié)點(diǎn)，以便 Pod 可以被調(diào)度。同樣，當(dāng)現(xiàn)有工作節(jié)點(diǎn)的利用率較低時(shí)，集群自動(dòng)縮放器可以通過(guò)從一個(gè)工作節(jié)點(diǎn)中逐出所有工作負(fù)載并將其移除來(lái)縮減規(guī)模。

使用 Cluster Autoscaler 對(duì)于高度可變的工作負(fù)載是有意義的，例如，當(dāng) Pod 的數(shù)量可能在短時(shí)間內(nèi)增加，然后又回到之前的值時(shí)。在這種情況下，Cluster Autoscaler 允許您通過(guò)過(guò)度配置工作節(jié)點(diǎn)來(lái)滿足需求高峰，而不會(huì)浪費(fèi)資源。

但是，如果您的工作負(fù)載變化不大，則可能不值得設(shè)置 Cluster Autoscaler，因?yàn)樗赡苡肋h(yuǎn)不會(huì)被觸發(fā)。如果您的工作負(fù)載增長(zhǎng)緩慢且單調(diào)，那么監(jiān)控現(xiàn)有工作節(jié)點(diǎn)的利用率并在達(dá)到臨界值時(shí)手動(dòng)添加一個(gè)額外的工作節(jié)點(diǎn)可能就足夠了。

配置和Secret

外部化所有配置

配置應(yīng)在應(yīng)用程序代碼之外維護(hù)。

這有幾個(gè)好處。首先，更改配置不需要重新編譯應(yīng)用程序。其次，可以在應(yīng)用程序運(yùn)行時(shí)更新配置。第三，相同的代碼可以在不同的環(huán)境中使用。

在 Kubernetes 中，可以將配置保存在 ConfigMaps 中，然后可以將其掛載到容器中，因?yàn)榫碜鳛榄h(huán)境變量傳入。

在 ConfigMaps 中僅保存非敏感配置。對(duì)于敏感信息（例如憑證），請(qǐng)使用 Secret 資源。

將 Secret 掛載為卷，而不是環(huán)境變量

Secret 資源的內(nèi)容應(yīng)該作為卷掛載到容器中，而不是作為環(huán)境變量傳入。

這是為了防止秘密值出現(xiàn)在用于啟動(dòng)容器的命令中，這可能會(huì)被不應(yīng)訪問(wèn)秘密值的個(gè)人查看到。

Governance(治理)

命名空間限制

名稱空間配置LimitRange

沒(méi)有限制的容器可能會(huì)導(dǎo)致與其他容器的資源爭(zhēng)用和計(jì)算資源的未優(yōu)化消耗。

Kubernetes 有兩個(gè)限制資源使用的特性：ResourceQuota 和 LimitRange。

使用 LimitRange 對(duì)象，您可以定義資源請(qǐng)求的默認(rèn)值和命名空間內(nèi)單個(gè)容器的限制。

在該命名空間內(nèi)創(chuàng)建的任何容器，沒(méi)有明確指定請(qǐng)求和限制值，都會(huì)被分配默認(rèn)值。

資源配額，您應(yīng)該查看官方文檔。https://kubernetes.io/docs/concepts/policy/resource-quotas/

名稱空間配置ResourceQuota

使用 ResourceQuotas，您可以限制命名空間內(nèi)所有容器的總資源消耗。

為命名空間定義資源配額會(huì)限制屬于該命名空間的所有容器可以使用的 CPU、內(nèi)存或存儲(chǔ)資源的總量。

您還可以為其他 Kubernetes 對(duì)象設(shè)置配額，例如當(dāng)前命名空間中的 Pod 數(shù)量。

如果您認(rèn)為有人可以利用您的集群并創(chuàng)建 20000 個(gè) ConfigMap，那么使用 LimitRange 可以防止這種情況發(fā)生。

Pod安全策略

啟用Pod安全策略

可以使用 Kubernetes Pod 安全策略來(lái)限制：

• 訪問(wèn)主機(jī)進(jìn)程或網(wǎng)絡(luò)命名空間
• 運(yùn)行特權(quán)容器
• 容器運(yùn)行的用戶
• 訪問(wèn)主機(jī)文件系統(tǒng)
• Linux 功能、Seccomp 或 SELinux 配置文件

參考Kubernetes Pod安全策略最佳實(shí)戰(zhàn) https://www.mend.io/resources/blog/kubernetes-pod-security-policy/

禁用特權(quán)容器

在 Pod 中，容器可以在“特權(quán)”模式下運(yùn)行，并且?guī)缀蹩梢圆皇芟拗频卦L問(wèn)主機(jī)系統(tǒng)上的資源。

雖然在某些特定用例中需要此級(jí)別的訪問(wèn)權(quán)限，但總的來(lái)說(shuō)，讓您的容器執(zhí)行此操作會(huì)帶來(lái)安全風(fēng)險(xiǎn)。

特權(quán) Pod 的有效用例包括使用節(jié)點(diǎn)上的硬件，例如 GPU。

您可以從本文中了解有關(guān)安全上下文和權(quán)限容器的更多信息 ：https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

在容器中使用只讀文件系統(tǒng)

在容器中運(yùn)行只讀文件系統(tǒng)會(huì)強(qiáng)制容器不可變。

這不僅可以減輕一些舊的（和有風(fēng)險(xiǎn)的）做法，例如熱補(bǔ)丁，還可以幫助您防止惡意進(jìn)程在容器內(nèi)存儲(chǔ)或操作數(shù)據(jù)的風(fēng)險(xiǎn)。

使用只讀文件系統(tǒng)運(yùn)行容器可能聽(tīng)起來(lái)很簡(jiǎn)單，但它可能會(huì)帶來(lái)一些復(fù)雜性。

如果您需要在臨時(shí)文件夾中寫入日志或存儲(chǔ)文件怎么辦？

您可以在本文中了解有關(guān)在生產(chǎn)環(huán)境中安全運(yùn)行容器的權(quán)衡取舍： https://medium.com/@axbaretto/running-docker-containers-securely-in-production-98b8104ef68

防止容器以root身份運(yùn)行

在容器中運(yùn)行的進(jìn)程與主機(jī)上的任何其他進(jìn)程沒(méi)有什么不同，只是它有一小段元數(shù)據(jù)聲明它在容器中。

因此，容器中的 root 與主機(jī)上的 root (uid 0) 相同。

如果用戶設(shè)法突破在容器中以 root 身份運(yùn)行的應(yīng)用程序，他們可能能夠獲得對(duì)具有相同 root 用戶的主機(jī)的訪問(wèn)權(quán)限。

將容器配置為使用非特權(quán)用戶，是防止提權(quán)攻擊的最佳方法。

如果您想了解更多信息，以下文章提供了一些詳細(xì)說(shuō)明示例，說(shuō)明當(dāng)您以 root 身份運(yùn)行容器時(shí)會(huì)發(fā)生什么 ：ttps://medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b

限制一些Linux功能

Linux 功能使進(jìn)程能夠執(zhí)行默認(rèn)情況下只有 root 用戶才能執(zhí)行的許多特權(quán)操作。

例如，CAP_CHOWN允許進(jìn)程“對(duì)文件 UID 和 GID 進(jìn)行任意更改”。

即使您的進(jìn)程不以 身份運(yùn)行root，進(jìn)程也有可能通過(guò)提升權(quán)限來(lái)使用這些類似 root 的功能。

換句話說(shuō)，如果您不想受到損害，您應(yīng)該只啟用您需要的功能。

但是應(yīng)該啟用哪些功能，為什么？

以下兩篇文章深入探討了有關(guān) Linux 內(nèi)核功能的理論和實(shí)踐最佳實(shí)踐：

• Linux 功能：它們?yōu)槭裁创嬖谝约八鼈兪侨绾喂ぷ鞯?：https://blog.container-solutions.com/linux-capabilities-why-they-exist-and-how-they-work
• 實(shí)踐中的 Linux 功能 https://blog.container-solutions.com/linux-capabilities-in-practice

防止Linux權(quán)限提升

您應(yīng)該在關(guān)閉權(quán)限提升的情況下運(yùn)行容器，以防止使用setuid或setgid二進(jìn)制文件提升權(quán)限。

網(wǎng)絡(luò)策略

集群中的惡意用戶要獲得對(duì)集群的訪問(wèn)權(quán)限——他們可以向整個(gè)集群發(fā)出請(qǐng)求。

為了解決這個(gè)問(wèn)題，您可以使用網(wǎng)絡(luò)策略定義如何允許 Pod 在當(dāng)前命名空間和跨命名空間中進(jìn)行通信。

啟用網(wǎng)絡(luò)策略

Kubernetes 網(wǎng)絡(luò)策略指定 Pod 組的訪問(wèn)權(quán)限，就像云中的安全組用于控制對(duì) VM 實(shí)例的訪問(wèn)一樣。

換句話說(shuō)，它在 Kubernetes 集群上運(yùn)行的 Pod 之間創(chuàng)建了防火墻。

Kubernetes 集群網(wǎng)絡(luò) : https://ahmet.im/blog/kubernetes-network-policy/

每個(gè)名稱空間中都應(yīng)該有一個(gè)默認(rèn)較保守的NetworkPolicy

如果想深入了解如何丟棄/限制運(yùn)行在 Kubernetes 上的應(yīng)用程序的流量，請(qǐng)查看此文檔。 https://github.com/ahmetb/kubernetes-network-policy-recipes

基于角色的訪問(wèn)控制（RBAC）策略

禁用默認(rèn)ServiceAccount的自動(dòng)掛載

請(qǐng)注意，默認(rèn)的 ServiceAccount 會(huì)自動(dòng)掛載到所有 Pod 的文件系統(tǒng)中。

您可能希望禁用它并提供更精細(xì)的策略。

RBAC策略設(shè)置為所需的最少權(quán)限

很難找到關(guān)于如何設(shè)置 RBAC 規(guī)則的好建議。在Kubernetes RBAC 的 3 種實(shí)際方法中，您可以找到三個(gè)實(shí)際場(chǎng)景和有關(guān)如何開(kāi)始的實(shí)用建議。

實(shí)際場(chǎng)景參考文檔：https://thenewstack.io/three-realistic-approaches-to-kubernetes-rbac/

RBAC策略是細(xì)粒度且不共享

有一個(gè)簡(jiǎn)明的策略來(lái)定義角色和 ServiceAccounts。

首先，他們描述了他們的要求：

• 用戶應(yīng)該能夠部署，但他們不應(yīng)該被允許閱讀 Secrets 例如
• 管理員應(yīng)該獲得對(duì)所有資源的完全訪問(wèn)權(quán)限
• 默認(rèn)情況下，應(yīng)用程序不應(yīng)獲得對(duì) Kubernetes API 的寫入權(quán)限
• 應(yīng)該可以寫入 Kubernetes API 以用于某些用途。

這四個(gè)要求轉(zhuǎn)化為五個(gè)單獨(dú)的角色：

• 只讀
• 超級(jí)用戶
• 操作員
• 控制器
• 行政

您可以在此鏈接中了解他們的定義：https://kubernetes-on-aws.readthedocs.io/en/latest/dev-guide/arch/access-control/adr-004-roles-and-service-accounts.html

自定義策略

僅允許從已知的鏡像倉(cāng)庫(kù)部署容器

在Ingress強(qiáng)制定義域名的唯一性

在 Ingress 主機(jī)名中使用已批準(zhǔn)的域名

集群配置

推薦的Kubernetes配置

集群通過(guò)CIS基準(zhǔn)從測(cè)試

互聯(lián)網(wǎng)安全中心為保護(hù)您的代碼的最佳實(shí)踐提供了一些指南和基準(zhǔn)測(cè)試。

他們還維護(hù)了kubernetes的基準(zhǔn)；官網(wǎng)地址：https://www.cisecurity.org/benchmark/kubernetes

雖然您可以閱讀冗長(zhǎng)的指南并手動(dòng)檢查您的集群是否合規(guī)，但更簡(jiǎn)單的方法是下載并執(zhí)行kube-bench.

下載地址：https://github.com/aquasecurity/kube-bench

kube-bench是一種工具，旨在自動(dòng)化 CIS Kubernetes 基準(zhǔn)測(cè)試并報(bào)告集群中的錯(cuò)誤配置。

示例輸出：

[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)

當(dāng)master由云廠商托管的話，可能無(wú)法使用kube-bench。

限制對(duì)alpha或beta API功能的訪問(wèn)

Alpha 和 beta Kubernetes 功能正在積極開(kāi)發(fā)中，可能存在導(dǎo)致安全漏洞的限制或錯(cuò)誤。

始終評(píng)估 Alpha 或 Beta 功能可能提供的價(jià)值，以應(yīng)對(duì)您的安全狀況可能面臨的風(fēng)險(xiǎn)。

驗(yàn)證

使用 OpenID (OIDC) 令牌作為用戶身份驗(yàn)證策略

Kubernetes 支持各種身份驗(yàn)證方法，包括 OpenID Connect (OIDC)。

OpenID Connect 允許單點(diǎn)登錄 (SSO)（例如您的 Google 身份）連接到 Kubernetes 集群和其他開(kāi)發(fā)工具。

您無(wú)需單獨(dú)記住或管理憑據(jù)。

您可以將多個(gè)集群連接到同一個(gè) OpenID 提供程序。

有關(guān) Kubernetes 中的 OpenID 連接的更多信息。 可以訪問(wèn)：https://thenewstack.io/kubernetes-single-sign-one-less-identity/

基于角色的訪問(wèn)控制 (RBAC)

ServiceAccount 令牌僅適用于應(yīng)用程序和控制器

服務(wù)帳戶令牌不應(yīng)用于嘗試與 Kubernetes 集群交互的最終用戶，但它們是在 Kubernetes 上運(yùn)行的應(yīng)用程序和工作負(fù)載的首選身份驗(yàn)證策略。

日志記錄設(shè)置

日志的保留和歸檔策略

您應(yīng)該保留 30-45 天的歷史日志。

從節(jié)點(diǎn)、控制平面、審計(jì)收集日志

從哪些方面收集日志：

• 節(jié)點(diǎn)（kubelet、容器運(yùn)行時(shí)）
• 控制平面（API 服務(wù)器、調(diào)度程序、控制器管理器）
• Kubernetes 審計(jì)（對(duì) API 服務(wù)器的所有請(qǐng)求）

你應(yīng)該收集什么：

• 應(yīng)用名稱。從元數(shù)據(jù)標(biāo)簽中檢索。
• 應(yīng)用實(shí)例。從元數(shù)據(jù)標(biāo)簽中檢索。
• 應(yīng)用程序版本。從元數(shù)據(jù)標(biāo)簽中檢索。
• 集群 ID。從 Kubernetes 集群中檢索。
• 容器名稱。從 Kubernetes API 中檢索。
• 運(yùn)行此容器的集群節(jié)點(diǎn)。從 Kubernetes 集群中檢索。
• 運(yùn)行容器的 Pod 名稱。從 Kubernetes 集群中檢索。
• 命名空間。從 Kubernetes 集群中檢索。

首選每個(gè)節(jié)點(diǎn)上的守護(hù)進(jìn)程來(lái)收集日志而不是邊車

應(yīng)用程序應(yīng)該記錄到標(biāo)準(zhǔn)輸出而不是文件。

每個(gè)節(jié)點(diǎn)上的守護(hù)進(jìn)程可以從容器運(yùn)行時(shí)收集日志（如果記錄到文件，可能需要每個(gè) pod 的 sidecar 容器）。

參考地址：https://rclayton.silvrback.com/container-services-logging-with-docker#effective-logging-infrastructure

配置日志聚合工具

使用日志聚合工具，例如 EFK stack（Elasticsearch、Fluentd、Kibana）、DataDog、Sumo Logic、Sysdig、GCP Stackdriver、Azure Monitor、AWS CloudWatch。