無(wú)論你是剛開(kāi)始使用 Kubernetes，還是正在考慮將其用于應(yīng)用程序，肯定都知道 Kubernetes 是一套強(qiáng)大的工具，可用于管理支持可伸縮、高可用性的分布式云原生應(yīng)用程序，但很多人都會(huì)犯一些常見(jiàn)錯(cuò)誤。

本文將探討使用 Kubernetes 時(shí)最常見(jiàn)的一些陷阱，并提供如何避免踩坑提示。

未設(shè)置資源請(qǐng)求

這絕對(duì)是最值得關(guān)注的點(diǎn)，在本榜單排第一位。

通常情況下，要么沒(méi)有設(shè)置 CPU 請(qǐng)求，要么設(shè)置得很低（這樣我們就能在每個(gè)節(jié)點(diǎn)上安裝大量 pod），因此節(jié)點(diǎn)會(huì)超負(fù)荷運(yùn)行。在需求旺盛時(shí)，節(jié)點(diǎn)的 CPU 會(huì)被用光，而工作負(fù)載只能獲得所請(qǐng)求的資源，CPU 會(huì)被限流(CPU throttled) ，從而導(dǎo)致應(yīng)用程序出現(xiàn)延遲、超時(shí)等情況。

BestEffort（最好不要用）：

resources: {}

非常少的CPU（最好不要）：

resources:
      requests:
        cpu: "1m"

另一方面，即使節(jié)點(diǎn)的 CPU 沒(méi)有被充分利用，CPU 限制也會(huì)對(duì) pod 的運(yùn)行造成不必要的限制，這同樣會(huì)導(dǎo)致延遲增加。

關(guān)于 Linux 內(nèi)核中的 CPU CFS 配額，以及基于 CPU 設(shè)置限制和關(guān)閉 CFS 配額的 CPU 限流，有很多討論。

CPU 限制帶來(lái)的問(wèn)題可能比解決的更多。

內(nèi)存過(guò)量使用會(huì)給我們帶來(lái)更多麻煩。達(dá)到 CPU 限制會(huì)導(dǎo)致限流，而達(dá)到內(nèi)存限制則會(huì)導(dǎo)致 pod 被殺?？吹竭^(guò) OOMkill 嗎？沒(méi)錯(cuò)，說(shuō)的就是這個(gè)。想盡量減少這種情況的發(fā)生頻率嗎？那就不要過(guò)度占用內(nèi)存，并使用Guaranteed QoS將內(nèi)存請(qǐng)求設(shè)置為等于內(nèi)存限制，就像下面的例子一樣。請(qǐng)?jiān)?nbsp;Henning Jacobs（Zalando）的演講[3]中閱讀更多相關(guān)內(nèi)容。

Burstable（更容易經(jīng)常被 OOMkilled）：

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

Guaranteed:

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

那么，在設(shè)置資源時(shí)，有什么可以幫助我們呢？

可以通過(guò) metrics-server 查看 pod（以及其中的容器）當(dāng)前的 CPU 和內(nèi)存使用情況。很可能你已經(jīng)用過(guò)了，只需運(yùn)行以下命令即可：

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

不過(guò)，顯示的只是當(dāng)前的使用情況。也很不錯(cuò)了，可以有個(gè)大致的了解，但我們最終還是希望及時(shí)看到使用指標(biāo)（從而回答以下問(wèn)題：在高峰期、昨天上午等的 CPU 使用率是多少）。為此，可以使用 Prometheus、DataDog 和其他許多工具，它們只需從metrics-server獲取指標(biāo)并存儲(chǔ)，然后就可以查詢和繪制圖表了。

VerticalPodAutoscaler[4] 可以幫助我們將這一過(guò)程自動(dòng)化，輔助我們及時(shí)查看 CPU/內(nèi)存使用情況，并根據(jù)這些情況重新設(shè)置新的資源請(qǐng)求和限制。

