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

只要你理解它的概念，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 實戰講師.

這篇文章從「你的系統規模」出發，帶你判斷 Kubernetes 是什麼、解決什麼問題，以及你現在是否真的需要學它。

Kubernetes 是什麼？一句話先說清楚

Kubernetes 是一套容器編排（Container Orchestration）系統，讓你可以用一套統一的方式，管理跑在不同機器上的幾十甚至幾百個容器，包含自動部署、自動重啟、自動擴展、流量路由，全部都能自動化處理。

容器編排的意思是：當你的應用程式被打包成容器之後，你需要有人負責「指揮」這些容器在什麼機器上跑、出問題時怎麼處理、流量大的時候要不要多開幾個。

Kubernetes 就是扮演這個「指揮家」的角色。

K8s 這個縮寫怎麼來的

你在技術文章裡看到「K8s」，指的就是 Kubernetes。

縮寫的由來很簡單：Kubernetes 這個字在 K 和 s 之間剛好有 8 個字母（ubernete），所以工程師直接縮寫成 K8s。

這個命名方式在技術圈很常見，例如 i18n 代表 internationalization（i 和 n 之間有 18 個字母）。

往後你在搜尋資料、看文件的時候，K8s 和 Kubernetes 指的完全是同一件事，可以互換使用。

Kubernetes 和 Docker 的差別：不是競爭，是合作

這是新手最常搞混的一個問題。

Docker 是用來「建立和執行單一容器」的工具。你用 Dockerfile 定義應用程式環境，用 docker run 把容器跑起來，就這樣。

PS. 容器 (Container) 是一種技術，而在這個技術上出現非常多「廠商」，Docker 是巿佔率最高的一家，因為巿佔率太高了，所以大家很容易把 Docker 等同於 Container。

Kubernetes 則是用來「管理一大群容器」的平台。它自己不負責建立容器，而是依賴 Docker（或其他容器執行環境）把容器跑起來，然後在上面做調度、監控、擴展。

換句話說：Docker 是廚師，負責做出一道菜；Kubernetes 是餐廳的排班系統，負責決定今天要幾個廚師上班、哪個廚師負責哪個爐台、某個廚師請假時要怎麼補位。

兩者分工不同，實際上是一起搭配運作的。

沒有 Kubernetes 之前，工程師怎麼管容器？

單一容器的時代：在虛擬機上跑

當你的應用程式只有一個服務，例如一個 API 或一個網站，你根本不需要 Kubernetes，你可以直接在原有的虛擬機器上跑。

因為環境很單純，容器就像一個更小的虛擬器，可以直接 SSH 連進去做各種管理工作。

而在 GCP 上，Cloud Run 就能幫你把單一容器跑起來，自動處理 HTTPS、自動擴展、用多少付多少，設定時間不超過 10 分鐘。

這個階段引入 Kubernetes 反而是過度工程，徒增複雜度。很多團隊在這個階段就已經運作得很好，完全不需要 K8s。

系統變複雜之後，手動管理的三個痛點

當系統從 1 個服務成長到 5 個、10 個服務之後，手動管理容器會出現三個具體問題：

1. 故障處理靠人工：某個容器因為記憶體不足崩潰，你必須自己登入伺服器、手動重啟。如果是凌晨三點發生，就要凌晨三點爬起來。
2. 流量暴增應變慢：當某個服務突然湧入大量流量，你要手動判斷要多開幾個容器實例、在哪台機器上開、開完之後流量要怎麼導過去，每一步都是手動作業。
3. 服務間通訊難維護：A 服務要找 B 服務，B 服務的 IP 在容器重啟後會改變，你要手動更新設定檔。這個問題在服務數量超過 5 個之後會變得非常頻繁。

這三個痛點，就是 Kubernetes 出現要解決的核心問題。

Kubernetes 解決了什麼問題？

自動重啟：容器掛掉不用半夜爬起來

Kubernetes 持續監控每一個容器的健康狀態。

當某個容器因為程式錯誤、記憶體溢出或其他原因停止回應時，Kubernetes 會在 30 秒內自動偵測到異常，並在同一台或另一台節點上重新啟動一個新的容器來替代它。

整個過程不需要人工介入。對使用者來說，服務中斷的時間可以壓縮到幾秒鐘以內，而不是「等工程師醒來處理」的幾十分鐘。

自動擴展：流量暴增時不用手動加機器

Kubernetes 的 Horizontal Pod Autoscaler（水平自動擴展，簡稱 HPA）是一套根據指標自動調整容器執行數量的機制，可以根據 CPU 使用率或自定義指標，自動增加或減少容器的執行數量。

