避開日常Kubernetes最常見的10個坑

使用 Kubernetes，大家都會遇到哪些錯誤？本文分享了作者多年來使用 Kubernetes 最常見的 10 個錯誤。

使用 Kubernetes，大家都會遇到哪些錯誤？本文分享了作者多年來使用 Kubernetes 最常見的 10 個錯誤。

使用 kubernetes 這麼多年以來，我們見過的叢集不計其數（包括託管的和非託管的，GCP、AWS 和 Azure 上的都有），還見識了很多經常重複出現的錯誤。其中大部分錯誤我們自己也犯過，這沒什麼丟人的！

本文會給大家展示一些我們經常遇到的問題，並談談修復它們的方法。

這無疑是最值得關注的，也是這個榜單上的第一名。

人們經常不設定 CPU 請求或將 CPU 請求設定得過低（這樣我們就可以在每個節點上容納很多 Pod），結果節點就會過量使用（overcommited）。在需求較高時，節點的 CPU 全負荷執行，而我們的負載只能得到“它所請求的”資料，使 CPU 節流（throttled），從而導致應用程式延遲和超時等指標增加。

BestEffort（不要這樣做）：

resources: {}

very low cpu（不要這樣做）：

resources:
requests:
cpu: "1m"

另一方面，啟用 CPU 限制可能會在節點的 CPU 沒有充分利用的情況下，對 Pod 進行不必要地節流，這也會導致延遲增加。人們也討論過關於   核心中的 CPU CFS 配額，和因為設定了 CPU 限制並關閉 CFS 配額而導致的 CPU 節流問題。CPU 限制造成的問題可能會比它能解決的問題還多。想了解更多資訊，請檢視下面的連結。

記憶體過量使用會給我們帶來更多麻煩。達到 CPU 限制將導致節流，達到記憶體限制會導致 Pod 被殺。見過 OOMkill（因記憶體不足而被殺死）嗎？我們要說的就是這個意思。想要儘量減少這類狀況？那就不要過量使用記憶體，並使用 Guaranteed QoS（Quality of Service）將記憶體請求設定為與限制相等，就像下面的例子那樣。瞭解更多資訊，請參考 Henning Jacobs（Zalando）的演講。

Burstable（容易帶來更多 OOMkilled）：

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

Guaranteed：

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

那麼我們設定資源時有什麼訣竅呢？

我們可以使用 metrics-server 檢視 Pod（以及其中的容器）的當前 CPU 和記憶體使用情況。你可能已經啟用它了。只需執行以下 即可：

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

不過，這些只會顯示當前的使用情況。要大致瞭解這些資料的話這就夠用了，但我們到頭來是希望能及時看到這些使用量指標（以回答諸如：昨天上午 CPU 使用量的峰值等問題）。為此我們可以使用 Prometheus 和 DataDog 等工具。它們只是從 metrics-server 接收度量資料並儲存下來，然後我們就能查詢和繪製這些資料了。

VerticalPodAutoscaler 可以幫助我們自動化這一手動過程——及時檢視 cpu/ 記憶體的使用情況，並基於這些資料再設定新的請求和限制。

有效利用計算資源不是一件容易的事情，就像不停地玩俄羅斯方塊。如果我們發現自己花了大筆錢購買計算資源，可是平均利用率卻很低（比如大約 10%），那麼我們可能就需要 AWS Fargate 或基於 Virtual Kubelet 的產品。它們主要使用無伺服器 / 按使用量付費的的計費模式，這對我們來說可能會更省錢。

預設情況下，Kubernetes 不會指定任何 liveness 和 readiness 探針。有時它會一直保持這種狀態……

但如果出現不可恢復的錯誤，我們的服務將如何重新啟動呢？負載均衡器如何知道特定的 Pod 可以開始處理流量，或能處理更多流量呢？

人們通常不知道這兩者間的區別。

如果探針失敗，liveness 探針將重新啟動 Pod
Readiness 探針失敗時，會斷開故障 Pod 與 Kubernetes 服務的連線（我們可以用kubectl get endpoints檢查這一點），並且直到該探針恢復正常之前，不會向該 Pod 傳送任何流量。
它們兩個都執行在整個 Pod 生命週期中。這一點是很重要的。

人們通常認為，readiness 探針只在開始時執行，以判斷 Pod 何時 Ready 並可以開始處理流量。但這只是它的一個用例而已。

它的另一個用例是在一個 Pod 的生命週期中判斷它是否因過熱而無法處理太多流量（或一項昂貴的計算），這樣我們就不會讓它做更多工作，而是讓它冷卻下來；等到 readiness 探針成功，我們會再給它傳送更多流量。在這種情況下（當 readiness 探針失敗時），如果 liveness 探針也失敗就會非常影響效率了。我們為什麼要重新啟動一個健康的、正在做大量工作的 Pod 呢？

有時候，不指定任何探針都比指定一個錯誤的探針要好。如上所述，如果 liveness 探針等於 readiness 探針，我們將遇到很大的麻煩。我們一開始可能只會指定 readiness 探針，因為 liveness 探針太危險了。