有效利用計(jì)算機(jī)并非易事，這就像一直在玩俄羅斯方塊。如果你發(fā)現(xiàn)自己為計(jì)算支付了高昂的費(fèi)用，而平均利用率卻很低（例如約 10%），可能需要查看 AWS Fargate 或基于 Virtual Kubelet 的產(chǎn)品，它們更多利用的是無(wú)服務(wù)器/按使用付費(fèi)的計(jì)費(fèi)模式，價(jià)格可能更便宜。

省略健康檢查

將服務(wù)部署到 Kubernetes 時(shí)，健康檢查在維護(hù)服務(wù)方面發(fā)揮著重要作用。

在 Kubernetes 環(huán)境中，健康檢查的利用率非常低??。通過(guò)健康檢查，可以密切關(guān)注 pod 及其容器的健康狀況。

Kubernetes 有三種主要工具可用于健康檢查：

• 存活檢查(Liveness Check) 允許 Kubernetes 檢查應(yīng)用程序是否存活，每個(gè)節(jié)點(diǎn)上運(yùn)行的 Kubelet 代理都會(huì)使用存活探針來(lái)確保容器按預(yù)期運(yùn)行。
• 就緒檢查(Readiness checks) 在容器的整個(gè)生命周期內(nèi)運(yùn)行，Kubernetes 使用該探針了解容器何時(shí)準(zhǔn)備好接受流量。
• 啟動(dòng)探針(startup probe) 確定容器應(yīng)用何時(shí)成功啟動(dòng)，如果啟動(dòng)檢查失敗，就會(huì)重新啟動(dòng) pod。

使用latest標(biāo)簽

這個(gè)問(wèn)題非常經(jīng)典。latest標(biāo)簽沒(méi)有說(shuō)明性，難以使用。關(guān)于在生產(chǎn)環(huán)境中使用 images:latest 標(biāo)簽的容器，Kubernetes 文檔說(shuō)得很清楚：

在生產(chǎn)環(huán)境中部署容器時(shí)，應(yīng)避免使用 :latest 標(biāo)簽，因?yàn)樗茈y跟蹤運(yùn)行的是哪個(gè)版本的映像，也很難回滾。

最近我們很少看到這種情況了，因?yàn)楹芏嗳吮粋α颂啻危虼瞬辉偈褂?latest，每個(gè)人都開(kāi)始把版本固定下來(lái)。

ECR 有一個(gè)很棒的標(biāo)簽不變性功能[5]，絕對(duì)值得一試。

容器權(quán)限過(guò)高

容器權(quán)限過(guò)高是指容器被賦予了過(guò)多的權(quán)限，比如可以訪問(wèn)普通容器無(wú)法訪問(wèn)的資源。

這是開(kāi)發(fā)人員在使用 Kubernetes 時(shí)常犯的錯(cuò)誤，而且會(huì)帶來(lái)安全風(fēng)險(xiǎn)。

例如，在 Docker 容器內(nèi)運(yùn)行 Docker 守護(hù)進(jìn)程就是特權(quán)容器的一個(gè)例子，而特權(quán)容器并不一定安全。

為避免這種情況，建議避免為容器提供 CAP_SYS_ADMIN 能力，因?yàn)樗妓袃?nèi)核漏洞的 25% 以上。

此外，避免賦予容器完整權(quán)限以及主機(jī)文件系統(tǒng)權(quán)限也很重要，因?yàn)檫@兩個(gè)權(quán)限會(huì)讓容器可以通過(guò)替換惡意二進(jìn)制文件來(lái)入侵整個(gè)主機(jī)。

為防止容器權(quán)限過(guò)高，必須仔細(xì)配置權(quán)限設(shè)置，切勿以高于所需的權(quán)限運(yùn)行進(jìn)程。

此外，通過(guò)監(jiān)控和日志來(lái)發(fā)現(xiàn)和解決問(wèn)題也很重要。

缺乏監(jiān)控和日志記錄

