Kubernetes Weekly News 2019 W24

重點整理

本次的 K8S 週報主要是收集本年第 23 和 24 週網路聲量較大的文章，涵蓋有不少如何去管理甚至是監測 K8S 的文章，其中當然 Operator 的使用和介紹還是少不了，還有一些是討論 K8S 內應用程式如何達成 CI/CD ，以及推出一些工具來幫助喜歡在 Terminal 環境做事情的人，各種大家可能已經耳熟能響的服務如何部署在 K8S 內的教學文…等

K8S 監測方式

圖片來源 Denise Yu (@deniseyu21)

Sysdig 定義了 K8S 中的 Golden Signals 是什麼並且要如何去監測它們，而為什麼它們這麼的重要？因為在 Microservice 的架構下有太多的 Metrics，所以應該要如何化繁為簡，並從使用者和顧客的角度來看，將潛在會影響到應用服務的問題給直接揪出來，先提到需要被監測的東西有…

1. Latency: 應用服務回應一個請求所需要的時間，而看平均值不是一個妥當的做法，應該要去觀察 Latency 真實的分佈數據
2. Errors: 應用服務回應的錯誤率，譬如 HTTP 在 Header 中的 Error Status Code, 而推薦的做法是以每秒發生的頻率來觀察
3. Traffic/Connections: 應用服務在單位時間內的被使用狀況，它可以是 API 被調用的次數，也可以是串流服務的流量大小
4. Saturation: 應用服務的飽和程度，其實也就是應用服務最大乘載能力，不同系統會有不同的衡量方式，最常見的做法可以使用 CPU/Memory，當衡量的指標假如超過 80 % 的話，就應該要有告警通知被發送出來

接著提到除了 Golden Signals 之外，還比較另外兩種做法，分別是 RED method (只用從外部使用服務的觀點來監測，忽略系統方面的 Metric) 和 USE method (只著重在於資源的使用情況)；最後提到在 K8S 的架構下要如何收到 Golden Signals，首先可以修改程式碼讓 Prometheus 可以收到重要的 Metric 資料，利用 eBPF 協定取得所有系統的 System Call 資訊，或是使用 APM (Application Performance Monitoring) 直接取得應用程式資訊，並可以搭配 Istio 來輕易取得 Golden Signals 所需要的資訊，最後再用一個簡單的例子做收尾…詳全文 (How to monitor Golden signals in Kubernetes)

K8S 自動化部署

圖片來源 dailymotion

• Dailymotion 三年前開始使用 K8S，然而將應用服務部署於多個 K8S 叢集中是個不小的挑戰，他們的做法是使用 Helm (提到 Helm 3 可以解決很多他們目前遇到的問題)，並將所有的 Charts 放在同一個 Git Repository，其中有一個稱為 umbrella 的 chart 用來定義整個應用服務會使用到的相依 Chart，並使用自己刻劃的 Python Script 疊在 Helm 之上去處理各種有關 Helm 的相關事務；提完大方向後，作者更深入的介紹實作方式，這邊提到他們如何使用 Git Branching Workflow 來開發 Helm Charts，怎麼使用 Cluster Federation 管理不同的 K8S 叢集 (目前該公司服務行跨六個區域，三個是自建機房，三個是公有雲)，另外使用 Vault 來處理 Credentials，最後提到整個流程設計的原因及其限制…詳全文 (Deploying apps on multiple Kubernetes clusters with Helm)

圖片來源 The Startup

• 接下來提到的只適合 AWS 深度整合者參考，因為作者整個 CICD 架構使用 AWS CodePipeline, CodeBuild 和其他的 AWS 服務，例如 Lambda, ECR, S3…等，而再不同的 Project 間一定都有有三個基本的元件，1) AWS CodeBuild 的檔案 2) 應用程式的 Dockerfile 3) K8S 資源的 YAML 檔案，整個流程不複雜，透過 GitHub Webhook 觸發 API Gateway 讓 Lambda 將程式碼儲存到 S3 中，然後再透過 Dockerfile Build 出 Docker，最後在使用定義好的 K8S YAML 檔案將應用程式部署到 K8S 中…詳全文 (Universal CICD pipeline for K8S on AWS)

