零經驗轉職，從雲端工程師入門最快。

打開 104，搜尋「雲端」或「GCP」，你會看到一堆職稱跳出來：雲端工程師、雲端架構師、SRE、DevOps 工程師、資料工程師⋯⋯

看起來都跟雲端有關，但薪資區間、要會的技能、日常工作內容差距很大，光是月薪區間的起點，架構師就比工程師高 2 萬以上。

這是轉職者最常卡住的第一個問題：「我到底該投哪一個？」

為什麼一定要先搞懂職缺差別？

搞錯職缺，你會浪費半年學錯東西。

想當架構師卻先去學 Python 、想走 SRE 卻只考了 Associate 認證，這兩種情況都是真實發生過的彎路。

5 種角色的技能重疊度不到一半，證照方向也不同。先確定要走哪一條，再開始學，是最省時間的做法。

先用一個比喻，30 秒秒懂 5 種角色

把一個跑在雲端上的系統，想像成「一棟蓋在雲上、24 小時營業的大樓」：

• 雲端架構師（Cloud Architect）＝設計師：決定這棟樓怎麼蓋、幾層、水電怎麼配、消防怎麼做。動手少，但方向錯了全樓要打掉重來。
• 雲端工程師（Cloud Engineer）＝施工與水電師傅：照著設計圖把樓蓋起來、把服務一個一個裝上去、平常的修修補補。
• SRE（網站可靠性工程師）＝大樓的保全兼維修隊：確保這棟樓 24 小時不斷電、不出事，出事能最快修好，還會想辦法用自動化讓自己少值班。
• DevOps 工程師＝生產線的自動化總管：讓「設計→施工→開張」這條線跑得又快又順，蓋新東西不用每次都手工搬磚。
• 資料工程師（Data Engineer）＝專門鋪水管的人：把散在各處的資料，用管線接到一個大水塔（資料倉儲），讓需要用水（分析、AI）的人隨時打開就有。

記住這個比喻，下面每一段就很好懂了。

雲端工程師（Cloud Engineer）：最好的轉職起點

在做什麼？

雲端工程師是負責在雲端平台上實際建置與維運系統的執行角色，用來把架構師畫好的藍圖變成真的跑得起來的服務。

架構師畫好藍圖之後，由雲端工程師到 GCP、AWS、Azure 上把資源建起來。

日常工作包括：開 VM、設定虛擬私有網路（VPC，你在雲上的專屬網段）、部署 Cloud Run、設定權限（IAM）、處理維運和排錯。

一句話：架構師決定「要怎麼蓋」，雲端工程師負責「把它蓋出來、顧好它」。

需要什麼技能？

• 一朵雲的基本操作（建議先專精 GCP 或 AWS 一朵）
• Linux 基本指令、網路基礎（IP、DNS、防火牆）
• 容器基礎（Docker）
• 會看 Log、會排簡單的錯

薪水與適合誰

台灣月薪參考區間約 5～8 萬，同一個職稱在不同公司的落差可達 3 萬。

這是 5 種角色裡入門門檻最低、需求量最大的職缺，適合零經驗和非本科。

先卡進這個位置累積實戰，再往架構師發展，是最務實的路線。

雲端架構師（Cloud Architect）：薪資天花板最高

在做什麼？

雲端架構師是負責規劃整體雲端方案的設計角色，用來在系統動工前決定架構、成本與資安要怎麼配。

他要跟業務單位溝通需求，回答這些問題：系統要不要自動擴充（Autoscaling）？資料庫怎麼配才不會掛？成本怎麼壓？資安怎麼守？

架構師動手寫程式的比例比工程師低，但這不代表「不用懂 code」。

好的架構判斷，正是建立在「知道底層怎麼實作、會踩到什麼坑」之上。

差別在於，架構師的價值在「判斷怎麼設計才不會出事」，而不是「把功能刻出來的速度」。

需要什麼技能？

• 工程師那一整套技能，再往上加
• 整體架構設計能力（網路、運算、資料庫、資安怎麼串在一起）
• 成本意識（CUD／SUD 折扣、預算控制）
• 溝通能力：把技術講給非技術主管聽
• 當你要應徵架構師職缺時，Professional 等級認證是明確的加分條件

薪水與適合誰

台灣月薪參考區間約 6～12 萬以上，資深加上業務開發能力可以更高（詳細分級可看我另一篇《雲端架構師薪水完整指南》）。

適合已經有一些 IT 底子、想往上走、想突破薪資天花板的人。

雲端工程師和架構師的差別，最簡單記法：工程師「把系統做出來、顧好」，架構師「決定整個系統該長什麼樣」。同年資下，架構師的月薪區間起點比工程師高 3 萬以上。

轉職者最務實的路徑是：先當工程師卡位，累積各種架構經驗之後，再升架構師。

SRE 與 DevOps 工程師：高度重疊、常常混用

這兩個職稱在台灣的職缺裡界線非常模糊，有些公司直接混著用。但概念上還是有差別。

DevOps 是一種「文化與做法」

DevOps 原本不是一個職稱，而是一種「把開發（Dev）和維運（Ops）打通」的做法。

目標是讓「寫好程式→測試→上線」這條路自動化、又快又穩，不要每次上線都手忙腳亂。

DevOps 工程師的日常，圍繞在三件事：

1. 建立 CI/CD 流水線（CI/CD 是「持續整合／持續交付」，指程式一改好就自動測試、自動上線的機制）
2. 用 IaC（基礎架構即程式碼，例如 Terraform）把環境設定寫成可重複執行的檔案
3. 把重複的部署工作自動化

SRE 是「用軟體工程的方法做維運」

SRE（Site Reliability Engineering）是 Google 提出的可靠度工程方法，用來以軟體工程的手段確保系統穩定，可以理解成 DevOps 的一種具體實作。

SRE 更強調用數據和工程手段顧穩定：

• SLO／SLI：訂出可量化的可靠度目標，例如「一個月內成功率要達 99.9%」
• Error Budget（錯誤預算）：從 SLO 反推出「這個月還能容忍多少故障時間」，用完就停止上新功能
• Toil（重複勞務）：指可以被自動化卻還在手動做的工作，SRE 的任務之一就是把它消滅

一句話：DevOps 是理念，SRE 是把這套理念工程化落地的做法。

需要什麼技能 & 適合誰

• 兩者都要：熟一朵雲、容器與 Kubernetes（GKE）、CI/CD 工具、監控告警、寫腳本自動化（Python／Shell）
• SRE 職缺對寫程式和數據思維的要求，比 DevOps 更明確
• 台灣月薪參考區間約 7～14 萬
• 適合已經有開發或系統維運經驗、喜歡用自動化消滅重複工作的人；零經驗要先補不少底子

SRE 和 DevOps 差在哪？DevOps 是「理念」，把開發和維運打通、追求自動化交付；SRE 是「其中一種工程化做法」，用 SLO、error budget、削減 toil 來顧穩定。在台灣的職缺裡兩者常混用，看職務說明（JD）比看職稱準。

資料工程師（Data Engineer）：最需要寫程式的工作

在做什麼？

資料工程師是負責建置與維護資料管線的角色，用來把散落各系統的資料收乾淨、送進資料倉儲，讓分析和 AI 隨時有料可用。

他要把資料透過資料管道（Data Pipeline）收集、清理、轉換，送進資料倉儲（像 BigQuery，一個專門存放大量分析用資料的地方）。

