🔧 阿川の電商水電行
這篇文章是由人類真心製作的。
請放心享受這篇有機的文章。
終於來到12月了！
每年這個時候總讓我有種「糟糕！今年什麼都沒做！」的焦慮感。
話說各位，有在使用Kubernetes嗎？
有些人在工作中理所當然地使用Kubernetes，而有些人則可能因為Kubernetes的難度而感到猶豫。
Kubernetes很難
我認為Kubernetes因為困難而經常被避開，我自己也在避開它。
過去我多次翻閱過Kubernetes完全指南，但總是在它壓倒性的內容前感到挫折。（「Kubernetes完全指南」無疑是k8s界的聖經，是一本好書。只是內容實在太龐大了！）
最近，我終於下定決心深入理解Kubernetes，並在工作中開始使用它。
為什麼Kubernetes如此困難，隨著我逐步理解Kubernetes，逐漸明白了原因。
在這篇文章中，我會說明Kubernetes是什麼，Kubernetes的本質是什麼，還有為什麼它如此困難的內容。主要是針對初學者所寫。
不會涉及Pod是什麼？Namespace是什麼？這些技術的具體內容。如果想深入了解Kubernetes的技術內容，請參考Kubernetes完全指南！
目標讀者
- 正打算對Kubernetes進行補充學習的人
- 對Kubernetes多次感到挫折的人
- 雖然在使用Kubernetes，但坦白說並不太明白的人
Kubernetes是什麼
我還是很有必要簡單解釋一下Kubernetes。
這部分可以略過。
Kubernetes是當前最廣泛使用的容器編排工具。（關於容器編排的內容稍後會說明）
Kubernetes承襲了Google十多年來支撐公司內所有服務（如Gmail和YouTube）的集群管理系統「Borg」的設計思想與經驗，並於2014年作為開源軟體公開。隨後在2015年，捐贈給隸屬於Linux Foundation的CNCF（Cloud Native Computing Foundation），目前由CNCF主導進行開發。
順便一提，CNCF除Kubernetes之外，還支援Prometheus、Helm等多個雲原生生態系統中的項目，並在供應商中立的立場上推動雲原生技術的標準化與普及。
Kubernetes的本質
現在進入主題。
首先要理解的是，Kubernetes的本質不是容器執行環境。
實際上，Kubernetes常常被視為一個容器執行環境來進行討論（例如ECS vs EKS）。
Kubernetes的本質是實現平台的工具。
平台是什麼
在IT領域，「平台」的意義會根據上下文而有所不同。
因此，在本文中，我們定義平台=實現系統的環境。
構建系統時，該系統會在某個平台上運行。
AWS也是一個平台，而最近流行的Vercel也是一個平台。世上有各種平台，它們各自具有特徵，並擁有明確的差異。
以AWS為例。AWS擁有EC2、ECS等計算資源，並且有作為資料庫的RDS和DynamoDB。還有許多其他作為系統組件的服務，例如物件儲存的S3。它們可以組合成一個完整的系統。這就是真正的「平台」。
Kubernetes也是一個平台
Kubernetes不僅僅是容器執行環境（計算資源），而是一個平台。
我們以常被對比的ECS和EKS為例。
ECS僅僅是一個容器執行環境，具備豐富的執行容器的功能。然而，基本上不具備容器執行環境以外的功能，並且需要與其他AWS資源組合使用。例如資料庫需要搭配RDS，而認證資訊則需要與Secret Manager串接。
另一方面，EKS則是一個能夠單獨作為平台的解決方案。EKS擁有StatefulSet這一功能，可持久地運行資源。利用這功能可以在Kubernetes上運行MySQL等資料庫功能。此外，透過Secrets功能可以在Kubernetes上管理認證資訊。
ECS是AWS這個平台的容器執行環境的組件，而EKS則是本身就是一個平台。
無法簡單比較ECS和EKS哪個好／壞。
主要是因為它們的本質不同。
順便說一下
「EKS不就是運行在AWS上嗎？那不是等於在平台之上再次建立了一個平台？」可能有讀者會疑問。答案是肯定的。Kubernetes本身是平台，但Kubernetes也依賴於伺服器和網路等基礎設施的支持。因此，Kubernetes的管理服務EKS則是AWS來處理這些基礎設施的責任。
此外，EKS並不意味著不使用其他AWS管理服務。當在Kubernetes上運行MySQL時，相較於RDS的運行成本會增加。如果有需求希望將所有運行成本都移除，那麼即使削減Kubernetes單一平台的優勢，也可能會將EKS與RDS等管理服務結合使用。最終仍然取決於具體需求。
因此難度較高
如上所述，Kubernetes是一個平台。
AWS提供多種服務。因為實現平台需要多功能是必需的，Kubernetes的情況也一樣。
正因為具備多種功能，Kubernetes的組成要素才會如此繁多。
這也是為何它如此困難的原因。
Kubernetes的實態
之前提到Kubernetes是平台的說法，其實稍有不同。
Kubernetes的實態是容器編排這一工具。容器編排和基礎設施的結合，形成了平台。（在EKS中，基礎設施部分對應AWS。）
容器編排是什麼
容器編排指的是自動化多個容器的部署、擴展和管理技術。
隨著Docker等容器技術的出現，應用程式可以包裝為容器形式，並能在任何地方一致執行。然而，在生產環境中運行大規模服務時，僅僅是運行容器是不夠的。
實際運行大規模服務的時候，需要高效地將數百到數千個容器部署到多台伺服器上，並根據負載自動增減容器數量，以及自動重啟出現故障的容器。此外，容器間的通信控制、配置資訊的管理和儲存分配等問題在大規模場景下會變得繁瑣。
手動管理這一切相當複雜且容易出錯，因此需要一種機制來定義系統的整體狀態，並自動維護該狀態。
這就是容器編排的概念產生的背景，而Kubernetes正是目前最廣泛使用的容器編排方案。
Kubernetes的特點
最後總結一下Kubernetes的特點。
Kubernetes是一個具備
- 宣告式的組態管理
- 自動化
- 完善的生態系統
的容器編排工具。
接下來針對每一項進行解說。
宣告式的組態管理
在Kubernetes中，使用YAML或JSON格式的清單檔案定義系統的「期望狀態（Desired State）」。
這是一種宣告式的方法，描述的是「應該是什麼樣」，而不是「如何實現」。相較之下，這與細節操作（命令式）方法形成對照。
（宣告式的組態管理的特性可用冪等性一詞來表示。）
自動化
Kubernetes自動化了容器運行所需的許多工作。
例如：
- 服務發現功能允許服務之間的通信，而不需要關注動態變化的Pod的IP地址。這使得Kubernetes自動提供DNS名稱和負載平衡，應用程式始終能連接到正確的端點
- 擴展功能允許根據負載自動增加或減少Pod數量，並調整節點數
- 自我修復功能自動重啟或重新排程異常Pod，維持系統的可用性
這些自動化功能大幅降低了運行的負擔，實現了平台的優化。
完善的生態系統
Kubernetes本身專注於容器編排的核心功能平台。
而用於實際應用運用中需要的中介軟體和工具，如資料庫、消息佇列、監控工具（Observability），設計思想是整合第三方產品在Kubernetes上使用。
這種高度的擴展性是Kubernetes的一大優勢。
CNCF生態系統中包含了豐富的與Kubernetes集成的工具，如監控（Prometheus）、日誌管理（Fluentd）、服務網格（Istio）、包管理（Helm）等，這些工具都能與Kubernetes無縫整合。
通過以附加形式將這些生態系統與Kubernetes結合，可以實現多種用途的獨特平台。
總結
- Kubernetes不只是一個容器執行環境，而是一個平台
- 實際上是容器編排工具
- 由於實現平台需要多種組件，因而難度較高
你明白Kubernetes難的原因了嗎？
如果理解了其難度的緣由，那麼學習會更有動力，不是嗎？（大概）
別放棄，鼓勵自己逐步學習，讓Kubernetes幫你打造屬於自己的平台吧！
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
