新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

kubernetes生產(chǎn)環(huán)境優(yōu)秀實踐

Kubernetes生產(chǎn)環(huán)境優(yōu)秀實踐

作者：ikubernetes 2022-09-01 08:50:22
云計算
云原生本文僅提供在kubernetes上部署安全、可擴展和彈性服務的可行性最佳實踐。僅供參考。

本文僅提供在kubernetes上部署安全、可擴展和彈性服務的可行性最佳實踐。僅供參考。

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

應用開發(fā)

健康檢查

容器要有就緒探針。
注意：readiness probe（就緒探針）和 liveness probe（存活探針）沒有默認值。
如果您沒有設置就緒探測，kubelet 會假定應用程序已準備好在容器啟動后立即接收流量。
如果容器需要 2 分鐘才能啟動，那么在這 2 分鐘內對它的所有請求都將失敗。
發(fā)生不可恢復錯誤（致命錯誤）時讓容器崩潰。
如果應用程序遇到不可恢復的錯誤，您應該讓它崩潰。
此類不可恢復錯誤的示例如下：

未捕獲的異常。
代碼中的錯字（對于動態(tài)語言）。
無法加載標頭或依賴項。

請注意，您不應發(fā)出失敗的 Liveness 探測信號。
相反，您應該立即退出進程并讓 kubelet 重新啟動容器。
配置被動liveness探測。
Liveness 探針旨在在容器卡住時重新啟動容器。
考慮以下場景：如果您的應用程序正在處理無限循環(huán)，則無法退出或尋求幫助。
當進程消耗 100% CPU 時，它沒有時間回復（其他）Readiness 探測檢查，最終會從 Service 中刪除。
但是，Pod 仍然注冊為當前 Deployment 的活動副本。
如果您沒有 Liveness 探針，它會保持運行但與服務分離。
換句話說，該進程不僅不服務任何請求，而且還在消耗資源。
你該怎么辦？
從您的應用程序公開端點。
端點始終回復成功響應。
使用 Liveness 探針中的端點。
請注意，您不應使用 Liveness 探針來處理應用程序中的致命錯誤并請求 Kubernetes 重新啟動應用程序。
相反，您應該讓應用程序崩潰。
只有在進程沒有響應的情況下，才應將 Liveness 探針用作恢復機制。
readiness probe（就緒探針）和 liveness probe（存活探針）的值要確保不相同
如果Liveness和Readiness值相同時，如果應用程序發(fā)出未準備好或未上線的信號時，kubelet會將容器從服務中分離并刪除，可能會導致連接丟失。因為容器沒有足夠的時間來處理傳入的連接。

應用程序獨立部署

readiness probe（就緒探針）是獨立的

就緒探測不包括對服務的依賴，例如：

databases。
database migrations。
APIs。
第三方服務。

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

應用程序的重連機制

當應用程序啟動時，它不應該因為數(shù)據(jù)庫等依賴項尚未準備好而崩潰。

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

Kubernetes 期望應用程序組件可以以任何順序啟動。

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

優(yōu)雅關閉應用程序

應用程序不會再接收到SIGTERM后立即關閉，等待一段時間后，優(yōu)雅終止連接

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

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

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

但是顯然，這是不可能的，因為所有這些組件都分布在許多不同的計算機上。如果有一個沒有寫響應，都會導致應用無法關閉。

一般情況下我們會配置一個預停止的hook：

lifecycle:
       preStop:
         exec:
           command:
           - sh
           - c
           - "sleep 5"

將SIGTERM信號轉發(fā)給進程

當pod即將終止時，可以通過在應用程序中捕獲SIGTERM信號?？梢允褂胻ini。tini項目地址：https://github.com/krallin/tini。

關閉所有的空閑的kaap-alive套接字

如果調用應用程序沒有關閉TCP連接；當pod被刪除時；理想情況下，請求應該發(fā)送到另一個 Pod；但是，調用應用程序與即將終止的 Pod 建立了長期連接，并將繼續(xù)使用它；不應該突然終止長期連接；您應該在關閉應用程序之前終止它們。

容錯機制

為部署的POD運行多個副本

永遠不要單獨運行單個 Pod。

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

運行多個 Pod 實例可確保刪除單個 Pod 不會導致停機。

避免將 Pod 放置到單個節(jié)點中

考慮以下場景：單個集群節(jié)點上有 11 個副本。

