# POD解決了什麼問題？
成組資源排程問題的解決。 mesos採用的資源囤積策略容易出現死鎖和排程效率低下問題；
google採用的樂觀排程技術難度非常大；

而k8s使用pod優雅的解決了這個問題。

pod的出現解決了兩個問題。
第一：解決了超親密關係的程序協作；
第二：容器設計模式sidecar應用的載體；

# POD是什麼？

pod是邏輯概念，在linux作業系統中並不存在，對應了容器組，是k8s中原子排程單位，物理結構如下圖：




infra容器是一個使用編譯語言編寫的輕量級程式，其它業務容器共享了infra容器的network namespace，即pod的所有網路流量都是通過infra容器來處理的，永遠處於暫停狀態，跟pod同生命週期。

pod裡的容器共享volumn ;


物理結構決定了它非常適合用來處理超親密關係的容器或者說程式。


# POD的應用例子

共享volumn:的兩個容器
```yaml apiVersion: v1 kind: pod metadata: name: two-container spec: restartPolicy: Never volumes: - name: shared-data hostPath: path: /data containers: - name: nginx-container image: nginx volumeMounts: - name: shared-data mountPath: /usr/share/nginx/html - name: debian-container image: debian volumeMounts: - name: shared-data mountPath: /pod-data command: ["/bin/sh"] args: ["-c","echo hello from > /pod-data/index.html"] ```

sidecar模式應用例子：(javaweb程式採用sidecar模式共享volumn，是的war跟tomcat獨立更新和演進)
```yaml apiVersion: v1 kind: Pod metadata: name: javaweb spec: initContainers: - image: war:v2 name: war command: ["cp", "/sample.war","app"] volumeMounts: - mountPath: /app name: app-volunn containers: - image: tomcat name: tomcat command: ["sh","-c","startup.sh"] volumeMounts: - mountPath: /app name: app-volunn volumes: - name: app-volumn emptyDir: {} ```

# 小結


pod的物理結構決定了它非常適合處理超親密關係的一組容器，也是sidecar即服務網格的基礎。



 > 原創不易，關注誠可貴，轉發價更高！轉載請註明出處，讓我們互通有無，共同進步，歡迎溝通