Helm 是 kubernetes 的包管理工具。 Helm 有一個公共 Repository ，裏面主要都是配置文件，會把 Kubernetes 服務中各種元件 yaml ，統一打包成一個叫做 Chart 的模組，然後透過 value.yaml，可用來統一管理與設定 Kubernetes ，幫助 developer 和系統管理員，更輕鬆地部署、管理和升級 Kubernetes 中的應用程式。
k8s Cluster 並不直接與 Pod 做互動，而是透過一些管理元件來處理 Pod ，這些管理元件總體被稱為 Workload，這裏介紹 DaemonSet 控制器。DaemonSet 用於提供 Node 基本設施的 Pod，會確保在所有(或是特定)節點上，一定運行著指定的一個 Pod。若想只運行在特定節點運行 DaemonSet Pod，可藉由給定的標籤，讓 Pod 可以只在特定節點上運行。
我們知道 kubernetes 的 deployment 可以生成並管理 Pod ，且盡量維持其狀態為 Running 。但有的時候我們會有只運行一次性任務的需求，這時候就可以使用 kubernetes Job。 Kubernetes Job 主要是針對短時和批量的 workload ，用於處理一次性工作，會創建一個或多個 Pod，並在該工作完成後終止這些 Pod，而不是像 deployment、DaemonSets 那樣持續運行。
kubectl 是針對 k8s cluster 的 API Server 發送命令的工具，有些指令會改變 K8s cluster 的 state 和任何對應到的環境變量。默認情況下，kubectl 在 $HOME/.kube 目錄下查找名為 config 的文件，kubectl 使用該 config 文件來查找要通訊的 K8s cluster 資料。
在上一篇文章中，簡單介紹了 Kubernetes 的架構，接下來簡介 Kubernetes 在部屬 app 時的單位 Pod 。 Pod 對多容器的支持是 K8 最基礎的設計理念，但 Pod 應該怎麼被管理呢 ? 怎麼和外網連線呢 ? 這些部分由如下元件提供功能解決 :
- Deployment
- Service
- Ingress
像在實現進階的操作如:負載均衡、滾動更新、安全與監控等概念，都會跟這些元件有關係。
從第一次聽到 Kubernetes 以來，已經有一年多了，永遠都記得 k8s 名稱的由來只是保留「開頭 K」及「結尾 S」，然後中間的英文字母數量剛好是 8 個英文字就這樣命名了…。全球三大雲服務商，AWS、Azure 和 GCP 都有提供託管 Kubernetes 集群服務( EKS、AKS、GKE )，可見其有名火熱程度。現在終於有機會在工作上碰到這項技術，就來寫些簡單筆記吧 !