Kubernetes基礎元件概述主控端B

本文講的是<b>Kubernetes基礎元件概述</b>【編者的話】最近總有同學問Kubernetes中的各個元件的相關問題，其實這些概念内容在官方文檔中都有，奈何我們有些同學可能英文不好，又或者懶得去看，又或者沒有找到，今天有時間就專門寫了這篇部落格。

<a href="http://dockone.io/article/2228">【深圳站｜3天燒腦式Kubernetes訓練營】教育訓練内容包括：Kubernetes概述、架構、日志和監控，部署、自動駕駛、服務發現、網絡方案等核心機制分析，進階篇——Kubernetes排程工作原理、資源管理及源碼分析等。</a>

本文主要介紹Kubernetes的基礎元件，先介紹Master節點上的控制管理元件，再介紹Node節點上的計算元件，最後是附加元件，後邊會找時間再寫一篇介紹Kubernetes中的各種資源及使用。

Master節點元件是指運作在Kubernetes叢集中的Master節點上，提供整個叢集的管理控制功能的元件，例如排程元件（kube-scheduler），接口元件（kube-apiserver）等

kube-apiserver主要負責暴露Kubernetes API，不管是kubectl還是HTTP調用來操作Kubernetes叢集各種資源，都是通過kube-apiserver提供的接口進行操作的。

管理控制器負責整個Kubernetes的管理工作，保證叢集中各種資源的狀态處于期望狀态，當監控到叢集中某個資源狀态不正常時，管理控制器會觸發對應的排程操作，主要由以下幾部分組成：

節點控制器（Node Controller）

副本控制器（Replication Controller）

端點控制器（Endpoints Controller）

命名空間控制器（Namespace Controller）

身份認證控制器（Serviceaccounts Controller）

雲管理控制器是Kubernetes 1.6新加入的元件（元件抽象了一層IaaS平台的接口，具體的實作由各雲廠商負責提供），主要負責與基礎計算雲平台（IaaS）的互動，目前還處于測試開發階段，我們也還沒有使用過該元件。該元件的具體實作包括：

路由控制器（Route Controller）

負載均衡服務控制器（Service Controller）

資料卷控制器（Volume Controller）

排程器負責Kubernetes叢集的具體排程工作，接收來自于管理控制器（kube-controller-manager）觸發的排程操作請求，然後根據請求規格、排程限制、整體資源情況等因素進行排程計算，最後将任務發送到目标節點的kubelet元件執行。

etcd是一款用于共享配置和服務發現的高效KV存儲系統，具有分布式、強一緻性等特點。在Kubernetes環境中主要用于存儲所有需要持久化的資料。

Node節點元件是指運作在Node節點上，負責具體POD運作時環境的元件。

kubelet是Node節點上最重要的核心元件，負責Kubernetes叢集具體的計算任務，具體功能包括：

監聽Scheduler元件的任務配置設定

挂載POD所需Volume

下載下傳POD所需Secrets

通過與docker daemon的互動運作docker容器

定期執行容器健康檢查

監控、報告POD狀态到kube-controller-manager元件

監控、報告Node狀态到kube-controller-manager元件

kube-proxy主要負責Service Endpoint到POD執行個體的請求轉發及負載均衡的規則管理。

kube-proxy本身實際上并不負責請求轉發和負載均衡，而時從kube-apiserver擷取Service和POD的狀态更新，生成對應的DNAT規則到本地的iptabels，最終的轉發和負載均衡動作有iptabels實施，是以kube-proxy元件即使出現問題，已經更新到iptabels的轉發規則依然能夠生效。

BTW：所謂的附加元件并不是說這類元件在kunernetes環境中可有可無，隻是為了差別于底層的基礎計算元件。

有了上邊介紹的Master節點元件和Node節點元件後，基礎的Kubernetes環境算是已經建構好了：

kubectl調用apiserver發送建立pod的請求，scheduler收到排程任務發送到符合要求的node節點，node節點上的kubelet與docker daemon通訊建立docker容器。但是離真正可用的Kubernetes叢集還有一定距離，例如Container IP管理，内部DNS解析，簡單的管理控制台等。

Flannel是由ConreOS主導設計的用于容器技術的覆寫網絡（Overlay Network），在Flannel管理的容器網絡中，每一個主控端都會擁有一個獨立子網，用于配置設定給其上的容器使用。通信方式是基于隧道協定的UDP和VXLAN等方式封包、解包及傳輸。

原生的docker網絡結構：docker在啟動的時候會建立一個網橋docker0(172.17.0.0)，容器啟動的時候會建立一對Veth pair，這個Veth pair成對出現用于連結容器與docker0網橋（可以将其了解成一根網線的兩個插頭，一頭插在容器内改名為eth0，另一頭插在主控端的docker0網橋上），這樣同一台主控端上的容器就可以互相通路了，此時的路由表記錄：

但是對于不同的主控端A和主控端B來說，它們的docker網絡一模一樣，IP也是一樣，網絡與網絡之間也不通。

