正文

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

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

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

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

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

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

解決這類(lèi)問(wèn)題的意義

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

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

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

從一份yaml開(kāi)始

正常情況下，負(fù)責(zé)部署業(yè)務(wù)系統(tǒng)的工作人員是通過(guò)聲明式的配置文件來(lái)定義業(yè)務(wù)系統(tǒng)的，其中的關(guān)鍵部分稱(chēng)之為規(guī)約(Spec)。這些規(guī)約字段通過(guò)格式嚴(yán)苛的 Yaml 類(lèi)型配置文件來(lái)定義，正確填寫(xiě)其中的鍵與值需要龐雜的 Kubernetes 知識(shí)的保障。而掌握配置文件的格式，以及配置中的內(nèi)容，往往是開(kāi)發(fā)人員學(xué)習(xí)原生 Kubernetes 的首個(gè)陡峭門(mén)檻。

原生的使用方式中，kubectl 命令行工具會(huì)為這些配置文件提供嚴(yán)苛的校驗(yàn)機(jī)制，然而在校驗(yàn)無(wú)法通過(guò)時(shí)，能夠給出的提示卻并不是很友好。

以一份非常簡(jiǎn)單的 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"  # 此處必須用引號(hào)擴(kuò)起來(lái)，因?yàn)檫@是個(gè) string 類(lèi)型
        securityContext:
          privileged: true # 此處必須不能使用引號(hào)，因?yàn)檫@是個(gè) bool 類(lèi)型

配置中有兩個(gè) true 值，然而其中一個(gè)必須使用引號(hào)，而另一個(gè)則不是，這對(duì)一些新手而言并不是很友好。而加載這份配置文件的錯(cuò)誤版本時(shí)，系統(tǒng)給出的報(bào)錯(cuò)雖然可以定位問(wèn)題，但是交互體驗(yàn)更加不友好。

$ 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"}]}}}}

像這樣的問(wèn)題，在類(lèi)似 Rainbond 這樣的云原生應(yīng)用管理平臺(tái)中，則不會(huì)出現(xiàn)。產(chǎn)品設(shè)計(jì)之時(shí)，就已經(jīng)屏蔽了一些常見(jiàn)輸入錯(cuò)誤，用戶(hù)不需要關(guān)注傳入值的類(lèi)型問(wèn)題，平臺(tái)會(huì)自行進(jìn)行轉(zhuǎn)換。

平臺(tái)會(huì)自動(dòng)為環(huán)境變量添加引號(hào)以匹配 string 類(lèi)型：

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

對(duì)于一些特殊輸入，也會(huì)進(jìn)行合理校驗(yàn)，提供的反饋信息更加人性化：

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

調(diào)度過(guò)程中的問(wèn)題排查

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

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

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

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

當(dāng)所有的計(jì)算節(jié)點(diǎn)都沒(méi)有足夠的內(nèi)存資源來(lái)調(diào)度業(yè)務(wù)系統(tǒng)的 Pod 時(shí)，事件信息是這樣的：

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"

對(duì)事件列表的解讀，是需要較深厚的 Kubernetes 領(lǐng)域知識(shí)的。開(kāi)發(fā)者需要從事件列表中找到關(guān)鍵詞，進(jìn)而采取正確的行動(dòng)來(lái)解決問(wèn)題。

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

運(yùn)行過(guò)程中的問(wèn)題排查

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

一般情況下，正常運(yùn)行中的 Pod 是體現(xiàn) Running 狀態(tài)的，開(kāi)發(fā)人員可以通過(guò)命令行的方式獲取其狀態(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等。對(duì)于每一種錯(cuò)誤類(lèi)型的處理也不盡相同。這需要非常豐富的 Kubernetes 問(wèn)題排查經(jīng)驗(yàn)。

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

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

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

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

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

寫(xiě)在最后

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

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

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

最新評(píng)論