例如你設定「當 CPU 使用率超過 70% 時，自動增加容器數量」，Kubernetes 就會在流量高峰時自動擴展，在流量退去後自動縮減。

這個功能讓你不需要在流量高峰前手動預估資源、提前擴容，也不用擔心流量退潮後忘記縮容浪費費用。

服務發現：多個服務之間怎麼找到彼此

在傳統部署方式下，服務 A 要連線到服務 B，需要知道服務 B 的 IP 位址。

但容器每次重啟後 IP 都會改變，這讓服務間的連線設定變成一場惡夢。

Kubernetes 用「Service」物件解決了這個問題。每個服務都有一個固定的 DNS 名稱，例如 user-service.default.svc.cluster.local，不管後面的容器 IP 怎麼變，這個 DNS 名稱永遠有效。

服務 A 只要用這個名稱呼叫服務 B，Kubernetes 自動幫你把請求導到正確的容器上。

你需要 Kubernetes 嗎？用系統規模來判斷

情境一：單一服務、流量穩定 → 不需要

如果你的系統只有 1 到 3 個獨立服務，彼此之間沒有複雜的依賴關係，流量也相對穩定，引入 Kubernetes 只會讓你多花時間在維護基礎設施，而不是開發功能。

這個階段最適合的工具是 Cloud Run（GCP）、App Engine，或者是最單純的 Compute Engine VM。

設定快、成本低、出問題好追蹤。

情境二：多個服務互相依賴 → 開始考慮

當你的系統開始出現微服務架構，例如前端、後端 API、資料處理服務、通知服務各自獨立部署，服務之間的相依關係會讓你管理越來越繁雜。

手動管理的痛點開始產生：服務上線順序要協調、某個服務掛掉其他服務跟著受影響、部署新版本要小心翼翼，因為牽一髮而動全身。

這是開始評估要不要用 Kubernetes 的時機。

情境三：需要高可用、自動擴展 → 強烈建議

如果你的系統有以下任何一個需求，Kubernetes 幾乎是必選項：

1. 服務不能中斷超過 1 分鐘（高可用需求）
2. 流量有明顯的尖峰與離峰（需要彈性擴縮）
3. 需要零停機時間的滾動更新部署
4. 有超過 10 個以上的微服務需要統一管理

判斷要不要導入 K8s 的 3 個問題

在決定要不要導入 Kubernetes 之前，先問自己這 3 個問題：

1. 我的系統有幾個獨立部署的服務？ 少於 5 個，先考慮更簡單的方案。
2. 我的團隊有沒有人願意負責維護 K8s 叢集？ 沒有專人維護，建議直接選 GKE Autopilot 或其他代管服務。
3. 我現在的痛點是什麼？ 如果痛點不是「容器管理太複雜」，Kubernetes 不是解答。

Kubernetes 的核心概念：看懂這 5 個詞就夠了

學 Kubernetes 不需要一次搞懂所有東西。

以下 5 個核心物件是你一定會碰到的，先建立基本印象就夠了。

Pod：容器的最小包裝單位

Pod 是 Kubernetes 中最小的部署單位，一個 Pod 裡面通常包含 1 個容器，但在特殊情況下也可以包含 2 到 3 個緊密相關的容器，它們共享同一個網路和儲存空間。

你可以把 Pod 想成是一個「容器的宿舍」——裡面住的是你的應用程式容器，宿舍本身負責提供網路連線和磁碟空間。

Pod 的生命週期很短，隨時可能被建立或銷毀，所以不要把重要資料直接存在 Pod 裡面。

Node：跑 Pod 的工作機器

Node 是 Kubernetes 叢集裡的工作節點，也就是實際跑 Pod 的機器。

Node 可以是實體伺服器，也可以是雲端上的虛擬機器（在 GKE 上就是 Compute Engine VM）。

一個 Kubernetes 叢集裡會有多個 Node，Kubernetes 的調度器會自動決定每個 Pod 要跑在哪個 Node 上，確保資源使用均衡。

Deployment：告訴 K8s「我要幾個副本」

Deployment 是 Kubernetes 中用來管理應用程式副本數量與更新策略的物件，你告訴它「我要這個應用程式跑幾份」，它就負責維持這個狀態。

例如你設定 replicas: 3，Kubernetes 就會確保永遠有 3 個相同的 Pod 在運行。如果其中一個 Pod 掛掉，Deployment 會立刻建立新的 Pod 來補位，讓總數維持在 3 個。

