12/20 2019

AWS re:Invent 2019 技術專欄 – 容器與 K8S 最佳實踐的五大心法

Nextlink re:Invent 技術專欄 容器 K8S

Nextlink 技術小編在五天的 AWS re:Invent 2019 活動當中參加了許多場次的技術 Session。本篇跟大家分享的是由美國軟體分析公司 New Relic 的技術顧問主講她在輔導客戶使用容器與 K8S 最佳實踐的五大心法。

首先,講者不免俗地提到客戶對於導入容器與 K8S 的簡要流程以及說明使用相關服務所帶來的好處,包含能讓整體的服務開發流程更迅速、成本優化以及具有可攜性。她表示其實在網路上搜尋 ”Best practice for Kubernetes” 其實就有很多相關的資源可以閱讀,但是根據她多年來在真實的商業環境中輔導的經驗,最後歸類出以下五點:

Build small container images

Container images 檔案若過於龐大可能會產生許多的問題,也與 Container 的精神背道而馳,縮小的好處為能夠減少佈建時間、減少資安弱點、使用較少的儲存空間以及使下載更新及冷啟動時間更快速。開發者應該在建置前就要先確認哪些的 app 是要包進容器裡面、選擇適合的 image based (例如:使用 Alpine 會比使用 node.js 節省10倍的空間) 並避免不必要的封包及檔案。

Leverage namespaces

K8S 裡面的 namespace 可依照執行團隊、開發策略等原因將各組的資源做出虛擬化的 Cluster 分隔。開發人員使用 namespace 來區隔出資源之後,不只是可增加易管理性以及安全性並且提升 Kubernetes API 在執行上的效能。可以透過修正 config file 、使用 kubectl 去啟動變更並更新每個 cluster 的 namespace 不要是重複的名字。

Set up health checks

當發生緊急狀況時若在發生前有設置 health checks 可以快速找出問題所在並解決問題,在營運時也能看到在 Cluster 裡面的狀況並能夠追蹤特定的事件。開發人員可以透過下載 YAML 檔並使用正確的語法來修正,並設置 initialDelaySeconds 以及使用 kubectl 來去蒐集 K8S 裡面的相關資訊。

Use resource requests & limits

開發者應該要去特別限制以及使用 config file 去做資源的request 並使用kubectl去推送更新和描述node去看到request 和限制的清單。若沒有設置資源的限制條件會導致pod不穩定進而導致被限制或是強迫終止。如果設置的值大於最大節點的核心數量,則Pod就永遠不會被進行排程。

Understand the context of problems

開發人員可以透過安裝K8S log output套件、更新正確的憑證資訊以及使用kubectl來擷取 log,這可以讓K8S整體環境運行的狀況提供更加詳細的內容並可以將此方法應用於node、pod以及cluster層級。