如果節(jié)點不可用，則 11 個副本將丟失，并且您有停機時間。

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

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

設置 Pod 中斷預算。

Set Pod disruption budgets

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

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

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

資源利用

為所有的容器設置內存限制和請求

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

調度程序使用這些作為指標之一來決定哪個節(jié)點最適合當前 Pod。

沒有做資源限制的容器調度優(yōu)先級為0.即當發(fā)生OOM時，會先停掉此類容器。

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

請注意，如果您不確定正確的CPU 或內存限制應該是多少，您可以在 Kubernetes 中使用Vertical Pod Autoscaler并打開推薦模式。自動縮放器會分析您的應用并為其推薦限制。

將 CPU 請求設置為 1 個 CPU 或以下

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

禁用CPU限制

如果您不確定應用程序的最佳設置是什么，最好不要設置 CPU 限制。

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

為namesapce（名稱空間）設置LimitRange

如果您認為您可能忘記設置內存和 CPU 限制，您應該考慮使用 LimitRange 對象來定義部署在當前命名空間中的容器的標準大小。

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

為Pod設置適當?shù)腝os（服務質量）

當一個節(jié)點資源使用率過高時，kubernetes會嘗試驅驅逐該節(jié)點中的一些pod。

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

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

資源標記

定義技術相關標簽

下面是官方推薦的相關技術的標簽：

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

name, 應用程序的名稱，例如“用戶 API”。
instance，標識應用程序實例的唯一名稱（您可以使用容器image標簽）。
version，應用程序的當前版本（增量計數(shù)器）。
component，架構內的組件，例如“API”或“數(shù)據(jù)庫”。
part-of, 一個更高級別的應用程序的名稱，這是“支付網(wǎng)關”的一部分。
managed-by，用于管理應用程序操作的工具，例如“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è)務標簽

您可以使用以下標簽標記您的 Pod：

owner，用于標識誰負責該資源。
project，用于確定資源所屬的項目。
business-unit，用于標識與資源關聯(lián)的成本中心或業(yè)務單位；通常用于成本分配和跟蹤。

示例：

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

定義安全標簽

您可以使用以下標簽標記您的 Pod：

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

示例：

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

日志記錄

應用程序日志輸出到stdout和stderr

有兩種日志記錄策略：passive（被動） 和 active（主動）。

使用被動策略的應用程序將日志消息記錄到標準輸出。

此最佳實踐是十二因素應用程序的一部分。

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

主動日志記錄被認為是一種反模式，應該避免。

避免使用sidecar進行日志記錄（如果可以的話）

如果您希望將日志轉換應用于具有非標準日志事件模型的應用程序，您可能需要使用邊車容器。

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

例如，您可能希望在將 Apache 日志傳送到日志基礎設施之前將其轉換為 Logstash JSON 格式。

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

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

縮放

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

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

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

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

相反，任何持久性信息都應該保存在 Pod 之外的中心位置。例如，在集群中的一個 PersistentVolume 中，甚至在集群外的一些存儲服務中更好。

將 Horizontal Pod Autoscaler 用于具有可變使用模式的應用程序

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

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

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

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

請勿在 Vertical Pod Autoscaler 仍處于測試階段時使用它

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

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

這對于擴展無法水平擴展的應用程序很有用。

然而，VPA 目前處于 beta 階段，它有一些已知的限制（例如，通過改變 Pod 的資源需求來擴展 Pod，需要殺死并重新啟動 Pod）。

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

如果您有高度變化的工作負載，請使用 Cluster Autoscaler

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

Cluster Autoscaler 可以通過添加或刪除工作節(jié)點來自動擴展集群的大小。

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

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

但是，如果您的工作負載變化不大，則可能不值得設置 Cluster Autoscaler，因為它可能永遠不會被觸發(fā)。如果您的工作負載增長緩慢且單調，那么監(jiān)控現(xiàn)有工作節(jié)點的利用率并在達到臨界值時手動添加一個額外的工作節(jié)點可能就足夠了。

配置和Secret

外部化所有配置

配置應在應用程序代碼之外維護。

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

在 Kubernetes 中，可以將配置保存在 ConfigMaps 中，然后可以將其掛載到容器中，因為卷作為環(huán)境變量傳入。

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

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

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

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

Governance(治理)

命名空間限制

名稱空間配置LimitRange

沒有限制的容器可能會導致與其他容器的資源爭用和計算資源的未優(yōu)化消耗。

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

