容器與虛擬機

什麼是容器與虛擬機？

容器與**虛擬機（VM）**是雲端打包並執行應用程式工作負載的兩大主流方式。從遠處看，兩者十分相似——都能在單一實體伺服器上執行多個隔離環境——但底層技術大相徑庭，成本、效能與營運方式也截然不同。Cloud Digital Leader（CDL）考試要求您能清楚說明兩者差異，並將各個模型對應到正確的 Google Cloud 產品。

虛擬機是一台完整的模擬電腦。它在一個稱為 Hypervisor 的軟體層之上，執行完整的客戶作業系統（Linux、Windows 等），Hypervisor 負責將實體伺服器的 CPU、RAM 與磁碟切分成隔離的區塊。在 Google Cloud 上，VM 服務是 Compute Engine。

容器是一個輕量級的軟體套件，只打包應用程式本身及其直接相依套件，不包含整個作業系統。多個容器共用同一個主機核心（kernel），因此啟動時間僅需秒甚至毫秒，記憶體用量也遠低於同等規格的 VM。在 Google Cloud 上，容器可在 Google Kubernetes Engine（GKE） 執行編排工作負載，或在 Cloud Run 執行無伺服器工作負載，映像檔儲存於 Artifact Registry。

對 CDL 考生而言，問題很少是「技術上容器是什麼？」，而是「企業什麼時候應該用容器，什麼時候 VM 仍然是正確選擇？」本章節建立這套決策框架，說明 Docker → 映像檔 → 登錄處 → 執行環境的完整流程，以商業領導者易懂的方式介紹 Kubernetes，並解說 Google Cloud 從 VM 到容器再到無伺服器的現代化旅程。

虛擬機：基礎抽象層

虛擬機是最早的雲端抽象層。在 VM 出現之前，一台實體伺服器只能執行一個作業系統。若工作負載只用了 10% 的 CPU，其餘 90% 就白白閒置。Hypervisor 改變了一切。

Hypervisor 的運作方式

Hypervisor 是介於實體硬體與一個或多個客戶作業系統之間的薄軟體層。它讓每個客戶 OS 以為自己獨佔整台機器，實際上 Hypervisor 在幕後調度 CPU 時脈、分配記憶體頁，並在客戶與真實硬體之間路由 I/O。Google Cloud 的 Hypervisor 是一個客製化強化版的 KVM，運行在 Google 的全球資料中心機群上。

Compute Engine 上的每台 VM 擁有自己的核心、自己的 /proc 檔案系統、自己的網路堆疊，以及自己的區塊裝置（Persistent Disk 或 Hyperdisk）。啟動 VM 時，您需要等待整個作業系統開機——標準 Linux 映像通常需要 30 到 90 秒，Windows Server 更久。

使用 VM 能獲得什麼

佈建 Compute Engine VM 時，您需要選擇：

• 機器系列（通用型：E2、N2、N4；運算最佳化：C3；記憶體最佳化：M3；加速器最佳化：A3，含 NVIDIA GPU）。
• 機器類型，定義 vCPU 與 RAM（例如：e2-medium = 2 vCPU、4 GB RAM）。
• OS 映像（Debian、Ubuntu、RHEL、Windows Server、COS，或您自訂的映像）。
• 開機磁碟與選用的額外磁碟。
• VPC 網路與防火牆設定。

接著您透過 SSH 登入，像操作任何實體 Linux 或 Windows 伺服器一樣使用 VM——安裝執行環境、部署應用程式、設定監控代理程式，並按自己的排程套用作業系統修補程式（或透過 OS Patch Management）。

完全隔離的代價

強隔離是 VM 最大的優勢，也是最大的成本。由於每台 VM 都執行完整的作業系統，您需要支付：

• 記憶體額外負擔： 客戶核心、init 系統、系統守護行程與套件管理工具，在應用程式啟動前就已佔用 200 MB 到 1 GB 的 RAM。
• 磁碟額外負擔： 每個 VM 映像都帶有完整的根目錄檔案系統，通常 2 到 20 GB。
• 啟動時間： 冷啟動需要 30 秒以上，使按請求擴展不切實際。
• 修補工作量： 每台 VM 都是您必須自行修補、監控與強化的獨立伺服器。

