要如何直面到 Kubernetes 所帶來的技術 影響力? Phil Huang 黃秉鈞 MOPCON 2022, Oct. 16, 2022

#pichuang # whois Phil Huang 黃秉鈞 ● Cloud Native Taiwan User Group (CNTUG) 打雜工 ● 現任 Microsoft Sr. Cloud Solution Architect ● 曾任 VMware / Red Hat 解決方案架構師 ● 專長為混合雲 IT 基礎建設之設計規劃與實踐部署 ● blog.pichuang.com.tw Ref: https://www.linkedin.com/in/phil-huang-09b09895/ 2

#pichuang Cloud Native Taiwan User Group ● 體諒大家手機空間有限， 簡報會後會完整提供至 Cloud Native Taiwan User Group ● 會後想要交流問題的朋友 可以至開放文化基金會 (Open Culture Foundation, OCF) 或開源 人年會 (COSCUP) 攤位找 我

#pichuang

#pichuang Kubernetes 帶來的現象級影響 應用程式容器化 (Containerized) 加速普及 無論是業務服務、平台服務，都可 以盡可能依循 OCI 標準將服務打 包成一個個容器映像檔 (Container Images)，為了更快速 地且更穩定提供服務交付 採用 Open Source 軟體相較以往 更盛行 透過應用程式容器化的作法，讓應 用程式跟平台從以前強耦合性變 成低耦合性，故很多實踐只要能包 成容器基本上運行不是太大的問 題 以 Kubernetes 為核心，技術語言 趨於一致 無論你是 AppDev / Infra / Network / Security 地端還是雲端 人員，使用的用詞都是環繞在 Kubernetes 用字為主

#pichuang 應用程式容器化 常見挑戰 (1/2) AppDev: 如何把應用服務包成 Container Image Infra: 如何持續提供穩定運行的 OS 和 Container Engine? ● 容器化使用和容器平台學習路徑分 ˇ 4 個等級 ○ Level 0: 敵不動我不動~ ○ Level 1: 應用程式容器化，偏 AppDev ○ Level 2: 基於 Level 1，採用 docker-compose 做 IaC，偏 AppDev ○ Level 3: 改寫 Level 2，將容器映像檔放到 Kubernetes 上運行，AppDev 和 Infra 兩者都有

#pichuang 應用程式容器化 常見挑戰 (2/2) ● 會使用 Docker 跟會使用 Kubernetes 之間，是有一個很大的學習曲線需要克服 ● 對於第一次接觸者，建議參考 CNCF CKA / CNCF CKAD 先入手學習，主要熟悉 kubectl 跟基本 Kubernetes 術語，其他進階的再依需求深入看 AppDev: 如何將部署服務改寫成 YAML Infra: 如何穩定地提供 Kubernetes 平台 CNCF: Cloud Native Computing Foundation CKA: Certification Kubernetes Administrator CKAD: Certification Kubernetes Application Developer

#pichuang CNCF 花花綠綠的開源專案們 整個專案市值現為 $18.1 兆美元

#pichuang OpenSource 軟體採用 常見挑戰 (1/3) ● CNCF 專案超多該怎麼選? ● 常見軟體開發生命週期 (Software Lifecycle) 分為 3 個階段 ○ Day 0 Design: 設計架構 ○ Day 1 Build: 安裝設定 ○ Day 2 Operate: 維護，包含漏洞修補、更新、效能調教 ● 會安裝系統跟會維護系統之間，是有一個很大的學習曲線需要克服

#pichuang OpenSource 軟體採用 常見挑戰 (2/3) ● CNCF 專案 3 個等級 ○ Graduated Projects: 優選，起碼有 2 家以上參與，有完善的貢獻流程和較廣泛的採用程度 ○ Incubating Projects: 次選，有些專案討論度不小，可以實際上看專案活躍度決定 ○ Sandbox Projects: 下選，一律採取觀望態度 Ref: https://github.com/cncf/toc/blob/main/process/graduation_criteria.md

