🍀 Pod和container除了一般使用外，也有其他變化款，讓整個服務運作更加可靠

🥊 Container小幫手出動：先鋒隊友與輔助隊友

先鋒隊友 init container
有時候服務會有些前置或只執行一次的作業，像是從特定repo拉code或是確認某個東西已經建置，也就是要「排在主程式前，且需要執行完成」，並且不需要持續運行，這類的container以init containers的特別形式處理：

• 按照順序執行
• 執行失敗的話，預設重啟init container
  • Pod的restartPolicy設定為Never，則此Pod為執行失敗
  • Pod的restartPolicy設定為Always，啟動後持續運行

輔助隊友 sidecar container, helper container
通常一個Pod裡面放一個container，如果想要有「輔助」的功能，或是程式本體過於難調整等原因，可以增加container，設計成單Pod多containers，這些containers被稱為側邊掛車(sidecar) 或幫手(helper)，將主邏輯與輔助邏輯分離，降低耦合程度，因為身處同個Pod，共享空間及網路等，屬於密切合作的狀態，注意需維護主container本身與幫手container之間的對應關係

• 稱為helper containers或是sidecar containers
• 功能像是有紀錄資料(log)、監控(monitor)或是資料同步等
• 有自己的生命週期，可以在不影響主程式的情況下啟用、調整設定、停用或重啟等操作

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers: # key為initContainers, 除了probe之外，大多設置與container相同
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]

🥊 不能沒有我，靜態Pod- Static pod

在K8s中，大部分的Pod經API Server由控制平台管理，為了提高可用性，另外設計由Kubelet直接管理在特定的節點的Pod，則稱「Static pod」，通常會在 Kubelet 的配置文件中定義，並且只在特定的 Kubelet 主機上運行

• K8s叢集啟動前運行關鍵元件(e.g. etcd)，即使api-server不可用時也不影響，提高叢集可用性
• Kubelet根據staticPod目錄下的yaml檔案自動創建及更新
  • 從kubelet取得static pod檔案路徑: ps -aux | grep kubelet
    • 取得設定檔位置: --config=/var/lib/kubelet/config.yaml
    • 查看設定檔中靜態pod路徑: staticPodPath
    • kubeadm建立叢集的話，預設目錄為 /etc/kubernetes/manifests
      • 💬 有可能建立deployment或ReplicaSet嗎? kubelet存在於pod level，因此無效

感覺也很像的DaemonSet
類似replica set和static pod，DaemonSet部署pod的instances，在叢集的每個節點都有個副本(pod)，此Pod跟著節點同進退，若是移除DaemonSet, 則這些建立的Pod會一併被移除

• 使用場景: monitor agent, log collector的pod
• 運作方式: 使用nodeName, 或是採用NodeAffinity + default的scheduler(v1.12+)

REF.

• 邊車模式 (The Sidecar Pattern) - 介紹