對於持續運行且需要強隔離的工作負載——資料庫、授權鎖定的企業軟體、GPU 訓練任務——這些代價完全可以接受。對於需要快速擴展或高密度部署的工作負載，則會成為瓶頸。

容器：現代打包單元

容器是一個行程——或一小群行程——在主機作業系統上執行，透過 Linux 核心功能與其他行程隔離，包括命名空間（namespace，用於檔案系統、網路與行程可見性）以及 cgroups（用於 CPU 與記憶體限制）。關鍵在於：單一主機上的所有容器共用同一個核心。

容器映像檔與 Docker 工作流程

您發布的不是容器本身，而是容器映像檔。映像檔是唯讀的分層檔案系統快照，包含應用程式執行檔、其函式庫，以及最小化的使用者空間（通常基於 Alpine、Debian-slim 或 Google 的 Distroless 基礎映像）。主流的映像建置工具是 Docker，但 Buildpacks、Kaniko 和 ko 等替代方案都能產生符合 OCI 標準的映像格式。

完整的工作流程如下：

1. 撰寫 Dockerfile，描述基礎映像、相依套件與進入點（CDL 考試不要求您撰寫 Dockerfile 語法——只需理解概念）。
2. 建置映像，使用 docker build 或 Cloud Build。
3. 推送映像至容器登錄處。在 Google Cloud 上，這是 Artifact Registry，它於 2023 年取代了舊版的 Container Registry。
4. 拉取並執行映像，部署在安裝有容器執行環境的主機上——containerd、Docker Engine，或 GKE、Cloud Run 等受管服務。

映像檔的不可變性

容器映像檔是不可變的產出物。您在開發環境測試的同一份映像，在預備與正式環境中位元對位元地完全相同。這消除了「在我的電腦上能跑」這類問題，也是現代 CI/CD 流程的基礎。

容器 vs VM 一覽

白話文解釋

容器與 VM 的技術差異，只要對應到台灣人熟悉的日常場景，就會變得容易記憶。以下三個類比呈現的是同一個核心概念——共用底層基礎讓您跑得更快、裝得更多——但各自著重不同的決策面向。

類比 1 — 公寓大樓 vs 旅館客房

想像要在台北市中心安置 50 個人，有兩種方式。

租 50 間獨立公寓（Compute Engine 上的虛擬機），每個房客擁有自己的廚房、自己的熱水器、自己的電表、自己的大門。隔離效果絕佳——一間公寓發生的事不會影響另一間。但整棟大樓必須提供 50 個廚房、50 台熱水器、50 套獨立的水管配管。建設費用昂貴、維護費用昂貴，而且搬入要花一週，因為每間公寓都必須完整裝潢。這正是 Compute Engine 上執行 50 台 VM 的樣子——每台 VM 有自己的核心、自己的 systemd、自己的網路堆疊、自己的磁碟。強隔離，高額外負擔。

租 50 間旅館客房（GKE 或 Cloud Run 上的容器），50 位房客共用旅館的中央廚房、中央洗衣房、中央空調系統與中央警衛室。每個房間仍有自己的床、浴室和門鎖——這就是容器透過命名空間獲得的隔離。但沉重的共用基礎設施由整棟建築一次性提供。新房客五分鐘就能入住，而非五天。旅館在相同的樓地板面積內可以放 200 間客房，因為共用設施不會隨房客數量倍增。這就是容器模型：共用核心、隔離行程、遠高的密度。

在 Google Cloud 上，當您將十台執行 Node.js API 的 Compute Engine VM 遷移至 Cloud Run，通常可以節省 30 到 70% 的費用，因為您不再為十套冗餘的 Linux 安裝付費。Artifact Registry 儲存逐間客房的「藍圖」（容器映像檔），Cloud Run 是按需訂房的旅館連鎖，GKE 則是為有複雜需求的房客提供禮賓服務（編排）的高階旅館。