如果你的任何共享依賴項出現故障，就不要讓任何一個探針失敗，否則它將導致所有 Pod 的級聯故障。我們這是搬起石頭砸自己的腳。

https://blog.colinbreck.com/kubernetes-liveness-and-readiness-probes-how-to-avoid-shooting-yourself-in-the-foot/

我們的叢集中可能有很多 HTTP 服務，並且我們希望將這些服務對外界公開。

如果我們將 Kubernetes 服務以type: LoadBalancer的形式公開，那麼它的控制器（取決於供應商）將提供並協調一個外部負載均衡器（不一定是 L7 的，更可能是 L4 lb）；當我們建立很多這種資源時，它們可能會變得很昂貴（外部靜態 ipv4 地址、計算、按秒計費……）。

在這種情況下，共享同一個外部負載均衡器可能會更好些，這時我們將服務以type: NodePort的形式公開。或者更好的方法是，部署 nginx-ingress-controller（或 traefik）之類的東西，作為公開給這個外部負載均衡器的單個 NodePort 端點，並基於 Kubernetes ingress 資源在叢集中路由流量。

其他相互通訊的叢集內（微）服務可以透過 ClusterIP 服務和開箱即用的 DNS 服務發現來通訊。注意不要使用它們的公共 DNS/IP，因為這可能會影響它們的延遲和雲成本。

在叢集中新增節點或刪除節點時，不應該考慮一些簡單的度量指標，比如這些節點的 CPU 利用率。在排程 Pod 時，我們需要根據許多排程約束來進行決策，比如 Pod 和節點的親密關係（affinities）、汙點（taints）和容忍（tolerations）、資源請求（resource requests）、QoS 等。讓一個不瞭解這些約束的外部自動縮放器（autoscaler）來處理縮放可能會招來麻煩。

假設有一個新的 Pod 要被排程，但是所有可用的 CPU 都被請求了，並且 Pod 卡在了 Pending 狀態。可是外部自動縮放器會檢視當前的平均 CPU 使用率（不是請求數量），然後決定不擴容（不新增新的節點）。結果 Pod 也不會被排程。

縮容（從叢集中刪除節點）總是更難一些。假設我們有一個有狀態的 Pod（連線了持久卷），由於持久卷（persistent volumes）通常是屬於特定可用區域的資源，並且沒有在該區域中複製，我們自定義的自動縮放器會刪除一個帶有此 Pod 的節點，而排程器無法將其排程到另一個節點上，因為這個 Pod 只能待在持久磁碟所在的那個可用區域裡。Pod 將再次陷入 Pending 狀態。

社群正在廣泛使用 cluster-autoscaler，它執行在叢集中，能與大多數主要的公共雲供應商 API 整合；它可以理解所有這些約束，並能在上述情況下擴容。它還能搞清楚是否可以在不影響我們設定的任何約束的前提下優雅地縮容，從而節省我們的計算成本。

不要使用 IAM Users 永久儲存機器和應用程式的秘鑰，而要使用角色和服務帳戶生成的臨時秘鑰。

我們經常看到這種情況，那就是在應用程式配置中硬編碼訪問（access ）和金鑰（secret），並在使用 Cloud IAM 時從來不輪換金鑰。我們應該儘量使用 IAM 角色和服務帳戶來代替 Users。

請跳過 kube2iam，直接按照Štěpán Vraný在這篇博文中介紹的那樣，使用服務賬戶的 IAM 角色。

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

apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
name: my-serviceaccount
namespace: default

只有一個 annotation。沒那麼難做吧。

另外，當服務帳戶或例項配置檔案不需要admin和cluster-admin許可權時，也不要給它們這些許可權。這有點困難，尤其是在 k8s RBAC 中，但仍然值得一試。

某個部署有 3 個 Pod 副本正在執行，然後節點關閉了，所有的副本也都隨之關閉。豈有此理？所有副本都在一個節點上執行？Kubernetes 難道不應該很厲害，並提供高可用性的嗎？！

我們不能指望 Kubernetes 排程程式為我們的 Pod 強制使用 anti-affinites。我們必須顯式地定義它們。

// omitted for brevity
labels:
app: zk
// omitted for brevity
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: "app"
operator: In
values:
- zk
topologyKey: "kubernetes.io/hostname"

就是這樣。這樣就能保證 Pod 被排程到不同的節點上（這僅在排程時檢查，而不是在執行時檢查，因此需要requiredDuringSchedulingIgnoredDuringExecution ）。

我們討論的是不同節點名稱上（ topologyKey: "kubernetes.io/hostname" ）的 podAntiAffinity，而不是不同可用區域的 podAntiAffinity。如果你確實需要很好的可用性水平，可以在這個主題上再深入做些研究。

我們在 Kubernetes 上執行生產負載。我們的節點和叢集必須不時升級或停用。PodDisruptionBudget（pdb）是一種用於在叢集管理員和叢集使用者之間提供服務保證的 API。