在 GCP 上，這個角色天天碰的是 BigQuery、Dataflow、Pub/Sub、Cloud Composer 這些服務。

需要什麼技能？

• 要會寫程式：SQL 是基本，Python 是資料工程師職缺最常列出的語言（這一點跟架構師很不一樣，別搞混）
• 資料庫與資料建模概念
• 資料管道工具（ETL／ELT，指把資料「抽取→轉換→載入」的兩種流程順序）
• 大數據處理（批次 vs 串流），串流資料 (Streaming Data) 指的是「每分每秒持續不斷產生的資料」。

薪水與適合誰

台灣月薪參考區間約 8～16 萬，AI 熱潮下需求持續走高。

適合喜歡跟資料打交道、不排斥寫程式的人。

如果你本來就是後端工程師、或做過數據相關工作，這是很順的轉職方向。

一張表看懂 5 種雲端職缺

⚠️ 薪資皆為市場「參考區間」，實際受公司規模、產業、年資、面試表現影響，不是保證數字。最準的方式是自己上 104 搜尋對應職稱，看你所在地區實際開出來的薪資與職缺量。

重要提醒：這些職稱的界線，在台灣其實很模糊

上面的分法是「理想中的分工」，但台灣的中小型公司沒有分這麼細。

一個人同時做架構設計、資源部署、CI/CD 維護，甚至兼顧資料庫，在中小型團隊是常態。

反過來，當公司規模大到有獨立的 SRE 團隊時，角色會切得很細，SRE 就是 SRE，不碰資料管道。

所以我的建議是：別太糾結職稱，要看「職務說明（JD）」裡實際列的工作內容和技能要求。

職稱只是入口，JD 才是你真正要做的事。

我該從哪一個入門？轉職路徑建議

如果你正在轉職，我會這樣建議：

1. 零經驗／非本科：從雲端工程師入門。入門門檻最低、需求最大，先考一張 Associate 等級認證（如 GCP Associate Cloud Engineer）卡進去，累積實戰。
2. 已有 IT 底子（後端、網管、系統）：可以直接朝雲端架構師或 SRE／DevOps 準備，考 Professional 等級認證。
3. 做過資料、喜歡寫程式：資料工程師會是很順的方向。

不管走哪一條，共同的起手式都是這三步：

1. 選定一朵雲（建議先專精 GCP 或 AWS）
2. 考一張對應等級的證照
3. 想辦法碰到真實專案 （你可以叫 AI 出題目，也能教你手把手實作專案）

這三件事同步做，比漫無目的地自學快得多。

到底該考哪一張 GCP 證照？非 IT 背景建議先考 Associate 拿手感，有 IT 背景可以直接攻 Professional。（這部分我另有專文詳談。）

雲端職缺 FAQ 常見問題

Q1：完全沒經驗，我該投哪一個雲端職缺？

A： 投雲端工程師（Cloud Engineer）。這是 5 種雲端職缺裡入門門檻最低、需求量最大的職缺，適合零經驗和非本科。先考一張 Associate 等級認證卡進去，邊做邊學，再往架構師或 SRE／DevOps 發展。

Q2：SRE 和 DevOps 到底差在哪？

A： DevOps 是一種「把開發和維運打通、追求自動化交付」的理念與做法；SRE 則是 Google 提出的具體實作，用 SLO、Error Budget、削減 Toil 這些工程手段來落實它。在台灣的職缺裡兩者經常混用，看職務說明比看職稱準。

Q3：資料工程師需要很會寫程式嗎？

A： 需要。資料工程師是這 5 個角色裡最需要寫程式的，SQL 是基本，Python 是職缺中最常出現的語言要求。這一點和雲端架構師剛好相反（架構師寫 code 較少、重在設計判斷），常被搞混，轉職前要想清楚自己喜不喜歡寫程式。

Q4：這幾個職缺，哪個薪水最高？

A： 以台灣市場的天花板來看，資料工程師最高，其次資深 SRE 與雲端架構師。但同一個職稱在不同公司可以差兩倍以上，認證、實戰成果和產業別對薪資的影響比職稱本身更大。

Q5：這些職缺都要會 Kubernetes 嗎？

A： 不一定，但會是加分。SRE、DevOps 幾乎一定要碰 Kubernetes（在 GCP 上就是 GKE）；雲端工程師和架構師要懂概念、知道何時該用，不見得天天操作；資料工程師相對碰得少。想走 SRE／DevOps，Kubernetes 是必補的一塊。

Q6：非資訊科系、學歷普通，投雲端職缺會被刷掉嗎？

A： 雲端職缺看的是「你能不能操作」，不是科系。104 上的雲端工程師職缺，多數把證照和專案經驗列在必要條件，學歷欄常是「不拘」。與其糾結學歷，不如把一個能展示的實作專案做出來，面試時能講清楚你怎麼建、遇到什麼錯、怎麼解，比科系有用。

Q7：沒有證照可以直接應徵雲端工程師嗎？

A： 可以，但會辛苦很多。證照的功能是幫你通過履歷篩選這一關，尤其在你沒有相關工作經驗時，它是唯一能證明你懂的東西。如果你已經有 3 年以上系統或後端經驗，實戰成果可以取代證照；零經驗的話，證照是最短的敲門磚。

Q8：雲端職缺會不會被 AI 取代？

A： 短期內不會，但工作內容會變。AI 已經能生成 Terraform 設定檔和排錯建議，取代的是「手動打指令」這一層，也就是 SRE 口中的 toil。留下來的是判斷力：架構怎麼設計、成本怎麼取捨、出事時怎麼決策。越往架構和設計端走，越不容易被取代。

Q9：應該先學 GCP 還是 AWS？

A： 先選一朵學到會，比兩朵都學一半有用。AWS 在台灣的職缺數量較多，GCP 在資料分析和 Kubernetes 領域強勢、證照考試對非本科相對友善。兩者的核心概念（VM、網路、IAM、容器）有七成相通，學會一朵之後跳到另一朵，通常 1～2 個月能上手。

Q10：從傳統 IT（網管、MIS）轉雲端，要補什麼？

A： 補三塊：容器（Docker 與 Kubernetes）、自動化腳本（Python 或 Shell）、雲端平台的權限與網路模型（IAM、VPC）。網管和 MIS 的網路與系統底子在雲端仍然通用，這是你的優勢，缺的多半是「把手動流程變成程式碼」這個習慣。

結論：先搞懂差別，再選對入門的位置

雲端職缺拆開來就是 5 種角色：工程師蓋、架構師設計、SRE 顧穩定、DevOps 顧交付、資料工程師鋪資料水管。

對想轉職的人來說，最務實的路線是：從雲端工程師入門卡位，再依興趣和底子往架構師、SRE／DevOps 或資料工程師發展。

別被職稱嚇到，也別被職稱綁死——看清楚 JD、選定一朵雲、考一張證照、碰到真實專案，方向就會越來越清楚。

如果你看完還是不確定自己適合哪一條路，我做了一份免費的評估工具，花 3 分鐘就能幫你抓出方向：

👉 你適合轉職 GCP 雲端架構師嗎？3 分鐘職涯評估

想更有系統地從零開始，也可以看看我的 雲端架構師養成班，或直接加 Line: @754xlakm 跟我聊聊你的背景，我幫你看適合先從哪個職缺、哪張證照下手。

The post 雲端職缺大解析：雲端工程師、架構師、SRE、DevOps、資料工程師差在哪？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