類比 2 — 自己開餐廳 vs 在夜市租攤位

您想在信義區賣牛肉麵給上班族。

自己開一家獨立餐廳（VM），意味著簽十年商業租約、申請自來瓦斯管線、聘請水電師傅、裝設油脂截留器、應付衛生稽查，以及從零開始裝潢。廚房完全屬於您——您可以安裝炭火爐、200 公升的大鍋，任何設備都行。但總開辦成本輕易就要 300 萬新台幣，而且生意淡季時仍要支付整個空間的租金。這就是在 Compute Engine 上執行客製化 OS 應用程式的感覺——您控制核心、可安裝客製驅動程式、可執行 GPU 工作負載——但不管繁忙或閒置，都要為整台 VM 付費。

在夜市租一個攤位（Cloud Run 或 GKE 上的容器），意味著您走進一個已備好瓦斯、排油設備、座位區、洗碗站、清潔人員與冷氣的場地。您帶來配方、招牌食材與品牌識別。兩天就能開張，而不是兩個月，而且您可以搬到別區的另一個夜市，只需重新印製招牌——不可變的容器映像檔就相當於您的配方手冊，在任何符合規格的廚房都能使用。

以 Google Cloud 術語來說，「夜市場地」是 GKE 或 Cloud Run 所在的主機 VM，「共用水電設施」是主機核心與容器執行環境，「攤位」是您各自的容器。GKE Autopilot 是高級夜市，管理方決定開幾個攤位、何時開設，自動最佳化人流。Cloud Run 是更隨需應變的模式——只有顧客真正來到攤位前才收費，夜市打烊時自動縮減到零。

類比 3 — 貨運：木箱 vs 標準化貨櫃

1956 年之前，貨物運輸是一場噩夢。每批貨物使用不同大小的木箱、麻袋或桶子。裝船需要數週，因為碼頭工人必須一件一件搬運。貨物在途中損壞、遺失或被竊。每次轉運——從貨車到輪船到火車——都必須完整拆包再重新打包。

後來 Malcolm McLean 發明了標準化的國際貨運集裝箱。突然間，每個貨運單元都是相同規格——20 或 40 英尺長、可堆疊、可上鎖，最關鍵的是不需要拆包，就能跨越貨車、火車與輪船流通。原本要三週才能裝完的輪船，現在一天就能裝載完畢。全球貿易量爆炸性成長。

軟體容器將同樣的理念套用在應用程式上。容器出現之前，部署軟體猶如木箱時代——每個團隊有自己的腳本、每台伺服器有些微的設定漂移，「在我電腦上能跑」是每日的煩惱。Docker 標準化了 OCI 映像格式之後，同一份映像可以在開發者的筆記型電腦、CI 流程、Compute Engine VM、GKE 叢集或 Cloud Run 服務上執行，無需任何修改。

Artifact Registry 是容器的「港口碼頭」——儲放整疊標準化映像等待裝載的安全地點。Kubernetes（以及 GKE）是港口的起重機操作員，決定哪個貨櫃裝上哪艘船（節點），以及如何堆疊。Cloud Run 是隨需快遞服務，取出一個容器、完成單次配送，送達後歸還儲存。可攜性的故事與集裝箱革命如出一轍：一旦標準化了單元，整個物流網絡就會加速運轉。

Docker → 映像檔 → 登錄處 → 執行環境的完整流程

CDL 考試不要求您撰寫 Dockerfile，但您需要理解容器從原始碼到 Google Cloud 執行工作負載的四個概念階段。

第一階段 — 建置

開發者撰寫 Dockerfile，描述基礎 OS 層、應用程式相依套件與啟動指令。Cloud Build（Google Cloud 的受管 CI 服務）讀取這份 Dockerfile，建置映像並標記版本號。Cloud Build 可直接從 GitHub 或 Cloud Source Repositories 觸發建置，無需開發者的筆記型電腦介入。

第二階段 — 推送至 Artifact Registry

