在k8s中部署應用遇到的問題

目錄

1 背景

2 集合

1) 通過Helm方式部署有關聯的應用時報錯

2) 增加一個初始容器做“前鋒”

3) 容器中Hook

4) Helm中變量的使用

5）增加健康檢查

3.其他參考資料

1 背景

前面幾篇部落格已經寫過如何安裝k8s，以及相關資源或元件。基于這些基礎設施，繼續往上，便是部署應用（廣義）了。這裡記錄在部署過程中遇到的一些問題或者經驗總結。

2 集合

1) 通過Helm方式部署有關聯的應用時報錯

期望：部署Service，StatefulSet，待Pod就緒之後，再真正執行Job。

問題：Job在Service和StatefulSet還未完全就緒後，就已經執行完成。

解決方案：

A.首先需要了解Helm部署chart時的生命周期：

• 使用者運作

  helm install foo

• chart 被加載到服務端 Tiller Server 中
• 經過一些驗證，Tiller Server 渲染 foo 模闆
• Tiller 将産生的資源加載到 kubernetes 中去
• Tiller 将 release 名稱和其他資料傳回給 Helm 用戶端
• Helm 用戶端退出

B.Helm Hook的作用：

簡單來說，就是通過Hooks幹擾上述生命周期的一些過程。具體措施可以通過3個方面進行：

• 不同的Hook類型
  • pre-install：在模闆檔案被渲染之後、而在Kubernetes建立任何資源建立之前執行。
  • post-install：在Kubernetes加載全部的資源之後執行。
  • pre-delete：在Kubernetes删除任何resource之前執行。
  • post-delete：在一個release的全部資源被删除之後執行。
  • pre-upgrade：在模闆渲染之後，而在Kubernetes加載任何資源之前執行。
  • post-upgrade：在Kubernetes更新完全部resource之後執行。
  • pre-rollback：在模闆被渲染之後、而在Kubernetes執行對全部resource的復原之前。
  • post-rollback：在Kubernetes的全部resource已經被修改之後執行。
  • crd-install：在運作其他檢查之前添加CRD資源，隻能用于chart中其他的資源清單定義的 CRD 資源。
• Hook的權重
  • 由負到正、從小到大 預設權重：預設為0
• Hook的删除
  • “hook-succeeded” ：指定Tiller應該在hook成功執行後删除hook。
  • “hook-failed” ：指定如果hook在執行期間失敗，Tiller應該删除hook。
  • “before-hook-creation” ： 指定Tiller應在删除新hook之前删除以前的hook。

C.Hooks在Job中的聲明，參考下方問題二中的腳本示例。

D.部署的指令：

# helm install <helm name> <chart name> -n <namespace> --wait
           

E.參考資料：

https://github.com/SecurityNeo/ReadingNotes/blob/master/PaaS/Helm/Helm.md  -- Helm官方文檔

https://blog.csdn.net/hxpjava1/article/details/86647706 -- 網友的Helm Hooks簡單實踐

2) 增加一個初始容器做“前鋒”

從某種角度來說，這也算是上述問題一的一種解決方案，隻是不能算最佳。原因是：這裡由于業務特殊性，無其他等待方式，隻能Sleep固定時間。這就導緻這種等待“不靠譜”。

換做其他業務場景，也可以是一種不錯的方式，是以記錄在此。

增加一個初始容器，在容器中做時間處理，如sleep，調用某個其他已知業務接口，執行某些腳本等。幹擾該Pod的就緒時間。

apiVersion: v1
kind: Job
metadata:
  name: myJob
  namespace: myNameSpace
  # Hook的聲明
  annotations:
    "helm.sh/hook": post-install
    "helm.sh/hook-weight": "5"
    "helm.sh/hook-delete-policy": before-hook-creation
spec:
  template:
    metadata:
      name: myJob
    spec:
      restartPolicy: Never
      initContainers:
      - name: myInit
        image: 10.0.45.123:5000/alpine:3.9.5
        command: ["/bin/sh","-c","sleep 5"]
      containers:
      - name: myJob
        image: 10.0.45.123:5000/alpine:3.9.5
        command:
...
        
           

3) 容器中Hook

這個也實踐過，不過同樣不适用于目前業務需要，但也是一個參考：

https://blog.csdn.net/wang725/article/details/90719429

https://www.cnblogs.com/wuchangblog/p/13409485.html

4) Helm中變量的使用

Helm中有3個重要的概念：

• helm：指令行用戶端工具，類似kubectl。主要用于k8s應用chart的建立、打包、釋出和管理。
• chart：可簡單看做一組yaml檔案，是一系列用于描述k8s資源相關檔案的集合。
• release：基于chart部署實體，應用級别的版本管理。通過helm執行一個chart後，就會生成對應的一個release，并在k8s中建立出真實的資源對象。

Chart模闆中有一定的檔案結構，不同的檔案有不同的作用。可參考：

https://blog.csdn.net/twingao/article/details/105188730

https://www.it610.com/article/1281815336882028544.htm

https://blog.csdn.net/kozazyh/article/details/81747903

https://www.it610.com/article/1281815336882028544.htm

5）增加健康檢查

這個是k8s的基礎了，自己也不是特别了解，隻能結合自己業務的特點，選擇了其中一種方式，增加了存活和就緒檢查，供參考。

...

    containers:
    - name: myService
      image: 10.0.45.123:5000/busyboy
      ports:
      ...
      env:
      ...
      livenessProbe:
        tcpSocket:
          port: 1099
        initialDeplaySeconds: 3
        periodSeconds: 2
      readinessProbe:
        tcpSocket:
          port: 1099
        initialDelaySeconds: 3
        periodSeconds: 2
           

參考：

https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/  -- 官方文檔

https://blog.csdn.net/weixin_39534208/article/details/112219228   -- 網友實踐

3.其他參考資料

https://blog.csdn.net/weixin_43757555/article/details/108418821   -- Helm自定義模闆

https://blog.csdn.net/a772304419/article/details/113589534   -- configmap挂載到pod