它比虛擬機輕量、啟動快，是現代雲端開發的核心基礎。

只要你理解它的概念，Docker、Kubernetes 這些詞就不會再讓你頭痛。

容器技術的定義

一種「把應用程式和它需要的所有東西打包在一起」的技術，確保程式在任何環境都能穩定執行。

這個「所有東西」包含：

1. 程式碼本身
2. 執行環境 (不同程式需要的環境都不一樣)
3. 相依套件 (像是函式庫 Library 或模組，沒有裝就不能順利跑起來，像 python 要處理資料就要再裝 pandas)
4. 容器設定檔 (Dockerfile)

打包完之後，這個容器可以在任何支援容器的機器上執行。

不管你的作業系統是 Ubuntu、CentOS 還是 Windows Server，甚至在你的 Mac 電腦，只要先裝好 Docker，同一個容器都可以順利跑起來。

容器和「貨櫃」的關係：生活化比喻

容器的英文是 Container，這個字本來就是「貨櫃」的意思。

以前船運貨物，每次都要重新裝箱、綁繩、確認尺寸，而每艘船、每個港口規格不同，搬運過程很容易出錯。

貨櫃標準化之後，不管是船運、火車還是卡車，同一個貨櫃直接搬上去就能走，裡面的東西不需要重新整理。

容器技術做的事情一模一樣：把你的應用程式裝進一個標準化的「盒子」，這個盒子搬到哪裡都能直接執行。

容器技術解決了什麼問題？

在它出現之前，工程師最常遇到這個情境：

開發環境裝的是 Python 3.8，測試環境是 Python 3.6，上線環境是 Python 3.11。

程式在開發機跑得好好的，一到正式環境就報錯，花兩天找問題，最後發現程式根本沒寫錯，而是套件版本不對。

容器從根本解決這個問題：開發、測試、上線用的是同一個容器映像檔，環境完全一致，不會出現版本差異。

容器技術的運作原理

容器是怎麼隔離環境的？

容器使用 Linux 核心內建的兩個機制來做隔離：

1. Namespace：讓每個容器有自己的「視角」，容器 A 看不到容器 B 的處理程序、網路介面、檔案系統。
2. Cgroups（Control Groups）：限制每個容器能用多少 CPU、記憶體、磁碟 I/O，避免一個容器把整台機器的資源吃光。

這兩個機制讓多個容器可以同時在同一台機器上執行，彼此不干擾，也不互搶資源。

如果你是初學者來，不需要記住 Namespace 和 Cgroups 的細節。

只要記住一件事：容器的隔離是靠作業系統核心直接支援的，不是靠模擬出另一台電腦。這就是容器比虛擬機輕量的根本原因。

為什麼容器可以這麼輕量？

虛擬機要模擬一整台電腦，包含硬體層、作業系統、核心。

光是一個虛擬機就要佔用 10–20 GB 的空間，啟動需要 30 秒到幾分鐘，所以開機才這麼慢。

容器不模擬硬體，也不需要自己的作業系統核心，直接借用宿主機（Host）的 Linux 核心。

一個容器映像檔大約只有 100–200 MB，啟動時間在 1–3 秒以內。

這個差異在大規模部署時非常明顯：一台實體機器可能只能跑 10–20 個虛擬機，但可以輕鬆跑超過 100 個容器。

容器映像檔（Image）是什麼？

容器映像檔（Image）是容器的「範本」，是一個唯讀的打包檔案，裡面包含程式碼和所有執行環境，用來啟動容器實例。

「實例」這個名詞有點難解釋，你可以理解爲一臺虛擬的小電腦，隨時可以產生出來或刪除掉。

你可以把 Image 想成「食譜」，容器是「用這份食譜做出來的菜」。

同一份食譜可以做出很多份菜，同一個 Image 可以啟動很多個容器實例，彼此獨立、互不影響。

你也可以把 Image 想成遊戲光碟片，那容器就是光碟片開始轉，裡面的遊戲檔被讀出來執行的樣子。

Image 採用分層結構：

1. 底層是作業系統基礎（例如 Ubuntu slim）
2. 上面一層是語言環境（例如 Node.js 18）
3. 最上面才是你的應用程式

如果你第一次打包映像檔，它會先上網下載作業系統環境的相關檔案；然後第二層再下載你的程式語言所需要的環境檔案，以及一些相依性的套件。

由於它每一層都可以快取 (暫存在你電腦裡面)，如果你的程式碼有改，更新容器只需要重新打包有變動的那層，不用再下載作業系統跟程式語言環境，效率很高。

容器 vs 虛擬機：哪裡不一樣？

容器（Container）和虛擬機（Virtual Machine，VM）都是用來隔離執行環境的技術，但架構完全不同：

容器共用宿主機的 OS 核心，虛擬機則模擬出一整台獨立的電腦。這個差異直接決定了兩者在速度、體積和資源消耗上的巨大差距。

架構差異一次看懂

啟動速度與資源佔用的比較

容器啟動快，不是因為硬體更好，而是架構不同。

虛擬機每次啟動的流程：

1. 初始化虛擬硬體
2. 載入 BIOS
3. 啟動 OS 核心
4. 載入系統服務
5. 才能執行你的程式

容器啟動的流程：

1. 在宿主機核心上建立隔離空間
2. 載入映像檔
3. 執行程式

跳過了模擬硬體和啟動 OS 這兩個最耗時的步驟，所以快。

在資源佔用方面：一台 8 GB RAM 的伺服器，跑虛擬機時每個 VM 至少需要 1–2 GB RAM 給 OS 本身；

跑容器時 OS 的 RAM 消耗幾乎為零，幾乎所有記憶體都給應用程式用。

什麼情況該用容器？什麼情況該用虛擬機？

適合容器的情況：

1. 微服務架構，需要大量部署小型服務
2. CI/CD 流程，需要快速啟動、測試、銷毀環境
3. 開發環境一致性，多人協作的專案
4. 雲端部署，需要彈性擴充和縮減的應用程式

適合虛擬機的情況：

1. 需要完整 OS 隔離（例如執行不信任的第三方程式）
2. Windows 應用程式（容器對 Windows 的支援較複雜）
3. 需要模擬不同作業系統進行相容性測試
4. 對安全隔離要求極高的金融或醫療系統

兩者不是非此即彼的關係。

實際生產環境中，常見做法是：虛擬機作為底層基礎設施，容器在虛擬機上運行。

Docker 容器：最主流的容器工具

Docker 是什麼？和容器的關係

容器技術這個概念在 Docker 之前就存在，但當時提供容器技術的廠商非常多，而且操作複雜、工具不統一，只有少數工程師會用。

Docker 是目前最主流的容器工具，由 Docker Inc. 於 2013 年發布。

它讓開發者可以用簡單的指令打包、分發、執行容器，大幅降低容器技術的使用門檻。

並且提供統一的指令介面、映像檔格式，以及 Docker Hub 這個映像檔共享平台。

所以 Docker 幾乎一統江湖，成為容器技術的獨佔廠商。

容器技術是概念，Docker 則是最受歡迎的容器廠商。

現在說「用容器部署」，90% 的情況都是在用 Docker 或基於 Docker 格式的工具。

Docker Hub：映像檔從哪裡來？

Docker Hub 是 Docker 官方的映像檔倉庫（Repository），可以把它想成「容器的 App Store」。

想跑一個 MySQL 資料庫？不需要自己安裝，一行指令就能從 Docker Hub 下載官方的 MySQL 映像檔，直接啟動。

