pod
Pod是K8S的最小操作單元，一個Pod可以由一個或多個容器組成；
整個K8S系統都是圍繞着Pod展開的，比如如何部署運行Pod、如何保證Pod的數量、如何訪問Pod等。
特點
Pod是能夠被創建、調度和管理的最小單元；
每個Pod都有一個獨立的IP；
一個Pod由一個或多個容器構成，並共享命名空間和共享存儲等；Pod所有容器在同一個Node上；
容器生命週期管理；
對資源使用進行限制，resources（requests、limits）；
對容器進行探測：livenessProbe；
集羣內的Pod之間都可以任意訪問，這一般是通過一個二層網絡來實現的。
Pod與容器
在Docker中，容器是最小的處理單元，增刪改查的對象是容器，容器是一種虛擬化技術，容器之間是隔離的，隔離是基於Linux Namespace實現的。
而在K8S中，Pod包含一個或者多個相關的容器，Pod可以認爲是容器的一種延伸擴展，一個Pod也是一個隔離體，而Pod內部包含的一組容器又是共享的（包括PID、Network、IPC、UTS）。除此之外，Pod中的容器可以訪問共同的數據捲來實現文件系統的共享。
資源請求與限制
創建Pod時，可以指定計算資源（目前支持的資源類型有CPU和內存），即指定每個容器的資源請求（Request）和資源限制（Limit），資源請求是容器所需的最小資源需求，資源限制則是容器不能超過的資源上限。關係是： 0<=request<=limit<=infinity
Pod的資源請求就是Pod中所有容器資源請求之和。K8S在調度Pod時，會根據Node中的資源總量（通過cAdvisor接口獲得），以及該Node上已使用的計算資源，來判斷該Node是否滿足需求。
資源請求能夠保證Pod有足夠的資源來運行，而資源限制則是防止某個Pod無限制地使用資源，導致其他Pod崩潰。特別是在公有云場景，往往會有惡意軟件通過搶佔內存來攻擊平臺。
具體配置請見http://blog.csdn.net/liyingke112/article/details/77452630
一pod多容器
Pod主要是在容器化環境中建立一個面向應用的“邏輯主機”模型，它可以包含一個或多個相互間緊密聯繫的容器。當其中任一容器異常時，該Pod也隨之異常。
一pod多容器，讓多個同應用的單一容器整合到一個類虛擬機中，使其所有容器共用一個vm的資源，提高耦合度，從而方便副本的複製，提高整體的可用性。
一pod多容器的優勢：
同個Pod下的容器之間能更方便的共享數據和通信，使用相同的網絡命名空間、IP地址和端口區間，相互之間能通過localhost來發現和通信。
在同個Pod內運行的容器共享存儲空間（如果設置），存儲卷內的數據不會在容器重啓後丟失，同時能被同Pod下別的容器讀取。
相比原生的容器接口，Pod通過提供更高層次的抽象，簡化了應用的部署和管理，不同容器提供不同服務。Pod就像一個管理橫向部署的單元，主機託管、資源共享、協調複製和依賴管理都可以自動處理。
yaml文件格式請見http://blog.csdn.net/liyingke112/article/details/76155428
Job
概念
在有些場景下，是想要運行一些容器執行某種特定的任務，任務一旦執行完成，容器也就沒有存在的必要了。在這種場景下，創建pod就顯得不那麼合適。於是就是了Job，Job指的就是那些一次性任務。通過Job運行一個容器，當其任務執行完以後，就自動退出，集羣也不再重新將其喚醒。
從程序的運行形態上來區分，可以將Pod分爲兩類：長時運行服務（jboss、mysql等）和一次性任務（數據計算、測試）。RC創建的Pod都是長時運行的服務，Job多用於執行一次性任務、批處理工作等，執行完成後便會停止（status.phase變爲Succeeded）。
yaml配置參數說明
重啓策略
支持兩種重啓策略：
OnFailure:在出現故障時其內部重啓容器，而不是創建。
Never:會在出現故障時創建新的，且故障job不會消失。
設置超時
job執行超時時間可以通過spec.activeDeadlineSeconds來設置，超過指定時間未完成的job會以DeadlineExceeded原因停止
並行
.spec.completions：這個job運行pod的總次數
.spec.parallelism：併發數，每次同時運行多少個pod
當completions少於parallelism，parallelism的值爲completions
可以使用kubectl scale命令來增加或者減少completions的值
pod selector
job同樣可以指定selector來關聯pod。需要注意的是job目前可以使用兩個API組來操作，batch/v1和extensions/v1beta1。當用戶需要自定義selector時，使用兩種API組時定義的參數有所差異。
使用batch/v1時，用戶需要將jod的spec.manualSelector設置爲true，纔可以定製selector。默認爲false。
使用extensions/v1beta1時，用戶不需要額外的操作。因爲extensions/v1beta1的spec.autoSelector默認爲false，該項與batch/v1的spec.manualSelector含義正好相反。換句話說，使用extensions/v1beta1時，用戶不想定製selector時，需要手動將spec.autoSelector設置爲true。
例子
kubectl delete -f kube-lykops-job.yaml
cat << EOF > kube-lykops-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
labels:
app: job
project: lykops
version: v1
name: lykops-job
namespace: default
spec:
completions: 50
parallelism: 5
template:
metadata:
labels:
app: job
job-name: lykops-job
project: lykops
version: v1
name: lykops-job
spec:
containers:
- command: ['sleep','60']
image: web:apache
name: lykops-job
restartPolicy: Never
EOF
kubectl create -f kube-lykops-job.yaml
細節
job執行完後，不會自動啓動一個新的pod，pod也不會被自動刪除。
使用kubectl get pod無法顯示執行完的job的pod，需要添加參數—all-show或者-a，kubectl get pods -a。