1. 程式人生 > >kubernetes資源物件--pod和job

kubernetes資源物件--pod和job

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崩潰。特別是在公有云場景,往往會有惡意軟體通過搶佔記憶體來攻擊平臺。

一pod多容器

Pod主要是在容器化環境中建立一個面向應用的“邏輯主機”模型,它可以包含一個或多個相互間緊密聯絡的容器。當其中任一容器異常時,該Pod也隨之異常。

一pod多容器,讓多個同應用的單一容器整合到一個類虛擬機器中,使其所有容器共用一個vm的資源,提高耦合度,從而方便副本的複製,提高整體的可用性。

一pod多容器的優勢:

同個Pod下的容器之間能更方便的共享資料和通訊,使用相同的網路名稱空間、IP地址和埠區間,相互之間能通過localhost來發現和通訊。

在同個Pod內執行的容器共享儲存空間(如果設定),儲存卷內的資料不會在容器重啟後丟失,同時能被同Pod下別的容器讀取。

相比原生的容器介面,Pod通過提供更高層次的抽象,簡化了應用的部署和管理,不同容器提供不同服務。Pod就像一個管理橫向部署的單元,主機託管、資源共享、協調複製和依賴管理都可以自動處理。

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。