Kubernetes 環(huán)境中缺乏監(jiān)控和日志記錄會(huì)對(duì)其安全性和整體性能造成損害，日志記錄和監(jiān)控不足會(huì)給事件調(diào)查和響應(yīng)工作帶來(lái)挑戰(zhàn)，從而難以有效發(fā)現(xiàn)和解決問(wèn)題。

一個(gè)常見(jiàn)的陷阱是，由于缺乏相關(guān)日志或指標(biāo)，無(wú)法找到 Kubernetes 平臺(tái)和應(yīng)用程序中的故障點(diǎn)。

要解決這個(gè)問(wèn)題，必須設(shè)置適當(dāng)?shù)谋O(jiān)控和日志工具，如 Prometheus、Grafana、Fluentd 和 Jaeger，以收集、分析和可視化指標(biāo)、日志和跟蹤，深入了解 Kubernetes 環(huán)境的性能和健康狀況。

通過(guò)實(shí)施強(qiáng)大的監(jiān)控和日志記錄實(shí)踐，企業(yè)可以有效關(guān)聯(lián)信息，獲得更深入的見(jiàn)解，并克服與 Kubernetes 環(huán)境的動(dòng)態(tài)和復(fù)雜性相關(guān)的挑戰(zhàn)。

所有對(duì)象使用默認(rèn)命名空間

對(duì) Kubernetes 中的所有對(duì)象使用默認(rèn)命名空間會(huì)帶來(lái)組織和管理方面的挑戰(zhàn)。

默認(rèn)(default)命名空間是創(chuàng)建服務(wù)和應(yīng)用程序的默認(rèn)位置，除非明確指定，否則也是活躍命名空間。

完全依賴默認(rèn)命名空間會(huì)導(dǎo)致群集中不同組件或團(tuán)隊(duì)缺乏隔離和組織，從而導(dǎo)致資源管理、訪問(wèn)控制和可見(jiàn)性方面的困難。為避免這種情況，建議為不同項(xiàng)目、團(tuán)隊(duì)或應(yīng)用創(chuàng)建自定義命名空間，以便在 Kubernetes 集群內(nèi)實(shí)現(xiàn)更好的組織、資源分配和訪問(wèn)控制。

通過(guò)利用多個(gè)命名空間，用戶可以有效分割和管理資源，提高 Kubernetes 環(huán)境的整體運(yùn)行效率和安全性。

缺少安全配置

在部署應(yīng)用程序時(shí)，應(yīng)始終牢記安全性。那么，在安全方面有哪些最重要的事項(xiàng)需要考慮呢？例如，使用集群外部可訪問(wèn)的端點(diǎn)、secrets缺乏保護(hù)、不考慮如何安全運(yùn)行特權(quán)容器等。

Kubernetes 安全是任何 Kubernetes 部署不可分割的一部分。安全挑戰(zhàn)包括：

• 授權(quán) -- 身份驗(yàn)證和授權(quán)對(duì)于控制 Kubernetes 集群中的資源訪問(wèn)至關(guān)重要。
• 網(wǎng)絡(luò) -- Kubernetes 網(wǎng)絡(luò)涉及管理overlay網(wǎng)絡(luò)和服務(wù)端點(diǎn)，以確保容器之間的流量在集群內(nèi)路由的安全性。
• 存儲(chǔ) -- 確保集群中的存儲(chǔ)安全，包括確保數(shù)據(jù)不會(huì)被未經(jīng)授權(quán)的用戶或進(jìn)程訪問(wèn)。

Kubernetes API 服務(wù)器有 REST 接口，可以訪問(wèn)存儲(chǔ)的所有信息。這意味著用戶只需向 API 發(fā)送 HTTP 請(qǐng)求，就能訪問(wèn) API 中存儲(chǔ)的任何信息。為防止未經(jīng)身份驗(yàn)證的用戶訪問(wèn)這些數(shù)據(jù)，需要使用用戶名/密碼或基于令牌的身份驗(yàn)證等方法為 API 服務(wù)器配置身份驗(yàn)證。