圖片來源 The Startup

• 談到 CI/CD 很多人會直接回答 Jenkins，雖然老爺爺相當的成熟，不過他缺乏創新，而且有點肥，Spinnaker 也可以說是一樣的狀況，兩者對於企業用戶來說或許不錯，但並不是可以用很簡單的方式將 CI/CD 快速建立完成的工具，所以作者決定選擇支援簡易的 Workflow 以及 Canary 部署的 Argo，其透過定義一個新的 K8S CRD 稱為 Workflow，在 Workflow 中利用 YAML 檔案再去定義 CI/CD 的步驟；而在 Argo 項目中主要分三個部分 1) Argo: 主要項目，負責在 K8S 中的 Wrokflow 2) Argo CD: 使用 GitOps 的方式來處理部署和 Git Repository 3) Argo CI: 目前看起來沒有在維護了，本來應該要充當的事 CI 的角色…詳全文 (CI/CD with Argo on Kubernetes)

K8S 維運不再苦

圖片來源 The Graphical Terminal

圖片來源 kubeasy

• 在有關 Terminal 的工具方面，這週多了兩個生力軍，分別是 kui 和 kubeasy，兩個其實想要達成的目的我覺得有點像，都是希望使用者在 terminal 介面之下可以獲得更多 K8S 更多的資訊，然後利用這些資訊來做更多事，兩者看起來最大的不同在於 kui 看起來把網頁都內嵌進來了，所以可以用指標去做操作，相較之下 kubeasy 是相對單純的 cli 工具
• 近來資安的需求越來越被重視，因此架設在 K8S 內需要被外部存取的服務該如何支援 SSL/TLS 又再度有人提到，有人使用 cert-manager Operator 來保護其使用 Moodle 架設在 K8S 中的線上教育平台系統，也看到有透過 K8S Job 引用 acme.sh 來達成的方式，兩者都是借助於 Let’s Encrypt 平台來完成其支援 SSL/TLS 的目標；而不該被外部存取的服務，就應該放在內網，而不是讓他在外面拋頭露面，不過還是可以看到新聞說有將近 40,000 個含有個人資料的 K8S 和 Container 暴露在網路上…

圖片來源 dailymotion

• Dailymotion 三年前為了求快速佈建其服務，所以選擇了 GKE，為了降低 Latency 所以跨了三個 Region 架設其服務；不過隨著成本的上升，他們在將近一年後決定也要開始研發自己的資料中心，讓整個架構變成 Hybrid Cloud；在將近兩年的建置後，他們已經有信心可以將部分的流量從 GKE 導流到自己的資料中心，目前公司服務的最前面是透過 AWS Route53 在幫忙決定流量的方向，未來希望繼續透過 Hybrid Cloud 的架構來降低成本並且提升使用這體驗
• 自己認為最會寫安裝教學文章的 DigitalOcean 發文述說當使用他們的 K8S 託管服務時，如何利用 ExternalDNS 來讓 DigitalOcean DNS 變成 K8S 叢集內的 DNS 提供者，讓本來需要手動增加 DNS Record 的行為消失，一切變成自動化，而在其另外一篇文章則是提到要如何去架設和使用 Istio
• 而相信大家都知道 K8S 有一個叫做 HPA (Horizontal Pod Autoscalers) 的功能，有網友示範了如何使用 Customized Metric ，使得在 RabbitMQ 有太多未消化的 Job 時，可以自動增加 replica 數量，讓 Job 可以馬上被處理完畢
• 對於本地端開發 K8S 應用服務覺得困擾的人，可以參閱此網友分享如何使用 MicroK8s 在本地端建立一個類似於生產環境的 K8S 叢集，如此一來便可以方便地在本地端開發，又不會遇到環境差異所產生的不良影響
• 自建機房的大企業應該有不少人會使用 vSphere，K8S 的 StorageClass 其實也有支援，cormachogan.com 這篇圖文豐富的教學文章提到要如何在 vSphere 的環境下讓 K8S 的 Persistent Volume 使用 VsphereVolume StorageClass

