Kubernetes 作為大規模企業級應用容器編排的首推工具，其為容器化的應用提供部署運行、資源調度、服務發現和動態伸縮等一系列完整功能，本文作者 Marek Bartik 深入分享了 K8s 的避坑寶典，相信會對開發者們大有裨益。

作者 | Marek Bartik，已獲作者翻譯授權

譯者 | 蘇本如，責編 | 唐小引

頭圖 | CSDN 下載自 VCG

出品 | CSDN（ID：CSDNnews）

在我們多年使用 Kubernetes（以下簡稱為 K8s）的經歷中，我們有機會近距離接觸了相當多的集群（包括依托于 GCP、AWS 和 Azure 上的托管和非托管集群），并且看到一些錯誤在不斷重復。但不必為此感到羞恥，因為我們也犯了很多這樣的錯誤！

接下來，我會盡量解釋那些我們經常犯的錯誤，并討論如何修復它們。

資源 —— 請求（Request）和限制（Limit）的設置

這無疑是最值得關注的，因而列在了這個錯誤榜單的第一位。

設置 CPU request 的常見錯誤有兩種 —— 「不設置」或「設置得很低」（這樣我們可以在每個節點上容納更多的 pod），這兩種錯誤會導致節點被過量使用。在高需求的時候，節點的 CPU 就會被完全占用，我們的工作負載就只能得到“它所請求的很低的資源”，因此工作負載得到的 CPU 資源就很有限，這樣就會導致應用程序延遲、超時等問題的增加。

不設置 CPU request（BestEffort，應盡量避免）時的配置如下：

????resources:?{}