當你要更新應用程式版本時，Deployment 也會協調滾動更新的過程，讓新舊版本交替上線，不中斷服務。

Service：讓其他人找得到你的 Pod

因為 Pod 的 IP 會隨著重啟而改變，Kubernetes 用 Service 物件提供一個穩定的網路端點。

Service 就像是 Pod 群組的「固定門牌」，不管後面的 Pod 怎麼換，外部呼叫方只要記住這個門牌（DNS 名稱），就永遠能找到正確的 Pod。

Service 同時也做負載平衡，當有 3 個 Pod 在跑同一個服務時，Service 會把流量平均分配給這 3 個 Pod。

Ingress：對外開放的統一入口

Ingress 是 Kubernetes 叢集對外的流量入口物件，負責把外部的 HTTP 和 HTTPS 請求，根據 URL 路徑或網域名稱，路由到叢集內正確的 Service。

舉例來說，當使用者訪問 api.example.com/users 時，Ingress 把請求導向 user-service；訪問 api.example.com/orders 時，導向 order-service。

這樣你只需要一個對外 IP，就能管理多個內部服務的流量入口。

自己架 Kubernetes vs 用雲端代管服務

自己架的成本：光設定環境就要幾天

自己在虛擬機器上架設 Kubernetes（俗稱 self-hosted K8s）需要處理以下步驟：

1. 安裝並設定 Control Plane（Master Node）
2. 設定 Worker Node 並讓它們加入叢集
3. 設定網路插件（CNI Plugin）讓 Pod 之間可以通訊
4. 設定儲存方案（Storage Class）
5. 設定監控、日誌收集、備份機制

從零開始，一個有經驗的工程師要花 2 到 5 天才能把環境架好，更別說後續的版本升級和安全性維護。

這些時間成本，對大多數團隊來說都不划算。

GKE、EKS、AKS 的差別在哪裡

三大雲端平台都有提供代管 Kubernetes 服務：

1. GKE（Google Kubernetes Engine）：Google Cloud 的代管 K8s。因為 Kubernetes 本身就是 Google 開源的，GKE 在相容性和新功能支援上往往最快。
2. EKS（Amazon Elastic Kubernetes Service）：AWS 的代管 K8s，與 AWS 其他服務（IAM、VPC、ALB）整合最深。
3. AKS（Azure Kubernetes Service）：Microsoft Azure 的代管 K8s，與 Azure DevOps 和 Active Directory 整合完善。

三者核心功能差異不大，選擇的關鍵通常是「你已經在用哪家雲」，而不是 K8s 功能本身的差異。

在 GCP 上為什麼推薦 GKE

GKE 有兩個對初學者特別友善的優點。

第一，GKE Autopilot 模式讓你完全不需要管理 Node。你只要定義要跑什麼應用程式，Google 自動幫你配置和維護底層節點，費用也只針對你實際使用的 Pod 資源計算，沒有部署應用程式的時候不收 Node 的費用。

第二，GKE 是 Kubernetes 的發源地，新功能和安全性修補的支援速度在三大雲中最快，官方文件和社群資源也最豐富。

如果你的雲端環境已經在 GCP 上，GKE 是進入 Kubernetes 世界成本最低的起點。

Kubernetes 值不值得學？給不同背景的人的建議

後端工程師：了解概念就夠，不一定要會操作

如果你是後端工程師，工作內容以開發功能為主，你需要的是「看得懂 K8s 設定檔、能和 DevOps 溝通」的程度，不一定需要自己架叢集或寫 YAML 設定。

重點是理解 Pod、Deployment、Service 這幾個核心物件的用途，知道你的程式碼被打包成容器之後，在 K8s 上是怎麼跑起來的。

這個程度大概需要 2 到 3 天的學習時間就能建立起來。

DevOps / 雲端架構師：必學，沒有例外

如果你的職涯目標是 DevOps 工程師或雲端架構師，Kubernetes 是 2024 年之後幾乎所有大型企業的標配基礎設施，不會 K8s 等於少了一張重要的入場券。

你需要學到的程度包含：

1. 能夠自己建立和管理叢集
2. 寫 Kubernetes YAML 設定檔
3. 設定 CI/CD 流水線整合 K8s 部署
4. 處理常見的故障排查

想考 GCP 證照的人：考前要懂的 K8s 核心考點

GCP 的 Associate Cloud Engineer 和 Professional Cloud Architect 兩張證照，都會考到 GKE 和 Kubernetes 相關知識。

考試中高頻出現的考點包含：

