文章目錄
前言
一：pod概念
- Pod是kubernetes中你可以創建和部署的最小也是最簡的單位。Pod代表着集羣中運行的進程。
- Pod中封裝着應用的容器（數量大於等於1，docker最常用，也可使用其他的），存儲、獨立的網絡IP，管理容器如何運行的策略選項。Pod代表着部署的一個單位：kubernetes中應用的一個實例，可能由一個或者多個容器組合在一起共享資源。
1.1：pod的種類
- 自主式pod
- 控制器管理的pod
1.2：pod網絡
- 每個Pod都會被分配一個唯一的IP地址。Pod中的所有容器共享網絡空間，包括IP地址和端口。Pod內部的容器可以使用localhost互相通信。Pod中的容器與外界通信時，必須分配共享網絡資源（例如使用宿主機的端口映射）。
1.3：pod存儲
- 可以爲一個Pod指定多個共享的Volume。Pod中的所有容器都可以訪問共享的volume。Volume也可以用來持久化Pod中的存儲資源，以防容器重啓後文件丟失。
1.4：使用pod
- 你很少會直接在kubernetes中創建單個Pod。因爲Pod的生命週期是短暫的，用後即焚的實體。當Pod被創建後（不論是由你直接創建還是被其他Controller），都會被Kubernetes調度到集羣的Node上。直到Pod的進程終止、被刪掉、因爲缺少資源而被驅逐、或者Node故障之前這個Pod都會一直保持在那個Node上。
- Pod不會自愈。如果Pod運行的Node故障，或者是調度器本身故障，這個Pod就會被刪除。同樣的，如果Pod所在Node缺少資源或者Pod處於維護狀態，Pod也會被驅逐。Kubernetes使用更高級的稱爲Controller的抽象層，來管理Pod實例。雖然可以直接使用Pod，但是在Kubernetes中通常是使用Controller來管理Pod的。
1.5：pod控制器類型
-
Kubernetes中內建了很多controller（控制器），這些相當於一個狀態機，用來控制Pod的具體狀態和行爲
-
有如下幾種類型：RC（ReplicationController），RS（ReplicaSet），Deployment，HPA（HorizontalPodAutoScale）,StatefullSet，DaemonSet，Job，Cronjob
-
RC：
- ReplicationController用來確保容器應用的副本數始終保持在用戶定義的副本數，即如果有容器異常退出，會自動創建新的Pod來替代；而如果異常多出來的容器也會自動回收。
- 在新版本的 Kubernetes中建議使用 ReplicaSet來取代 ReplicationControlle
-
RS：
- ReplicaSet跟 ReplicationController沒有本質的不同，只是名字不一樣，但是ReplicaSet支持集合式的selector
-
Deployment：
- 雖然 ReplicaSet可以獨立使用，但一般還是建議使用 Deployment來自動管理ReplicaSet，這樣就無需擔心跟其他機制的不兼容問題（比如 ReplicaSet不支持rolling-update（回滾更新）但 Deployment支持）
- Deployment爲Pod和 ReplicaSet提供了一個聲明式定義（ declarative）方法，用來替代以前的ReplicationController來方便的管理應用。典型的應用場景包括
- 定義 Deployment來創建Pod和 ReplicaSet
- 滾動升級和回滾應用
- 擴容和縮容
- 暫停和繼續 Deployment
-
HPA
- Horizontal Pod Autoscaling僅適用於 Deployment和 ReplicaSet，在V1版本中僅支持根據Pod的CPU利用率擴所容，在 V1alpha版本中，支持根據內存和用戶自定義的 metric擴縮容
-
StatefullSet
- StatefulSet是爲了解決有狀態服務的問題（對應 Deployments和 ReplicaSets是爲無狀態服務而設計），其應用場景包括
- 穩定的持久化存儲，即Pod重新調度後還是能訪問到相同的持久化數據，基於PVC來實現
- 穩定的網絡標誌，即Pod重新調度後其 PodName和 HostName不變，基於 Headless Service（即沒有 Cluster IP的 Service）來實現
- 有序部署，有序擴展，即Pod是有順序的，在部署或者擴展的時候要依據定義的順序依次依次進行（即從0到N1，在下一個Pod運行之前所有之前的Pod必須都是 Running和 Ready狀態），基於 init containers來實現
- 有序收縮，有序刪除（即從N-1到0）
-
DaemonSet
- DaemonSet確保全部（或者一些）Node上運行一個Pod的副本。當有Node加入集羣時，也會爲他們新增一個Pod。當有Node從集羣移除時，這些Pod也會被回收。刪除 DaemonSet將會刪除它創建的所有Pod
- 使用 DaemonSet的一些典型用法：
- 運行集羣存儲 daemon，例如在每個Node上運行 glusterd、ceph
- 在每個Node上運行日誌收集 daemon，例如 fluentd、 logstash
- 在每個Node上運行監控 daemon，例如 Prometheus Node Exporter
-
Job,Cronjob
- Job負責批處理任務，即僅執行一次的任務，它保證批處理任務的一個或多個Pod成功結束
- CronJob管理基於時間的Job，即：
- 在給定時間點只運行一次
- 週期性地在給定時間點運行
1.6：服務發現
- Kubernetes中爲了實現服務實例間的負載均衡和不同服務間的服務發現，創造了Serivce對象，同時又爲從集羣外部訪問集羣創建了Ingress對象。
- Kubernetes
Service定義了這樣一種抽象：一個Pod的邏輯分組，一種可以訪問它們的策略 —— 通常稱爲微服務。（通過一些標籤與pod建立聯繫，且service有自己的IP地址和端口） - client客戶端通過訪問service的IP地址和端口和RR（輪詢算法）來訪問到下面的pod。
二：網絡通訊方式
- Kubernetes的網絡模型假定了所有Pod都在一個可以直接連通的扁平的網絡空間中，這在GCE（ Google Compute Engine）裏面是現成的網絡模型， Kubernetes假定這個網絡已經存在。
- 而在私有云裏搭建 Kubernetes集羣，就不能假定這個網絡已經存在了。我們需要自己實現這個網絡假設，將不同節點上的 Docker容器之間的互相訪問先打通，然後運行 Kubernetes
2.1：網絡通訊模式
- 同一個Pod內的多個容器之間：lo（通過localhost迴環地址）
- 各Pod之間的通訊：overlay Network （覆蓋網絡）
- Pod與 Service之間的通訊：各節點的 Iptables規則
2.2：K8S中網絡層次說明
2.3：網絡解決方案，通過Flannel訪問
- Flannel是CoreOS團隊針對 Kubernetes設計的一個網絡規劃服務，簡單來說，它的功能是讓集羣中的不同節點主機創建的 Docker容器都具有全集羣唯一的虛擬IP地址。而且它還能在這些IP地址之間建立一個覆蓋網絡（overlay Network），通過這個覆蓋網絡，將數據包原封不動地傳遞到目標容器內
- ETCD在這裏的作用：爲Flannel提供說明
- 存儲管理 Flannel可分配的IP地址段資源
- 監控ETCD中每個Pod的實際地址，並在內存中建立維護Pod節點路由表
2.4：網絡通訊方式總結
- 同一個Pod內部通訊
- 同一個Pod共享同一個網絡命名空間，共享同一個 Linux協議棧
- pod1和pod2通訊–在同一臺機器：
- Pod1與Pod2不在同一臺主機，Pod的地址是與 docker0在同一個網段的，但doke0網段與宿主機網卡是兩個完全不同的IP網段，並且不同Node之間的通信只能通過宿主機的物理網卡進行。將Pod的IP和所在Node的IP關聯起來，通過這個關聯讓Pod可以互相訪問
- pod1和pod2通訊–不在同一臺機器：
- Pod1與Pod2在同一臺機器，由 Docker0網橋直接轉發請求至Pod2，不需要經過 Flanne1
- Pod至 Service的網絡
- 目前基於性能考慮，全部爲 iptables（現在版本都是通過LVS）維護和轉發
- Pod到外網
- Pod向外網發送請求，查找路由表，轉發數據包到宿主機的網卡，宿主網卡完成路由選擇後， iptables執行 Masquerade，把源IP更改爲宿主網卡的IP，然後向外網服務器發送請求
- 外網訪問Pod
- 外網訪問Pod通過Service
