這篇文章從「你的系統規模」出發，帶你判斷 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 實戰講師.

主要包含：

• 應用程式的 Kubernetes YAML 檔案（如 Deployment、Service、ConfigMap 等）
• 版本資訊
• 應用程式的配置選項
• 相依性設定

舉例來說，如果要部署一個 WordPress 網站，一個 WordPress Chart 會包含：

wordpress/
  Chart.yaml          # Chart 的版本和資訊
  values.yaml         # 預設配置值
  templates/          # Kubernetes 資源模板
    deployment.yaml   # WordPress 的部署設定
    service.yaml      # 服務設定
    ingress.yaml      # 入口設定

OCI（Open Container Initiative）原本是用來定義容器映像檔的標準格式，現在這個標準也被用來儲存 Helm Charts。

主要優點：

• 可以和容器映像檔使用相同的儲存庫
• 有標準的版本控制
• 支援數位簽名，提高安全性
• 可以使用相同的存取控制機制

比較傳統方式和 OCI 格式：

傳統 Chart 儲存：

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install wordpress bitnami/wordpress

OCI 格式儲存：

helm install wordpress oci://registry.example.com/charts/wordpress:1.0.0

在 Google Cloud 的情境下，使用 Artifact Registry 儲存 OCI 格式的 Charts 特別有優勢：

1. 可以集中管理容器映像檔和 Charts
2. 整合 Google Cloud 的存取控制
3. 支援 VPC Service Controls 提高安全性
4. 有完整的版本追蹤和稽核記錄

那你可能會問 WordPress 不是一整包 php 程式檔嗎？它們存在哪裡？

Helm Charts 本身不包含 WordPress 的 PHP 檔案。Charts 只包含了 Kubernetes 的部署設定檔。實際的 WordPress PHP 檔案是存在於容器映像檔（Container Image）中。

讓我用 WordPress 為例子來說明整個架構：

1. 容器映像檔（Container Image）
   • 包含 WordPress 的所有 PHP 檔案
   • 包含 Apache/PHP 運行環境
   • 通常存放在像 Docker Hub 這樣的容器登錄庫
   • 例如：wordpress:6.4.3
2. Helm Chart
   • 只包含 Kubernetes 的設定檔
   • 會在設定中引用上面的容器映像檔
   • 例如在 deployment.yaml 中：

spec:
  containers:
  - name: wordpress
    image: wordpress:6.4.3   # 這裡引用包含實際 PHP 檔案的容器映像檔
    ports:
    - containerPort: 80

所以完整的部署流程是：

1. Kubernetes 讀取 Helm Chart 的設定
2. 根據設定去下載指定的容器映像檔
3. 將容器映像檔（包含 PHP 檔案）部署到 Kubernetes 集群中

這種設計的好處是：

• 關注點分離：部署設定（Chart）和應用程式程式碼（容器映像檔）可以分開管理
• 重用性：同一個容器映像檔可以用不同的 Chart 設定來部署
• 版本控制：程式碼和部署設定可以分別進行版本控制

The post [GKE 教學] Helm Charts 是什麼？什麼是 OCI 格式的 Charts？ first appeared on 東東 GCP 教學 - GCP 實戰講師.