VM 工作負載部署作業總覽

本指南說明部署虛擬機器 (VM) 型工作負載時，所需的概念背景知識。工作負載會部署至 Google Distributed Cloud (GDC) 實體隔離方案叢集，並使用 VM 執行階段在裸機上執行。本指南中的工作負載是地端部署硬體上可用的範例票務系統平台。

架構

資源階層結構

在 GDC 中，您會將構成票務系統的元件部署在營運團隊的專屬租戶組織中，這與任何客戶組織相同。組織是一組統一管理的叢集、基礎架構資源和應用程式工作負載。GDC 執行個體中的每個組織都使用一組專屬伺服器，在租戶之間提供強大的隔離機制。如要進一步瞭解基礎架構，請參閱「設計存取權邊界」。

此外，您可以在專案中一併部署及管理票務系統資源，透過軟體政策和強制執行機制，在組織內提供邏輯隔離。專案中的資源旨在結合必須在生命週期內保持在一起的元件。

支援單處理系統採用三層式架構，仰賴負載平衡器將流量導向應用程式伺服器，這些伺服器會連線至儲存永久資料的資料庫伺服器。

這種架構可獨立開發及維護各層，因此具備擴充性和可維護性。此外，這項架構也能清楚區分關注點，簡化偵錯和疑難排解作業。將這些層級封裝在 GDC 專案中，即可一併部署及管理元件，例如應用程式和資料庫伺服器。

網路

在正式環境中執行票務系統時，必須部署兩個以上的應用程式伺服器，才能在節點故障時達到高可用性。搭配負載平衡器，這個拓撲也能將負載分配到多部機器，水平擴充應用程式。GDC 的 Kubernetes 原生平台會使用 Cloud Service Mesh，將流量安全地轉送至構成票務系統的應用程式伺服器。

Cloud Service Mesh 是 Google 根據開放原始碼專案建構而成，可管理、觀測及保護服務。在 GDC 上託管票務系統時，會用到下列 Cloud Service Mesh 功能：

• 負載平衡：Cloud Service Mesh 將流量與基礎架構擴充作業分離，提供多項流量管理功能，包括動態要求轉送。票務系統需要永久用戶端連線，因此我們使用 DestinationRules 啟用黏性工作階段，設定流量轉送行為。

• TLS 終止：Cloud Service Mesh 會使用 TLS 憑證公開輸入閘道，並透過 mTLS (雙向傳輸層安全標準) 在叢集內提供傳輸驗證，不必變更任何應用程式程式碼。

• 故障復原：Cloud Service Mesh 提供許多重要的故障復原功能，包括逾時管理、斷路器、主動式健康狀態檢查和受限的重試機制。

在 Kubernetes 叢集中，我們使用標準 Service 物件，以抽象方式將應用程式和資料庫伺服器公開至網路。Service 可讓您使用選取器指定目標執行個體，並使用叢集感知 DNS 伺服器在叢集內提供名稱解析。

apiVersion: v1
kind: Service
metadata:
  name: http-ingress
spec:
  selector:
    app.kubernetes.io/component: application-server
  ports:
  - name: http
    port: 80
---
apiVersion: v1
kind: Service
metadata:
  name: database-ingress
spec:
  selector:
    app.kubernetes.io/component: database-server
  ports:
  - name: mysql
    port: 3306

運算

票務系統建議使用裸機或虛擬機器託管地端部署安裝，我們則使用 GDC Virtual 虛擬機器 (VM) 管理功能，將應用程式和資料庫伺服器部署為 VM 工作負載。定義 Kubernetes 資源後，我們就能指定 VirtualMachine 和 VirtualMachineDisk，根據不同類型的伺服器需求調整資源。VirtualMachineExternalAccess 可讓我們設定 VM 的資料傳入和傳出。

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
  name: vm1-boot-disk
spec:
  size: 100G
  source:
    image:
      name: ts-ticketing-system-app-server-2023-08-18-203258
      namespace: vm-system
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachine
metadata:
  labels:
    app.kubernetes.io/component: application-server
  name: vm1
  namespace: support
spec:
  compute:
    vcpus: 8
    memory: 12G
  disks:
  - boot: true
    virtualMachineDiskRef:
      name: vm1-boot-disk

---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineExternalAccess
metadata:
  name: vm1
  namespace: support
spec:
  enabled: true
  ports:
   - name: ssh
     protocol: TCP
     port: 22

