Goolgle 於 2022 年發佈的 The future of infrastructure will be containerized 白皮書中提到越來越多的科技和新創公司為了專注於有利於業務成長的優先事項（如產品開發），並減少在維護基礎設施上的花費並積極地採用代管式的容器平台 (Managed Container Platform)。
相較於傳統的虛擬機器，容器（Container）是一種更加輕量（MB等級）、啟動更快、可移轉性和彈性更高的虛擬化技術。容器化技術是在作業系統層級進行虛擬化，節省掉了 guest os 的配置，只將服務或應用程式必要的 libraries 和 dependencies 進行打包，節省硬體資源的同時達到是更加的輕量和更高的可移轉性。相反的，傳統 VM 是在硬體層級進行虛擬化，因此每台 VM 都擁有各自的 Guest OS 導致需要高的硬體資源和管理成本，也造成更低的一致性和擴展性。
相較於傳統VM，容器化應用程式擁有以下優勢：
更適用於軟體開發
Continuous integration 和 Continuous deployment (CI/CD) 是現在軟體開發常見的步驟，也就是所謂將自動化引入軟體開發階段來持續向客戶提供最新版本的應用程式。而在軟體開發的 CI/CD 的流程中，常會有“It works on my machine” 的問題產生。比如說測試工程師發現了一個 bug 是開發人員沒辦法重現的，或是開發人員部署了一個僅可以在測試環境運行但在生產環境會 crash 的代碼。
藉由container image作為中介將應用程式和其 runtimes 與 dependencies 打包起來，便可以確保應用程式在不同的階段都可以在相同的環境下運行。再加上 Container 可以於 VM 中進行部署，大幅降低在不同 VM間維護和部署軟體的複雜性。如此一來，DevOps 工程師就可以確保一個經過 CI 測試的 Container 在Production 環境中不會有 error 的產生。
此外，由於 Container 更輕量的特性可以在數秒內完成建置並使企業快速地發布與更新服務，它更加的符合現代軟體對快速發布、運營的需求。另外 Container 中並不包含作業系統，傳統軟體開發常面臨的作業系統版本、規格、升級等所造成的 error 也可以隨之避免。
硬體資源使用效率
傳統虛擬機器在 Hypervisor 環境中執行，由於每個虛擬機器必須都必須包含自己的 guest OS，導致消耗大量的系統資源和例行成本。尤其是當多個 VM 在同一部實體伺服器上執行時，傳統虛擬機器無法將多餘的資源分配給其他虛擬機器導致常常會有大量的閒置資源。根據 Google 的白皮書指出，大多數企業僅使用了 5-10% CPU 資源。
相對的，在同一時實體機器上的不同 Container 將相同的主機作業系統或系統核心，降低對於硬體資源的需求，且由於 Container 較為輕量，在同樣規格的機器上通常可以運行的 container 數量會大於 VM 數量。此外，Container 也可以將剩餘的運算資源分配給其他 Container 來做使用，使資源可以更有效率地被使用。
自動化調度管理
管理 VM 伴隨大量管理和維護負擔，常常需執行數十或數百個管理基礎架構的步驟。即便這些都是自動化作業，這些自動化工具（Terraform、Puppet、Chef 和 Ansible等）仍須持續維護。而對於自製或自訂工具來說，維護作業的負擔將會更高。
相較來說，藉由容器編排工具 Kubernetes 或是全代管的 Kuberenetes 服務 – Google Kuberenetes Engine，都可以自動化方式提供容器調度管理，能提升作業可靠性，並減少分配至日常運作的時間和資源。
Kubernetes Introduction
上面的段落提到了容器化技術的種種好處，但要有效率的運行大量的容器就必須搭配容器編排工具（Container Orchestration Tool）的使用，而最具有代表性的便是由Google在2014年所發佈的Kubernetes。現在我們所看到的 Kubernetes 是基於 Google 內部的集群管理系統 – Borg 以及開源社群多年來的貢獻所建立而成。使用 Kubernetes 對於開發人員來說，代表得以從傳統以 Host Server 為中心的的架構跳脫，進入一個以容器為中心的環境。
簡單來說，Kubernetes 是一個容器管理平台，最主要的功用在於管理、部署、擴張、監控、移轉跨多個主機的容器化應用程序。Kubernetes 的架構中包含了一個 Control Plane 以及數個 Worker Nodes。Worker Nodes 是主要提供服務的單位，而 Control Plane 會對 Worker Node 和其內部的 Pod 進行管理和監控。
Kubernetes 集群架構圖如下：
Control Plane 主要由以下四種元件組成：
- API Server: 作為 Kubernetes 集群中內外溝通的介面
- Scheduler: Kubernetes 集群中的調度服務，確保新生成的Pod都會被分配至 worker node
- Controller: 包含了集群中不同的控制器：Node controller、Job controller、Endpoints controller 和Service Account & Token controllers，用以調節集群狀態。
- etcd: Kubernetes 集群中的儲存服務，以鍵-值的方式進行資料儲存，作為集群中數據的後備儲存。
每一個 Worker Node 中包含了：
- Kubelet: Node agent。負責接收 Pods 的當前狀態以檢查當中的容器健康狀態，確保容器按照計畫運行。
- Kube Proxy: 負責節點上的 network 規則。network 規則規範了針對 pod 的內外網路溝通。
- Pod: Kubernetes 集群中最小的元素，包含著一個或多個容器在內。通常同一個應用程式的 container會儲存在同一 pod 中，使用共同的網路介面與外部溝通。此外，Kubernetes cluster 的自動擴展則也是以Pod 作為運作的單位，包含了 HPA（Horizoontal Pod Autoscaler）和 VPA（Vertical Pod Autoscaler）。
Kubernetes 的劣勢
雖然使用 Kubernetes 可以幫助我們更有效率地管理容器化的應用程式，但 Kuberbetes 在建立和管理上是非常複雜以及繁瑣，主要步驟包含了：
- 提供基本運算資源（bare metal, VM etc.）
- 安裝客戶端工具（cfssl, cfssljson, kubectl etc.）
- 建立 Certificate Authority 並產生 TLS certificate
- 建立 Kuberbetes 環境（kubeconfigs file）
- 建立資料加密配置和密鑰
- 建立 etcd 集群
- 建立 Kubernetes Control Plane
- 建立 Kubernetes Worker Nodes
- 建立 kubectl的kubeconfig file
- 建立 POD Network Route
想了解重頭到尾打造 kubernetes cluster 的所有過程，可以更進一步參考 GitHub 上面的Kubernetes-The-Hard-Way。而除了建立集群之外，Day-2 Operations 也是另一個複雜的管理流程，包含 CI/CD、資料備份及災難復原、POD 擴充、版本升級、建立 HA（High Availability）、用戶管理、硬體維護等都必須耗費大量人力來進行操作。
講到這邊相信大家已經了解到自行建立Kubernetes集群的複雜，但如果今天只是想單純使用 Kubernetes 架構進行軟體開發，而非底層的集群管理該怎麼做？Google 在 GCP 上所推出的 Kubernetes 服務 – Google Kubernetes Engine 將會是你的首選，也是我們接下來介紹的重點。
Google Kubernetes Engine
Google Kubernetes Engine 是由 Google 所提供的 Kuberbetes 代管服務，在分類上屬於 IaaS 和 PaaS 之間，其核心概念在於藉由 GCP 上的運算資源（Compute Engine）、UI 介面（GCP Console）、網路服務（Load Balancing, VPC etc.）、儲存服務（Persistent Disk) 和作業套件（Cloud Monitoring＆Logging）等雲端服務來大量減輕開發人員操作 Kubernetes 的負擔。
GKE的特色包含以下：
- 一鍵式建立，平均3分鐘內便可自動佈建 Kubernetes Cluster。
- 在單一 Console 上管理 Kubernetes Cluster 狀態。
- 基於 Compute Engine 來建立 Kubernetes Cluster。
- 支援建立 Regional Cluster，提高 Control Plane 和 Worker Nodes 的可用性。
- 支援利用不同組合的 Node pools 來提高部署 GKE Cluster 的靈活性。
- 軟體自動升級(Auto-Upgrade) 使 control plane 和 worker nodes 與最新的 Kubernetes 功能保持同步。
- 自動擴充(Auto-Scaling)功能 使 worker node 數量可以根據不同的工作負載在給定的 node pool 中進行調整。
- 節點的自動修復(Auto-Repair)功能使 GKE 集群中的節點保持健康、運行狀態。
- 結合 Google Cloud Operations Suite（Monitoring and Logging）使開發人員隨時掌握 Kubernetes Cluster狀態。
- 結合 Cloud Load-Balancing 將工作負載分配置不同 worker nodes。
與一般 Kubernetes Cluster 相同，開發人員可透過 kubectl 指令對 GKE Cluster 的 Control Plane 進行操作。但除了 kubectl 外，GKE 也支援 HTTP、gRPC、GUI 的方式來呼叫 api，也就是說除了原本 K8s 的指令式控制外，也能直接透過 GCP Console，以 圖像式的介面來操作 Control Plane。
GKE Autopilot Mode
GKE提供兩種不同的模式 – Standard Mode 和 Autopilot Mode。其中最主要的差別在於使用者對 GKE Cluster 的控制程度。在 Standard 模式底下，雖然 GKE 可以幫忙使用者做到不同元件的自動化操作，但在集群節點、網路和安全性的部署上還是必須交由使用者手動進行配置。若今天你在尋找的是一個全代管的Kubernetes 服務，只想專注在軟體的開發和部署而將 cluster 的建立、擴展和升級完全交由 Google 來幫你進行管理，這時候就可以選擇 Autopilot 模式。
在GKE Autopilot 模式下，GKE會根據你的工作負載來自動提供 Kubernetes cluster，並且幫助您維護和管理整個集群。GKE 是基於 Google SRE 和過往工程經驗所學習到的最佳實踐方式來建立不同 kubernetes cluster，其所建立的最佳化配置集群是可以直接作為 production 環境，有助於縮短 GKE 學習曲線。
在安全性上，Autopilot 模式下所建立的 cluster 都會採用 GKE hardening guidelines，使用了 GCP 獨有的安全性功能，包含 Shielded GKE Nodes 和 Workload Identity。此外，在 Autopilot 模式下，外部 IP 服務和 legacy authorization（X. 509認證、傳統密碼等）等高風險功能都會被禁用，並且 Autopilot 以會關閉 CAP_NET_RAW。藉由鎖定單個 Kubernetes 節點，Autopilot 可以幫助集群減少被攻擊的機會，並將地安全性配置的錯誤。
GKE Autopilot 可以為您提供具有所有強大安全默認值的標準 Kubernetes API，因此您可以專注於工作負載而不是集群。以上就是針對 Container、Kubernetes、GKE 介紹，希望可以幫助到初次接觸此或不熟的讀者釐清一些概念和方向。