Docker Hub 上有超過 1,000 萬個映像檔，包含：

• 各種語言的執行環境（Python、Node.js、Go）
• 資料庫（MySQL、PostgreSQL、Redis）
• Web 伺服器（Nginx、Apache）

你也可以把自己打包好的映像檔推上去，私有或公開都支援。

用 Docker 跑第一個容器：3 個步驟

假設你已經安裝好 Docker，跑第一個 Docker 容器只需要：

1. 開啟終端機，輸入 docker pull nginx，從 Docker Hub 下載 Nginx 的映像檔
2. 輸入 docker run -d -p 8080:80 nginx，啟動容器並把 8080 port 對應到容器內的 80 port
3. 開啟瀏覽器，前往 http://localhost:8080，看到 Nginx 歡迎頁面就代表成功

從下載到執行，整個過程在 30 秒內完成。你不需要安裝、設定 Nginx，只要這三步就有一個完整運行的 Web 伺服器。這就是 Docker 容器改變開發流程的地方。

Kubernetes 容器編排：容器多了之後怎麼管？

為什麼需要 Kubernetes？

3–5 個容器，Docker 指令就夠用。300 個容器分散在 20 台伺服器上，Docker 指令完全不夠用。你需要解決：

• 某個容器掛掉，要怎麼自動重啟？
• 流量暴增，要怎麼自動增加容器數量？
• 新版本要怎麼在不停機的情況下更新？
• 20 台伺服器的資源要怎麼統一分配？

這些問題就是「容器編排」要解決的事。

Kubernetes（簡稱 K8s）是目前最主流的容器編排平台，由 Google 於 2014 年開源，現在由 CNCF（雲端原生運算基金會）維護，是大規模容器化應用的業界標準。

Kubernetes 和 Docker 的分工

Docker 負責：建立和執行單個容器。

Kubernetes 負責：管理大量容器的生命週期，包含排程、擴縮、自我修復、網路和儲存配置。

兩者是互補關係，不是競爭關係。在大多數生產環境中，Kubernetes 會呼叫容器執行時（Container Runtime）來實際啟動和停止容器，Docker 就是最常見的容器執行時之一。

容器編排解決的三個核心問題

Kubernetes 解決了容器規模化之後最常見的三個痛點：

1. 自我修復（Self-healing）：容器掛掉，Kubernetes 在幾秒內自動重新啟動，不需要人工介入
2. 水平擴展（Horizontal Scaling）：CPU 使用率超過 80% 時，Kubernetes 自動新增容器副本；流量下降後自動縮減，節省成本
3. 滾動更新（Rolling Update）：新版本部署時，Kubernetes 逐步替換舊容器，零停機時間，出問題可以一鍵回滾到上一版

容器技術的實際應用場景

開發環境一致性：再也不會「我電腦上可以跑」

這是最直接、最普遍的應用場景。

10 人的開發團隊，每個人的電腦環境都不一樣：Windows、macOS、不同版本的 Linux，不同版本的 Node.js、Python、資料庫。

用容器技術，把開發環境定義在一個 docker-compose.yml 檔案中。新成員加入團隊，執行一個指令就能啟動和資深工程師完全相同的開發環境，從加入到開始寫程式只需要 15 分鐘，而不是過去光設定環境就要花一整天的「環境設定地獄」。

微服務架構與容器化應用

微服務架構是把一個大型應用程式拆成很多個小型、獨立的服務，每個服務負責一個功能，可以獨立開發、部署、擴展。容器化應用是微服務架構的最佳搭配：每個微服務打包成一個容器，可以用不同的程式語言撰寫、獨立部署、獨立擴展。

舉個例子：一個電商平台有訂單服務、庫存服務、推薦系統、金流服務各自獨立。促銷期間推薦系統需要大量 CPU，你可以只針對推薦系統的容器擴展，不需要把整個平台都擴展，省下大量成本。

CI/CD 流程中的容器角色

CI/CD（持續整合 / 持續交付）是現代軟體開發的標準流程：工程師提交程式碼後，自動執行測試、打包、部署，不需要人工介入。

容器在 CI/CD 流程中扮演關鍵角色：

1. 測試環境用容器啟動，每次測試都在乾淨的環境中執行，不受之前測試殘留的狀態影響
2. 打包成容器映像檔，確保開發、測試、正式環境用完全相同的產物
3. 部署時直接替換容器，速度快、可回滾，比傳統部署方式風險低很多

容器技術的限制與常見誤解

容器不是萬能的：三種不適合用容器的情境

它很強，但不是所有情境都適合：

1. 需要 GUI 的桌面應用程式：容器設計上是無頭（Headless）的，跑有圖形介面的軟體需要額外設定
2. 需要直接存取硬體的應用程式：例如需要存取特定 GPU、USB 裝置，容器的隔離層會增加複雜度
3. 狀態複雜的單體式舊系統（Legacy System）：把有幾十年歷史的大型系統容器化，往往需要大量改寫，成本超過效益

容器技術最適合「雲端原生（Cloud Native）」的應用程式——從設計之初就考慮到分散式部署、無狀態、水平擴展的架構。

容器安全性：常見疑慮與對應做法

容器的隔離比虛擬機弱——這是事實，但不代表容器不安全。

常見的安全疑慮和對應做法：

1. 容器逃逸（Container Escape）：攻擊者從容器內部突破隔離，存取宿主機。
   對應方式：不以 root 身分執行容器、定期更新容器映像檔、使用 Seccomp 和 AppArmor 限制系統呼叫
2. 映像檔安全性：從 Docker Hub 下載的映像檔可能包含漏洞或惡意程式。
   對應方式：只使用官方映像檔或自建基礎映像、在 CI/CD 流程中加入映像檔掃描（例如 Trivy、Snyk）
3. 密鑰管理：不要把密碼、API Key 直接寫進映像檔。
   對應方式：使用 Kubernetes Secret 或 HashiCorp Vault 管理敏感資訊

容器安全是可以管理的問題，只要遵守基本的安全實踐，風險完全在可接受的範圍內。

學容器的建議路徑

從 Docker 開始還是從概念開始？

建議先從概念開始，再動手。

很多人第一步就打開終端機跑 Docker 指令，結果遇到錯誤不知道為什麼，也不知道自己在做什麼，很快就放棄。

理解「容器是什麼、解決什麼問題、和虛擬機有什麼差別」之後，再開始動手，每一個指令都有清楚的脈絡，遇到問題也更容易判斷方向。

推薦的學習順序與資源

從零開始學容器技術，建議依這個順序：

1. 理解概念：搞清楚容器 vs 虛擬機、Image vs 容器的關係（本文就是起點）
2. 安裝 Docker Desktop：官網提供 Windows 和 macOS 的圖形化安裝包，10 分鐘內完成
3. 跑第一個容器：用 docker run hello-world 確認環境正常，再跑 Nginx 或 Python 應用程式
4. 學習 Dockerfile：學會自己撰寫 Dockerfile，把自己的應用程式打包成映像檔
5. 學習 Docker Compose：用 YAML 檔案定義多容器環境，例如「應用程式 + 資料庫」的組合
6. 入門 Kubernetes：理解 Docker 之後再學 K8s，不要跳過 Docker 直接學 K8s

每個階段大約需要 1–2 週，有實作練習的情況下，2–3 個月可以達到在工作中使用容器技術的基本水準。

