適用於 AKS 的平臺自動化和 DevOps

Kubernetes 是雲端原生建構,需要雲端原生方法來部署和作業。 Azure 和 Kubernetes 是開放且可延伸的平臺,具有豐富且架構完善的 API,可提供機會和能力,以在完整範圍內自動化。 依賴自動化和一般 DevOps 最佳做法,規劃 DevOps 和高度自動化的方法。

設計考量

以下是 AKS 平臺自動化和 DevOps 的一些設計考慮:

  • 在判斷工程和自動化方法時, 請考慮 Azure 服務限制 和持續整合和持續傳遞 (CI/CD) 環境。 如需另一個範例,請參閱 GitHub 使用限制

  • 保護和保護開發、測試、Q&A 和生產環境的存取權時,請考慮從 CI/CD 的觀點來看的安全性選項。 部署會自動進行,因此會據以對應訪問控制。

  • 請考慮搭配定義完善的慣例來使用前置詞和後綴,以唯一識別每個已部署的資源。 這些命名慣例可避免彼此部署解決方案時發生衝突,並改善整體小組靈活度和輸送量。

  • 清查工作流程,以支援在一般和災害復原計劃 (DRP) 制度中支援工程、更新和部署您的解決方案。 請考慮根據這些工作流程對應管線,以最大化熟悉度和生產力。

    一些要考慮的範例案例和管線包括:

    • 部署、修補和升級叢集
    • 部署和升級應用程式
    • 部署和維護附加元件
    • 故障轉移以進行災害復原
    • 藍綠部署
    • 維護 Canary 環境
  • 請考慮使用 服務網格 ,將更多安全性、加密和記錄功能新增至您的工作負載。

  • 請考慮部署其他資源,例如訂用帳戶、標記和標籤,藉由追蹤部署和相關成品來支援DevOps體驗。

  • 請考慮牛與寵物範式轉變的影響。 預期 Kubernetes 的 Pod 和其他層面暫時性,並據此調整您的自動化和管線基礎結構。 請勿依賴IP位址或其他資源來修正或永久。

設計建議

以下是 AKS 平臺自動化和 DevOps 的一些設計建議:

  • 依賴管線或動作來:

    • 將整個小組的套用做法最大化。
    • 消除重塑車輪的大部分負擔。
    • 提供整體質量和靈活度中的可預測性和深入解析。
  • 使用以觸發程式和排程的管線來早期且經常部署。 以觸發程式為基礎的管線可確保變更經過適當的驗證,而排程管線則會管理變更環境中的行為。

  • 將基礎結構部署與應用程式部署分開。 核心基礎結構變更小於應用程式。 將每種部署類型視為個別的流程和管線。

  • 使用 雲端原生 選項進行部署。 使用 基礎結構即程式代碼 來部署基礎結構,包括控制平面,並使用 HelmKubernetes 中的操作員模式來部署和維護 Kubernetes 原生元件。

  • 使用 GitOps 來部署和維護應用程式。 GitOps 會使用 Git 存放庫作為單一事實來源,避免設定漂移,並在復原和相關程式期間提高生產力和可靠性。

  • 使用適用於秘密存放區 CSI 驅動程式的 Pod 受控識別和 Azure 金鑰保存庫 提供者來保護秘密、憑證和 連接字串。

  • 避免硬式編碼的組態項目和設定,以達到最大化部署並行。

  • 依賴基礎結構和應用程式相關部署的已知慣例。 使用與 Kubernetes Azure 原則 附加元件結合的許可控制器,來驗證並強制執行其他已定義原則之間的慣例。

  • 以一致的方式擁抱 移:

    • 安全性,方法是在管線早期新增容器掃描之類的弱點掃描工具。
    • 原則,方法是使用原則作為程序代碼,並透過許可控制者以雲端原生方式強制執行原則。
  • 將每個失敗、錯誤或中斷視為自動化並改善整體解決方案質量的機會。 在左移和 月臺可靠性工程 (SRE) 架構中整合此方法。