VM 工作負載部署作業總覽

本指南涵蓋的概念背景，有助您使用 VM Runtime，將以虛擬機器 (VM) 為基礎的工作負載，部署到裸機上的 Google Distributed Cloud (GDC) 氣隙叢集。本指南中的工作負載是範例票務系統平台，可在內部部署硬體上使用。

架構

資源階層

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

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

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

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

網路

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

Cloud Service Mesh 是 Google 根據開放原始碼專案建構而成，可管理、觀察及保護服務。我們運用 Cloud Service Mesh 的下列功能，在 GDC 上代管售票系統：

• 負載平衡：Cloud Service Mesh 會將流量與基礎架構的資源調度加以分離，可提供許多流量管理功能，包括動態要求轉送。票務系統需要持續的用戶端連線，因此我們使用 DestinationRules 啟用固定式工作階段，以設定流量轉送行為。

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

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

在 Kubernetes 叢集內，我們使用標準 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 虛擬機器 (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: <a href="/distributed-cloud/hosted/docs/latest/gdch/gdch-io/service-manual/ts/runbooks/ts-r0001">TS-R0001</a>
      resource: vm1
    annotations:
      message: "vm1 disk usage above 90% utilization"

確認系統穩定性後，我們將重心轉移到票務系統中的應用程式故障模式。由於我們經常需要透過安全殼層 (SSH) 連線至每個應用程式伺服器 VM，才能檢查票務系統記錄，因此我們設定了應用程式，將這些記錄轉送至記錄工具，以便在 GDC 可觀測性堆疊上建構，並在監控執行個體中查詢所有票務系統作業記錄。

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

備份

備份對軟體系統的運作至關重要，因為系統發生故障時，備份可讓系統復原。GDC 可透過 Kubernetes 資源備份及還原 VM。建立VirtualMachineBackupRequest自訂資源VirtualMachineBackupPlanTemplate，即可將連結至每個 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. 作業系統升級。
2. 平台升級，例如修補程式和主要版本。
3. 更新設定。

為升級 OS，我們會持續為應用程式和資料庫伺服器建構及發布新的 VM 映像檔，並在每次 GDC 發布時一併發布。這些映像檔包含安全漏洞的修正程式，以及基礎作業系統的更新。

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

最後，透過票務系統 API 更新集和其他使用者資料，即可套用設定更新，不會造成停機。我們會在開發和預先發布環境中開發及測試設定更新，然後在 GDC 發布程序中，將多個更新集封裝在一起。

整合

識別資訊提供者

為提供順暢的客戶體驗，並協助機構導入使用者，我們將票證系統與 GDC 中提供的多個身分識別供應商整合。一般來說，企業和公部門客戶都有自己的身分識別資訊提供者，可妥善管理員工的授權授予和撤銷作業。為符合法規要求，並簡化身分和存取權控管作業，這些客戶希望使用現有的身分識別提供者做為單一事實來源，管理員工對票務系統的存取權。

票務系統透過多重身分識別提供者模組，同時支援 SAML 2.0 和 OIDC 提供者。我們已在應用程式伺服器 VM 映像中預先啟用這個模組。顧客會透過機構的 IDP 進行驗證，系統會自動在票務系統中建立使用者並指派角色。

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

快訊擷取

除了讓使用者登入並手動建立支援案件，我們也會根據系統快訊建立票證系統事件。

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

API 金鑰會儲存在 GDC 密鑰存放區，並透過角色型存取權控管 (RBAC) 機制控管 Kubernetes 密鑰。其他設定 (例如 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 資料傳輸方式。