結語：容器技術值得學嗎？

值得，而且越早學越好。

容器技術已經不是「進階技能」，而是現代後端工程師和 DevOps 工程師的基本配備。

人才需求中出現 Docker、Kubernetes 的頻率，在過去五年內增加了超過三倍。

從理解容器的概念開始，裝好 Docker，跑幾個練習專案，這樣就夠了。Kubernetes 和進階的容器編排，等你對容器有基本掌握之後再學，不會太晚。

容器技術的學習曲線在前兩週最陡，一旦度過那段，後面會越來越順。

常見問題（FAQ）

Q1：容器技術是什麼？用一句話說明。
A：容器技術是一種把應用程式和它的執行環境打包在一起的技術，確保程式在任何機器上都能穩定執行，不受底層作業系統差異影響。
它比虛擬機輕量、啟動更快，是現代雲端部署的核心基礎。
尤其是它在開發、測試、上線環境完全一致，是容器技術解決的最核心問題。

Q2：一個容器可以同時跑多個應用程式嗎？
A：技術上可以，但不建議。容器的設計哲學是「一個容器、一個程序」，這樣才能充分發揮容器的輕量性和獨立性。
如果你需要跑多個應用程式，應該用多個容器，再用 Docker Compose 或 Kubernetes 讓它們協同工作。

Q3：容器和 Serverless 有什麼關係？
A：Serverless（如 AWS Lambda、GCP Cloud Functions）是更高階的抽象，你不需要管理伺服器或容器，只要上傳函數程式碼就好。
但實際上，很多 Serverless 平台的底層就是用容器技術來隔離和執行函數，只是這個細節被平台隱藏起來了。
最有名的就是 Cloud Run，它可以直接讓你的容器跑起來。

Q4：Docker 和 Podman 有什麼差別？
A：Podman 是 Red Hat 推出的容器工具，最大差別是不需要常駐的 Daemon（背景服務），以及預設不需要 root 權限執行，安全性稍高。
指令格式和 Docker 幾乎完全相同，可以直接替換使用。
對初學者來說，先學 Docker 就好，兩者概念完全通用。Podman 知名度低很多。

Q5：容器映像檔更新了，跑起來的容器會自動更新嗎？
A：不會。已經在跑的容器使用的是啟動時的映像檔版本，不會自動套用新映像檔。
你需要停止舊容器、拉取新映像檔、再啟動新容器。
這也是為什麼 Kubernetes 的滾動更新（Rolling Update）功能很重要，它可以幫你自動完成這個過程，而且不停機。

Q6：容器的資料存放在哪裡？容器刪掉資料會不見嗎？
A：預設情況下，容器內部產生的資料在容器刪除後就消失了。這是容器「無狀態」設計的一部分。如果你需要持久保存資料（例如資料庫的資料），要使用 Volume（磁碟掛載），把資料存在宿主機的指定路徑，容器刪除後資料仍然存在。

Q7：學容器技術需要先學 Linux 嗎？
A：不需要精通，但需要基本熟悉。你需要能看懂基本的 Linux 指令（ls、cd、cat、chmod）、了解檔案系統結構，以及知道什麼是 Port 和環境變數。
如果這些概念對你完全陌生，建議先花 1–2 週補一下 Linux 基礎，之後學容器技術會順很多。

Q8：免費使用 Docker 有限制嗎？
A：Docker Desktop（桌面版）對個人使用和小型公司（員工數少於 250 人、年營收低於 1,000 萬美元）免費。超過這個規模需要付費訂閱。
Docker Engine（命令列版本，在 Linux 伺服器上使用）則是完全免費且開源的。Docker Hub 免費帳號有 Image 下載次數限制，付費帳號則無限制。

Q9：GCP、AWS、Azure 上的容器服務有什麼差別？
A：三大雲端平台都提供託管的 Kubernetes 服務：GCP 是 GKE（Google Kubernetes Engine）、AWS 是 EKS（Elastic Kubernetes Service）、Azure 是 AKS（Azure Kubernetes Service）。
三者核心功能相似，差異在於和各自雲端生態系的整合程度。GKE 因為 Kubernetes 本身就是 Google 開發的，整合度和功能被認為是最成熟的。

Q10：公司說要「容器化」現有的系統，這有多難？
A：難度差異很大，取決於現有系統的架構。
如果是相對現代的應用程式（有明確的相依套件清單、設定可以用環境變數注入），架構清晰的應用程式， 1–3 週就能完成基礎版本。
如果是有幾十年歷史的大型單體式系統，深度依賴特定硬體或作業系統功能，容器化可能需要數個月甚至不值得做。
建議先評估系統架構，再決定是否容器化以及容器化的範圍，有可能需要大幅的更動甚至重寫程式碼。

The post 容器 (Container) 技術是什麼？從零開始看懂 Docker 與容器化應用 first appeared on 東東 GCP 教學 - GCP 實戰講師.

假如你本來就已經會使用容器技術，例如 Docker，可以使用虛擬機器或是 Cloud Run 來運作容器應用程式，但當我們的系統變得更加複雜時，我們可能需要更強大的工具來管理整個應用程式生態系統。

這時候就需要「容器編排」技術了。編排（Orchestration）這個詞來自音樂領域，就像指揮家需要協調管弦樂團中的各種樂器，讓他們在正確的時間演奏正確的音符，最終產生和諧的音樂一樣，容器編排就是自動化協調和管理複雜系統中多個容器元件的過程。它負責決定哪些容器應該在哪裡運行、如何分配資源、確保容器間的通訊，以及根據需求自動擴展或縮減容器數量。

Kubernetes 簡介

為什麼需要 Kubernetes？

想像一下，你正在經營一家大型的線上商店。最初，你可能只有一個簡單的網站容器在運行，這時 Cloud Run 就足夠了。但隨著業務成長，你的系統開始變得複雜：

• 前端網站需要與後端 API 服務通訊
• 需要負載平衡來分配流量
• 某些服務需要定期備份和更新
• 不同的服務有不同的資源需求
• 需要監控各個環節的健康狀態

這時候，單純使用多個獨立的容器服務就變得難以管理。你需要手動協調各個服務之間的通訊、處理故障恢復、管理各種設定檔和機密資訊等等。這就是 Kubernetes 要解決的問題。

Kubernetes（常簡稱為 K8s）是一個開源的容器編排平台，它就像是一個聰明的指揮家，能夠協調和管理大量的容器化應用程式。

Kubernetes 的核心價值

它的核心價值在於：

自動化部署和擴充：
根據負載自動增加或減少容器執行個體的數量。

服務發現 (Service Discovery) 和負載平衡：
服務發現機制讓服務能夠輕鬆找到彼此，並自動分配流量到健康的容器。

自我修復能力：
當某個容器發生故障，會自動重啟新的容器，確保系統的高可用性。

設定和機密資訊管理：
提供了統一的方式來管理應用程式的設定資訊和敏感資料。

滾動更新 (Rolling Update)：
能夠逐步替換舊版本的容器，確保服務不中斷。

從單一容器到容器叢集

如果說 Cloud Run 讓我們能夠輕鬆運行單一的容器化應用程式，那麼 Kubernetes 就是讓我們能夠管理整個容器化應用程式生態系統的平台。它將多個容器組織成一個協調運作的叢集 (Cluster) ，每個容器都有自己的角色和責任，但它們共同協作來提供完整的服務。