建置好的映像推送至 Artifact Registry，這是 Google Cloud 的受管產出物儲存服務。Artifact Registry 支援容器映像檔，以及 Maven、npm、Python、Go 與 OS 套件格式——一個整合的儲存庫，管理所有軟體產出物。映像以區域或多區域方式儲存，並受 IAM 政策保護，只有經授權的服務帳號才能拉取映像。

第三階段 — 弱點掃描

Artifact Registry 可以使用 Container Analysis 自動掃描每個推送的映像，檢查已知的 CVE（Common Vulnerabilities and Exposures）。掃描結果回饋至 Binary Authorization，後者可阻擋任何不符合政策的映像部署。

第四階段 — 拉取並執行

運算目標——GKE 節點、Cloud Run 服務，或安裝了容器最佳化 OS 的 Compute Engine VM——從 Artifact Registry 拉取映像並啟動。映像會在本地快取，後續重啟近乎即時。在 Cloud Run 上，整個拉取與啟動週期通常只需一到三秒。

Kubernetes 與容器編排

在單一伺服器上執行一個容器很簡單。在 50 台伺服器上執行 500 個容器——同時處理健康檢查、滾動升級、流量路由、密鑰管理，以及在某個容器掛掉時自動重啟——則截然不同。解決這個難題的系統就是 Kubernetes，常縮寫為 K8s。

Kubernetes 的功能

Kubernetes 是一個容器編排器。它最初由 Google 內部開發，是內部 Borg 系統的開源後繼者，於 2015 年捐贈給雲端原生運算基金會（CNCF），已成為正式環境執行容器的實際標準。在概念層面，Kubernetes：

• 根據可用的 CPU 與記憶體，將容器排程到節點（底層 VM）上。
• 自動重啟失敗的容器。
• 發布新映像版本時執行滾動升級。
• 將流量路由至健康的容器，遠離不健康的容器。
• 根據需求自動增減容器數量。
• 管理在執行時注入容器的設定與密鑰。

Pod、Deployment 與 Service——CDL 層級理解

CDL 考試不要求您撰寫 Kubernetes 清單，但您應該認識三個關鍵術語：

• Pod 是最小的可部署單元——一個或多個緊密耦合的容器，共用網路位址與儲存空間。大多數 Pod 只包含單一容器。
• Deployment 宣告「我需要 N 個副本的此 Pod，執行此映像版本，以此策略進行升級。」Kubernetes 讓現實與宣告保持一致。
• Service 是穩定的網路端點，對 Deployment 的各個 Pod 進行負載平衡。Pod 來來去去，Service 的 IP 與 DNS 名稱保持不變。

GKE 與 GKE Autopilot

Google Kubernetes Engine（GKE） 是 Google Cloud 的受管 Kubernetes 服務，提供兩種營運模式：

• GKE Standard： 您管理節點池——執行 Pod 的 VM。您選擇機器類型、設定自動擴展政策，並處理節點升級（Google 仍負責管理控制平面）。
• GKE Autopilot： Google 代您管理節點。您只需指定工作負載，Google 決定要佈建哪些 VM 以及大小。依請求的 vCPU 與記憶體的 Pod 秒數計費，消除了閒置節點的成本。

對於新的 Kubernetes 工作負載，GKE Autopilot 是建議的預設選項，因為它在保留完整 Kubernetes API 相容性的同時，大幅降低了節點管理的營運負擔。

Cloud Run：無伺服器容器

Cloud Run 是 Google Cloud 的無伺服器容器平台。您建置 Docker 映像、推送至 Artifact Registry、指向 Cloud Run，即可獲得一個 HTTPS 端點，在數秒內從零擴展到數千個執行個體。Cloud Run 處理 TLS 終止、負載平衡、自動擴展、流量分流，以及按每 100 毫秒計費——您無需撰寫任何基礎設施程式碼。

Cloud Run 的重要性

Cloud Run 匯聚了三個強大的特性：

