Pod的概念
Pod類型
-
自主式 Pod
-
控制器管理的 Pod
Pod 控制器類型
-
ReplicationController & ReplicaSet & Deployment >HPA（HorizontalPodAutoScale）
-
StatefullSet
-
DaemonSet
-
Job，Cronjob
ReplicationController & ReplicaSet & Deployment
ReplicationController 用來確保容器應用的副本數始終保持在用戶定義的副本數，即如果有容器異常退出，會自動創建新的 Pod 來替代；而如果異常多出來的容器也會自動回收。 在新版本的 Kubernetes 中建議使用 ReplicaSet 來取代 ReplicationController
ReplicaSet 跟 ReplicationController 沒有本質的不同，只是名字不一樣，並且 ReplicaSet 支持集合式的 selector
雖然 ReplicaSet 可以獨立使用，但一般還是建議使用 Deployment 來自動管理 ReplicaSet ，這樣就無需擔心跟其他機制的不兼容問題（比如 ReplicaSet 不支持 rolling-update 但 Deployment 支持）
Deployment(ReplicaSet)
Deployment 爲 Pod 和 ReplicaSet 提供了一個聲明式定義 (declarative) 方法，用來替 代以前的 ReplicationController 來方便的管理應用。典型的應用場景包括：
-
定義 Deployment 來創建 Pod 和 ReplicaSet
-
滾動升級和回滾應用
-
擴容和縮容
-
暫停和繼續 Deployment
HPA(HorizontalPodAutoScale)
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 到 N-1，在下一個 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 成功結束 Cron Job 管理基於時間的 Job，即：
- 在給定時間點只運行一次
- 週期性地在給定時間點運行
服務發現
網絡通訊方式
網絡通訊模式
Kubernetes 的網絡模型假定了所有 Pod 都在一個可以直接連通的扁平的網絡空間中，這在 GCE（Google Compute Engine）裏面是現成的網絡模型，Kubernetes 假定這個網絡已經存在。 而在私有云裏搭建 Kubernetes 集羣，就不能假定這個網絡已經存在了。我們需要自己實現這 個網絡假設，將不同節點上的 Docker 容器之間的互相訪問先打通，然後運行 Kubernetes
同一個 Pod 內的多個容器之間：lo
各 Pod 之間的通訊：Overlay Network
**Pod 與 Service 之間的通訊：各節點的 Iptables 規則 **
通過ifconfig可以查看
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 130 bytes 14131 (13.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 130 bytes 14131 (13.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
網絡解決方案 Kubernetes + Flannel
Flannel 是 CoreOS 團隊針對 Kubernetes 設計的一個網絡規劃服務，簡單來說，它的功能是 讓集羣中的不同節點主機創建的 Docker 容器都具有全集羣唯一的虛擬IP地址。而且它還能在 這些 IP 地址之間建立一個覆蓋網絡（Overlay Network），通過這個覆蓋網絡，將數據包原封 不動地傳遞到目標容器內
ETCD 之 Flannel 提供說明：
存儲管理 Flannel 可分配的 IP 地址段資源
監控 ETCD 中每個 Pod 的實際地址，並在內存中建立維護 Pod 節點路由表
不同情況下網絡通信方式
同一個 Pod 內部通訊：同一個 Pod 共享同一個網絡命名空間，共享同一個 Linux 協議棧
Pod1 至 Pod2
-
Pod1 與 Pod2 不在同一臺主機，Pod的地址是與docker0在同一個網段的，但docker0網段與宿主機網卡是兩個完 全不同的IP網段，並且不同Node之間的通信只能通過宿主機的物理網卡進行。將Pod的IP和所在Node的IP關聯起來，通過 這個關聯讓Pod可以互相訪問
-
Pod1 與 Pod2 在同一臺機器，由 Docker0 網橋直接轉發請求至 Pod2，不需要經過 Flannel
Pod 至 Service 的網絡：目前基於性能考慮，全部爲 iptables 維護和轉發
Pod 到外網：Pod 向外網發送請求，查找路由表, 轉發數據包到宿主機的網卡，宿主網卡完成路由選擇後，iptables執 行Masquerade，把源 IP 更改爲宿主網卡的 IP，然後向外網服務器發送請求 外網訪問 Pod：Service
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:69:89:95:a7 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