就像管理一個小型團隊發展到管理一個大型組織。在小團隊中，每個人可能身兼多職，溝通簡單直接。但在大型組織中，你需要明確的分工、標準化的流程、有效的溝通機制，以及能夠快速適應變化的管理體系。

Google Kubernetes Engine (GKE) 簡介

雖然 Kubernetes 非常強大，但設置和維護一個 Kubernetes 叢集本身就是一項複雜的任務。你需要處理主節點的高可用性、網路配置、安全性設定、監控和日誌收集等等。

你可以在地端，或使用 Compute Engine 的虛擬機器來架設 Kubernetes，但是整個過程非常繁瑣，架設完成還要處理各個節點之前的通訊，極為複雜且耗時，當你花了好幾搭建好環境，你都還沒處理到應用程式的部分。

這就是為什麼 Google 推出了 Google Kubernetes Engine。

GKE 是 Google Cloud 提供的代管式 Kubernetes 服務。它讓你能夠善用 Kubernetes 的所有強大功能，同時 Google 會負責處理底層的基礎建設管理工作。代表你可以專注於開發和部署應用程式，而不需要擔心 Kubernetes Cluster 本身的維護。

Kubernetes 的幾個核心物件

在開始使用 GKE 之前，先來了解 Kubernetes 的幾個核心物件：

Node：工作節點而非虛擬機器

Node 是指叢集中的工作節點。為什麼不直接叫「虛擬機器」？因為 Node 是一個更抽象的概念：它可以是實體機器或虛擬機器。Kubernetes 把這些不同類型的運算資源統一稱為 Node，強調的是它們的「工作節點」角色，能夠運作容器，至於它們到底是怎樣的機器，其實並不重要。

Pod：容器的最小單位

Pod 是 Kubernetes 中部署和管理的最小單位。一個 Pod 通常包含一個容器，但也可以包含多個緊密相關的容器。這些容器共享網路和儲存資源，就像室友共享一個公寓一樣。Pod 的生命週期很短暫，隨時可能被創建或銷毀。

Deployment：管理應用程式的生命週期

Deployment 負責管理你的應用程式如何部署和更新。它告訴 Kubernetes：「我想要運行 3 個網站的副本」，然後 Deployment 會確保始終有 3 個健康的 Pod 在運行。如果某個 Pod 掛掉了，Deployment 會自動建立新的來替代。當你要更新應用程式時，Deployment 也會協調整個更新過程。

Service：穩定的網路端點

由於 Pod 會頻繁地建立和銷毀，它們的 IP 地址也會不斷變化。Service 就像是一個穩定的門牌號碼，為一組 Pod 提供固定的網路端點。無論後面的 Pod 如何變化，其他服務都可以通過 Service 找到它們，不需要你手動調整網路連結。

Ingress：對外開放的大門

Ingress 是叢集的對外入口，負責將外部的 HTTP/HTTPS 流量路由到叢集內的 Service。它就像是一個智慧的接待人員，根據 URL 路徑或網域將流量導向正確的服務。比如，當用戶訪問 api.example.com 時，Ingress 會將請求轉發給 API 服務；訪問 app.example.com 時，則轉發給前端應用程式。

整體的運作架構示意如下圖：

這些元件形成了一個完整的體系：Node 提供運算資源，Pod 在 Node 上運行你的應用程式，Deployment 管理 Pod 的生命週期，Service 為 Pod 提供穩定的網路訪問方式，而 Ingress 則負責將外部流量導入到正確的 Service。

就像一個運作良好的公司：Node 是辦公大樓，Pod 是員工工作的辦公室，Deployment 是人事部門負責人員配置，Service 是內部電話系統，而 Ingress 是前台接待處。

建立你的第一個 GKE Cluster

了解了 Kubernetes 的核心概念後，現在讓我們實際建立一個 GKE Cluster。GKE 提供了兩種主要的叢集模式，讓我們先來了解它們的差異。

Standard 模式 vs Autopilot 模式

GKE 提供兩種不同的 Cluster 運作模式，各有其適用場景：

Standard 模式（標準模式）

Standard 模式讓你擁有完整的控制權，就像擁有一輛可以自己調整引擎、變速箱的汽車。你需要自己管理節點（Node）的配置、擴展策略、安全性設定等等。這種模式適合有經驗的團隊，需要精細控制叢集行為，或是有特殊的硬體需求。

要注意的是，當你建立完 Cluster，它會幫你建立好節點，其實你還沒部署應用程式，代表這些節點資源已經開始隨著時間計費，這樣會浪費你的預算，你就可以選擇 Autopilot 模式。

Autopilot 模式（自動駕駛模式）

Autopilot 模式就像使用自動駕駛汽車，Google 會自動處理大部分的基礎設施管理工作。它會自動配置節點、處理安全性更新、優化資源使用，並且只針對你實際使用的 Pod 資源收費，所以讓你還沒部署 Pod 的時候，還沒建立任何 Node，就不會針對 Node 收取費用。

這種模式特別適合想要專注於應用程式開發，而不想花時間管理基礎設施的團隊。對於初學者和大多數應用場景，我們推薦使用 Autopilot 模式，因為它大幅簡化了叢集管理的複雜度。

使用 GCP Console 來建立 GKE Autopilot Cluster

讓我們透過 Google Cloud Console 來建立第一個 Autopilot Cluster，點擊「叢集」，再點「建立」：

名稱我們保持預設，區域一樣選擇 asia-east1，然後在級別的部分選擇「標準級」，然後再點「下一個區段：機群註冊」：

GKE 有個最新功能叫做 GKE Fleet Management，可以將不同 Google Cloud 專案中的GKE Cluster 地群組在一起，而且不只 GKE Cluster，也包含地端環境、其他雲端平台的 Cluster 都可以納入管理，這樣就能一次管理所有應用程式，簡化維運工作。

在這裡我們只有一個 Cluster，所以可略過這個功能，再點「下一個區段：網路連線」：

在這裡保持預設即可，其中可以注意的是，最右邊有 Pod 和 Service 的 IP 範圍，代表 Kubernetes 會分配 IP 位址給它們使用，而在 GKE 環境下，就是會把 Subnet 的次要 IP 範圍自動分配給它們，我們不用額外設定。再點「下一個區段：進階設定」：

在「目前發布版本」的下拉式選單中，我們選擇「一般（建議）」，然後再按下「建立」： 

接下來就等待  Cluster 建立完成，在這裡大概需要等待 5～10 分鐘左右：

這裡順便補充一下，大部分熟悉 Kubernertes 的工程師都偏好使用指令來建立和管理 GKE Cluster，我們也開啟 Cloud Shell 來建立第二個 Cluster 看看吧！

使用 gcloud 指令建立 Autopilot Cluster

gcloud container clusters create-auto autopilot-cluster-2  –region=asia-east1     –release-channel=regular

執行完後，你會看到它在建立過程的相關訊息，包含 Cluster 名稱、版本、Cluster IP、機器類型、節點數量等等：

使用 gcloud 和 kubectl 指令操作 GKE Cluster

我們回到建立好的 autopilot-cluster-1，我們可以用指令來查看它的相關資訊 (autopilot-cluster-2 如果沒用到可以先刪除)：

取得 Cluster 憑證以便使用 kubectl 工具

gcloud container clusters get-credentials autopilot-cluster-1  –region=asia-east1