• 容器可攜性： 任何可打包為 OCI 映像的內容都能在 Cloud Run 上執行——Python、Node.js、Go、Java、.NET 6+、Rust，甚至自訂的 C 二進位檔。
• 無伺服器經濟效益： 無節點需要管理、縮減到零計費、按請求定價。一個 Cloud Run 服務若整週沒有流量，該週費用為零。
• 營運簡便： 無叢集、無節點池、無複雜的網路配管。部署後即可忘懷。

Cloud Run Services vs Cloud Run Jobs

• Cloud Run services 處理 HTTP、gRPC 與 WebSocket 流量——典型的 API、網頁應用程式與 Webhook 接收器。
• Cloud Run jobs 將容器執行至完成，用於批次工作（每晚的資料匯出、ETL 執行、排程報告）。它們不監聽連接埠。

VM 仍然勝出的情境

容器並非永遠是正確答案。CDL 題目有時會描述 Compute Engine VM 仍然是最佳選擇的情境，識別這些情境可以輕鬆拿分。

情境 1 — 無法容器化的舊版應用程式

某些企業應用程式需要特定的 Windows Server 版本、安裝核心模式驅動程式，或使用假設完整 OS 存在的系統服務。容器化在技術上可行，但通常不具經濟效益。使用 Migrate to Virtual Machines（M2VM）直接搬遷至 Compute Engine，再逐步現代化。

情境 2 — GPU 驅動程式與特殊硬體

GPU 密集型工作負載（AI 訓練、科學模擬、3D 渲染）通常需要直接存取 NVIDIA 驅動程式、CUDA 或廠商特定的核心模組。Compute Engine A2/A3/G2 機器系列，搭配 NVIDIA T4、L4、A100 或 H100 GPU，是標準選擇。雖然 GKE 支援 GPU 節點，但對許多 ML 團隊而言，裸 VM 路徑更為簡單。

情境 3 — 授權鎖定的軟體

企業軟體供應商通常依 VM 數量、插槽數量，或特定 OS 版本進行授權。傳統 VM 模型能清晰滿足這些授權限制；容器模型則可能模糊或不受支援。

情境 4 — 法規合規所需的強隔離

部分合規法規要求硬體層級隔離——例如某些政府工作負載或金融業的安全隔區。Compute Engine 上的 Hypervisor 隔離，輔以 Confidential VMs（AMD SEV / Intel TDX 硬體加密），超越了共用核心容器所能提供的隔離程度。

情境 5 — 自訂核心或網路

需要自訂核心模組、原始 Socket 存取，或主機未向容器公開的特定 Linux 核心功能的工作負載，在您能控制核心建置的專屬 VM 上會更可靠地執行。

直接搬遷再現代化的遷移模式

大多數企業不會直接從地端跳躍到無伺服器容器。Google Cloud 驗證有效的路徑是三階段現代化旅程。

第一階段 — 直接搬遷至 Compute Engine（Migrate to Virtual Machines）

使用 Migrate to Virtual Machines（M2VM）（前身為 Migrate for Compute Engine），將現有地端 VM 原封不動地搬移至 Compute Engine。應用程式程式碼不變，工作負載只是改在 Google 的硬體上執行，而非地端機架。遷移速度快（通常數天到數週），即刻獲得彈性擴展、全球網路與 Cloud Monitoring 可觀測性。

第二階段 — 使用 Migrate to Containers 容器化

工作負載上到 Google Cloud 後，Migrate to Containers（M2C） 分析選定的 VM，提取應用程式執行檔及其相依套件，並產出帶有 Kubernetes 清單的容器映像檔。輸出結果在 GKE 或 Cloud Run 上執行，大幅縮減需要修補作業系統的範圍。

第三階段 — 朝無伺服器重構

應用程式在容器中執行後，團隊通常會將整合型應用程式拆分為較小的服務，以 Pub/Sub 和 Cloud Functions 取代有狀態的黏合程式碼，並將無狀態 HTTP 服務遷移至 Cloud Run。最終狀態通常是舊版元件保留部分 VM，但將大部分新功能移至無伺服器容器。

容器與 Google Cloud 其他服務的整合

GKE 或 Cloud Run 上的容器工作負載，可直接接入更廣泛的 Google Cloud 平台：