1. GKE Standard 和 Autopilot 模式的差異與適用情境
2. Deployment、Service、Ingress 物件的用途
3. kubectl 常用指令（get、apply、delete）
4. GKE 和 Cloud Run 的選擇判斷題

考前不需要實際操作建叢集，但要能看懂題目描述的情境，並判斷哪個 K8s 物件或哪種 GKE 設定最合適。

結語：搞懂 Kubernetes 是什麼之後，下一步去哪？

Kubernetes 是管理容器化系統的標準平台，但它不是每個人都需要的工具。

系統服務數量少於 5 個，先用 Cloud Run。服務開始互相依賴、需要高可用，再評估 GKE。你在 GCP 上，GKE Autopilot 是成本和複雜度最平衡的起點。

搞懂概念之後，下一步建議直接動手：在 GKE 上建立你的第一個 Cluster，部署一個真實的容器應用程式——這篇文章有完整的手把手操作流程，從建 Cluster 到部署 Ingress 全部都有截圖說明。

如果想看實際操作影片，可以參考 YouTube 上的 GKE 教學手把手實作。

常見問題（FAQ）

Q1：Kubernetes 和 Docker Compose 有什麼不同？
A：Docker Compose 是在單台機器上同時啟動多個容器的工具，適合本機開發或小型部署。Kubernetes 是設計給跨多台機器、需要高可用和自動擴展的生產環境使用的容器編排平台。當你的應用程式需要跑在超過 1 台機器上，Docker Compose 就不夠用了，這時候才是 Kubernetes 的用武之地。

Q2：Kubernetes 學起來難嗎？需要多久？
A：入門概念（Pod、Deployment、Service）大約需要 1 週時間可以理解並動手操作。能夠獨立管理生產環境的 K8s 叢集，需要 3 到 6 個月的實際操作經驗。最快的學習方式是直接在 GKE 上操作真實的叢集，而不是只看文件。

Q3：不用 Kubernetes，能不能用其他方式管理多個容器？
A：可以。常見的替代方案包含 Docker Swarm（較簡單，但功能有限）、HashiCorp Nomad（支援非容器工作負載）、或直接用雲端平台的託管服務（GCP 的 Cloud Run、AWS 的 ECS）。當你的規模不需要 Kubernetes 的全部功能時，這些替代方案的維護成本更低。

Q4：Kubernetes 本身是免費的嗎？費用從哪裡來？
A：Kubernetes 開源軟體本身是免費的。費用來自於執行叢集所需的基礎設施：你需要付費給雲端平台使用的虛擬機器（Node）、儲存空間和網路流量。GKE 在 Autopilot 模式下另外收取叢集管理費，但在 Standard 模式下每個帳號有 1 個免費的區域性叢集。

Q5：Kubernetes 適合個人專案或小型新創嗎？
A：在 95% 的情況下，個人專案和小型新創（團隊少於 5 人、服務數量少於 5 個）使用 Kubernetes 是過度工程。Cloud Run 或類似的 serverless 容器服務，在這個規模下成本更低、維護更簡單。等到服務複雜度真的撐不住了，再遷移到 Kubernetes 也不遲。

Q6：什麼是 Helm？學 Kubernetes 一定要學 Helm 嗎？
A：Helm 是 Kubernetes 的套件管理工具，讓你可以用「Helm Chart」的格式打包和部署應用程式，類似 npm 之於 Node.js。對初學者來說，先學會基本的 kubectl 操作和 YAML 設定之後，再學 Helm 比較合理。Helm 不是必學，但在實際工作環境中使用率極高。

Q7：Kubernetes 和 Service Mesh（如 Istio）是什麼關係？
A：Service Mesh 是建立在 Kubernetes 上的進階網路管理層，提供服務間流量的加密（mTLS）、詳細的流量觀測、流量控制（金絲雀部署）等功能。Istio 是目前最主流的 Service Mesh 實作之一。你需要先學會 Kubernetes，才有辦法理解 Service Mesh 解決的是什麼層次的問題。

Q8：GKE 和 Cloud Run 怎麼選？
A：Cloud Run 最適合無狀態的 HTTP 服務，設定簡單、自動擴展到零、按請求計費。GKE 適合有複雜部署需求、多個相互依賴的服務、或需要自定義網路和儲存設定的情況。判斷關鍵在於：你的應用程式是否有狀態（Stateful），以及你需不需要精細控制 Kubernetes 的部署設定。

