Rainbond云原生平臺簡化Kubernetes業務問題如何排查

本篇內容主要講解“Rainbond云原生平臺簡化Kubernetes業務問題如何排查”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Rainbond云原生平臺簡化Kubernetes業務問題如何排查”吧!

業務問題的范疇

首先有必要明確一點，什么樣的問題算是 Kubernetes 領域的業務系統問題。Kubernetes 目前已經是云原生時代各類 “上云” 業務系統所處運行環境的事實標準。

我們假定你已經擁有了一套健壯的 Kubernetes 環境，業務系統的運行狀態不會受到底層運行環境異常的影響，當業務系統出現問題時，Kubernetes 也可以正確的收集到業務系統的運行狀態信息。

有了這假定條件之后，我們就可以將業務系統問題約束在業務從部署到正常運行起來這一時間區間內。所以本文探討的業務系統問題的范疇包括：

• 業務系統的規格定義問題

• 業務系統的調度問題

• 業務系統長期運行中的問題

解決這類問題的意義

解決這一類的問題的意義是顯而易見的，因為將業務系統運行起來是一種最基礎的需求。具備一套健壯的 Kubernetes 運行環境或者是編寫了一套業務系統代碼都不會為我們產生直接的價值。只有將業務系統代碼運行到一個穩定的環境中，面向最終用戶提供服務時才會為我們產生真正的價值。

值得慶幸的是，解決這類問題多半只需要我們踩一次坑。對于大多數全新的業務系統而言，部署到 Kubernetes 環境中去時，所可能遭遇的問題只需要被處理一次。一旦部署完成，業務系統就可以專注于迭代功能，不斷循環完成發布過程即可，順利進入了一個循環往復的 CI/CD 流程之中。

除去基礎需求這一顯而易見的意義，我們也會探討如何降低解決這類問題的難度，解決問題難度的降低本身也具有意義。云原生時代，我們倡導每個開發人員都能夠掌控自己的業務系統，這種掌控也對開發人員提出了新的要求，即掌控 Kubernetes 的使用。這有點將運維層面的工作附加給開發人員的意思，實際推廣過程并不順利。為了便于開發人員使用 Kubernetes 來部署與調試自己開發的業務系統，企業可以選擇云原生應用平臺來降低開發人員使用 Kubernetes 的門檻，Rainbond 就是這樣一款云原生應用管理平臺，其易用性的特點降低了開發人員的學習門檻，同時能夠為業務系統賦能。

從一份yaml開始

正常情況下，負責部署業務系統的工作人員是通過聲明式的配置文件來定義業務系統的，其中的關鍵部分稱之為規約(Spec)。這些規約字段通過格式嚴苛的 Yaml 類型配置文件來定義，正確填寫其中的鍵與值需要龐雜的 Kubernetes 知識的保障。而掌握配置文件的格式，以及配置中的內容，往往是開發人員學習原生 Kubernetes 的首個陡峭門檻。

原生的使用方式中，kubectl 命令行工具會為這些配置文件提供嚴苛的校驗機制，然而在校驗無法通過時，能夠給出的提示卻并不是很友好。

以一份非常簡單的 Yaml 配置文件為例：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: my-nginx
  name: my-nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      labels:
        app: my-nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        env:
        - name: DEMO_GREETING
          value: "true"  # 此處必須用引號擴起來，因為這是個 string 類型
        securityContext:
          privileged: true # 此處必須不能使用引號，因為這是個 bool 類型

配置中有兩個 true 值，然而其中一個必須使用引號，而另一個則不是，這對一些新手而言并不是很友好。而加載這份配置文件的錯誤版本時，系統給出的報錯雖然可以定位問題，但是交互體驗更加不友好。

$ kubectl apply -f my-deployment.yaml
Error from server (BadRequest): error when creating "my-deployment.yaml": Deployment in version "v1" cannot be handled as a Deployment: v1.Deployment.Spec: v1.DeploymentSpec.Template: v1.PodTemplateSpec.Spec: v1.PodSpec.Containers: []v1.Container: v1.Container.Env: []v1.EnvVar: v1.EnvVar.Value: ReadString: expects " or n, but found t, error found in #10 byte of ...|,"value":true}],"ima|..., bigger context ...|ainers":[{"env":[{"name":"DEMO_GREETING","value":true}],"image":"nginx","name":"nginx"}]}}}}

像這樣的問題，在類似 Rainbond 這樣的云原生應用管理平臺中，則不會出現。產品設計之時，就已經屏蔽了一些常見輸入錯誤，用戶不需要關注傳入值的類型問題，平臺會自行進行轉換。

平臺會自動為環境變量添加引號以匹配 string 類型：

以開啟/關閉來體現 bool 類型：

對于一些特殊輸入，也會進行合理校驗，提供的反饋信息更加人性化：

借助這些功能，即使是小白用戶也可以正確的定義業務系統的規格。

調度過程中的問題排查