這不僅關(guān)系到群集本身的安全，還關(guān)系到群集上的secrets和配置的安全。為了保護(hù)群集免受漏洞攻擊，需要在群集上配置一套安全控制。

利用基于角色的訪問(wèn)控制（RBAC）確保 Kubernetes 集群安全就是這樣一種強(qiáng)大的安全控制?；诮巧脑L問(wèn)控制可根據(jù)分配給用戶的角色限制對(duì)資源的訪問(wèn)，從而確保 Kubernetes 集群的安全。這些角色可以配置為"管理員(admin)"或"運(yùn)維人員(operator)"。

管理員角色擁有完整訪問(wèn)權(quán)限，而運(yùn)維人員角色對(duì)群集內(nèi)的資源擁有有限的權(quán)限。我們可以通過(guò)這種方式控制和管理訪問(wèn)群集的任何人。

缺少 PodDisruptionBudget：

當(dāng)你在 kubernetes 上運(yùn)行生產(chǎn)工作負(fù)載時(shí)，節(jié)點(diǎn)和集群時(shí)常需要升級(jí)或退役。PodDisruptionBudget (pdb) 相當(dāng)于集群管理員和集群用戶之間的服務(wù)保證 API。

確保創(chuàng)建 pdb，以避免因節(jié)點(diǎn)耗盡而造成不必要的服務(wù)中斷。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: db-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: database

作為集群用戶，可以這樣告訴集群管理員："嘿，我這里有一個(gè)數(shù)據(jù)庫(kù)服務(wù)，無(wú)論如何，我希望至少有兩個(gè)副本始終可用。"

pod的anti-affinities功能：

例如，在運(yùn)行某個(gè)部署的 3 個(gè) pod 復(fù)本時(shí)，節(jié)點(diǎn)宕機(jī)，所有復(fù)本也隨之宕機(jī)。什么意思？所有副本都在一個(gè)節(jié)點(diǎn)上運(yùn)行？Kubernetes不是應(yīng)該提供 HA 嗎？

你不能指望 kubernetes 調(diào)度器為 pod 強(qiáng)制執(zhí)行anti-affinites，而是必須顯式定義。

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

就是這樣。這將確保 pod 被調(diào)度到不同的節(jié)點(diǎn)上（僅在調(diào)度時(shí)檢查，而不是在執(zhí)行時(shí)，因此需要配置requiredDuringSchedulingIgnoredDuringExecution）。

我們討論的是不同節(jié)點(diǎn)上的 podAntiAffinity - topologyKey："kubernetes.io/hostname"，而不是不同的可用區(qū)。如果真的需要適當(dāng)?shù)?HA，請(qǐng)深入了解這一主題。

用于所有HTTP服務(wù)的負(fù)載均衡

集群中可能有很多 http 服務(wù)，希望向外部公開(kāi)。

如果將 kubernetes 服務(wù)以type: LoadBalancer對(duì)外暴露，其控制器（特定于供應(yīng)商）將提供和配置外部負(fù)載均衡器，而這些資源可能會(huì)變得很昂貴（外部靜態(tài) IPv4 地址、計(jì)算、按秒計(jì)價(jià)......），因?yàn)槲覀冃枰獎(jiǎng)?chuàng)建很多這樣的資源。

在這種情況下，共享同一個(gè)外部負(fù)載均衡器可能更有意義，可以將服務(wù)公開(kāi)為 type: NodePort類型，或者部署類似 nginx-ingress-controller（或 traefik 或 Istio）的東西作為暴露給外部負(fù)載均衡器的單個(gè) NodePort 端點(diǎn)，并根據(jù) kubernetes ingress 資源在集群中路由流量，這樣會(huì)更好。

集群內(nèi)其他（微）服務(wù)可通過(guò) ClusterIP 服務(wù)和開(kāi)箱即用的 DNS 服務(wù)發(fā)現(xiàn)進(jìn)行通信。

