Pod詳解及 harbor憑據登入
- 一、Pod基礎概念
- 二、pod分類
- 三、Pod容器的分類
- 四、映象拉取策略(image PullPolicy)
- 五、Pod重啟策略
- 六、部署 harbor 建立私有專案
- 6.1、在 Docker harbor 節點(192.168.80.14)上操作
- 6.2、上傳 docker-compose 和 harbor-offline-installer-v1.2.2.tgz 到 /opt 目錄中
- 6.3、部署 Harbor 服務
- 6.4、在 Harbor 中建立一個新專案
- 6.5、在每個 node 節點配置連線私有倉庫(注意每行後面的逗號要新增)
- 6.6、在每個 node 節點登入 harbor 私有倉庫
- 6.7、在一個 node 節點下載 Tomcat 映象進行推送
- 6.8、檢視登陸憑據
- 6.9、建立 harbor 登入憑據資源清單
- 6.10、建立 secret 資源
- 6.11、建立資源從 harbor 中下載映象
- 6.12、node節點刪除之前在 node 節點下載的nginx映象
- 6.13、master節點建立資源
- 6.14、檢視 Pod 的描述資訊,可以發現映象時從 harbor 下載的
- 6.1、在 Docker harbor 節點(192.168.80.14)上操作
- 七、pod總結
一、Pod基礎概念
Pod是kubernetes中最小的資源管理元件,Pod也是最小化執行容器化應用的資源物件。一個Pod代表著叢集中執行的一個程序。kubernetes中其他大多陣列件都是圍繞著Pod來進行支撐和擴充套件Pod功能的,例如,用於管理Pod執行的StatefulSet和Deployment等控制器物件,用於暴露Pod應用的Service和Ingress物件,為Pod提供儲存的PersistentVolume儲存資源物件等。
一個Pod下的容器必須運行於同一節點上。現代容器技術建議一個容器只執行一個程序,該程序在容器中PID命令空間中的程序號為1,可直接接收並處理訊號,程序終止時容器生命週期也就結束了。若想在容器內執行多個程序,需要有一個類似Linux作業系統init程序的管控類程序,以樹狀結構完成多程序的生命週期管理。運行於各自容器內的程序無法直接完成網路通訊,這是由於容器間的隔離機制導致,k8s中的Pod資源抽象正是解決此類問題,Pod物件是一組容器的集合,這些容器共享Network、UTS及IPC命令空間,因此具有相同的域名、主機名和網路介面,並可通過IPC直接通訊。
Pod資源中針對各容器提供網路命令空間等共享機制的是底層基礎容器pause,基礎容器(也可稱為父容器)pause就是為了管理Pod容器間的共享操作,這個父容器需要能夠準確地知道如何去建立共享執行環境的容器,還能管理這些容器的生命週期。為了實現這個父容器的構想,kubernetes中,用pause容器來作為一個Pod中所有容器的父容器。這個pause容器有兩個核心的功能,一是它提供整個Pod的Linux名稱空間的基礎。二來啟用PID名稱空間,它在每個Pod中都作為PID為1程序(init程序),並回收殭屍程序。
1.1、k8s叢集中pod兩種使用方式
-
一個Pod中執行一個容器。“每個Pod中一個容器”的模式是最常見的用法;在這種使用方式中,你可以把Pod想象成是單個容器的封裝,kuberentes管理的是Pod而不是直接管理容器。
-
在一個Pod中同時執行多個容器。一個Pod中也可以同時封裝幾個需要緊密耦合互相協作的容器,它們之間共享資源。這些在同一個Pod中的容器可以互相協作成為一個service單位,比如一個容器共享檔案,另一個“sidecar”容器來更新這些檔案。Pod將這些容器的儲存資源作為一個實體來管理。
-
總結:每個Pod都有一個特殊的被稱為“基礎容器”的Pause容器。Pause容器對應的映象屬於Kubernetes平臺的一部分,除了Pause容器,每個Pod還包含一個或者多個緊密相關的使用者應用容器。
1.2、pause容器功能
- 在pod中擔任Linux名稱空間(如網路命令空間)共享的基礎
- 啟用PID名稱空間,開啟init程序
1.3、Pod概念和特殊組成結構用意
- 原因一:在一組容器作為一個單元的情況下,難以對整體的容器簡單地進行判斷及有效地進行行動。比如,一個容器死亡了,此時是算整體掛了麼?那麼引入與業務無關的Pause容器作為Pod的基礎容器,以它的狀態代表著整個容器組的狀態,這樣就可以解決該問題。
- 原因二:Pod裡的多個應用容器共享Pause容器的IP,共享Pause容器掛載的Volume,這樣簡化了應用容器之間的通訊問題,也解決了容器之間的檔案共享問題。
二、pod分類
2.1、自主式Pod
這種Pod本身是不能自我修復的,當Pod被建立後(不論是由你直接建立還是被其他Controller),都會被Kuberentes排程到叢集的Node上。直到Pod的程序終止、被刪掉、因為缺少資源而被驅逐、或者Node故障之前這個Pod都會一直保持在那個Node上。Pod不會自愈。如果Pod執行的Node故障,或者是排程器本身故障,這個Pod就會被刪除。同樣的,如果Pod所在Node缺少資源或者Pod處於維護狀態,Pod也會被驅逐。
2.2、控制器管理的Pod
Kubernetes使用更高階的稱為Controller的抽象層,來管理Pod例項。Controller可以建立和管理多個Pod,提供副本管理、滾動升級和叢集級別的自愈能力。例如,如果一個Node故障,Controller就能自動將該節點上的Pod排程到其他健康的Node上。雖然可以直接使用Pod,但是在Kubernetes中通常是使用Controller來管理Pod的。
三、Pod容器的分類
3.1、基礎容器(infrastructure container)
#維護整個 Pod 網路和儲存空間
#node 節點中操作
#啟動一個容器時,k8s會自動啟動一個基礎容器
cat /opt/kubernetes/cfg/kubelet
#每次建立 Pod 時候就會建立,執行的每一個容器都有一個 pause-amd64 的基礎容器自動會執行,對於使用者是透明的
docker ps -a
3.2、初始化容器(initcontainers)
#Init容器必須在應用程式容器啟動之前執行完成,而應用程式容器是並行執行的,所以Init容器能夠提供了一種簡單的阻塞或延遲應用容器的啟動的方法。
Init 容器特點
#Init 容器總是執行到成功完成為止
#每個 Init 容器都必須在下一個 Init 容器啟動之前成功完成啟動和退出
#如果 Pod 的 Init 容器失敗,k8s 會不斷地重啟該 Pod,直到 Init 容器成功為止。然而,如果 Pod 對應的重啟策略(restartPolicy)為 Never,它不會重新啟動。
Init 的容器作用
因為init容器具有與應用容器分離的單獨映象,其啟動相關程式碼具有如下優勢
- Init 容器可以包含一些安裝過程中應用容器中不存在的實用工具或個性化程式碼。例如,沒有必要僅為了在安裝過程中使用類似 sed、 awk、 python 或 dig 這樣的工具而去FROM 一個映象來生成一個新的映象。
- Init 容器可以安全地執行這些工具,避免這些工具導致應用映象的安全性降低。
- 應用映象的建立者和部署者可以各自獨立工作,而沒有必要聯合構建一個單獨的應用映象。
- Init 容器能以不同於Pod內應用容器的檔案系統檢視執行。因此,Init容器可具有訪問 Secrets 的許可權,而應用容器不能夠訪問。
- 由於 Init 容器必須在應用容器啟動之前執行完成,因此 Init 容器提供了一種機制來阻塞或延遲應用容器的啟動,
直到滿足了一組先決條件。一旦前置條件滿足,Pod內的所有的應用容器會並行啟動。
3.3、應用容器(Maincontainer)
#並行啟動
#官網示例:
https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
- name: init-mydb
image: busybox:1.28
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
kubectl describe pod myapp-pod
kubectl logs myapp-pod -c init-myservice
#這個例子是定義了一個具有 2 個 Init 容器的簡單 Pod。 第一個等待 myservice 啟動, 第二個等待 mydb 啟動。 一旦這兩個 Init容器都啟動完成,Pod 將啟動 spec 中的應用容器。
vim myservice.yaml
apiVersion: v1
kind: Service
metadata:
name: myservice
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9376
kubectl create -f myservice.yaml
kubectl get svc
kubectl get pods -n kube-system
kubectl get pods
vim mydb.yaml
apiVersion: v1
kind: Service
metadata:
name: mydb
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9999
kubectl create -f mydb.yaml
kubectl get pods
3.4、特別說明
- 在Pod啟動過程中,Init容器會按順序在網路和資料卷初始化之後啟動。每個容器必須在下一個容器啟動之前成功退出。
- 如果由於執行時或失敗退出,將導致容器啟動失敗,它會根據Pod的restartPolicy指定的策略進行重試。然而,如果Pod的restartPolicy設定為Always,Init容器失敗時會使用RestartPolicy策略。
- 在所有的Init容器沒有成功之前,Pod將不會變成Ready狀態。Init容器的埠將不會在Service中進行聚集。正在初始化中的Pod處於Pending狀態,但應該會將Initializing狀態設定為true。
- 如果Pod重啟,所有Init容器必須重新執行。
- 對Init容器spec的修改被限制在容器image欄位,修改其他欄位都不會生效。更改Init容器的image欄位,等價於重啟該Pod。
- Init容器具有應用容器的所有欄位。除了readinessProbe,因為Init容器無法定義不同於完成(completion)的就緒(readiness)之外的其他狀態。這會在驗證過程中強制執行。
- 在Pod中的每個app和Init容器的名稱必須唯一;與任何其它容器共享同一個名稱,會在驗證時丟擲錯誤。
四、映象拉取策略(image PullPolicy)
#Pod 的核心是執行容器,必須指定容器引擎,比如 Docker,啟動容器時,需要拉取映象,k8s 的映象拉取策略可以由使用者指定
1、IfNotPresent:在映象已經存在的情況下,kubelet 將不再去拉取映象,僅當本地缺失時才從倉庫中拉取,預設的映象拉取策略
2、Always:每次建立 Pod 都會重新拉取一次映象;
3、Never:Pod 不會主動拉取這個映象,僅使用本地映象。
注意:對於標籤為“:latest”的映象檔案,其預設的映象獲取策略即為“Always”;而對於其他標籤的映象,其預設策略則為“IfNotPresent”。
#官方示例:
https://kubernetes.io/docs/concepts/containers/images
4.1、建立測試案例
vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-test1
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: Always
command: [ "echo", "SUCCESS" ]
kubectl create -f pod1.yaml
kubectl get pods -o wide
#此時 Pod 的狀態異常,原因是 echo 執行完程序終止,容器生命週期也就結束了
kubectl describe pod pod-test1
、
#修改 pod1.yaml 檔案
vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-test1
spec:
containers:
- name: nginx
image: nginx:1.14 #修改 nginx 映象版本
#imagePullPolicy: Always
command: [ "echo", "SUCCESS" ]
五、Pod重啟策略
Pod 在遇到故障之後重啟的動作
1.Always:當容器終止退出後,總是重啟容器,預設策略
2.OnFailure:當容器異常退出(退出狀態碼非0)時,重啟容器;正常退出則不重啟容器
3.Never:當容器終止退出,從不重啟容器
注:K8S 中不支援重啟 Pod 資源,只有刪除重建
5.1、建立測試案例
vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-test2
spec:
containers:
- name: nginx
image: nginx;1.14
args:
- /bin/sh
- -c
- sleep 10; exit 3
kubectl apply -f pod3.yaml
kubectl get pods
#檢視Pod狀態,等容器啟動後30秒後執行exit退出程序進入error狀態,就會重啟次數加1
六、部署 harbor 建立私有專案
6.1、在 Docker harbor 節點(192.168.80.14)上操作
systemctl stop firewalld.service
systemctl disable firewalld.service
setenforce 0
#安裝docker
yum install -y yum-utils device-mapper-persistent-data lvm2
yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
yum install -y docker-ce
systemctl start docker.service
systemctl enable docker.service
6.2、上傳 docker-compose 和 harbor-offline-installer-v1.2.2.tgz 到 /opt 目錄中
cd /opt
chmod +x docker-compose
mv docker-compose /usr/local/bin/
6.3、部署 Harbor 服務
tar zxvf harbor-offline-installer-v1.2.2.tgz -C /usr/local/
vim /usr/local/harbor/harbor.cfg
--5行--修改,設定為Harbor伺服器的IP地址或者域名
hostname = 192.168.80.14
cd /usr/local/harbor/
./install.sh
6.4、在 Harbor 中建立一個新專案
(1)瀏覽器訪問:http://192.168.80.14 登入 Harbor WEB UI 介面,預設的管理員使用者名稱和密碼是 admin/Harbor12345
(2)輸入使用者名稱和密碼登入介面後可以建立一個新專案。點選“+專案”按鈕
(3)填寫專案名稱為“lk-project”,點選“確定”按鈕,建立新專案
6.5、在每個 node 節點配置連線私有倉庫(注意每行後面的逗號要新增)
cat > /etc/docker/daemon.json <<EOF
{
"registry-mirrors": ["https://6ijb8ubo.mirror.aliyuncs.com"],
"insecure-registries":["192.168.80.14"]
}
EOF
systemctl daemon-reload
systemctl restart docker
6.6、在每個 node 節點登入 harbor 私有倉庫
docker login -u admin -p Harbor12345 http://192.168.80.14
6.7、在一個 node 節點下載 Tomcat 映象進行推送
docker pull nginx
docker images
docker tag nginx:latest 192.168.80.14/lk-project/nginx:v1
docker images
docker push 192.168.80.14/lk-project/nginx:v1
6.8、檢視登陸憑據
cat /root/.docker/config.json | base64 -w 0 #base64 -w 0:進行 base64 加密並禁止自動換行
6.9、建立 harbor 登入憑據資源清單
vim harbor-pull-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: harbor-pull-secret
data:
.dockerconfigjson: ewoJImF1dGhzIjogewoJCSIxOTIuMTY4LjgwLjE0IjogewoJCQkiYXV0aCI6ICJZV1J0YVc0NlNHRnlZbTl5TVRJek5EVT0iCgkJfQoJfQp9 #複製貼上上述檢視的登陸憑據
type: kubernetes.io/dockerconfigjson
6.10、建立 secret 資源
kubectl create -f harbor-pull-secret.yaml
#看 secret 資源
kubectl get secret
6.11、建立資源從 harbor 中下載映象
vim nginx-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: my-nginx
spec:
replicas: 2
template:
metadata:
labels:
app: my-nginx
spec:
imagePullSecrets: #新增拉取 secret 資源選項
- name: harbor-pull-secret #指定 secret 資源名稱
containers:
- name: my-nginx
image: 192.168.80.14/lk-project/nginx:v1 #指定 harbor 中的映象名
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: my-ngixn
spec:
type: NodePort
ports:
- port: 8080
targetPort: 80
nodePort: 31111
selector:
app: my-nginx
6.12、node節點刪除之前在 node 節點下載的nginx映象
docker rmi nginx
docker rmi 192.168.80.14/lk-project/nginx:v1
docker images
6.13、master節點建立資源
kubectl create -f tomcat-deployment.yaml
kubectl get pods
6.14、檢視 Pod 的描述資訊,可以發現映象時從 harbor 下載的
kubectl describe pod my-nginx-6b7756d84f-l9hwl
七、pod總結
#pod執行方式
##自主式pod:沒有自愈能力
##控制器管理的pod:有自愈能力(pod被刪除後會重新拉起新的pod)
#pod3種容器
##基礎容器(pause):初始化容器環境,開啟pid=1的init程序來管理其他容器的生命週期;提供網路和儲存空間的共享環境基礎
##init容器:是在基礎容器之後,應用ring器之前執行的容器,多個init容器是序列執行,init容器必須在上一個init容器成功好執行和退出後才會執行
##應用容器(main c):執行業務的容器,在init容器都成功執行和退出後執行的,多個應用容器是並行執行的
##在一個pod中:init容器和應用容器的名稱都是惟一的
#pod映象拉取策略 imagePullPolicy 配置containers欄位下面一層
##IfNotPresent:是帶有指定標籤的映象的預設拉取策略。本地有則用本地映象,本地沒有則從倉庫拉取映象
##Always:是沒有標籤的映象或者使用latest標籤的映象的預設拉取策略,建立Pod總是從倉庫拉取映象
##Nerver:不從倉庫拉取映象,僅使用本地映象
#pod 重啟策略 restartPolicy 配置跟containers欄位同一層
##Always:預設的重啟策略,容器退出時,總是重啟容器
##Nerver:容器退出,從不重啟容器
##OnFailure:只用容器異常退出(非0狀態碼退出時),才會重啟容器