#pichuang OpenSource 軟體採用 常見挑戰 (3/3) ● 對非 R&D 的職能來講，何謂對 OOXX 開源專案很熟? ○ 很熟不是只會安裝和設定就好 ○ 會不會除錯 (Troubleshooting) 才是判斷熟悉與否的依據 ● 要多了解專案底層細節運作時的行為和相依性，無論是正常還是不正常運作，尤其是跟網路有關的

#pichuang kubectl Anywhere Docker / Containerd / CRI-O Operating System Vendor Storage Provider External Network Provider Kubernetes API (v1.2x) kubectl apply -f xxoo.yaml kubectl top kubectl get service AppDev SRE Infra kubectl get networkpolicy Network Container Runtime Interface Container Network Interface Container Storage Interface Cilium / Calico / OVN Vendor Specific Driver IaaS Provider: Baremetal / VMware / Azure / AWS / GCP …

#pichuang 採用 Kubernetes 常見挑戰 ● 其實安裝和使用 Kubernetes 本身不難，是非 Kubernetes 範圍的排列組合太多導致整合有高度困 難 ○ 譬如: 如何選擇 OS / Load Balancer / Storage / CNI / Security 策略等等 ● 角色不同，挑戰不同 ○ 如果你是 AppDev Eng.，你的煩惱應該是怎麼把程式寫出來、 Kubernetes YAML 和應用程式 容器化搞好 ○ 如果你是 Infra Eng.，除了 AppDev 的範圍都算在這個角色身上...尤其是整合相關的問題，這 也是為什麼能用雲端代管 (Managed Service) 或地端花錢解決方案的服務會是常見作法 ○ 如果你是 Security Eng.，過去的地端規則不一定可以全套用在現在的雲端世界 ○ 如果你是 Network Eng.，無論是不是在 Kubernetes 內還是外，只要網路不通還是會找你... ● 身為一個混合雲工程師，如何應對挑戰?

#pichuang 沒有不掛的系統 ● 以混沌工程 (Chaos Engineering) 原則為理論基礎，建立驗證 範圍，獲取除錯經驗 ● 一個新的服務或方案來，我通常會... ○ 了解以各組件的爆炸半徑 ■ 當系統掛掉的時候行為模式是如何? ■ 正常的行為模式是什麼? ■ 怎麼以第三方手段測試證明系統狀態? ○ 收集可重複驗證的測試手法 ■ 建立 Baseline (Hello World / Ping) ■ 提供重現手法及狀態證明 ○ 思考災害復原 (BCDR) 手段 ■ RTO: 我可以接受服務掛掉多久 ■ RPO: 我可以接受資料噴掉多久 Ref: https://learn.microsoft.com/zh-tw/azure/architecture/framework/resiliency/chaos-engineering BCDR: Business Continuity and Disaster Recovery

#pichuang 這是一個基本 Kubernetes 架構圖

#pichuang 清晰地 IT 架構圖可以大量減少溝通障礙 Ref: https://techcommunity.microsoft.com/t5/fasttrack-for-azure/azure-red-hat-openshift-reference-architecture-amp-reference/ba-p/3470115

#pichuang Recap ● 之後新建立專案，提供 Container Images 及 Kubernetes YAML (或 docker-compose.yaml) 會是 新常態 ● OpenSource 百花齊放，你很難找到一個人什麼專案都會也會修，不如選擇性參與業務關鍵專案 運作，集社群眾人智慧一起討論和貢獻回饋，也能延續整體人才培育 ● Kubernetes 是一個集很多既有 IT Infra 技術為一體的平台 ○ 現況是對很多 Infra 人員有相當大的學習曲線挑戰，建議當它是一個新的作業系統 (Cloud OS) 學習會是較好的心態 ○ Kubernetes 雖然看似需要學習的東西很多，但實際上核心運作原理這幾年沒太大變化，投 資學習為時不晚