我們建立了自訂映像檔做為客體 OS 映像檔，以符合法規遵循和安全性要求。您可以使用 VirtualMachineAccessRequest 透過 SSH 連線至執行中的 VM 執行個體，這樣就能透過 Kubernetes RBAC 限制連線至 VM 的能力，並避免在自訂映像檔中建立本機使用者帳戶。存取要求也會定義存留時間 (TTL)，允許以時間為依據的存取要求管理自動到期的 VM。

自動化

這項專案的主要交付項目，是我們設計出一種方法，能以可重複的方式安裝票務系統執行個體，支援廣泛的自動化作業，並減少部署作業之間的設定差異。

發布管道

如要自訂應用程式和資料庫伺服器映像檔，請先從基礎作業系統映像檔開始，視需要修改基礎映像檔，安裝各個伺服器映像檔所需的依附元件。我們選取基本 OS 映像檔，是因為該映像檔廣泛用於託管地端部署安裝的票務系統。這個基本 OS 映像檔也提供安全性強化功能，可滿足安全性技術導入指南 (STIG) 的要求，提供符合 NIST-800-53 控管規範的映像檔。

我們的持續整合 (CI) 管道使用下列工作流程，自訂應用程式和資料庫伺服器映像檔：

開發人員變更自訂指令碼或映像檔依附元件時，系統會在 CI 工具中觸發自動化工作流程，產生一組新的映像檔，並與 GDC 版本一併發布。在映像檔建構過程中，我們也會重新整理 OS 依附元件 (yum update)，並透過壓縮將映像檔稀疏化，減少將映像檔轉移至客戶環境所需的映像檔大小。

軟體開發生命週期

軟體開發生命週期 (SDLC) 是協助組織規劃、建立、測試及部署軟體的程序。只要遵循明確定義的 SDLC，組織就能確保軟體開發方式一致且可重複，並及早找出潛在問題。除了在持續整合 (CI) 管道中建構映像檔外，我們也定義了環境，用於開發及測試票務系統的預先發布版本，並進行品質保證。

為每個 GDC 專案部署獨立的票證系統執行個體，即可單獨測試變更，不會影響同一 GDC 執行個體上的現有執行個體。我們使用 ResourceManager API，以宣告方式建立及拆除使用 Kubernetes 資源的專案。

apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: ticketing-system-dev
---
apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: ticketing-system-qa
---
apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: ticketing-system-staging

結合圖表封裝和管理基礎架構 (例如虛擬機器) 做為程式碼，開發人員可以快速疊代，在正式版執行個體中進行變更及測試新功能。宣告式 API 也可讓自動化測試執行架構執行定期迴歸測試，並驗證現有功能。

可操作性

可操作性是指系統操作和維護的難易程度。在設計任何軟體應用程式時，這都是一項重要考量。有效的監控有助於提升可操作性，因為您可以在問題對系統造成重大影響之前，找出並解決問題。監控功能也可用於找出改善空間，並建立服務水準目標 (SLO) 的基準。

監控

我們將票證系統與現有的 GDC 觀測能力基礎架構整合，包括記錄和指標。針對指標，我們會從每個 VM 公開 HTTP 端點，讓應用程式擷取應用程式和資料庫伺服器產生的資料點。這些端點包括使用應用程式節點匯出工具收集的系統指標，以及應用程式專屬指標。

由於每個 VM 都公開端點，我們使用 MonitoringTarget 自訂資源設定應用程式輪詢行為，定義抓取間隔並為指標加上註解。

apiVersion: monitoring.gdc.goog/v1
kind: MonitoringTarget
metadata:
  name: database-monitor
spec:
  podMetricsEndpoints:
    path:
      value: /metrics
    port:
      annotation: application.io/dbMetrics
    scrapeInterval: 60s

在記錄方面，我們在每個 VM 中安裝並設定記錄和指標處理器，以追蹤相關記錄，並將記錄資料傳送至記錄工具，然後透過監控執行個體建立索引及查詢資料。稽核記錄會轉送至特殊端點，並設定延長保留期限，以符合法規。容器型應用程式可以使用 LoggingTarget 和 AuditLoggingTarget 自訂資源，指示記錄管道從專案中的特定服務收集記錄。

我們根據記錄和監控處理器中的可用資料，使用 MonitoringRule 自訂資源建立快訊，以便在圖表套件中以程式碼的形式管理這項設定。使用宣告式 API 定義快訊和資訊主頁，也能讓我們將這項設定儲存在程式碼存放區中，並遵循與其他程式碼變更相同的程式碼審查和持續整合程序。

故障模式

早期測試發現了幾種與資源相關的失敗模式，有助於我們優先決定要先新增哪些指標和快訊。我們一開始先監控高記憶體和磁碟用量，因為資料庫設定錯誤，導致緩衝區資料表耗盡所有可用記憶體，且過度記錄填滿了附加的永久磁碟區磁碟。調整儲存空間緩衝區空間大小並實作記錄輪替策略後，我們接著導入了警示，在 VM 接近高記憶體或磁碟用量時執行。