• 網路： Cloud Run 服務與 GKE 工作負載可放在 Cloud Load Balancing 後方，透過 Cloud CDN 獲得全球任播 IP，並使用 API Gateway 或 Apigee 路由請求。
• 身分識別： IAM 管控誰能部署容器，Workload Identity 讓每個容器以 Google 服務帳號的身分存取 Cloud Storage、BigQuery、Spanner 等服務，無需管理靜態金鑰。
• 資料： 容器通常寫入 Cloud SQL、Firestore、Spanner、BigQuery 或 Cloud Storage——儲存決策框架請參閱 /en/certs/gcp/cdl/topics/google-cloud-databases。
• 訊息傳遞： Pub/Sub 透過推送訂閱將事件傳遞至 Cloud Run 服務，實現事件驅動的容器架構。
• 可觀測性： Cloud Logging、Cloud Monitoring 與 Cloud Trace 以最少設定自動擷取容器日誌與指標。

關於將容器置於 App Engine 與 Cloud Functions 脈絡中的更廣泛運算決策框架，請參閱 /en/certs/gcp/cdl/topics/google-cloud-compute-options。關於這種現代化如何節省費用並加速團隊，請參閱 /en/certs/gcp/cdl/topics/cloud-value-proposition。

成本與營運比較

成本視角往往能清楚釐清 CDL 情境中 VM 與容器的選擇。

• Compute Engine（VM）： 依整台 VM 的秒數計費（最低 1 分鐘），無論 CPU 使用率如何。持續使用折扣（SUDs） 自動套用；承諾使用折扣（CUDs） 可在 1 年或 3 年合約下節省 20 到 60%。Spot VM 為可容錯工作負載提供 60 到 91% 的折扣。風險：閒置的 VM 仍持續計費。
• GKE Standard： 依節點 VM（Compute Engine 定價）加小額叢集費計費。工作負載密度很重要——在每個節點上放更多 Pod，以攤銷節點成本。
• GKE Autopilot： 依請求的 vCPU、記憶體與暫時性儲存空間的 Pod 秒數計費。無閒置節點成本——更接近無伺服器計費模型，同時保留 Kubernetes API。
• Cloud Run： 依服務請求期間每 100 毫秒的 CPU 與記憶體計費，另加小額每請求費用。縮減到零在預設層級為自動且不可避免。

對於全天候運行的穩態內部應用程式，搭配 CUD 的 Compute Engine 通常最便宜。對於流量忽高忽低的公開 API，Cloud Run 在成本上勝出。對於擁有數十個內部服務的微服務架構，GKE Autopilot 在成本與編排能力之間取得平衡。

安全態勢：容器 vs VM

容器安全是獨立的專業領域，但 CDL 層級的摘要很直接：

• VM 透過 Hypervisor 在硬體層級隔離，使跨 VM 的攻擊極為困難。Confidential VMs 在 AMD SEV 或 Intel TDX 晶片上增加硬體記憶體加密。
• 容器透過命名空間與 cgroups 在核心層級隔離。理論上，核心弱點可能讓一個容器逃脫並攻擊另一個，因此縱深防禦很重要：GKE Sandbox（gVisor）在容器與主機核心之間增加一個使用者空間核心；Binary Authorization 強制只有已簽署、已掃描的映像才能部署；Workload Identity 從容器中移除長期存活的憑證。

對大多數工作負載而言，搭配 Binary Authorization、弱點掃描與 Workload Identity 的容器安全能提供優異的保護。對頂級合規要求，Confidential VMs 或 Confidential GKE 節點增加了硬體加密層。

常見問題

Q：容器一定比虛擬機更快嗎？

A： 就啟動時間與打包大小而言，是的——容器因為重用主機核心、只打包應用程式層，啟動時間以秒計算，而 VM 需要 30 到 90 秒才能完整開機。就穩態執行時的 CPU 效能而言，差異可忽略不計——兩者都在相同的實體硬體上執行。容器的優勢在於密度、啟動速度與部署速度，而非原始運算吞吐量。