CPU request 設置得很低(應盡量避免）時的配置如下：

????resources:requests:cpu:?"1m"

另一方面，設置一個 CPU limit 值可能會不必要地限制 pod 對 CPU 的使用，即使節點的 CPU 沒有被充分利用時，這同樣會導致延遲問題的增加。對于使用 Linux 內核中的 CPU CFS quota 來控制對 CPU 的使用，或關閉 CPU CFS quota 并用 CPU limit 設置來代替，這兩種方式到底孰優孰劣？有一個公開的討論，結論是 CPU limit 這個設置可能會導致更多的問題。

內存的過量使用會給你帶來更多的麻煩。達到 CPU limit 時只會導致 CPU 使用受限，達到 Memory limit 將會導致 Pod 被殺死。你聽說過 OOMkill 嗎？是的，它正是我們要說的內存不足時自動殺死進程的機制。如果你想盡量減少這種情況的發生，那就不要過度使用內存，而應該使用“Guaranteed QoS”模式，將 Memory Request 值設為等于 Memory limit 值（就像下面的示例一樣）。關于這個話題，你可以從 Henning Jacobs（Zalando）的這個演講中獲得更多信息[1]。

Burstable QoS 模式下的資源設置（很可能導致 OOMKill 機制更頻繁地被觸發）：

????resources:requests:memory:?"128Mi"cpu:?"500m"limits:memory:?"256Mi"cpu:?2

Guaranteed QoS 模式的資源設置：

????resources:requests:memory:?"128Mi"cpu:?2limits:memory:?"128Mi"cpu:?2

那么在你設置 resource 時，有什么工具可以幫助你呢？

你可以借助 metrics-server 來檢查 pod（和其中的容器）當前的 CPU 和內存的使用情況。很有可能它已經在服務器端運行了。要想看到使用情況，你只需簡單地運行以下命令：

kubectl?top?pods kubectl?top?pods?--containers kubectl?top?nodes

不過，這些命令只能顯示當前的使用情況。這對于大致地了解資源使用情況是足夠了，但最終你希望能夠及時查看一些使用指標（比如：CPU 峰值、昨天上午的 CPU 使用情況等指標）。在這個方面，Prometheus、DataDog 和許多其他的監控系統可以幫助你。它們從 metrics-server 上獲取這些指標信息并存儲起來，然后你就可以對其進行查詢和繪制圖形。

VerticalPodAutoscaler[2]?工具可以幫助你自動化這一手動過程：包括及時查看 CPU/內存的使用情況，以及基于使用情況設置新的 request 和 limit 的值。

高效地利用你的計算資源并非易事。就像一直在玩俄羅斯方塊。如果發現自己在平均利用率很低（例如?10％）的情況下為計算支付了大量費用，那么你可能需要看看基于 AWS Fargate 或 Virtual Kubelet 之類的產品是否能解決你的問題，這些產品更多地利用了無服務器/按使用付費的計費模式，這對你來說可能更便宜。

存活（liveness）探針和就緒（readiness）探針的設置

默認情況下，系統不會設置檢測一個 pod 狀態的存活探針和就緒探針。K8s 的自愈能力有時可以讓容器一直工作下去……

但是，如果容器出現了不可恢復的錯誤，你的服務將如何重新啟動呢？負載均衡器（loadbalancer）如何判斷某個特定的 Pod 是否可以開始處理流量？或者是否可以繼續處理更多流量？

通常，人們不知道這兩個探針（liveness 和 readiness）之間的區別。

• 如果對一個 pod 的 liveness 探測失敗，就會重啟這個 pod。

• 如果對一個 pod 的 readiness 探測失敗，就會將這個 pod 和 K8s 服務斷開連接（你可以使用 kubectl get endpoints 命令進行檢查），并且在該探測再次成功之前，不再向其發送任何流量。

注意：這兩種探測需要在整個 pod 的生命周期內都運行。這點很重要。

人們常常認為，readiness 探測僅在容器起動時運行，以告知 K8s 服務 pod 何時就緒，并且可以開始為流量提供服務。但這只是它的一個應用場景。

另外一個應用場景是：在一個 pod 的生命周期內，使用 readiness 探測可以讓系統知道一個 pod 是否變得太“熱”而無法處理過多的流量（或昂貴的計算），以便系統停止向它發送更多的流量而讓它“冷靜”下來。直到 readiness 再次探測成功，系統才開始繼續向它發送更多流量。在這種情況下（當 pod 過熱導致 readiness 探測失敗時），如果讓 liveness 探測失敗就不是我們想要的。因為，我們為什么要重啟一個運行良好，并且正在處理大量工作的 Pod 呢？

有時候，不配置任何一個探針比錯誤地配置探針要好。如上所述，如果將 liveness 探針配置成和 readiness 探針一樣，那么你將遇到大麻煩。作為開始，建議你僅僅配置 readiness 探針，因為 liveness 探針很危險。

如果一個和其它 pod 有共享依賴項的 pod 被關閉，那么你必須保證針對這個 pod 的任何一個探針都不能失敗，否則將導致所有 Pod 的級聯失敗。那你就是在搬起石頭砸自己的腳了。

用于 HTTP 服務的負載均衡器

你的集群中可能有很多你想對外開放的 HTTP 服務。

如果你把 K8s 的外部訪問方式設置為 LoadBalancer 類型，則其控制器（特定于供應商）將被配置來支持一個外部負載均衡器（不一定非得是支持七層交換的 L7 負載均衡器，更可能是僅僅支持四層交換的 L4 負載均衡器），并且這些資源（外部靜態 IPv4 地址、計算硬件、帶寬等等）可能會變得很昂貴，因為你會創建許多這樣的服務。

在這種情況下，共享一個外部負載均衡器可能更有意義，并且你可以將 K8s 的外部訪問方式設置為 NodePort 類型。或者，更好的方法是，部署一個像 nginx-ingress-controller（或者 traefik）之類的東西作為暴露給外部負載均衡器的單個 NodePort endpoint，并基于 K8s ingress resource 配置在集群中分配并路由流量。

集群內的其他需要會話的（微）服務可以通過 ClusterIP 服務和 K8s 自帶的 DNS 服務發現（DNS Service Discovery）來實現會話。注意不要使用公共 DNS / IP，因為這可能會導致延遲和云使用成本的增加。

非 K8s 感知的集群自動伸縮

在集群中添加節點或者從集群中刪除節點時，你不應該只是考慮一些簡單的指標：如節點的 CPU 利用率。在調度 Pod 時，你需要根據很多調度約束條件（如 Pod 和節點的親和性，污點和容忍，資源請求，QoS 等等）來進行決策。如果一個外部自動伸縮器不能理解這些約束，可能會帶來很大的麻煩。

假設一個新的 pod 要被調度，但是所有可用的 CPU 都被占用了，而且這個 pod 現在處于掛起狀態。當外部自動伸縮器看到當前使用的平均 CPU 情況（非常高），就不會向外擴展了（將這個 pod 添加作為節點）。也就是說這個 pod 不會被調度。

向內收縮（從集群中刪除節點）總是更加困難。假設你有一個有狀態的 pod（連接了持久化存儲卷），由于持久化存儲卷這種資源通常屬于某個特定的可用區域，并且不能在該區域中復制，當你的自定義自動伸縮器刪除一個帶有此 pod 的節點時，調度器無法將其調度到另一個節點上，因為它受到持久化存儲卷屬于唯一可用區域的限制。所以這個 Pod 再次被卡在掛起狀態。

K8s 社區正在廣泛使用 cluster-autoscaler 集群自動伸縮器，它運行在你的集群中，并且已經和大多數主要的公共云提供商的 API 實現了集成，理解所有這些約束，可以幫助你在上述情況下實現自動向外擴展。它還能夠幫助你確定在不影響設置的約束條件下方便地實現自動向內收縮，以節省你的計算成本。

不使用 IAM/RBAC 能力

不要將 IAM User 與機器和應用程序的永久 secret 一起使用，而應該使用角色（role）和服務賬戶(service account)生成臨時 secret。

我們經常看到這樣錯誤的用法：將訪問權限和 secret key 硬編碼到應用程序的配置中，當使用云 IAM 時，從來不輪換 secret。在合適的情況下，你應當使用 IAM 角色(role)和服務帳戶(service account)而不是 IAM Users。

跳過 kube2am，直接用于服務帳戶的 IAM 角色。就像 ?těpán Vrany 在這篇博客文章[3]中所說的那樣。

apiVersion:?v1 kind:?ServiceAccount metadata:annotations:eks.amazonaws.com/role-arn:?arn:aws:iam::123456789012:role/my-app-rolename:?my-serviceaccountnamespace:?default

上面的示例不是很難理解，不是嗎？

另外，在不是必要時，千萬不要將 admin 和 cluster-admin 的權限給予服務帳戶或實例配置文件。這點做起來有點困難，尤其是在使用 K8s 的 RBAC 時，但是仍然值得努力。

POD 的自我反親和性

運行某個部署的 pod 副本（比如說有 3 個 pod 副本），當節點下線時，你發現所有副本都隨之同時下線了。呵呵？所有副本竟然都是在一個節點上運行的嗎？K8s 難道不應該有魔法，可以自動提供高可用性嗎？！

你不能指望 K8s 調度器自動為你的 pod 強加一個反親和性設置。相反，你應該明確地定義它們（如下例）。

//?omitted?for?brevitylabels:app:?zk //?omitted?for?brevityaffinity:podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:-?labelSelector:matchExpressions:-?key:?"app"operator:?Invalues:-?zktopologyKey:?"kubernetes.io/hostname"

你需要像上面這樣設置 pod 的反親和性，它將確保 pod 被調度到不同的節點上（注意：這個設置是在調度時檢查，而不是在執行時檢查，因此需要設置成 requiredDuringSchedulingIgnoredDuringExecution 類型）。

我們這里討論的是在不同節點（這里是 topologyKey: "kubernetes.io/hostname"）上的 pod 反親和性（podAntiAffinity），而不是不同可用區域的 pod 反親和性。如果你真的需要高可用性，你應該更加深入地探討這個話題。

沒有 poddisruptionbudget

你是在 K8s 上運行生產環境的工作負載。你的節點和集群必須不時地升級或停用。而 PodDisruptionBudget（pdb）就是一種被集群管理員和集群用戶廣泛用來確保服務質量的 API。

請確保你創建了 pdb，以避免由于節點停用過多而導致不必要的服務中斷。

apiVersion:?policy/v1beta1 kind:?PodDisruptionBudget metadata:name:?zk-pdb spec:minAvailable:?2selector:matchLabels:app:?zookeeper

作為集群用戶，你可以這樣告訴集群管理員：“嘿，我這里有個 zookeeper 服務，不管你想做什么，我希望至少保證兩個副本始終可用。”

關于這個話題，我在這篇博文中作了深入地討論[4]。

共享集群中有更多租戶或環境

K8s 命名空間不提供任何強隔離。

人們似乎期望，如果將非生產環境工作負載分離到一個命名空間，將生產環境工作負載分離到另一個命名空間，那么一個工作負載就永遠不會影響另一個工作負載，這樣就可以實現某種程度的公平性（基于資源請求和限制、配額、優先級類）和隔離性（基于親和性、容忍度、污點（或節點選擇器），以便“物理地”分離數據平面(data plane)中的工作負載，但是，實現這種程度地分離相當復雜。

如果你需要在同一集群中同時擁有這兩種類型的工作負載，那么你將不得不承受這種復雜性。但是如果你不是非要這樣做不可，并且擁有另一個集群對你來說相對便宜（比如在公共云中），那么最好將它們放在不同的集群中，以實現更高的隔離級別。

設置 externalTrafficPolicy 值為 Cluster

經常看到這種情況，所有的流量在集群內全部被路由到一個 NodePort 服務， K8s 服務默認將 externalTrafficPolicy:的值設為 Cluster（即 externalTrafficPolicy: Cluster）。這意味著集群內的每個節點都打開該 NodePort 服務，這樣你就可以使用任何一個節點和所需的服務（一組 pods）通信。

通常，負責提供 NodePort 服務的實際 pod 只在這些節點的子集上運行。這意味著，如果你與一個沒有運行 pod 的節點會話，它會將流量轉發到另一個節點，從而導致額外的網絡跳數和延遲的增加（如果節點位于不同的 AZ 或不同的數據中心，則延遲可能會變得非常高，并且給它帶來額外的出口（egress）成本）。

將 K8s 服務的 externalTrafficPolicy 值設置為 Local （即 externalTrafficPolicy: Local）將不會導致在每個節點上打開該 NodePort 服務，它只會在 pod 實際運行的節點上打開。如果你使用一個能夠對 endpoint 進行狀態檢查的外部負載平衡器（如 AWS ELB 所做的），它就僅僅將流量發送到它應該發送到的節點，從而改進延遲、降低計算開銷和出口成本，并提高健全性。

很可能，你會將像 traefik 或 nginx-ingress-controller 之類的服務公開為 NodePort 類型（或者 LoadBalancer，它也使用 NodePort），以便路由 http ingress 流量，這個設置可以大大減少此類請求的延遲。

這里有篇很棒的博客文章[5]，深入探討了 externalTrafficPolicy 各種設置以及它們的優點和缺點。

有狀態（pet）集群以及過高地控制平面的壓力

你從按名字調用你的服務器 Anton, HAL9000 和 Colossus，到為你的 K8s 節點生成隨機 id，現在你開始按名字來調用集群了？

你知道你是如何開始使用 K8s 進行概念驗證的，你將集群命名為“testing”，并且在生產環境中仍然使用這個名字(testing)。這樣命名導致了每個人都害怕碰它嗎？（這個故事真實發生過）

Pet 集群（有狀態的集群）并不容易管理，你可能需要考慮不時地刪除你的集群，練習災難恢復并管理好控制平面（control plane）。害怕操作控制平面不是個好現象。Etcd 組件掛起？好吧，你有個大麻煩。

另一方面，對控制平面操作太多也不好。隨著時間的推移，控制平面會越來越慢，可能的原因是，你要么創建了太多對象而不輪換其狀態（這在使用默認設置的 helm 時非常常見，它將導致在 configmaps/secrets 中不輪換其狀態，最終在控制平面中有數千個對象），要么不斷地從 kube-api 中拚湊并編輯了大量內容（用于自動伸縮、cicd、監控，事件、事件和控制器的日志等等）。

另外，請查看你的 K8s 托管服務提供商承諾的 SLA/SLO 以及服務質量保障。你的提供商可能會保證控制平面（或其子組件）的可用性，但不會保證讓你滿意的 p99 延遲。也就是說，你運行 kubectl get nodes 命令，只要該命令在 10 分鐘執行完成并返回正確結果，你的服務提供商就仍然沒有違反服務保證。

附送一個問題：使用 latest 標簽

這是一個經典的問題。但是最近我發現自己不經常看到這種問題了，可能因為我們太多人都在這上面栽過跟頭，所以我們不再使用:latest 這個標簽了。

AWS ECR 現在支持標簽不變性，這個很棒的特性絕對值得你去查看。

總結

不要指望一切都會自動進行，K8s 并非靈丹妙藥。一個糟糕的應用程序始終是糟糕的應用程序，即使在 K8s 上也改變不了（實際上可能甚至更糟糕）。稍不小心，你可能就會面對諸如太多復雜性，過高的壓力，控制平面緩慢，沒有災難恢復策略等麻煩。不要對開箱即用的多租戶設計和高可用性期望過高。花點時間思考如何讓你的云應用成為原生應用。

查看 Henning 收集的這些關于 K8s 使用的失敗故事[6]，可以對你在將來避開這些錯誤有所幫助。

如果你看到有人在 K8s 使用上犯了不同于本文中的錯誤，請在 Twitter 上告訴我們（@MarekBartik @MstrsObserver）！

[1] Optimizing Kubernetes Resource Requests/Limits for Cost-Efficiency and Latency - Highload++, https://www.slideshare.net/try_except_/optimizing-kubernetes-resource-requestslimits-for-costefficiency-and-latency-highload

[2] https://cloud.google.com/kubernetes-engine/docs/concepts/verticalpodautoscaler

[3] https://blog.pipetail.io/posts/2020-04-13-more-eks-tips/

[4] https://blog.marekbartik.com/posts/2018-06-29_kubernetes-in-production-poddisruptionbudget/

[5] https://www.asykim.com/blog/deep-dive-into-kubernetes-external-traffic-policies

[6] https://k8s.af/

【作者自我簡介】Marek Bartik，一名 NoOps/NoCode 的堅定支持者。在攻讀“計算機系統和網絡”碩士學位時開始從事 C++編程工作。在 SysAdmin 年代長大的我很快意識到溝通和協作的重要性。現在我專注于云架構、微服務和 Continuous Everything 來解決業務問題，而非技術問題。我熱愛旅行，并且是極簡主義，DevOps 和云原生的大力倡導者。

英文：10 most common mistakes using Kubernetes

鏈接：https://blog.pipetail.io/posts/2020-05-04-most-common-mistakes-k8s/

作者：Marek Bartik

翻譯：蘇本如，責編：唐小引

【END】

推薦閱讀

• 一文帶你從頭認識什么是「緩存」！
  

• 在 520 這天，竟然有人把 Docker講清楚了？ | 原力計劃

• 如何使用 SQL Server FILESTREAM 存儲非結構化數據？這篇文章告訴你！

• 平安科技王健宗：所有 AI 前沿技術，都可以在聯邦學習中大展身手！

• 踢翻這碗狗糧：程序員花 7 個月敲出 eBay，只因女票喜歡糖果盒！

• 又一年5.20，用Python助力程序員脫單大攻略（視頻版）

• 斗地主嗎？能學區塊鏈那種！ | 原力計劃

真香，朕在看了！

總結

以上是生活随笔為你收集整理的避坑！使用 Kubernetes 最易犯的 10 个错误的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。