這個指令的作用就像是取得鑰匙，告訴 kubectl 叢集在哪裡，並且提供身分驗證資訊，來證明你有權限管理這個 Cluster 的憑證，然後把連線的設定儲存在本機電腦的 ~/.kube/config 檔案。

檢查叢集狀態

kubectl cluster-info

查看節點資訊

kubectl get nodes

檢查系統 Pod 狀態

kubectl get pods –all-namespaces

到這裡你可能會覺得奇怪，為什麼指令分成 gcloud 和 kubectl？

gcloud 是 Google Cloud 的管理工具，負責管理 Google Cloud 上的資源，包含建立或刪除 GKE 叢集、管理帳單、權限、API 啟用。

而 kubectl 是 Kubernetes 用來管理 Cluster 內部的應用程式。能夠部署應用程式到 Cluster、查看 Pod、Service 的狀態、管理設定檔和執行日常維護工作。

而且每次下達 kubectl 指令，並不會用參數指定要操作的 Cluster，當你專案內有多個 Cluster 的時候，它不會知道你要對誰操作，所以才必須要 get-credentials 這個指令，才能操作到正確的 Cluster，當然你也可以再執行一次 get-credentials，切換到另外一個 Cluster，再去執行管理動作。 

部署應用程式到 GKE Cluster

使用 GKE Deployment 物件部署容器映像檔到 Pod

Cluster 建立完成，現在來部署應用程式到 Cluser，我們點擊「佈署」（雖然我覺得是「部署」）：

這裡設定的部署作業就像上面提到的 deployment 物件，我們可以在這裡指定跟上個單元相同的容器映像檔，再按「下一步：公開（選用）」：

部署 GKE Service 物件 （Network Load Balancer）

做到這裡可以讓 Pod 部署完成，但是要注意這個設定還不會讓 Pod 直接對外，你必須在勾選「以新 Service 的形式公開 Deployment」 。

在這裡要注意，我們當初在建立容器映像檔的時候，我們讓容器本身對外開放 Port 8080，上面的 80 是指負載平衡器對外的 Port，但是當流量進來之後，要指定 8080 才能存取到容器上的網頁喔。 

在服務類型保持預設的「負載平衡器」，它就會直接在 Google Cloud 上建立負載平衡器。 然後我們再按下建立。

接下來再等待幾分鐘會看到這個 Deployment 已經部署完成了，視窗可以再往下滑：

我們往下看到各種物件產生，包含一個 Deployment 物件，和三個 Pod 物件，都是在正常運作的狀態：

你可以再打開 Cloud Shell，下達各種相關的查詢指令 (記得要先 get-credentials) 喔！ 

查看目前部署的 Deployment

kubectl get deployments

查看目前部署的 Pod

kubectl get pods

查看目前部署的 Service 

kubectl get services

你會看到它有產生一個外部 IP，是對外開放存取的。

你可以打開瀏覽器輸入 https://[IP位址]，或是直接在 Web Console 上面點擊會看到網頁秀出來，不過在這裡要稍微等待一下，因為我們現在使用的是 Autopilot 模式，是連 Node 都還沒建立的情況，所以現在要先等它建立 Node，再部署 Deployment、Pod 和 Service。

過幾分鐘之後，我們看到它部署完成，也看到網頁出現了！

另外我們也可以在負載平衡器頁面看到一個負載平衡器：

要注意它是 TCP 負載平衡器，它工作在網路的第 4 層（傳輸層），只能根據 IP 位址和 Port 來分配流量。無法根據 URL 路徑進行導向 (例如 /api 或 /admin)，也無法根據網域名稱進行路由。

如果我們想要更聰明的流量路由功能，就需要使用 Application Load Balancer (ALB)。ALB 工作在第 7 層（應用層），能夠處理 HTTP/HTTPS 通訊協定的內容，提供更豐富的路由功能。

但目前在 Google Cloud 的 Console 上沒有辦法直接建立 ALB，必須要使用指令和設定檔的方式，來建立 Ingress 物件。

部署 GKE Ingress 物件 (Application Load Balancer)

不過！現在要先刪除原有的 deployment-1-service (Load Balancer)，以免後續物件在建立時，會有衝突喔！

刪除之後，我們再建立 2 個物件：

第一個物件：ClusterIP 類型的 Service

ClusterIP Service 是 Kubernetes 中最基本的 Service 類型，它只在 Cluster 內部提供一個穩定的 IP 位址和 DNS 名稱。雖然 ClusterIP Service 無法從 Cluster 外部直接訪問，但它為 Cluster 內部的通訊提供了完美的抽象層。

你可以把 ClusterIP Service 想像成公司內部的分機號碼系統。員工可以通過分機號碼找到彼此，但外部的人無法直接撥打分機號碼。

我們現在 Cloud Shell 的環境準備好一個設定檔 cluster-ip-service.yaml，內容如下：

apiVersion: v1
kind: Service
metadata:
  name: deployment-1-service
  labels:
    app: deployment-1
spec:
  type: ClusterIP 
  selector:
    app: deployment-1
    app.kubernetes.io/managed-by: cloud-console
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

接著來執行這個指令：

kubectl apply -f cluster-ip-service.yaml

這裡說明一下指令和參數：

kubectl apply 

這是 Kubernetes 的宣告式管理指令。它的意思是：「讓 Cluster 的實際狀態符合這個檔案中描述的期望狀態」。如果資源不存在，它會建立；如果已存在但設定有任何不同，它會更新。

-f 參數

代表 “file”，告訴 kubectl 從檔案中讀取設定。你也可以使用 -f 指定多個檔案，或是指定包含多個 YAML 檔的目錄。

YAML（YAML Ain’t Markup Language）

這是是一種人類易讀的資料序列化格式。在 Kubernetes 中，我們使用 YAML 檔來描述我們想要的資源狀態。

在 Kubernetes 的術語中，這些 YAML 檔被稱為 Manifest（資訊清單）。Manifest 是一份宣告式的文件，描述了 Kubernetes 資源的期望狀態。它不是告訴 Kubernetes「如何做」，而是告訴它「我想要什麼結果」，有點像在許願的感覺，而且它會使命必達的實現你的願望。

PS. 我以前不懂 Manifest 到底是什麼，但自從看了國外的吸引力法則或顯化法則，才知道 Manifest 就是顯化的意思，把你想要的現實呈現出來。

第二個物件：Ingress

Ingress 是真正負責處理外部流量並提供 ALB 功能的物件，它就像是建築物的智慧接待處，能夠根據 URL 路徑決定要導向哪個服務，也能根據網域名進行路由，把流量帶向目的服務。（感覺跟 Load Balancer 一模一樣）

設定檔 ingress-1.yaml 的內容如下：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-1
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "gce"
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: deployment-1-service
            port:
              number: 80

接著來執行這個指令：

kubectl apply -f ingress-1.yaml

你會看到它有一個警告訊息「 Warning: annotation “kubernetes.io/ingress.class” is deprecated, please use ‘spec.ingressClassName’ instead」，是因為 Kubernetes 本身推薦使用新的 spec.ingressClassName，但 GKE 的官方文件卻說要用舊的註解方式。

在這裡以 GKE 的官方文件為主，不用理會該訊息。

接下來需要等待至少 5~10 分鐘的時間，如果設定正確，就能夠在 Ingress 的地方看到一個前端的 IP，點擊之後就能看到網頁。

也能在負載平衡頁面看到 ALB，代表它能夠處理 HTTP/HTTPS 通訊協定的內容，提供更豐富的路由功能。