Q9：Kubernetes 的 YAML 設定檔看起來很複雜，有沒有簡化的方法？
A：有 3 個方向可以降低 YAML 的複雜度。第一，使用 Helm Chart 把常用設定打包成模板；第二，使用 Kustomize 做環境差異的設定管理（開發環境和生產環境共用同一份基礎設定）；第三，在 GKE 上使用 Google Cloud Console 的圖形介面建立基本物件，再從介面上匯出對應的 YAML 來學習格式。

Q10：Kubernetes 版本更新很快，學了會不會很快過時？
A：Kubernetes 核心概念（Pod、Deployment、Service、Ingress）從 1.0 版本至今幾乎沒有根本性的改變，這些概念不會過時。版本更新主要是功能新增、效能改善和安全性修補，不會讓你原本學的知識失效。建議追蹤每個版本的 Changelog 了解新增功能，但不需要因為版本更新而重新學習基礎。

The post Kubernetes 是什麼？白話解釋 + 判斷你是否真的需要它 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 實戰講師.

簡單來說，它就像是一個翻譯器，把 Google Cloud 的資源轉換成 Kubernetes 可以理解的格式。

在實際使用中，Config Connector 扮演著橋樑的角色。

當我們想要在Google Cloud上建立新的服務，比如說建立一個 Cloud Storage Bucket 或是設定一個負載平衡器，我們不需要去 GCP 的控制台點點按按，而是可以直接用 Kubernetes 的設定檔來描述我們想要的資源。

Config Connector會自動幫我們在Google Cloud上建立這些資源，並且持續確保它們的狀態符合我們的期望。

這個工具的強大之處在於它的自動化能力。

比如說，如果有人不小心在 GCP Console 上手動修改了某些設定，Config Connector 會自動發現這個變化，並把它改回到我們在設定文件中定義的狀態。這樣可以確保我們的環境始終保持一致性。

在安全性方面，Config Connector 完全整合了 Kubernetes 的權限管理系統。代表我們可以精確控制誰能夠管理哪些 GCP 的資源，而且所有的操作都有完整的稽核記錄。

使用 Config Connector 的時候，我們需要先在 Kubernetes Cluster 中安裝它，然後配置適當的權限。之後，我們就可以用 YAML 格式的設定檔來描述我們想要的Google Cloud資源。

這些配置文件可以存放在Git倉庫中，配合 CI/CD 流程實現自動化部署。

在實際工作中，Config Connector 特別適合需要經常建立和管理GCP 資源的團隊。

比如說開發團隊需要經常建立測試環境，或者維運團隊需要統一管理多個專案的資源，使用 Config Connector 都能大大提高工作效率。

當遇到問題時，我們可以通過查看 Config Connector 的 Log 來進行故障排除。它會清楚地告訴我們哪裡出了問題，比如權限不足或者資源設定有誤。這讓問題診斷和修復變得更加直接和簡單。

總的來說，Config Connector 是一個非常實用的工具，它讓 GCP 資源的管理變得更加自動化和規範化，特別適合已經在使用Kubernetes的團隊。它不僅簡化了日常運維工作，還能確保環境的一致性和可靠性。

要使用 Config Connector，先準備以下 YAML 檔案：

apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnector
metadata:
  name: configconnector.core.cnrm.cloud.google.com
spec:
  mode: cluster
  googleServiceAccount: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

當這個 YAML 被應用 (Apply) 到GKE後，它會在你的 Kubernetes Cluster 中設置 Config Connector，並且設定使用指定的 Google Service Account 來操作 GCP 資源。

例如我們想要建立一個 Bucket，可以準備以下的 YAML 檔：

apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: my-bucket
spec:
  location: US-CENTRAL1
  uniformBucketLevelAccess: true

當這個 YAML 被套用 Apply 到 GKE 後，流程是這樣的：

1. GKE 中的 Config Connector 會讀取這個YAML檔
2. Config Connector 會解析這個檔案，了解到你想要創建一個Cloud Storage bucket
3. Config Connector 會使用它被配置的 Google Service Account的權限
4. 通過 Google Cloud API 去創建實際的 Storage bucket
5. 持續監控這個 bucket 的狀態，確保它符合 YAML 中描述的配置

如果之後有人直接在 GCP 控制台修改了這個 bucket 的設定，Config Connector 會自動發現並改回 YAML 檔中定義的狀態。

這就是為什麼它特別適合用在 GitOps 的工作流程中，因為它能確保實際的 GCP 資源狀態始終與程式碼倉庫中的定義保持一致。

The post [GKE 教學] Config Connector 是什麼東東？如何使用？ first appeared on 東東 GCP 教學 - GCP 實戰講師.