業務系統的規格定義完成后，就可以提交給 Kubernetes 系統了，下一步，Kubernetes 將會借助自身調度機制，將業務系統分配到合適的宿主機上運行起來。在進行調度的過程中，業務系統會在一小段時間內處于 Pending（待定的） 的狀態，然而長期處于 Pending 狀態則說明調度過程中出現了問題。

Kubernetes 以事件的形式，記錄了業務系統在進入運行狀態之前的每一個步驟。一旦出現了 Warning 甚至更嚴重級別的事件時，就說明業務系統的部署過程受阻了。了解如何查看這些事件，并理解其背后代表的意義，對于排查調度問題非常有幫助。

能夠讓業務系統長期處于 Pending 狀態的常見問題包括：鏡像拉取失敗、資源不足等。使用原生 Kubernetes 時，難免和命令行打交道，來獲取對應 Pod 的事件信息。

$ kubectl describe pod <podName> -n <nameSpace>

當所有的計算節點都沒有足夠的內存資源來調度業務系統的 Pod 時，事件信息是這樣的：

Events:
  Type     Reason            Age        From               Message
  ----     ------            ----       ----               -------
  Warning  FailedScheduling  <unknown>  default-scheduler  0/3 nodes are available: 3 Insufficient memory.

而拉取鏡像失敗則是這樣的：

Events:
  Type     Reason     Age                From                              Message
  ----     ------     ----               ----                              -------
  Warning  Failed     26s                kubelet, cn-shanghai.10.10.10.25  Error: ErrImagePull
  Normal   BackOff    26s                kubelet, cn-shanghai.10.10.10.25  Back-off pulling image "nginx_error"
  Warning  Failed     26s                kubelet, cn-shanghai.10.10.10.25  Error: ImagePullBackOff
  Normal   Pulling    15s (x2 over 29s)  kubelet, cn-shanghai.10.10.10.25  Pulling image "nginx_error"

對事件列表的解讀，是需要較深厚的 Kubernetes 領域知識的。開發者需要從事件列表中找到關鍵詞，進而采取正確的行動來解決問題。

在 Rainbond 云原生應用管理平臺中，已經事先想到了降低問題排查成本的需求，用戶點擊代表有問題的業務系統 Pod 的方塊，即可了解其詳細信息。在這個頁面中，濃縮了核心問題的說明、當前 Pod 的狀態以及說明，可以幫助用戶極快的定位問題。

運行過程中的問題排查

當業務系統完成了調度過程后，Kubernetes 系統就會將業務系統對應的 Pod 啟動起來，到這里，已經距離業務系統對外提供服務很近了。但是不要掉以輕心，Pod 啟動時是有可能遭遇運行異常的。

一般情況下，正常運行中的 Pod 是體現 Running 狀態的，開發人員可以通過命令行的方式獲取其狀態：

$ kubectl get pod <podName> -n <nameSpace>

但是如果處于異常狀態，則可能得到以下結果：

NAME                                 READY   STATUS             RESTARTS   AGE
demo-test-my-nginx-6b78f5fc8-f9rkz   0/1     CrashLoopBackOff   3          86s

CrashLoopBackOff 是一種異常的狀態，除此之外還可能出現一些其他的異常狀態，比如：OOMkilled 、 Evicted等。對于每一種錯誤類型的處理也不盡相同。這需要非常豐富的 Kubernetes 問題排查經驗。

比如對于 CrashLoopBackOff 這種異常狀態，它意味著 Pod 中的某個容器無法正常運行，代碼運行過程中遭遇了不可容忍的問題，報錯退出了。正確的處理，是應該查詢問題 Pod 的日志，了解業務代碼層面的異常。

$ kubectl logs -f <podName> -n <nameSpace>

這種排查的思路是可以固化的，與所部署的業務系統本身沒有關系，所以 Rainbond 云原生應用管理平臺做了一些人性化的設計，如果業務系統的 Pod 處于這種異常狀態并被操作記錄捕獲，那么用戶點擊這條異常的操作記錄，即可直接跳轉到日志頁面查看問題日志。這種設計隱式的為用戶提供了排查思路，即使用戶自己并沒有意識到應該這么做。

還有一種特殊類型的運行過程中問題需要注意。 CrashLoopBackOff 這種問題一般出現在 Pod 啟動時，用戶很容易就可以捕捉到，而類似于 OOMkilled 這種問題一般是在業務系統運行很久之后，才會出現。這種問題不容易被用戶捕捉到，這是因為 Kubernetes 會自動重啟出現這類問題的業務系統 Pod 來自動恢復，從而導致問題的湮沒。

Rainbond 云原生應用管理平臺會自動記錄這一類異常狀態，并留下相應日志供后續的分析，了解到到底是 Pod 中的哪個容器導致了內存泄露。

到此，相信大家對“Rainbond云原生平臺簡化Kubernetes業務問題如何排查”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！