請確保建立了pdb ，以避免由於節點耗盡而造成不必要的服務中斷。

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

作為一個叢集使用者，我們可以告訴叢集管理員：“嘿，我這裡有個 zookeeper 服務，無論如何我都希望至少有 2 個副本是始終可用的”。

我在這篇部落格文章中更深入地討論了這個話題。

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

Kubernetes 名稱空間不提供任何強隔離。

人們似乎期望，如果將非生產負載放到一個名稱空間，然後將生產負載放到生產名稱空間，那麼這些負載之間就永遠不會相互影響了。我們可以在某種程度上公平分配（比如資源的請求和限制、配額、優先順序）並實現隔離（比如 affinities、tolerations、taints 或 nodeselectors），進而“物理地”分離資料平面上的負載，但這種分離是相當複雜的。

如果我們需要在同一個叢集中同時擁有這兩種型別的負載，那麼就必須要承擔這種複雜性。如果我們用不著侷限在一個叢集裡，而且再加一個叢集的成本更低時（比如在公共雲上），那麼應該將它們放在不同的叢集中以獲得更強的隔離級別。

經常看到這種情況，所有流量都在叢集內路由到一個 NodePort 服務上，該服務預設使用 externalTrafficPolicy: Cluster 。這意味著在叢集中的每個節點上都開啟了 NodePort，這樣我們可以任選一個來與所需的服務（一組 Pod）通訊。

通常情況下，NodePort 服務所針對的那些 Pod 實際上只執行在這些節點的一個子集上。這意味著，如果我與一個沒有執行 Pod 的節點通訊，它將會把流量轉發給另一個節點，從而導致額外的網路跳轉並增加延遲（如果節點位於不同的 AZs 或資料中心，那麼延遲可能會很高，並且會帶來額外的出口成本）。

在 Kubernetes 服務上設定externalTrafficPolicy: Local，就不會在每個節點上都開啟 NodePort，只會在實際執行 Pod 的節點上開啟它。如果我們使用一個外部負載均衡器來檢查它端點的執行狀況（就像 AWS ELB 所做的那樣），它就會只將流量傳送到應該接收流量的節點上，這樣就能改善延遲、減少計算開銷、降低出口成本並提升健全性。

我們可能會有像 traefik 或 nginx-ingress-controller 之類的東西，被公開成 NodePort（或使用 NodePort 的負載均衡器）來處理入口 HTTP 流量路由，而這種設定可以極大地減少此類請求的延遲。

這裡有一篇很棒的部落格文章，更深入地討論了 externalTrafficPolicy 和它們的權衡取捨。

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

你有沒有過這樣的經歷：給伺服器取 Anton、HAL9000 或 Colossus 之類的名字（都是帶梗的名稱，譯註），或者給節點隨機生成 id，卻給叢集取個有含義的名稱？

還可能是這樣的經歷：一開始用 Kubernetes 做概念驗證，給叢集取名"testing"，結果到了生產環境還沒給它改名，結果誰都不敢碰它？（真實的故事）

把叢集當寵物可不是開玩笑的，我們可能需要不時刪除叢集，演練災難恢復並管理我們的控制平面。害怕觸碰控制平面不是個好兆頭。Etcd 掛掉了？好嘞，我們遇到麻煩。

反過來說，控制平面也不要用過頭了。也許隨著時間的流逝，控制平面變慢了。這很可能是因為我們建立了很多物件而沒有輪換它們（使用 helm 時常見的情況，它的預設設定不會輪換 configmaps/secrets 的狀態，結果我們在控制平面中會有數千個物件），或者是因為我們不斷從 kube-api（用於自動伸縮、CI/CD、監視、事件日誌、控制器等）中刪除和編輯了大量內容。

另外，請檢查託管 Kubernetes 提供的“SLAs”/SLOs 和保證。供應商可能會保證控制平面（或其子元件）的可用性，但不能保證傳送給它的請求的 p99 延遲水平。換句話說，就算我們kubectl get nodes後用了 10 分鐘才得到正確結果，也沒有違反服務保證。

這一條是很經典的。我覺得最近它沒那麼常見了，因為大家被坑的次數太多，所以再也不用 :latest ，開始加上版本號了。這下清靜了！

ECR 有一個標籤不變性的強大功能，絕對值得一試。

https://aws.amazon.com/about-aws/whats-new/2019/07/amazon-ecr-now-supports-immutable-image-tags/

別指望所有問題都能自動解決——Kubernetes 不是銀彈。即使是在 Kubernetes 上，一個糟糕的應用程式還會是一個糟糕的應用程式（實際上，甚至還可能更糟糕）。如果我們不夠小心，最後就會遇到一系列問題：太過複雜、壓力過大、控制平面變慢、沒有災難恢復策略。不要指望多租戶和高可用性是開箱即用的。請花點時間讓我們的應用程式雲原生化。

原文地址：