[Kubernetes/K8s]Kubernetes summit 2022 | 2022 K8s summit 心得分享
時間 10/18–10/19 2022 K8s summit
地點 台北文創大樓
個人分享心得
k8s 好處
Auto Scaling
- 比VM快許多的scale速度幫助渡過服務peak
CICD更簡便
- 透過yaml定義部署程序
- 嚴謹的config管理可讓stateless service減少不同的環境因素干擾
建構容器平台實戰經驗分享
將系統切割為三層
前台、業務中台模組化、後台輕量化
前台專注於客戶服務體驗
中台專注於共通服務模組
後台是核心服務，但瘦身
中台是主要目前k8s導入的層別，負責提供共同服務，前台提供讀取結果、visualization
銀行建置經驗分享痛點：
痛點
- 如何因應年節與行銷活動的大量登入需求
- 如何降低伺服器 EOL 與 HotFix 影響
- 現有系統建置已久，程式碼維護不易
- 有狀態的程式碼，擴充不易
規劃
- 挑選合適的系統
- 需要配合業務需求，彈性擴充
- 可重用性質高的共用服務
- 完善的系統架構規劃
執行
- 依規劃落實執行
- 需要動用高階長官的力量
- 成立資訊管理委員會
導入前置評估
- Infra 已具備管理容器化平台的技術能力
- AP 已具備應用系統容器化的開發技能
- IT 人員皆已具備 k8s 的操作與維運能量
- k8s 使用實體機還是虛擬機
導入的效益分享
automated container deployment, scaling, and management
同時部署多個容器到多台機器
Argo CD 搭配 Kustomize 實作 GitOps 部署
同一類型deployment需要deploy的不同環境？有些許變數不同？
- 要maintain多份yaml？ > 維運成本高
- 用sed replace? > 容易出錯
- 打包成Helmchart? > 複雜度高
解決Kustomize 根據不同環境開設不同資料夾．
可以像Docker-compose一樣定義很多個Services
但是Kustomize基於K8s, 可以讓namespace下面跑的pods, ingresses都一目了然可以使用Overlays將部署環境(alpha, beta, production..)做區隔．
如何使用Kustomize
https://kubernetes.io/zh-cn/docs/tasks/manage-kubernetes-objects/kustomization/
Peek into Secure Software Supply Chain for Kubernetes
分享在雲原生應用上 (Cloud Native Application) 建議執行的相關資安管控
以 SLSA 架構，建構企業內完整的容器資安開發機制，落實在日常生活中．
目標：以安全的方式推送軟體
SLSA介紹
SLSA 的設計宗旨在於漸進式、可操作性，並提供每個步驟的安全優勢。構件達到最高等級後，消費者就能確定自身並未遭到竄改，而且可以安全追溯至來源。如果無法達成這個目標，可能會更困難。
SLSA 由 4 個層級組成，SLSA 4 代表理想的結束狀態。較低層級代表漸進式的里程碑，具有對應的漸進式完整性保證。這些需求條件目前的定義如下：
SLSA 1 要求建構程序必須具備完整指令碼/自動化作業，並產生來源。來源是構件的建構方式中繼資料，當中包含建構程序、頂層來源和依附元件。掌握來源後，軟體消費者就能做出風險相關安全性決策。雖然 SLSA 1 的來源無法防範竄改，但可提供基本的程式碼原始碼識別，可能有助於管理安全漏洞。
SLSA 2 需要使用版本管控和產生經過驗證的來源的託管建構服務。這些額外要求可讓消費者更確信自己軟體的來源。在這個層級，來源可防止他人竄改建構服務值得信賴的程度。SLSA 2 也為提供簡便的 SLSA 3 升級路徑。
SLSA 3 進一步要求來源和建構平台必須符合特定標準，才能確保來源的可稽核性和來源的完整性。SLSA 3 可防範特定類別的威脅 (例如跨建構的汙染情形)，讓安全性高於先前程度。
SLSA 4 目前為最高等級，需要兩人審查所有變更，以及密封、可重現的建構過程。雙人審查是偵測錯誤並防止不良行為的業界最佳做法。密封建構可確保依附元件清單的完整性。雖然可重現的建構並非強制要求，但仍提供許多可稽核性和可靠性優勢。整體而言，SLSA 4 能讓消費者放心地相信軟體未遭竄改。您可以在 GitHub 存放區中找到這些建議級別的詳細資料，包括對應的來源和版本/授權證明。