K8S Operator

圖片來源 flant

• 在上個月的週報有提到一個由 Flant 所開源的 shell-operator，沒想到半個月後該公司又推出了號稱為兄弟作的 addon-operator，有在玩 K8S 的人應該都知道剛架設完畢的 K8S 空空如也，根本就無法給開發者使用，一般來說都還需要安裝許多額外的套件，譬如 Ingress Controller, Prometheus, ElasticSearch，其他的 Operator…等，講到這邊，應該就知道 addon-operator 的主要任務為幫忙 Provision 什麼都沒有的 K8S 叢集；讓不同環境的 K8S 叢集可以透過 addon-operator 的協助，把該裝的東西定義在 YAML 檔案中就好，管理很多 Cluster 的人不用再怕漏裝東西或是改錯設定…詳全文 (Announcing addon-operator to simplify managing additional components in K8s clusters)

圖片來源 openshift

• openshift 寫了一篇關於開發 Operator 的最佳守則，從 Operator 的主要精神介紹，如 Operator 會去 Master API 查看事件，當相關的事件發生之後便會去執行對應的動作，例如再去打 Master API，但通常都是去對其他系統執行一些特定的任務，接著提到開法者要如何去建立 Watches, Reconciliation Cycle, 怎麼去做資源的各種驗證…等，有想要開發 operator 的人千萬不要錯過…詳全文 (Kubernetes Operators Best Practices)

K8S 應用整合

圖片來源 okteto

• 每週都可以看到有越來越多的服務可以被部署到 K8S 中，這次可以看到有 Coder (VS Code 的線上版 IDE)，Stellar Validator (開源的去中心化支付網路系統)，SAS Viya (綜合分析平臺，代表了SAS新一代的分析架構)，在大家拼命地想要將東西部署進來 K8S 的過程中，也讓 K8S 的缺陷一個一個的被揭露出來，不過社群這邊也很努力的將這些挑戰一個一個的排除掉XD

K8S 其他消息

圖片來源 amazon

• 看到一本有關於 Kubernetes 相關的書籍在 Amazon 上正在準備預購的樣子，書名為 Kubernetes 最佳守則: 在 Kubernets 上成功建立應用服務的藍圖規劃，內容簡介提到在學習完關於 K8S 的所有事後，該如何將其實踐，Tech Leads, DevOps 工程師, 開發者和架構師都可以透過此書學習到在真實世界如何把應用服務放到 K8S 中的最佳守則；從應用程式 CI/CD 對於應用程式的設計，部署和測試，同時也可以學習到其他公司如何使用 K8S (不知道什麼時候有中文版XD)

圖片來源 nextplatform

• 假如想要知道 K8S 的未來走向會是如何，或許可以參考 Facebook 內部從 2011 年就開始使用的容器控制系統 Tupperware，因為雖然 K8S 已經五歲了，但其實它當初是一個從無到有的計畫，並沒有把 Borg 的任何程式碼拿過來用，所以 Google 龐大應用服務所遇到的擴展問題，在 Borg 雖然都已經解掉了，但是未來在 K8S 遇到相同擴展問題時，其實對它來說算是新的問題，整個社群必須要再想辦法去解決；也可以發現目前 Google 跟 Facebook 內部的容器控制系統節點至少都是上萬等級，但 K8S 其實還在上千的等級奮鬥中；因此隨著大家開始大量採用 K8S 之後，以前在 Google 或是 Facebook 內部遇到且已經解決的擴展問題，應該都可以成為 K8S 的借鏡…詳全文 (FUTURE KUBERNETES WILL MIMIC WHAT FACEBOOK ALREADY DOES)