正文

Kubernetes 已經(jīng)成為了云原生時代基礎(chǔ)設(shè)施的事實標準，越來越多的應(yīng)用系統(tǒng)在 Kubernetes 環(huán)境中運行。Kubernetes 已經(jīng)依靠其強大的自動化運維能力解決了業(yè)務(wù)系統(tǒng)的大多數(shù)運行維護問題，然而還是要有一些狀況是需要運維人員去手動處理的。那么和傳統(tǒng)運維相比，面向 Kubernetes 解決業(yè)務(wù)運維問題是否有一些基本思路，是否可以借助其他工具簡化排查流程，就是今天探討的主題。

業(yè)務(wù)問題的范疇

首先有必要明確一點，什么樣的問題算是 Kubernetes 領(lǐng)域的業(yè)務(wù)系統(tǒng)問題。Kubernetes 目前已經(jīng)是云原生時代各類 “上云” 業(yè)務(wù)系統(tǒng)所處運行環(huán)境的事實標準。

我們假定你已經(jīng)擁有了一套健壯的 Kubernetes 環(huán)境，業(yè)務(wù)系統(tǒng)的運行狀態(tài)不會受到底層運行環(huán)境異常的影響，當業(yè)務(wù)系統(tǒng)出現(xiàn)問題時，Kubernetes 也可以正確的收集到業(yè)務(wù)系統(tǒng)的運行狀態(tài)信息。

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

• 業(yè)務(wù)系統(tǒng)的規(guī)格定義問題
• 業(yè)務(wù)系統(tǒng)的調(diào)度問題
• 業(yè)務(wù)系統(tǒng)長期運行中的問題

解決這類問題的意義

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

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

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

從一份yaml開始

正常情況下，負責部署業(yè)務(wù)系統(tǒng)的工作人員是通過聲明式的配置文件來定義業(yè)務(wù)系統(tǒng)的，其中的關(guān)鍵部分稱之為規(guī)約(Spec)。這些規(guī)約字段通過格式嚴苛的 Yaml 類型配置文件來定義，正確填寫其中的鍵與值需要龐雜的 Kubernetes 知識的保障。而掌握配置文件的格式，以及配置中的內(nèi)容，往往是開發(fā)人員學(xué)習(xí)原生 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 值，然而其中一個必須使用引號，而另一個則不是，這對一些新手而言并不是很友好。而加載這份配置文件的錯誤版本時，系統(tǒng)給出的報錯雖然可以定位問題，但是交互體驗更加不友好。

$ 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 這樣的云原生應(yīng)用管理平臺中，則不會出現(xiàn)。產(chǎn)品設(shè)計之時，就已經(jīng)屏蔽了一些常見輸入錯誤，用戶不需要關(guān)注傳入值的類型問題，平臺會自行進行轉(zhuǎn)換。

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

以開啟/關(guān)閉來體現(xiàn) bool 類型：

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

借助這些功能，即使是小白用戶也可以正確的定義業(yè)務(wù)系統(tǒng)的規(guī)格。

調(diào)度過程中的問題排查

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

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

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

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

當所有的計算節(jié)點都沒有足夠的內(nèi)存資源來調(diào)度業(yè)務(wù)系統(tǒng)的 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 領(lǐng)域知識的。開發(fā)者需要從事件列表中找到關(guān)鍵詞，進而采取正確的行動來解決問題。

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

運行過程中的問題排查

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

一般情況下，正常運行中的 Pod 是體現(xiàn) Running 狀態(tài)的，開發(fā)人員可以通過命令行的方式獲取其狀態(tài)：

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

但是如果處于異常狀態(tài)，則可能得到以下結(jié)果：

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

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

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

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

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

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

Rainbond 云原生應(yīng)用管理平臺會自動記錄這一類異常狀態(tài)，并留下相應(yīng)日志供后續(xù)的分析，了解到到底是 Pod 中的哪個容器導(dǎo)致了內(nèi)存泄露。

寫在最后

基于原生 Kubernetes 進行業(yè)務(wù)系統(tǒng)的各階段問題排查，需要開發(fā)人員對 Kubernetes 知識體系有較深入的了解，并且能夠接受命令行交互式操作體驗。這無形中提升了對開發(fā)人員的技術(shù)要求，也對其強加了一些運維領(lǐng)域的工作內(nèi)容，使云原生落地體驗受阻。開發(fā)人員也不應(yīng)該拿到可以直接操作 Kubernetes 的命令行權(quán)限，這不符合安全規(guī)定。

為了能夠讓開發(fā)人員合理的調(diào)試業(yè)務(wù)系統(tǒng)，選用一款云原生管理平臺將會是個正確的選擇。云原生應(yīng)用管理平臺的設(shè)計者，深入了解過開發(fā)人員的訴求，通過為開發(fā)人員提供簡單易用的功能，以及人性化的設(shè)計，讓開發(fā)人員調(diào)試業(yè)務(wù)系統(tǒng)變得事半功倍。

以上就是詳解Rainbond云原生平臺簡化Kubernetes業(yè)務(wù)問題排查的詳細內(nèi)容，更多關(guān)于Rainbond簡化Kubernetes的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論