[案例回顧] K8S 導入實戰分享
這是一篇談技術的故事，要求讀者具備一定的專業名詞理解能力。內容主要描述了專案建置過程中遇到的一些技術難關與解決方法。希望您喜歡！
前情提要
上個禮拜開始由於疫情的關係，公司全面實施 WFH 了，並且禁止任何實體的外出拜訪。儘管如此，我們還是順利完成了一個 K8S 導入案子的結案，並獲得客戶的高度評價與肯定！這真的是全賴我們優秀的業務與工程團隊通力合作才達成的任務。
我們服務的客戶，原本對於 K8S 所知不多，但主管們對於資訊轉型的敏銳度非常高，也很有魄力，覺得不能等到洪水淹到了才學游泳！主管的景願是成爲數位原生的基石，整體能見度就不受限於 K8S 。於是全盤交給我們公司規畫整個導入專案，從硬體的規格、伺服器類別與數量、軟體版本、架構選型、到專案時程與執行，全都以最信任的態度交給我們處理。當然，我們也不負所託，從去年底開始執行，歷時半年總算把整個系統從零基礎建置完成並交付到客戶手上。
K8S 基礎建置
專案一開始，我們根據客戶的實際環境進行客製，為客戶說明整體規劃並得到同意後，在硬體採購與搭建的同時，我們立即開始為客戶進行教育訓練，從 K8S 的基礎開始到應用程式的拆解等等，先讓客戶有基本的概念。等硬體環境完成後，再帶著客戶一起進行各項元件的安裝，過程中有不懂的地方再進行補充說明。
這次我們挑選了最硬的 K8S 管理平台：採用 Open Source 的 KubeAdmin 而捨棄現成的商業整合方案。這對客戶來說，入門難度的確高了很多！要知道當初客戶連怎麼保存 container 程式產生的訊息都沒有概念呢… 幸好客戶那邊的工程師非常好學，很快就能跟上基本的管理操作了。更難得的是，他們還三不五時提出一些平時連我們自己也不一定會注意到的細節問題，讓我們也能順便補充技能。真的可謂教學雙長啊！
CI/CD & HA
當 K8S 基礎平台搭建好之後，接下來幫客戶搭建 Harbor 作為內部 container image 倉庫使用，以及架設 Gitlab 來存放程式碼。然後再以 Git Runner 來搭建 CI/CD ，並提供教學協助客戶完成自動化部署流程。哪些可以自動部署哪些需要卡控，這些流程都需要讓客戶能夠自行掌握與設計。除了要教會客戶自組管線之外，還傳授了 submodule 跨不同 project 存取等應用技巧。同時，用來供應 PVC 的 NFS server 也需要搭建，雖然這次規劃中有專屬的 SAN storage，但客戶還是想要以 server 的方式提供 NFS 服務。
以上這些 Server 都需要具備 HA 能力，因此我們就在底層再建置 PaceMaker，再搭配 DRBD 來滿足客戶的需求。由於 PaceMaker 還沒有提供 docker-compose 的 resource module ，於是我們只得自己動手來刻一個 PCS 的 heartbeat module 來解決 docker-compose 的 HA 運行實作。完成後也就順手 contribute 回給 Pacemaker 的 Github ，也算是一份貢獻吧。
此外，為了降低客戶的維護難度，我們另外專門針對他們的環境撰寫一些 shell script ，讓客戶透過簡單的 CLI 就能完成一系列的判斷與複雜的操作。
應用程式轉移
接下來密鑼緊鼓進行的就是應用程式的拆解與轉移。客戶這邊大多是 .net 程式，需要轉移到 .net core 平台上面。我們先提供幾隻較為經典的範例給客戶參考與模仿，剩下的就得靠程式的維護人員慢慢轉移了。
過程中難免遇到一些環境配置的問題，還好團隊中的高手都能迅速協助客戶逐一排解。例如，利用統一的 swagger-ui 頁面讓客戶瀏覽不同服務的 API 文件說明功能；或是透過檢查客戶撰寫的程式碼修正 if 條件的判斷錯誤，解決了他們的 .net core 程式碼佈署到 k8s 上沒有 swagger 的 http request 反應問題，等等。
服務網格導入
再來就是安裝 Istio 部署 Service Mesh 架構。我們透過公司的一個名為 Pilotwave 的產品，以視覺化的 GUI 介面大幅降低了客戶在 istio 上面的操作複雜性。
Service Mesh 的導入過程中遇到的問題更多，除了簡單的 URL 路徑對應問題之外，還有各式各樣的意外，基本上我們都能在客戶反應之後順利處理掉。其中印象比較深刻的是一個 SSL 憑證的問題。客戶導入 istio 讓外部可以透過 gateway 連入，再依據 virtual service 設定交由給真實的 service 提供服務。在測試 JWT 驗證時，指定 JWKURL 設定使用外部 json 檔案提供組態，但一直無法正常驗證成功。設定好 pod 服務之後，其中的 sidecar 無法正常運作，查看 pod 記錄顯示:
Envoy proxy is NOT ready: config not receieved from Pilot (is Pilot running)後續查看 istiod 程式出現：
x509 certificate signed by unknown authority因此我們判斷是憑證的問題。但客戶的憑證不是 self-signed 憑證，而是花了真金白銀合法取得的 wildcard 通用憑證！而且同樣的憑證用在客戶官方網站是沒問題的。後來經過我們多番交叉測試驗證，甚至用到 openssl 命令進行底層的細部驗證，發現 istio 服務裡面使用的憑證中缺了必需的中繼憑證。然後我們將中繼等證書整理好彙整一份，重新把 cert 證書內容更新到 istio gateway 設定，就順利解決了！
監控建置
幾乎所有專案建置的最後階段，都會帶到監控的部分，本次的專案也當然不會例外。
除了必須的 Prometheus 之外，還幫客戶架設了 Grafana 作爲 Dashboard 與 Alert Manager。爲此，我們針對客戶的使用環境，提供了客製化的 alert rules。此外還安裝了 elasticsearch 、filebeat 、kiban 等工具來強化各項監控數據與功能。針對 Service Mesh 監控我們為客戶導入了 Kiali 作爲管理工具。總之就是要爲客戶打造一個安心的運作環境就是了。
我們遇到一個比較有趣的案例，在調整 CI/CD 的過程中，我們提供的 YAML 範本裏面有 Prometheus scape 的 annotation 設定，但客戶的程式實際上是沒有提供給 Prometheus endpoint ，這在原生的 kubernetes 環境裡不會有問題，但是搭配 istio 使用時，會因為 istio 的 sidecar (istio-proxy) 收到很多錯誤的 request ，而造成 kiali 誤判為這個 svc 不健康，然後呈現在 kiali 的 UI 上。這雖然花了我們一些時間來檢測，但解法也很簡單，就是把 annotation 的服務區段刪除就好了。
其他
整個專案下來，大大小小的意想不到的問題層出不窮，例如網路卡有 enable 但沒有接網路線，讓 metallb 發的 IP 會有 ARP 問題，導致其他 subnet 無法正確連線；又或者是節點上沒有 DNS 而需要修改 volume 來掛載 /etc/hosts 來解決；也有 gitlab 升版後會出現 ASAP 訊息的問題；還有更換 harbor/gitlab 憑證連帶調整 gitlab-runner 以及每個節點的 /etc/docker/certs.d 設定… 等等諸如此類的，大部分都是一些瑣碎零散的問題。所幸憑藉技術團隊的豐富經驗，都一一加以化解。當然，過程中難免會遇到一些不是很熟悉的題目，還好有 Google 與我們自己的 LAB ，在摸索驗證後幫客戶解決問題。
小結
專案執行的順利與否，除了要有良好的規劃外，導入團隊的專業水平也是絕對關鍵的重要指標。很多經驗不能光是靠看文件或影片就能獲得，有時候拜 Google 大神也不一定有結果。這時候，靠的就是團隊的實戰經驗了。所謂臺上一分鍾臺下十年功就是這個道理！其背後有着夥伴們不折不撓的求知精神，也有大家同心協力的無間合作，更多的是公司全體上下朝着一致目標邁進的決心與毅力。使命必達！
如果您在 K8S 治理上遇到困難，或是正在打算建置 K8S 環境而需要專業的顧問服務或教育訓練，歡迎聯絡我們寬橋。