恭喜你也把 GKE 的基本服務建立完成了，接下來還是要記得刪除相關服務喔！

逐步刪除 GKE 物件

下 kubectl 指令刪除 GKE 物件

你可以按照以下的順序刪除：

查詢 Ingress 名稱

kubectl get ingress

刪除 Ingress (執行後要等 3~5 分鐘刪除完畢)

kubectl delete ingress-1 

查詢 Service 名稱

kubectl get service

刪除 Service  (名稱為 kubernetes 的 Service 不用刪除)

kubectl delete service deployment-1-service

查詢 Deployment 名稱

kubectl get deployment

刪除 Deployment

kubectl delete deployment deployment-1

直接刪除整個 GKE Cluster

再用這個指令刪除整個 Cluster，其實你也可以跳過前面刪除物件的步驟，直接刪除 Cluster：

gcloud container clusters delete autopilot-cluster-1 –region asia-east1

或是更簡單的方法，直接在 Web Console 上刪除整個 Cluster， Cluster 裡所有物件也都會跟著被刪除掉。

最後要跟各位提醒，Kubernetes 本身是一個博大精深的領域，本文礙於篇幅只能介紹到這裡，如果需要深入鑽研，建議各位再去尋找專門的書籍或文件來看。而且 Kubernetes 本身不斷在更新，GKE 也持續更新，所以現在看到可以運作的樣子，也許過不久後又會改變，所以還請大家持續追蹤 GCP 官方文件喔！

影片版教學如下：

The post Google Kubernetes Engine 是什麼？GKE 簡介與手把手操作教學 first appeared on 東東 GCP 教學 - GCP 實戰講師.

我以前也不懂為什麼會有 Cloud Deploy 這個東西，因為原本 DevOps 相關的工具已經夠多了，後來看到這個 Release 才懂，它的確有其必要性。

具體來說：

Release 的組成部分包含如下：

• 容器映像檔（Container image）
• 部署設定檔（如 Kubernetes 清單）
• 部署相關的中介資料（metadata）
• 環境特定的設定

Release 的特點：

• 不可變性（Immutable）：一旦創建就不能修改
• 可追蹤性：每個 release 都有唯一的標識符
• 可重複使用：同一個 release 可以部署到不同環境

創建 Release 的方式：

gcloud deploy releases create release-001 \
  --delivery-pipeline=my-pipeline \
  --region=asia-east1 \
  --source=/path/to/source

Release 的生命週期：

• 創建（Create）：打包應用程式和配置
• 部署（Deploy）：部署到目標環境
• 推進（Promote）：將相同的 release 推進到下一個環境

Release 的優點：

• 確保一致性：相同的 release 在所有環境中保持一致
• 版本控制：每個 release 都有版本記錄
• 回滾能力：可以輕易回滾到之前的 release
• 稽核追蹤：可以追蹤每個 release 的部署歷史

Cloud Deploy Release 實際應用例子：

Release-001
├── 容器映像: gcr.io/my-project/my-app:v1.0.0
├── 部署配置: 
│   ├── deployment.yaml
│   ├── service.yaml
│   └── configmap.yaml
└── 中繼數據:
    ├── 創建時間
    ├── 創建者
    └── 描述信息

Cloud Deploy Release 與環境的關係：

• 開發（Dev）環境：初始部署和測試
• 暫存（Staging）環境：整合測試
• 生產（Production）環境：最終部署
  每個環境可能需要不同的配置，但基礎映像和應用邏輯保持一致。

使用 Release 的好處

通過使用 release，團隊可以：

• 確保部署過程的可重複性
• 維護清晰的部署歷史
• 在問題發生時快速回滾 (Rollback)
• 實現更安全和可控的部署流程

這種方式最能保證部署的一致性和可靠性。

The post [GCP DevOps] Cloud Deploy 的 Release 是什麼東東？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

GitOps方法論是什麼？

GitOps是一種現代的軟體部署和運維方法論，核心理念是使用Git作為單一事實來源(Single Source of Truth)，所有系統設定和基礎設施都以程式碼形式存儲在Git倉庫中，以宣告式語法來描述整個系統狀態。

主要特點

1. 自動化同步：系統會自動將Git倉庫中的期望狀態與實際運行環境同步
2. 版本控制：所有更改都有完整的版本歷史記錄
3. 可稽核性：每個變更都可以追踪誰在什麼時候做了什麼修改
4. 回滾能力：可以輕鬆回退到任何之前的版本

優點如下：

1. 提高部署一致性和可靠性
2. 減少人為錯誤
3. 更容易進行協作和審查
4. 簡化復原流程

常用工具包含：Flux、ArgoCD、Jenkins X、Config Connector (Google Cloud 專屬)。

GitOps特別適合管理Kubernetes環境，因為Kubernetes本身就是基於聲明式配置的系統。這也是為什麼在GKE環境中，Config Connector配合GitOps方法論會是一個理想的選擇。

撇開 GKE，Flux 和 ArgoCD 就是兩個業界常用的 GitOps 工具

Flux:

• 像是一個勤奮的管家,會定期檢查 Git 程式碼庫有沒有更新
• 如果發現更新了,就會自動把新的設定套用到系統
• 特別適合單一團隊使用,設定相對簡單

ArgoCD:

• 功能比較豐富,有圖形化介面可以看系統狀態
• 可以管理多個專案和團隊
• 提供更多進階功能,例如可以設定部署的順序和條件

這兩個工具的主要差別在於:

• Flux 比較輕量化,適合小型專案
• ArgoCD 功能比較完整,適合大型組織使用
• Flux 通常整合在系統內,ArgoCD 則是獨立運作的服務

你要選擇哪一個,主要看:

1. 團隊規模大小
2. 是否需要圖形化介面
3. 需要的進階功能有哪些
4. 維護的難易程度

GitOps的工作流程是什麼？

1. 開發階段

• 開發人員在本地開發功能或修改
• 將所有設定檔（包括應用代碼、基礎設施配置）存儲在 Git 倉庫 (Repository)，例如 Github。
• 創建 Pull Request（PR）提交更改

2. 審核階段

• 其他團隊成員審查代碼變更
• 自動化測試運行檢查
• CI（持續整合）流程驗證更改
• 審核通過後合併到主分支 (Main Branch)

3. 同步階段

• GitOps 操作器（如 ArgoCD 或 Flux）持續監控 Git 倉庫
• 自動檢測到主分支的新變更
• 比較目標環境與 Git 中定義的期望狀態

4. 部署階段

• 操作器自動將變更同步到目標環境
• 執行必要的部署和配置更新
• 確保實際狀態與 Git 中定義的狀態一致

5. 監控與修正

• 持續監控部署狀態
• 如果檢測到偏差，自動進行修正
• 將實際狀態調整回 Git 中定義的期望狀態

6. 回滾機制

• 如果發現問題，可以快速回滾
• 只需將 Git 倉庫回退到之前的穩定版本
• 操作器會自動將環境同步到回滾後的狀態

整個流程的核心是：

• 所有更改都通過 Git 進行
• 自動化工具負責同步和部署
• 持續確保系統狀態與 Git 定義保持一致

這種工作流程特別適合：

• Kubernetes 環境管理
• 微服務架構
• 大規模分布式系統
• 需要嚴格變更控制的環境

The post [GKE 教學] GitOps 方法論是什麼東東？GitOps的工作流程是什麼？ first appeared on 東東 GCP 教學 - GCP 實戰講師.