避开日常Kubernetes最常见的10个坑
云計(jì)算
使用 Kubernetes，大家都會(huì)遇到哪些錯(cuò)誤？本文分享了作者多年來(lái)使用 Kubernetes 最常見的 10 個(gè)錯(cuò)誤。
使用 Kubernetes，大家都會(huì)遇到哪些錯(cuò)誤？本文分享了作者多年來(lái)使用 Kubernetes 最常見的 10 個(gè)錯(cuò)誤。
使用 kubernetes 這么多年以來(lái)，我們見過(guò)的集群不計(jì)其數(shù)（包括托管的和非托管的，GCP、AWS 和 Azure 上的都有），還見識(shí)了很多經(jīng)常重復(fù)出現(xiàn)的錯(cuò)誤。其中大部分錯(cuò)誤我們自己也犯過(guò)，這沒(méi)什么丟人的！
本文會(huì)給大家展示一些我們經(jīng)常遇到的問(wèn)題，并談?wù)勑迯?fù)它們的方法。
1. 資源：請(qǐng)求和限制
這無(wú)疑是最值得關(guān)注的，也是這個(gè)榜單上的第一名。
人們經(jīng)常不設(shè)置 CPU 請(qǐng)求或?qū)?CPU 請(qǐng)求設(shè)置得過(guò)低（這樣我們就可以在每個(gè)節(jié)點(diǎn)上容納很多 Pod），結(jié)果節(jié)點(diǎn)就會(huì)過(guò)量使用（overcommited）。在需求較高時(shí)，節(jié)點(diǎn)的 CPU 全負(fù)荷運(yùn)行，而我們的負(fù)載只能得到“它所請(qǐng)求的”數(shù)據(jù)，使 CPU 節(jié)流（throttled），從而導(dǎo)致應(yīng)用程序延遲和超時(shí)等指標(biāo)增加。
BestEffort（不要這樣做）：
resources:{}
very low cpu（不要這樣做）：
resources: requests: cpu:"1m"
另一方面，啟用 CPU 限制可能會(huì)在節(jié)點(diǎn)的 CPU 沒(méi)有充分利用的情況下，對(duì) Pod 進(jìn)行不必要地節(jié)流，這也會(huì)導(dǎo)致延遲增加。人們也討論過(guò)關(guān)于
Linux內(nèi)核中的 CPU CFS 配額，和因?yàn)樵O(shè)置了 CPU 限制并關(guān)閉 CFS 配額而導(dǎo)致的 CPU 節(jié)流問(wèn)題。CPU 限制造成的問(wèn)題可能會(huì)比它能解決的問(wèn)題還多。想了解更多信息，請(qǐng)查看下面的鏈接。
內(nèi)存過(guò)量使用會(huì)給我們帶來(lái)更多麻煩。達(dá)到 CPU 限制將導(dǎo)致節(jié)流，達(dá)到內(nèi)存限制會(huì)導(dǎo)致 Pod 被殺。見過(guò) OOMkill（因內(nèi)存不足而被殺死）嗎？我們要說(shuō)的就是這個(gè)意思。想要盡量減少這類狀況？那就不要過(guò)量使用內(nèi)存，并使用 Guaranteed QoS（Quality of Service）將內(nèi)存請(qǐng)求設(shè)置為與限制相等，就像下面的例子那樣。了解更多信息，請(qǐng)參考 Henning Jacobs（Zalando）的演講。
https://www.slideshare.net/try_except_/optimizing-kubernetes-resource-requestslimits-for-costefficiency-and-latency-highload
Burstable（容易帶來(lái)更多 OOMkilled）：
resources: requests: memory:"128Mi" cpu:"500m" limits: memory:"256Mi" cpu:2
Guaranteed：
resources: requests: memory:"128Mi" cpu:2 limits: memory:"128Mi" cpu:2
那么我們?cè)O(shè)置資源時(shí)有什么訣竅呢？
我們可以使用 metrics-server 查看 Pod（以及其中的容器）的當(dāng)前 CPU 和內(nèi)存使用情況。你可能已經(jīng)啟用它了。只需運(yùn)行以下
命令即可：
kubectltoppods kubectltoppods--containers kubectltopnodes
不過(guò)，這些只會(huì)顯示當(dāng)前的使用情況。要大致了解這些數(shù)據(jù)的話這就夠用了，但我們到頭來(lái)是希望能及時(shí)看到這些使用量指標(biāo)（以回答諸如：昨天上午 CPU 使用量的峰值等問(wèn)題）。為此我們可以使用 Prometheus 和 DataDog 等工具。它們只是從 metrics-server 接收度量數(shù)據(jù)并存儲(chǔ)下來(lái)，然后我們就能查詢和繪制這些數(shù)據(jù)了。
VerticalPodAutoscaler 可以幫助我們自動(dòng)化這一手動(dòng)過(guò)程——及時(shí)查看 cpu/ 內(nèi)存的使用情況，并基于這些數(shù)據(jù)再設(shè)置新的請(qǐng)求和限制。
https://cloud.google.com/kubernetes-engine/docs/concepts/verticalpodautoscaler
有效利用計(jì)算資源不是一件容易的事情，就像不停地玩俄羅斯方塊。如果我們發(fā)現(xiàn)自己花了大筆錢購(gòu)買計(jì)算資源，可是平均利用率卻很低（比如大約 10%），那么我們可能就需要 AWS Fargate 或基于 Virtual Kubelet 的產(chǎn)品。它們主要使用無(wú)服務(wù)器 / 按使用量付費(fèi)的的計(jì)費(fèi)模式，這對(duì)我們來(lái)說(shuō)可能會(huì)更省錢。
2. liveness 和 readiness 探針
默認(rèn)情況下，Kubernetes 不會(huì)指定任何 liveness 和 readiness 探針。有時(shí)它會(huì)一直保持這種狀態(tài)……
但如果出現(xiàn)不可恢復(fù)的錯(cuò)誤，我們的服務(wù)將如何重新啟動(dòng)呢？負(fù)載均衡器如何知道特定的 Pod 可以開始處理流量，或能處理更多流量呢？
人們通常不知道這兩者間的區(qū)別。
如果探針失敗，liveness 探針將重新啟動(dòng) Pod
Readiness 探針失敗時(shí)，會(huì)斷開故障 Pod 與 Kubernetes 服務(wù)的連接（我們可以用kubectl get endpoints檢查這一點(diǎn)），并且直到該探針恢復(fù)正常之前，不會(huì)向該 Pod 發(fā)送任何流量。
它們兩個(gè)都運(yùn)行在整個(gè) Pod 生命周期中。這一點(diǎn)是很重要的。
人們通常認(rèn)為，readiness 探針只在開始時(shí)運(yùn)行，以判斷 Pod 何時(shí) Ready 并可以開始處理流量。但這只是它的一個(gè)用例而已。
它的另一個(gè)用例是在一個(gè) Pod 的生命周期中判斷它是否因過(guò)熱而無(wú)法處理太多流量（或一項(xiàng)昂貴的計(jì)算），這樣我們就不會(huì)讓它做更多工作，而是讓它冷卻下來(lái)；等到 readiness 探針成功，我們會(huì)再給它發(fā)送更多流量。在這種情況下（當(dāng) readiness 探針失敗時(shí)），如果 liveness 探針也失敗就會(huì)非常影響效率了。我們?yōu)槭裁匆匦聠?dòng)一個(gè)健康的、正在做大量工作的 Pod 呢？
有時(shí)候，不指定任何探針都比指定一個(gè)錯(cuò)誤的探針要好。如上所述，如果 liveness 探針等于 readiness 探針，我們將遇到很大的麻煩。我們一開始可能只會(huì)指定 readiness 探針，因?yàn)?liveness 探針太危險(xiǎn)了。
https://twitter.com/sszuecs/status/1175803113204269059
https://srcco.de/posts/kubernetes-liveness-probes-are-dangerous.html
如果你的任何共享依賴項(xiàng)出現(xiàn)故障，就不要讓任何一個(gè)探針失敗，否則它將導(dǎo)致所有 Pod 的級(jí)聯(lián)故障。我們這是搬起石頭砸自己的腳。
https://blog.colinbreck.com/kubernetes-liveness-and-readiness-probes-how-to-avoid-shooting-yourself-in-the-foot/
3. 在所有 HTTP 服務(wù)上啟用負(fù)載均衡器
我們的集群中可能有很多 HTTP 服務(wù)，并且我們希望將這些服務(wù)對(duì)外界公開。
如果我們將 Kubernetes 服務(wù)以type: LoadBalancer的形式公開，那么它的控制器（取決于供應(yīng)商）將提供并協(xié)調(diào)一個(gè)外部負(fù)載均衡器（不一定是 L7 的，更可能是 L4 lb）；當(dāng)我們創(chuàng)建很多這種資源時(shí)，它們可能會(huì)變得很昂貴（外部靜態(tài) ipv4 地址、計(jì)算、按秒計(jì)費(fèi)……）。
在這種情況下，共享同一個(gè)外部負(fù)載均衡器可能會(huì)更好些，這時(shí)我們將服務(wù)以type: NodePort的形式公開。或者更好的方法是，部署 nginx-ingress-controller（或 traefik）之類的東西，作為公開給這個(gè)外部負(fù)載均衡器的單個(gè) NodePort 端點(diǎn)，并基于 Kubernetes ingress 資源在集群中路由流量。
其他相互通信的集群內(nèi)（微）服務(wù)可以通過(guò) ClusterIP 服務(wù)和開箱即用的 dns 服務(wù)發(fā)現(xiàn)來(lái)通信。注意不要使用它們的公共 DNS/IP，因?yàn)檫@可能會(huì)影響它們的延遲和云成本。
4. 無(wú) Kubernetes 感知的集群自動(dòng)縮放
在集群中添加節(jié)點(diǎn)或刪除節(jié)點(diǎn)時(shí)，不應(yīng)該考慮一些簡(jiǎn)單的度量指標(biāo)，比如這些節(jié)點(diǎn)的 CPU 利用率。在調(diào)度 Pod 時(shí)，我們需要根據(jù)許多調(diào)度約束來(lái)進(jìn)行決策，比如 Pod 和節(jié)點(diǎn)的親密關(guān)系（affinities）、污點(diǎn)（taints）和容忍（tolerations）、資源請(qǐng)求（resource requests）、QoS 等。讓一個(gè)不了解這些約束的外部自動(dòng)縮放器（autoscaler）來(lái)處理縮放可能會(huì)招來(lái)麻煩。
假設(shè)有一個(gè)新的 Pod 要被調(diào)度，但是所有可用的 CPU 都被請(qǐng)求了，并且 Pod 卡在了 Pending 狀態(tài)。可是外部自動(dòng)縮放器會(huì)查看當(dāng)前的平均 CPU 使用率（不是請(qǐng)求數(shù)量），然后決定不擴(kuò)容（不添加新的節(jié)點(diǎn)）。結(jié)果 Pod 也不會(huì)被調(diào)度。
縮容（從集群中刪除節(jié)點(diǎn)）總是更難一些。假設(shè)我們有一個(gè)有狀態(tài)的 Pod（連接了持久卷），由于持久卷（persistent volumes）通常是屬于特定可用區(qū)域的資源，并且沒(méi)有在該區(qū)域中復(fù)制，我們自定義的自動(dòng)縮放器會(huì)刪除一個(gè)帶有此 Pod 的節(jié)點(diǎn)，而調(diào)度器無(wú)法將其調(diào)度到另一個(gè)節(jié)點(diǎn)上，因?yàn)檫@個(gè) Pod 只能待在持久磁盤所在的那個(gè)可用區(qū)域里。Pod 將再次陷入 Pending 狀態(tài)。
社區(qū)正在廣泛使用 cluster-autoscaler，它運(yùn)行在集群中，能與大多數(shù)主要的公共云供應(yīng)商 API 集成；它可以理解所有這些約束，并能在上述情況下擴(kuò)容。它還能搞清楚是否可以在不影響我們?cè)O(shè)置的任何約束的前提下優(yōu)雅地縮容，從而節(jié)省我們的計(jì)算成本。
https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler
5. 不要使用 IAM/RBAC 的能力
不要使用 IAM Users 永久存儲(chǔ)機(jī)器和應(yīng)用程序的秘鑰，而要使用角色和服務(wù)帳戶生成的臨時(shí)秘鑰。
我們經(jīng)常看到這種情況，那就是在應(yīng)用程序配置中硬編碼訪問(wèn)（access ）和密鑰（secret），并在使用 Cloud IAM 時(shí)從來(lái)不輪換密鑰。我們應(yīng)該盡量使用 IAM 角色和服務(wù)帳戶來(lái)代替 Users。
請(qǐng)?zhí)^(guò) kube2iam，直接按照?těpán Vrany在這篇博文中介紹的那樣，使用服務(wù)賬戶的 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
只有一個(gè) annotation。沒(méi)那么難做吧。
另外，當(dāng)服務(wù)帳戶或?qū)嵗渲梦募恍枰猘dmin和cluster-admin權(quán)限時(shí)，也不要給它們這些權(quán)限。這有點(diǎn)困難，尤其是在 k8s RBAC 中，但仍然值得一試。
6. Pod 的 self anti-affinities
某個(gè)部署有 3 個(gè) Pod 副本正在運(yùn)行，然后節(jié)點(diǎn)關(guān)閉了，所有的副本也都隨之關(guān)閉。豈有此理？所有副本都在一個(gè)節(jié)點(diǎn)上運(yùn)行？Kubernetes 難道不應(yīng)該很厲害，并提供高可用性的嗎？！
我們不能指望 Kubernetes 調(diào)度程序?yàn)槲覀兊?Pod 強(qiáng)制使用 anti-affinites。我們必須顯式地定義它們。
//omittedforbrevity labels: app:zk //omittedforbrevity affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: -labelSelector: matchExpressions: -key:"app" operator:In values: -zk topologyKey:"kubernetes.io/hostname"
就是這樣。這樣就能保證 Pod 被調(diào)度到不同的節(jié)點(diǎn)上（這僅在調(diào)度時(shí)檢查，而不是在執(zhí)行時(shí)檢查，因此需要requiredDuringSchedulingIgnoredDuringExecution ）。
我們討論的是不同節(jié)點(diǎn)名稱上（ topologyKey: "kubernetes.io/hostname" ）的 podAntiAffinity，而不是不同可用區(qū)域的 podAntiAffinity。如果你確實(shí)需要很好的可用性水平，可以在這個(gè)主題上再深入做些研究。
7. 無(wú) PodDisruptionBudget
我們?cè)?Kubernetes 上運(yùn)行生產(chǎn)負(fù)載。我們的節(jié)點(diǎn)和集群必須不時(shí)升級(jí)或停用。PodDisruptionBudget（pdb）是一種用于在集群管理員和集群用戶之間提供服務(wù)保證的 API。
請(qǐng)確保創(chuàng)建了pdb ，以避免由于節(jié)點(diǎn)耗盡而造成不必要的服務(wù)中斷。
apiVersion:policy/v1beta1 kind:PodDisruptionBudget metadata: name:zk-pdb spec: minAvailable:2 selector: matchLabels: app:zookeeper
作為一個(gè)集群用戶，我們可以告訴集群管理員：“嘿，我這里有個(gè) zookeeper 服務(wù)，無(wú)論如何我都希望至少有 2 個(gè)副本是始終可用的”。
我在這篇博客文章中更深入地討論了這個(gè)話題。
https://blog.marekbartik.com/posts/2018-06-29_kubernetes-in-production-poddisruptionbudget/
8. 共享集群中有不止一個(gè)租戶或環(huán)境
Kubernetes 命名空間不提供任何強(qiáng)隔離。
人們似乎期望，如果將非生產(chǎn)負(fù)載放到一個(gè)命名空間，然后將生產(chǎn)負(fù)載放到生產(chǎn)命名空間，那么這些負(fù)載之間就永遠(yuǎn)不會(huì)相互影響了。我們可以在某種程度上公平分配（比如資源的請(qǐng)求和限制、配額、優(yōu)先級(jí)）并實(shí)現(xiàn)隔離（比如 affinities、tolerations、taints 或 nodeselectors），進(jìn)而“物理地”分離數(shù)據(jù)平面上的負(fù)載，但這種分離是相當(dāng)復(fù)雜的。
如果我們需要在同一個(gè)集群中同時(shí)擁有這兩種類型的負(fù)載，那么就必須要承擔(dān)這種復(fù)雜性。如果我們用不著局限在一個(gè)集群里，而且再加一個(gè)集群的成本更低時(shí)（比如在公共云上），那么應(yīng)該將它們放在不同的集群中以獲得更強(qiáng)的隔離級(jí)別。
9. externalTrafficPolicy: Cluster
經(jīng)常看到這種情況，所有流量都在集群內(nèi)路由到一個(gè) NodePort 服務(wù)上，該服務(wù)默認(rèn)使用 externalTrafficPolicy: Cluster 。這意味著在集群中的每個(gè)節(jié)點(diǎn)上都打開了 NodePort，這樣我們可以任選一個(gè)來(lái)與所需的服務(wù)（一組 Pod）通信。
通常情況下，NodePort 服務(wù)所針對(duì)的那些 Pod 實(shí)際上只運(yùn)行在這些節(jié)點(diǎn)的一個(gè)子集上。這意味著，如果我與一個(gè)沒(méi)有運(yùn)行 Pod 的節(jié)點(diǎn)通信，它將會(huì)把流量轉(zhuǎn)發(fā)給另一個(gè)節(jié)點(diǎn)，從而導(dǎo)致額外的網(wǎng)絡(luò)跳轉(zhuǎn)并增加延遲（如果節(jié)點(diǎn)位于不同的 AZs 或數(shù)據(jù)中心，那么延遲可能會(huì)很高，并且會(huì)帶來(lái)額外的出口成本）。
在 Kubernetes 服務(wù)上設(shè)置externalTrafficPolicy: Local，就不會(huì)在每個(gè)節(jié)點(diǎn)上都打開 NodePort，只會(huì)在實(shí)際運(yùn)行 Pod 的節(jié)點(diǎn)上開啟它。如果我們使用一個(gè)外部負(fù)載均衡器來(lái)檢查它端點(diǎn)的運(yùn)行狀況（就像 AWS ELB 所做的那樣），它就會(huì)只將流量發(fā)送到應(yīng)該接收流量的節(jié)點(diǎn)上，這樣就能改善延遲、減少計(jì)算開銷、降低出口成本并提升健全性。
我們可能會(huì)有像 traefik 或 nginx-ingress-controller 之類的東西，被公開成 NodePort（或使用 NodePort 的負(fù)載均衡器）來(lái)處理入口 HTTP 流量路由，而這種設(shè)置可以極大地減少此類請(qǐng)求的延遲。
這里有一篇很棒的博客文章，更深入地討論了 externalTrafficPolicy 和它們的權(quán)衡取舍。
https://www.asykim.com/blog/deep-dive-into-kubernetes-external-traffic-policies
10. 把集群當(dāng)寵物 + 控制平面壓力過(guò)大
你有沒(méi)有過(guò)這樣的經(jīng)歷：給服務(wù)器取 Anton、HAL9000 或 Colossus 之類的名字（都是帶梗的名稱，譯注），或者給節(jié)點(diǎn)隨機(jī)生成 id，卻給集群取個(gè)有含義的名稱？
還可能是這樣的經(jīng)歷：一開始用 Kubernetes 做概念驗(yàn)證，給集群取名"testing"，結(jié)果到了生產(chǎn)環(huán)境還沒(méi)給它改名，結(jié)果誰(shuí)都不敢碰它？（真實(shí)的故事）
把集群當(dāng)寵物可不是開玩笑的，我們可能需要不時(shí)刪除集群，演練災(zāi)難恢復(fù)并管理我們的控制平面。害怕觸碰控制平面不是個(gè)好兆頭。Etcd 掛掉了？好嘞，我們遇到麻煩。
反過(guò)來(lái)說(shuō)，控制平面也不要用過(guò)頭了。也許隨著時(shí)間的流逝，控制平面變慢了。這很可能是因?yàn)槲覀儎?chuàng)建了很多對(duì)象而沒(méi)有輪換它們（使用 helm 時(shí)常見的情況，它的默認(rèn)設(shè)置不會(huì)輪換 configmaps/secrets 的狀態(tài)，結(jié)果我們?cè)诳刂破矫嬷袝?huì)有數(shù)千個(gè)對(duì)象），或者是因?yàn)槲覀儾粩鄰?kube-api（用于自動(dòng)伸縮、CI/CD、監(jiān)視、事件日志、控制器等）中刪除和編輯了大量?jī)?nèi)容。
另外，請(qǐng)檢查托管 Kubernetes 提供的“SLAs”/SLOs 和保證。供應(yīng)商可能會(huì)保證控制平面（或其子組件）的可用性，但不能保證發(fā)送給它的請(qǐng)求的 p99 延遲水平。換句話說(shuō)，就算我們kubectl get nodes后用了 10 分鐘才得到正確結(jié)果，也沒(méi)有違反服務(wù)保證。
11. 附贈(zèng)一條：使用 latest 標(biāo)簽
這一條是很經(jīng)典的。我覺(jué)得最近它沒(méi)那么常見了，因?yàn)榇蠹冶豢拥拇螖?shù)太多，所以再也不用 :latest ，開始加上版本號(hào)了。這下清靜了！
ECR 有一個(gè)標(biāo)簽不變性的強(qiáng)大功能，絕對(duì)值得一試。
https://aws.amazon.com/about-aws/whats-new/2019/07/amazon-ecr-now-supports-immutable-image-tags/
12.總結(jié)
別指望所有問(wèn)題都能自動(dòng)解決——Kubernetes 不是銀彈。即使是在 Kubernetes 上，一個(gè)糟糕的應(yīng)用程序還會(huì)是一個(gè)糟糕的應(yīng)用程序（實(shí)際上，甚至還可能更糟糕）。如果我們不夠小心，最后就會(huì)遇到一系列問(wèn)題：太過(guò)復(fù)雜、壓力過(guò)大、控制平面變慢、沒(méi)有災(zāi)難恢復(fù)策略。不要指望多租戶和高可用性是開箱即用的。請(qǐng)花點(diǎn)時(shí)間讓我們的應(yīng)用程序云原生化。
原文地址：
https://www.linuxprobe.com/kubernetes-10-error.html
總結(jié)
以上是生活随笔為你收集整理的避开日常Kubernetes最常见的10个坑的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 原生JS基于window.scrollT
- 下一篇： 云计算毕业设计论文：jumpserver