Q：我可以在容器內執行 Compute Engine VM，或反過來嗎？

A： 容器永遠在作業系統之上執行，而作業系統本身通常在 VM（或裸機）上執行——因此字面上容器確實在 VM「內部」執行。反過來則不實際：您無法在標準容器內執行完整的 VM，因為容器共用主機核心。Compute Engine 上的巢狀虛擬化（Nested Virtualization） 允許在特定情境（例如在自訂環境中執行 KVM）下 VM 執行在 VM 內。

Q：Cloud Run 是受管的 Kubernetes 服務嗎？

A： 不是。Cloud Run 是建立在開源 Knative 專案上的無伺服器容器平台，但不公開 Kubernetes API。您無法對 Cloud Run 使用 kubectl。若您需要 Kubernetes 原生功能——Operator、自訂資源、多容器 Pod、StatefulSet、DaemonSet——請使用 GKE Autopilot 或 GKE Standard。若您只需要在縮減到零的情境下執行無狀態 HTTPS 容器，Cloud Run 更簡單。

Q：企業什麼時候應選 GKE Standard 而非 GKE Autopilot？

A： 當您需要精細的節點控制時，GKE Standard 較合適——Autopilot 尚未支援的自訂機器類型、特定核心參數、必須在每個節點上執行的 DaemonSet、具有特殊驅動程式需求的 GPU 或 TPU 工作負載，或要求特定執行個體規格的授權模型。其他情況，GKE Autopilot 是建議的預設選項，因為它消除了節點管理的營運負擔。

Q：容器完全取代了 Compute Engine 的需求嗎？

A： 不會。Compute Engine 仍然是無法容器化的舊版工作負載、GPU/TPU 訓練任務、授權鎖定的軟體、特定核心或驅動程式需求，以及強隔離合規要求的正確答案。現代模式是在 Cloud Run 或 GKE 上執行新工作負載，同時在 Compute Engine 上保留舊版工作負載，然後在商業案例充分時，使用 Migrate to Containers 選擇性遷移。

Q：Container Registry 與 Artifact Registry 有什麼差別？

A： Container Registry 是較舊的 Google Cloud 產品（2023 年已棄用）。Artifact Registry 是現代替代品，不僅儲存容器映像檔，還儲存 Maven、npm、Python、Go 與 OS 套件產出物，整合成單一受管服務。新專案應獨家使用 Artifact Registry；現有的 Container Registry 使用者有遷移路徑可循。

總結

容器 vs 虛擬機的決策是每個現代 Google Cloud 架構的基礎：

• 虛擬機（Compute Engine）提供完整的 OS 控制、硬體層級隔離與廣泛的相容性——代價是啟動時間較慢、密度較低，以及每個工作負載的額外負擔較高。
• 容器（GKE、Cloud Run）提供秒級啟動、高密度與映像可攜性——代價是共用主機核心，並需要建立映像建置紀律。
• Artifact Registry 是容器映像檔的安全存放地，搭配 Container Analysis 掃描與 Binary Authorization 政策執行。
• Kubernetes（以 GKE Autopilot 或 GKE Standard 形式提供）透過 Pod、Deployment 與 Service 大規模編排容器。
• Cloud Run 以無伺服器方式執行容器——縮減到零、按請求計費、支援任何語言——但不是 Kubernetes API。
• VM 仍然勝出的情境：舊版應用程式、GPU 工作負載、授權鎖定的軟體，以及強隔離合規要求。
• Google Cloud 的現代化旅程是 M2VM → M2C → 無伺服器：先直接搬遷，再容器化，最後朝 Cloud Run 和 Cloud Functions 重構。

身為 Cloud Digital Leader，您的職責是識別每個情境的主要限制——OS 控制、擴展速度、成本、合規、團隊專業知識——並對應到正確的執行環境：Compute Engine 用於 VM、GKE 用於編排容器、Cloud Run 用於無伺服器容器。掌握這套對應關係，您就能有信心回答 CDL 考試中任何容器 vs VM 的題目。