POD解決了什么問題？
成組資源調度問題的解決，
mesos采用的資源囤積策略容易出現死鎖和調度效率低下問題；
google采用的樂觀調度技術難度非常大；
而k8s使用pod優雅的解決了這個問題，
pod的出現解決了兩個問題，
第一：解決了超親密關系的行程協作；
第二：容器設計模式sidecar應用的載體；
POD是什么？
pod是邏輯概念，在linux作業系統中并不存在，對應了容器組，是k8s中原子調度單位，物理結構如下圖：
infra容器是一個使用編譯語言撰寫的輕量級程式，其它業務容器共享了infra容器的network namespace，即pod的所有網路流量都是通過infra容器來處理的，永遠處于暫停狀態，跟pod同生命周期，
pod里的容器共享volumn ;
物理結構決定了它非常適合用來處理超親密關系的容器或者說程式，
POD的應用例子
共享volumn:的兩個容器
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獨立更新和演進)
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即服務網格的基礎，
原創不易，關注誠可貴，轉發價更高！轉載請注明出處，讓我們互通有無，共同進步，歡迎溝通交流，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/259643.html
標籤：其他
上一篇：Spring應用背景關系生命周期