使用 LimitRange 對象，您可以定義資源請求的默認值和命名空間內單個容器的限制。

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

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

名稱空間配置ResourceQuota

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

為命名空間定義資源配額會限制屬于該命名空間的所有容器可以使用的 CPU、內存或存儲資源的總量。

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

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

Pod安全策略

啟用Pod安全策略

可以使用 Kubernetes Pod 安全策略來限制：

訪問主機進程或網(wǎng)絡命名空間。
運行特權容器。
容器運行的用戶。
訪問主機文件系統(tǒng)。
Linux 功能、Seccomp 或 SELinux 配置文件。

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

禁用特權容器

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

雖然在某些特定用例中需要此級別的訪問權限，但總的來說，讓您的容器執(zhí)行此操作會帶來安全風險。

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

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

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

在容器中運行只讀文件系統(tǒng)會強制容器不可變。

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

使用只讀文件系統(tǒng)運行容器可能聽起來很簡單，但它可能會帶來一些復雜性。

如果您需要在臨時文件夾中寫入日志或存儲文件怎么辦？

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

防止容器以root身份運行

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

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

如果用戶設法突破在容器中以 root 身份運行的應用程序，他們可能能夠獲得對具有相同 root 用戶的主機的訪問權限。

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

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

限制一些Linux功能

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

例如，CAP_CHOWN允許進程“對文件 UID 和 GID 進行任意更改”。

即使您的進程不以身份運行root，進程也有可能通過提升權限來使用這些類似 root 的功能。

換句話說，如果您不想受到損害，您應該只啟用您需要的功能。

但是應該啟用哪些功能，為什么？

以下兩篇文章深入探討了有關 Linux 內核功能的理論和實踐最佳實踐：

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

防止Linux權限提升

您應該在關閉權限提升的情況下運行容器，以防止使用setuid或setgid二進制文件提升權限。

網(wǎng)絡策略

容器可以與網(wǎng)絡中的任何其他容器通信，并且在這個過程中沒有地址轉換——即不涉及 NAT。
集群中的節(jié)點可以與網(wǎng)絡中的任何其他容器通信，反之亦然。即使在這種情況下，也沒有地址轉換——即沒有 NAT。
一個容器的 IP 地址總是相同的，如果從另一個容器或它本身來看，它是獨立的。

集群中的惡意用戶要獲得對集群的訪問權限——他們可以向整個集群發(fā)出請求。

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

啟用網(wǎng)絡策略

Kubernetes 網(wǎng)絡策略指定 Pod 組的訪問權限，就像云中的安全組用于控制對 VM 實例的訪問一樣。

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

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

每個名稱空間中都應該有一個默認較保守的NetworkPolicy

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

基于角色的訪問控制（RBAC）策略

禁用默認ServiceAccount的自動掛載

請注意，默認的 ServiceAccount 會自動掛載到所有 Pod 的文件系統(tǒng)中。

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

RBAC策略設置為所需的最少權限

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

實際場景參考文檔：https://thenewstack.io/three-realistic-approaches-to-kubernetes-rbac/。

RBAC策略是細粒度且不共享

有一個簡明的策略來定義角色和 ServiceAccounts。

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

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

這四個要求轉化為五個單獨的角色：

只讀。
超級用戶。
操作員。
控制器。
行政。

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

自定義策略

?僅允許從已知的鏡像倉庫部署容器。
在Ingress強制定義域名的唯一性。
在 Ingress 主機名中使用已批準的域名?。

集群配置

驗證

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

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

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

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

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

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

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

ServiceAccount 令牌僅適用于應用程序和控制器

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

日志記錄設置

日志的保留和歸檔策略

您應該保留 30-45 天的歷史日志。

從節(jié)點、控制平面、審計收集日志

從哪些方面收集日志：

節(jié)點（kubelet、容器運行時）。
控制平面（API 服務器、調度程序、控制器管理器）。
Kubernetes 審計（對 API 服務器的所有請求）。

你應該收集什么：

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

首選每個節(jié)點上的守護進程來收集日志而不是邊車

應用程序應該記錄到標準輸出而不是文件。

每個節(jié)點上的守護進程可以從容器運行時收集日志（如果記錄到文件，可能需要每個 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。

當前題目：kubernetes生產(chǎn)環(huán)境優(yōu)秀實踐
轉載來源：http://m.5511xx.com/article/ccccscg.html