Kubernetes POD和JOB
pod
Pod是K8S的最小操作單元，一個(gè)Pod可以由一個(gè)或多個(gè)容器組成；
整個(gè)K8S系統(tǒng)都是圍繞著Pod展開的，比如如何部署運(yùn)行Pod、如何保證Pod的數(shù)量、如何訪問Pod等。
特點(diǎn)
Pod是能夠被創(chuàng)建、調(diào)度和管理的最小單元；每個(gè)Pod都有一個(gè)獨(dú)立的IP；
一個(gè)Pod由一個(gè)或多個(gè)容器構(gòu)成，并共享命名空間和共享存儲(chǔ)等；Pod所有容器在同一個(gè)Node上；
容器生命周期管理
對(duì)資源使用進(jìn)行限制，resources(requests、limits)
對(duì)容器進(jìn)行探測(cè)：livenessProbe
集群內(nèi)的Pod之間都可以任意訪問，這一般是通過一個(gè)二層網(wǎng)絡(luò)來實(shí)現(xiàn)的。
Pod與容器
在Docker中，容器是最小的處理單元，增刪改查的對(duì)象是容器，容器是一種虛擬化技術(shù)，容器之間是隔離的，隔離是基于Linux Namespace實(shí)現(xiàn)的。
而在K8S中，Pod包含一個(gè)或者多個(gè)相關(guān)的容器，Pod可以認(rèn)為是容器的一種延伸擴(kuò)展，一個(gè)Pod也是一個(gè)隔離體，而Pod內(nèi)部包含的一組容器又是共享的（包括PID、Network、IPC、UTS）。除此之外，Pod中的容器可以訪問共同的數(shù)據(jù)卷來實(shí)現(xiàn)文件系統(tǒng)的共享。
資源請(qǐng)求與限制
創(chuàng)建Pod時(shí)，可以指定計(jì)算資源（目前支持的資源類型有CPU和內(nèi)存），即指定每個(gè)容器的資源請(qǐng)求（Request）和資源限制（Limit），資源請(qǐng)求是容器所需的最小資源需求，資源限制則是容器不能超過的資源上限。關(guān)系是： 0<=request<=limit<=infinity
Pod的資源請(qǐng)求就是Pod中所有容器資源請(qǐng)求之和。K8S在調(diào)度Pod時(shí)，會(huì)根據(jù)Node中的資源總量（通過cAdvisor接口獲得），以及該Node上已使用的計(jì)算資源，來判斷該Node是否滿足需求。
資源請(qǐng)求能夠保證Pod有足夠的資源來運(yùn)行，而資源限制則是防止某個(gè)Pod無限制地使用資源，導(dǎo)致其他Pod崩潰。特別是在公有云場(chǎng)景，往往會(huì)有惡意軟件通過搶占內(nèi)存來攻擊平臺(tái)。
具體配置資源限制如下所示:
resources:
limits:
memory: {{ .ContainerMemory }}Gi
cpu: {{ .ContainerCPU }}
一pod多容器
Pod主要是在容器化環(huán)境中建立一個(gè)面向應(yīng)用的“邏輯主機(jī)”模型，它可以包含一個(gè)或多個(gè)相互間緊密聯(lián)系的容器。當(dāng)其中任一容器異常時(shí)，該P(yáng)od也隨之異常。
一pod多容器，讓多個(gè)同應(yīng)用的單一容器整合到一個(gè)類虛擬機(jī)中，使其所有容器共用一個(gè)vm的資源，提高耦合度，從而方便副本的復(fù)制，提高整體的可用性。
一pod多容器的優(yōu)勢(shì)：
同個(gè)Pod下的容器之間能更方便的共享數(shù)據(jù)和通信，使用相同的網(wǎng)絡(luò)命名空間、IP地址和端口區(qū)間，相互之間能通過localhost來發(fā)現(xiàn)和通信。
在同個(gè)Pod內(nèi)運(yùn)行的容器共享存儲(chǔ)空間（如果設(shè)置），存儲(chǔ)卷內(nèi)的數(shù)據(jù)不會(huì)在容器重啟后丟失，同時(shí)能被同Pod下別的容器讀取。
相比原生的容器接口，Pod通過提供更高層次的抽象，簡(jiǎn)化了應(yīng)用的部署和管理，不同容器提供不同服務(wù)。Pod就像一個(gè)管理橫向部署的單元，主機(jī)托管、資源共享、協(xié)調(diào)復(fù)制和依賴管理都可以自動(dòng)處理。
Job
在有些場(chǎng)景下，是想要運(yùn)行一些容器執(zhí)行某種特定的任務(wù)，任務(wù)一旦執(zhí)行完成，容器也就沒有存在的必要了。在這種場(chǎng)景下，創(chuàng)建pod就顯得不那么合適。于是就是了Job，Job指的就是那些一次性任務(wù)。通過Job運(yùn)行一個(gè)容器，當(dāng)其任務(wù)執(zhí)行完以后，就自動(dòng)退出，集群也不再重新將其喚醒。
從程序的運(yùn)行形態(tài)上來區(qū)分，可以將Pod分為兩類：長(zhǎng)時(shí)運(yùn)行服務(wù)（jboss、mysql等）和一次性任務(wù)（數(shù)據(jù)計(jì)算、測(cè)試）。RC創(chuàng)建的Pod都是長(zhǎng)時(shí)運(yùn)行的服務(wù)，Job多用于執(zhí)行一次性任務(wù)、批處理工作等，執(zhí)行完成后便會(huì)停止（status.phase變?yōu)镾ucceeded）。
yaml配置參數(shù)說明
重啟策略
支持兩種重啟策略：
OnFailure:在出現(xiàn)故障時(shí)其內(nèi)部重啟容器，而不是創(chuàng)建。
Never:會(huì)在出現(xiàn)故障時(shí)創(chuàng)建新的，且故障job不會(huì)消失。
設(shè)置超時(shí)
job執(zhí)行超時(shí)時(shí)間可以通過spec.activeDeadlineSeconds來設(shè)置，超過指定時(shí)間未完成的job會(huì)以DeadlineExceeded原因停止
并行
.spec.completions：這個(gè)job運(yùn)行pod的總次數(shù)
.spec.parallelism：并發(fā)數(shù)，每次同時(shí)運(yùn)行多少個(gè)pod
當(dāng)completions少于parallelism，parallelism的值為completions
可以使用kubectl scale命令來增加或者減少completions的值
pod selector
job同樣可以指定selector來關(guān)聯(lián)pod。需要注意的是job目前可以使用兩個(gè)API組來操作，batch/v1和extensions/v1beta1。當(dāng)用戶需要自定義selector時(shí)，使用兩種API組時(shí)定義的參數(shù)有所差異。
使用batch/v1時(shí)，用戶需要將jod的spec.manualSelector設(shè)置為true，才可以定制selector。默認(rèn)為false。
使用extensions/v1beta1時(shí)，用戶不需要額外的操作。因?yàn)閑xtensions/v1beta1的spec.autoSelector默認(rèn)為false，該項(xiàng)與batch/v1的spec.manualSelector含義正好相反。換句話說，使用extensions/v1beta1時(shí)，用戶不想定制selector時(shí)，需要手動(dòng)將spec.autoSelector設(shè)置為true。
例子
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
POD和JOB的區(qū)別
job執(zhí)行完后，不會(huì)自動(dòng)啟動(dòng)一個(gè)新的pod，pod也不會(huì)被自動(dòng)刪除。
使用kubectl get pod無法顯示執(zhí)行完的job的pod，詳細(xì)查看已運(yùn)行過的job的pod需要添加參數(shù)—all-show或者-a，kubectl get pods -a。