Flannel來了之後，在每個主控端上增加了個P2P的虛拟網卡flannel0(172.17.0.0)，一頭對接docker0網橋，一頭由Flanneld服務監聽。Etcd管理着整個Flannel網絡的子網配置設定，主控端A和主控端B分别用分到的子網<code>172.17.1.0</code>和<code>172.17.2.0</code>建立docker0網橋，然後又悄悄地修改了一下docker daemon的啟動參數<code>--bip=172.17.1.1/24</code>，同時添加路由表記錄：

172.17.0.0     0.0.0.0         255.255.0.0       U     0      0        0 flannel0

172.17.2.0     0.0.0.0         255.255.255.0     U     0      0        0 docker0

模拟下Flannel網絡下主控端A上的docker容器(172.17.1.10)發送資料到主控端B上的docker容器(172.17.2.15)的過程：

根據源容器和目的容器的IP比對路由規則，同時比對兩個IP的路由規則是<code>172.17.0.0/16</code>，如果是同一個主控端上的容器通路，比對的是<code>172.17.1.0</code>或者<code>172.17.2.0</code>

資料從docker0網橋出來以後投遞到flannel0網卡

監聽flannel0網卡的Flanneld服務收到資料後封裝成資料包發送到主控端B

主控端B上的Flanneld服務接收到資料包後解包還原成原始資料

Flanneld服務發送資料到flannel0網卡，根據目的容器位址比對到路由規則<code>172.17.2.0/24（docker0）</code>

投遞資料到docker0網橋，進而進入到目标容器172.17.2.15。

Flannel的Github上有張比較詳細的原理圖：

圖中的Flanneld運作在每個主控端上，負責資料的發送、監聽、封包、解包等任務。

強調下，Flannel的backend有UDP和VXLAN、GRE等實作，預設使用UDP，性能大約隻有本地實體網絡的一半，VXLAN推薦使用，性能損耗很小，不過需要3.9+的核心支援。

Calico是純三層的SDN實作，它基于BPG協定和Linux的路由轉發機制，不依賴特殊硬體，沒有使用NAT或Tunnel等技術。能夠友善的部署在實體伺服器，虛拟機（如OpenStack）或者容器環境下，可以無縫內建像OpenStack這種IaaS雲架構，能夠提供可控的VM、容器、裸機之間的IP通信，同時它自帶的基于Iptables的ACL管理元件非常靈活，能夠滿足比較複雜的安全隔離需求。

Clico網絡模型的特點：

在Calico中的資料包并不需要進行封包和解封。

Calico中的資料包，隻要被policy允許，就可以在不同租戶中的workloads間傳遞或直接接入網際網路或從網際網路中進到Calico網絡中，并不需要像overlay方案中，資料包必須經過一些特定的節點去修改某些屬性。

因為是直接基于三層網絡進行資料傳輸，TroubleShooting會更加容易，同時使用者也可以直接用一般的工具進行操作與管理，比如ping、Whireshark等，無需考慮解包之類的事情。

網絡安全政策使用ACL定義，基于iptables實作，比起overlay方案中的複雜機制更直覺和容易操作。

Calico 的核心元件：

Felix：Calico agent，跑在每台需要運作workload的節點上，主要負責配置路由及 ACLs等資訊來確定endpoint的連通狀态；

etcd：分布式鍵值存儲，主要負責網絡中繼資料一緻性，確定Calico網絡狀态的準确性；

BGP Client(BIRD)：主要負責把Felix寫入kernel的路由資訊分發到目前Calico網絡，確定workload間的通信的有效性；

BGP Route Reflector(BIRD)：大規模部署時使用，摒棄所有節點互聯的mesh模式，通過一個或者多個BGP Route Reflector來完成集中式的路由分發；

kube-dns負責Kubernetes叢集内的域名解析，解析服務通過dnsmasq實作。通過官方提供的Deployment和Service模闆，可以很友善地部署kube-dns服務，并且可以任意伸縮POD執行個體來保證其高可用性。

預設的kube-dns的service_ip：10.96.0.10，預設的域名字尾為：cluster.local，如果是kubeadm部署的Kubernetes叢集，kubelet的配置參數檔案是：<code>/etc/systemd/system/kubelet.service.d/10-kubeadm.conf</code>。

DNS解析的A記錄規則為：<code>my-svc.my-namespace.svc.cluster.local</code>，例如kube-dns的service的A記錄為：<code>kube-dns.kube-system.svc.cluster.local</code>。

POD執行個體建立後，其中的Container内的resolver.conf的配置如下：

因為添加了search domain，在POD的容器内通路其他Service時可以用縮略域名通路，如通路kube-dns服務：kube-dns（同namespace内通路），kube-dns.kube-system（跨namespace通路）。

Dashboard是官方提供的kubernetes叢集的UI界面，提供了一些基礎的檢視及簡單操作，随便用用還行。

可以通過官方提供的YAML模闆建立：<code>kubectl create -f https://rawgit.com/kubernetes/dashboard/master/src/deploy/kubernetes-dashboard.yaml</code>。

原文釋出時間為：2017-04-26

本文來自雲栖社群合作夥伴Dockerone.io，了解相關資訊可以關注Dockerone.io。

原文标題：Kubernetes基礎元件概述