注意不要使用公共 DNS/IP，因?yàn)檫@可能會(huì)影響時(shí)延和云成本。

非kubernetes網(wǎng)絡(luò)感知集群自動(dòng)擴(kuò)容

在向集群添加或移除節(jié)點(diǎn)時(shí)，不應(yīng)考慮簡(jiǎn)單指標(biāo)，如節(jié)點(diǎn) CPU 利用率等。在調(diào)度 pod 時(shí)，需要根據(jù)大量調(diào)度約束條件（如 pod 和節(jié)點(diǎn)親和性、taints和tolerations、資源請(qǐng)求、QoS 等）來(lái)做出決定，如果外部自動(dòng)調(diào)度器不了解這些約束條件，可能會(huì)造成麻煩。

想象一下，有一個(gè)新的 pod 需要調(diào)度，但所有可用的 CPU 都被請(qǐng)求完了，該 pod 被卡在 "Pending" 狀態(tài)。外部自動(dòng)擴(kuò)容器看到的是當(dāng)前使用的 CPU 平均值（而不是請(qǐng)求的），因此不會(huì)觸發(fā)擴(kuò)容（不會(huì)添加新節(jié)點(diǎn)），從而造成 pod 無(wú)法被調(diào)度。

縮容（從集群中移除節(jié)點(diǎn)）總是比較困難。試想一下，有一個(gè)有狀態(tài)的 pod（附加了持久卷），由于持久卷通常是屬于特定可用性區(qū)域的資源，在區(qū)域內(nèi)沒(méi)有復(fù)本，因此自定義自動(dòng)擴(kuò)容器會(huì)移除裝有此 pod 的節(jié)點(diǎn)，而調(diào)度器無(wú)法將其調(diào)度到其他節(jié)點(diǎn)上，因?yàn)樗艿窖b有持久化存儲(chǔ)的唯一可用區(qū)的極大限制，Pod 再次卡在了 Pending 狀態(tài)。

社區(qū)正在廣泛使用 cluster-autoscaler[6]，它可在集群中運(yùn)行，并與大多數(shù)主要公有云供應(yīng)商的 API 集成，了解所有限制，并會(huì)在上述情況下進(jìn)行擴(kuò)容。它還能在不影響我們?cè)O(shè)置的任何限制條件的情況下優(yōu)雅的縮容，為我們節(jié)約計(jì)算費(fèi)用。

結(jié)論

總之，Kubernetes 是管理容器化應(yīng)用的利器，但也有自己的一系列挑戰(zhàn)。為避免常見(jiàn)錯(cuò)誤和陷阱，必須密切關(guān)注與 Kubernetes 的交互，并了解與已部署服務(wù)的交互方式之間的差異。

不要指望一切都能自動(dòng)運(yùn)行，要投入一些時(shí)間讓?xiě)?yīng)用成為云原生的。通過(guò)避免這些錯(cuò)誤，高效完成 Kubernetes 部署，并提高 Kubernetes 環(huán)境的穩(wěn)定性、性能和安全性。

參考資料：

[1]Most common mistakes to avoid when using Kubernetes: Anti-Patterns: https://medium.com/@seifeddinerajhi/most-common-mistakes-to-avoid-when-using-kubernetes-anti-patterns-%EF%B8%8F-f4d37586528d

[2]Kubernetes Practical Exercises Hands on: https://github.com/seifrajhi/Kubernetes-practical-exercises-Hands-on

[3]Optimizing Kubernetes resource requests/limits for cost efficiency and latency high load: https://www.slideshare.net/try_except_/optimizing-kubernetes-resource-requestslimits-for-costefficiency-and-latency-highload

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

[5]Amazon ECR now supports immutable image tags: https://aws.amazon.com/about-aws/whats-new/2019/07/amazon-ecr-now-supports-immutable-image-tags

[6]cluster-autoscaler: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler