cloc https://github.com/AlDanial/cloc 計算 檔案數量 / 行數 等等的工具 可以使用 docker container 來跑，就不用安裝 binary # 最後的 . 是指當前目錄，可以換成對應的目錄 docker run --rm -v $PWD:/tmp aldanial/cloc . commitizen https://github.com/commitizen/cz-cli 可以簡單產生 commitizen 的 git commit https://www.conventionalcommits.org/en/v1.0.0/ 安裝: npm install commitizen commitizen init cz-conventional-changelog --save-dev --save-exact

Core Concepts k8s 的目的是要以自動化的形式管理 container 形式的 app 讓使用者可以簡單的部署，並讓各服務的溝通可以簡單化 解說: 假設現在有兩艘船，cargo ship 和 control ship Cargo Ship 負責實際運載 container 的工作 每艘船的船長，負責管理船上的 activities，負責接收當 master 需要裝載 container 時的資訊， 並回報給 master 這艘船的狀態和 container 的狀態 Control Ship 負責監測和管理 cargo ships 透過 control plane 元件負責管理 cargo ship 的大小事 ETCD: 每天都有很多 container 要被載到 cargo ships 上，所以需要紀錄不同的船上有哪個 container，包含載入的時間 而這些是以 key-value 的形式被保存的 kube-scheduler: 當 cargo ship 來的時候，要負責判斷並把對應的 container 奘載給他 Controller manager: 指派特殊工作，例: operation team 要處理交通控制，或是 container 壞掉的時候，怎麼樣建立一個可以用的 container service office 用來讓各部門溝通，或是讓不同的船之間溝通 最高部門: kube-apiserver，各部門之間管理的最高層級，負責 Cluster 的工作協調 對應到 k8s 的名詞

What is Helm 一般來說，要 deploy 一個服務，即使是簡單的 app 也要建立一整套完整的 k8s 元件 ex: Secret, Deployment, Service, PersistentVolumeClaim… 等等，需要 apply 一堆 yaml 檔案 Helm 被稱為 k8s 的 package manager 想像一個遊戲由千百個檔案組成 我們不需要自己處理那摩多檔案，透過安裝程式的方式 做到一次安裝一個完整的遊戲，對應的檔案也都被安裝到正確的位置 而 Helm 就像這樣，一次處理一堆 YAML 檔案和 K8s 物件，來設定 application Helm 讓我們操作 k8s 的元件就像操作 app 一樣，而不是一堆檔案物件 # 透過 helm 安裝 wordpress helm install wordpress # 修改完 yaml 檔案套用 helm upgrade wordpress # 可倒退版本 helm rollback wordpress # 移除 wordpress helm uninstall wordpress # debug 資訊 helm --debug Helm2 vs Helm3 Helm3 多了

kind official page kind 可以用來在 local 建立 k8s cluster # 安裝 kind brew install kind # 建立 cluster kind create cluster # 查看 clusters kind get clusters # 查看 kind 的 kubeconfig kind get kubeconfig # 切換到 kind cluster kubectl config use-context kind-kind # 查看 cluster 狀態 kubectl cluster-info

What is GitOps 為了避免手動 deploy 而提出的解決方案 Infrastructure as Code 提倡後，大家會把 infrastructure 寫成 code 以後管控 但是針對變更 infrastructure 仍然後是在本機安裝工具後手動變更 (ex: ansible / terraform…) GitOps 提倡一切 (infrastructure/network/policy/configuration/security…) 都以 YAML 的形式放在 git 上，並且透過 PR 自動更新資源 GitOps flow Create Pull/Merge Request 任何人都可以發 PR，大家可以 review Run CI pipeline 驗證 configuration files 跑自動化測試 Approve Changes 到這步代表 code 是經過測試以及 well reviewed Run CD Pipeline merge 回 main 以後觸發 CD pipeline 部署到 aws/k8s…等等 優點:

目前看起來像是 K8S 的 CD 工具 Flux 是什麼? Flux 是一組用於 k8s 的 delivery solution Flux 提供 GitOps for apps 和 infrastructure Flux 和 Flagger 提供 canaries/feature flags/AB rollouts 來部署 app 可用來管理 k8s 資源 推 git 以後，剩下的 Flux 會處理 可套用 CD (by Flagger) 和 PD (progressive delivery) container image 發生更新後，Flux 可以自動推 git Flux 相容現有的工具 含 github/gitlab/bitbucket/s3…，以及全部有提供 cli 的 provider Flux 可用於任何 k8s 和所有常見的 k8s 工具 Kustomize/Helm/RBAC…等等 Flux 處理 multi-everything 可以處理多數個 cluster Flux 有告警和提示 只要 git push，可以得到通知 使用者信任 Flux Flux 是 CNCF 孵化出的專案 Flux 有友善的社群 任何人都可以貢獻 Flux 是一組 k8s 用的工具，可以 sync 資源設定 (像 git repository)

使用標籤 tag # 建立標籤 git tag v1.0.0 -am "description for this tag v1.0.0" # 刪除標籤 git tag -d v1.0.0 # 把標籤推到 github 上 (預設的 git push 是不推 tag 的，所以要自己下 flag 指令) git push --tags

Environment variable SHELL: 系統使用了哪種 shell 確認 OS Version # 印出所有 release 版本 # * 是指 wildcard ls /etc/*release* # 印出當前版本細節 cat /etc/*release* package managers RPM (Red Hat Package Manager) RPM 不管 dependency CentOS Red Hat Enterprise Linux Fedora package 會被包裝成 <檔名>.rpm # install package rpm -i telnet.rpm # uninstall package rpm -e telnet.rpm # query package rpm -q telnet.rpm # query all installed package rpm -qa YUM 包裝過 rpm，會順便安裝 dependency

General YAML template 必要的 4 個欄位 apiVersion:# 要用來建立物件的 k8s API 版本 kind:# 要建立的物件metadata:# 物件的其他資訊，如 name, labels...spec:# 建立物件需要的訊息 apiVersion (string) POD: v1 Service: v1 ReplicaSet: apps/v1 Deployment: apps/v1 kind (string) Pod Service ReplicaSet Deployment metadata (dictionary) name labels labels 下的 key/value 值是可以自訂的 spec (dictionary) 指令: # 可以看介紹 kubectl explain <k8s kind> POD with YAML pod-definition.yaml apiVersion:v1kind:Podmetadata:name:myapp-podlabels:app:myapptype:front-endspec:containers:- name:nginx-containerimage:nginx指令 # 建立 kubectl create -f pod-definition.

概念 Container + Orchestration k8s 是一種容器編排技術，用於協調數百個對象的部署和管理 cluster 中的數千個容器 VM vs Docker VM 是在 原本的 OS 上，再額外起來的完整的虛擬機器，具有完整的虛擬 OS 每個 VM 裡面除了 OS 外還有各自的 libs 和 deps 動輒以 GB 為單位 啟動速度慢 Docker 是基於原本的內核，起起來的 container libs 和 deps 在各自容器內 大約以 MB 為單位 啟動速度快 術語 node (minion) 安裝了 k8s 的機器，container 會起在這上面 cluster 一組複數個 nodes ( 1 個 master / 多個 worker) 會有一台 master node，負責監管和負責流程編排 node 上 的 container components 安裝 k8s 時，會安裝的一些元件 API server 可以作為 k8s 的前端 (系統操作入口) 不管是使用者對 k8s 或是 node 對 master 都是透過 apiserver 溝通 唯一可以和 etcd 溝通的元件，其他元件都必須透過 apiserver 才能訪問集群狀態 以 RESTful interface 提供外部或內部組件使用 etcd key-value store 確保 master 間沒有 conflict kubelet 每個 node 都會安裝的 agent 確保 container 可以運作在 node 上 container runtime 用來跑 container 的環境 (ex: Docker) controller manager 負責 k8s cluster 故障檢測和恢復的自動化，執行多種 controller replication controller 定期關聯 replication controller 和 pod，保證 pod 數量正確 node controller kubelet 啟動的時候會通過 apiserver 註冊自己本身節點的資訊，定時向 apiserver 報告狀態 apiserver 收到後更新到 etcd node controller 實現管理和監控 node 資訊 resourceQuota controller 用來管理使用的資源不要超過設定 namespace controller 用戶透過 apiserver 可以建立新的 namespace，存於 etcd service account controller 確保 default 的 ServiceAccount 在每個 namespace 中都存在 token controller 用來監聽 service account 的建立/刪除 和 監聽 secret 的增加/刪除 service controller 監聽 service 的變化 endpoint controller endpoint 表示了 service 對應的所有 pod 副本的位址 而 endpoint controller 是負責生成和維護所有 endpoints 的控制器，保證 service 到 pod 的對應總是最新的 orchestration 的大腦，在 nodes / containers 發生故障時發出通知和回應 決定是否建立新的 container scheduler 分配 container 給 nodes master 上 會安裝 kube-apiserver 會安裝 etcd 儲存資訊 會安裝 controller 會安裝 scheduler worker 上 會安裝 kubelet 和 master 溝通 k8s component 的 kind 種類 ConfigMap