前言

本文將以此圖作為主軸，介紹K8s架構中的元件有哪些

K8s 架構

Pod
是K8s中運作的最小單位，一個Pod通常會對應到一個應用程式。
Pod裡的容器共享所有儲存空間與網路，因此當Pod裡的容器要進行通訊時，只需透過localhost的port即可溝通。

之後整理一篇關於Kubernetes網路

工作節點 (Worker Node)
K8s中運作的最小硬體單位，為一臺安裝了K8s的實體或虛擬機器，在其上可運行多個Pod，如下圖所示，過去也被稱作Minions。

Master 節點 (Control Panel)
運作的指揮中心，負責管理、調度叢集資源。
透過其上不同的組件，可以區分該臺機器為工作節點，抑或是Master。

叢集 (Cluster)
工作節點與Masters的集合，當其中一臺工作節點出現故障時，可藉由其他工作節點提供服務，進而達到服務不中斷的目標，除此之外，多節點也有助於負載平衡。
Master監視指揮所有的工作節點，負責安排在工作節點上執行的容器。

K8s元件

事實上，在進行安裝K8s時，系統其實安裝了以下幾個元件:

• API Server: 作為Kubernetes的前端，使用者、command-line皆需經過此層，才能與整個K8s叢集進行互動。
  1.管理K8s所需的API接口(Endpoint)，如透過command-line執行kubectl 指令
  2.Node之間的溝通橋樑，每個Node彼此不能直接溝通，需透過apiserver作為媒介

• etcd: 為分散式、鍵值存儲，用於存放、管理叢集資料，負責實作Lock機制，確保在masters之間不存在衝突。
  而當Master故障時，可透過etcd中儲存的叢集資訊，還原Kubernetes狀態。

• kubelet: 節點管理員，管理其上所有Pods狀態按預期運行，並負責與Master的API Server溝通。

• container runtime: 該節點真正負責容器執行的程式，以Docker容器為例，其對應的Container Runtime就是 Docker Engine，其餘的container runtime有rkt、CRI-O等。

• controllers: 負責監視叢集狀態並做出反應的Process，也就是說，會在叢集與預期狀態不符時，嘗試更新現有狀態。
  如當容器發生故障時，controllers需要即刻重啟新的容器。

• scheduler: 負責分配工作，會監視新建立但尚未被指定要跑在哪個節點上的 Pod，並根據每個節點的資源、硬體限制等條件，協調出一個最適合放置的節點，讓該Pod在其上執行。

小結

還有蠻多細節想要補充的