apiVersion: monitoring.gdc.goog/v1
kind: MonitoringRule
metadata:
  name: monitoring-rule
spec:
  interval: 60s
  limit: 0
  alertRules:
  - alert: vm1_disk_usage
    expr:
      (node_filesystem_size_bytes{container_name="compute"} -
      node_filesystem_avail_bytes{container_name="compute"}) * 100 /
      node_filesystem_size_bytes{container_name="compute"} > 90
    labels:
      severity: error
      code: TS-R0001
      resource: vm1
    annotations:
      message: "vm1 disk usage above 90% utilization"

確認系統穩定後，我們將重點轉移到票務系統中的應用程式故障模式。由於偵錯應用程式問題時，通常需要使用安全殼層 (SSH) 進入每個應用程式伺服器 VM，才能查看票證系統記錄，因此我們設定應用程式將這些記錄轉送至記錄工具，以便在 GDC 觀測能力堆疊上建構，並查詢監控執行個體中的所有票證系統作業記錄。

集中化記錄功能也讓我們能同時查詢多個 VM 的記錄，整合系統各個元件的檢視畫面。

備份

備份對於軟體系統的運作能力至關重要，因為系統在發生故障時可以還原。GDC 透過 Kubernetes 資源提供 VM 備份和還原功能。使用 VirtualMachineBackupPlanTemplate 自訂資源建立 VirtualMachineBackupRequest 自訂資源，即可將附加至各個 VM 的永久磁碟區備份至物件儲存庫，並按照設定的保留政策保留備份。

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineBackupPlanTemplate
metadata:
  name: vm-backup-plan
spec:
  backupRepository: "backup-repository"
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineBackupRequest
metadata:
  name: "db-vm-backup"
spec:
  virtualMachineBackupPlanTemplate: vm-backup-plan
  virtualMachine: db1
  virtualMachineBackupName: db-vm-backup

同樣地，從備份還原 VM 狀態時，需要建立 VirtualMachineRestoreRequest 自訂資源，以便還原應用程式和資料庫伺服器，而不必修改任一服務的程式碼或設定。

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineRestoreRequest
metadata:
  name: vm-restore-1
spec:
  virtualMachineBackup: db-vm-backup
  restoreName: restore1
  restoredResourceName: db1

升級

為支援票務系統及其依附元件的軟體生命週期，我們找出三種軟體升級類型，並分別處理，盡可能減少停機時間和服務中斷：

1. OS 升級。
2. 平台升級，例如修補程式和主要版本。
3. 設定更新。

針對 OS 升級，我們會持續建構及發布新的 VM 映像檔，用於應用程式和資料庫伺服器，並隨每個 GDC 版本發布。這些映像檔包含安全漏洞修正程式和基礎作業系統更新。

票務系統平台升級時，必須對現有 VM 映像檔套用更新，因此我們無法依賴不可變基礎架構來執行修補和主要發布版本更新。如果是平台升級，我們會先在開發和測試環境中測試及驗證修補程式或主要版本，然後再與 GDC 版本一起發布獨立升級套件。

最後，系統會透過票證系統 API 套用設定更新，不會造成停機，以便更新組合和其他使用者資料。我們會在開發和測試環境中開發及測試設定更新，然後在 GDC 發布程序中將多個更新組合在一起。

整合

識別資訊提供者

為了提供客戶流暢的體驗，並讓機構能引導使用者上手，我們將票證系統與 GDC 提供的多個識別資訊提供者整合。一般來說，企業和公部門客戶都有妥善管理的識別資訊提供者，可授予及撤銷員工的權利。基於法規遵循要求，以及為了輕鬆管理身分和存取權管理，這些客戶希望使用現有的識別資訊提供者做為可靠資料來源，管理員工對票務系統的存取權。

票務系統透過多重識別資訊提供者模組，同時支援 SAML 2.0 和 OIDC 提供者，我們已在應用程式伺服器 VM 映像檔中預先啟用該模組。客戶透過組織識別資訊提供者進行驗證，系統會自動建立使用者，並在票證系統中指派角色。

系統允許透過 ProjectNetworkPolicy 自訂資源輸出至識別資訊提供者伺服器，這會限制是否可從 GDC 中的組織連線至外部服務。這些政策可讓我們以宣告方式，控管票務系統在網路上可存取的端點。

快訊擷取

除了讓使用者登入並手動建立客服案件外，我們也會建立票證系統事件，以回應系統警示。

為達成這項整合，我們自訂了開放原始碼 Kubernetes Webhook，以便接收應用程式的快訊，並使用透過 Cloud Service Mesh 公開的票證系統 API 端點，管理事件的生命週期。

API 金鑰會儲存在 GDC 密鑰儲存庫，並由 Kubernetes 密鑰支援，透過角色式存取控管 (RBAC) 控管。其他設定 (例如 API 端點和事件自訂欄位) 則透過 Kubernetes ConfigMap 鍵/值儲存空間管理。

電子郵件

支援單處理系統提供郵件伺服器整合功能，可讓客戶透過電子郵件獲得支援。自動化工作流程會將客戶來信轉換為客服案件，並自動回覆客戶，提供案件連結。這樣一來，客服團隊就能更妥善地管理收件匣、有系統地追蹤及解決電子郵件要求，並提供更優質的客戶服務。

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ingress-traffic-from-ticketing-system
spec:
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - ticketing-system

將電子郵件公開為 Kubernetes 服務，也能提供服務探索和網域名稱解析功能，並進一步將電子郵件伺服器後端與票證系統等用戶端分離。

法規遵循

稽核記錄

稽核記錄可追蹤及監控軟體使用情形，並提供系統活動記錄，有助於提升法規遵循情形。稽核記錄會記錄未經授權使用者的存取嘗試、追蹤 API 使用情形，並找出潛在的安全風險。稽核記錄符合法規遵循要求，例如《健康保險流通與責任法案》(HIPAA)、付款卡產業資料安全標準 (PCI DSS) 和《沙賓法案》(SOX) 規定的要求。

GDC 提供系統，可記錄平台中的管理活動和存取權，並保留這些記錄一段時間 (可設定)。部署 AuditLoggingTarget 自訂資源後，系統會設定記錄管道，從應用程式收集稽核記錄。

針對票務系統，我們為收集到的系統稽核事件，以及票務系統安全性稽核記錄產生的應用程式專屬事件，設定了稽核記錄目標。這兩種記錄都會傳送至集中式 Loki 執行個體，我們可以在監控執行個體中編寫查詢及查看資訊主頁。

存取控管

存取控管是指根據要求存取權的使用者或程序身分，授予或拒絕資源存取權。這有助於防止資料遭到未經授權的存取，並確保只有授權使用者才能變更系統。在 GDC 中，我們仰賴 Kubernetes RBAC 宣告政策，並對構成票務系統應用程式的系統資源強制執行授權。

在 GDC 中定義 ProjectRole，即可使用預設授權角色，授予 Kubernetes 資源的精細存取權。

apiVersion: resourcemanager.gdc.goog/v1
kind: ProjectRole
metadata:
  name: ticketing-system-admin
  labels:
    resourcemanager.gdc.goog/rbac-selector: system
spec:
  rules:
  - apiGroups:
    - ""
    resources:
    - configmaps
    - events
    - pods/log
    - services
    verbs:
    - get
    - list

災難復原

資料庫複製

為滿足災難復原 (DR) 需求，我們在多個 GDC 執行個體中，以主次設定部署票證系統。在這個模式中，傳送至票務系統的要求通常會轉送至主要網站，而次要網站則會持續複製資料庫的二進位記錄。發生容錯移轉事件時，次要網站會升級為新的主要網站，要求也會轉送至新的主要網站。

我們運用資料庫複製功能，根據設定的參數，為每個 GDC 執行個體設定主要和副本資料庫伺服器。

如要為執行時間超過二進位記錄保留期限的現有執行個體啟用複製功能，可以使用資料庫備份還原副本資料庫，從主要資料庫開始複製。

在主要模式中，應用程式伺服器和資料庫的運作方式與目前相同，但主要資料庫會設為啟用複製功能。例如：

1. 啟用二進位記錄。

2. 設定伺服器 ID。

3. 建立複製功能使用者帳戶。

4. 建立備份。

在副本模式下，應用程式伺服器會停用票務網路服務，避免直接連線至副本資料庫。副本資料庫必須設為從主要資料庫開始複製，例如：

1. 設定伺服器 ID。

2. 設定複製使用者憑證和主要連線詳細資料，例如主機和通訊埠。

3. 從備份還原二進位記錄位置。

資料庫複製作業需要網路連線，副本才能連線至主要資料庫，開始複製。為了公開主要資料庫端點以進行複製，我們使用 Cloud Service Mesh 建立 Ingress 服務網格，支援在服務網格終止 TLS，類似於我們處理票務系統網頁應用程式 HTTPS 資料移轉的方式。