一、Pod
1.1 基礎概念
1.Pod是kubernetes中最小的資源管理組件,Pod也是最小化運行容器化 應用的資源對象。一個Pod代表着集群中運行的一個進程。kubernetes中其他大多數組件都是圍繞着Pod來進行支撐和擴展Pod功能的,例如,用於管理Pod運行的StatefulSet和Deployment等控制器對象,用於暴露Pod應用的Service和Ingress對象,為Pod提供存儲的PersistentVolume存儲資源對象等
2.一個Pod下的容器必須運行於同一節點上。現代容器技術建議一個容器只運行一個進程,該進程在容器中PID命令空間中的進程號為1,可直接接收並處理信號,進程終止時容器生命周期也就結束了。若想在容器內運行多個進程,需要有一個類似Linux操作系統init進程的管控類進程,以樹狀結構完成多進程的生命周期管理。運行於各自容器內的進程無法直接完成網絡通信,這是由於容器間的隔離機制導致,k8s中的Pod資源抽象正是解決此類問題,Pod對象是一組容器的集合,這些容器共享Network、UTS及IPC命令空間,因此具有相同的域名、主機名和網絡接口,並可通過IPC直接通信
1.2 在k8s集群中pod的使用方式
1.一個Pod中運行一個容器。“每個Pod中一個容器”的模式是最常見的用法;在這種使用方式中,你可以把Pod想象成是單個容器的封裝,kuberentes管理的是Pod而不是直接管理容器
2.在一個Pod中同時運行多個容器。一個Pod中也可以同時封裝幾個需要緊密耦合互相協作的容器,它們之間共享資源。這些在同一個Pod中的容器可以互相協作成為一個service單位,比如一個容器共享文件,另一個“sidecar”容器來更新這些文件。Pod將這些容器的存儲資源作為一個實體來管理
1.3 Pod容器的分類
1.自主式Pod:
這種Pod本身是不能自我修復的,當Pod被創建后(不論是由你直接創建還是被其他Controller),都會被Kuberentes調度到集群的Node上。直到Pod的進程終止、被刪掉、因為缺少資源而被驅逐、或者Node故障之前這個Pod都會一直保持在那個Node上。Pod不會自愈。如果Pod運行的Node故障,或者是調度器本身故障,這個Pod就會被刪除。同樣的,如果Pod所在Node缺少資源或者Pod處於維護狀態,Pod也會被驅逐
2.控制器管理的Pod:
Kubernetes使用更高級的稱為Controller的抽象層,來管理Pod實例。Controller可以創建和管理多個Pod,提供副本管理、滾動升級和集群級別的自愈能力。例如,如果一個Node故障,Controller就能自動將該節點上的Pod調度到其他健康的Node上。雖然可以直接使用Pod,但是在Kubernetes中通常是使用Controller來管理Pod的
1.4 pod中的3種容器
1.4.1 底層基礎容器pause
1.Pod資源中針對各容器提供網絡命令空間等共享機制的是底層基礎容器pause,基礎容器(也可稱為父容器)pause就是為了管理Pod容器間的共享操作,這個父容器需要能夠准確地知道如何去創建共享運行環境的容器,還能管理這些容器的生命周期。為了實現這個父容器的構想,kubernetes中,用pause容器來作為一個Pod中所有容器的父容器
2.pause容器有兩個核心的功能:
1)啟用PID命名空間,開啟init進程來管理其他容器的生命周期
2)提供網絡和存儲空間的共享基礎:
網絡:每個Pod都會被分配一個唯一的IP地址。Pod中的所有容器共享網絡空間,包括IP地址和端口。Pod內部的容器可以使用localhost互相通信。Pod中的容器與外界通信時,必須分配共享網絡資源(例如使用宿主機的端口映射)
存儲空間:可以Pod指定多個共享的Volume。Pod中的所有容器都可以訪問共享的Volume。Volume也可以用來持久化Pod中的存儲資源,以防容器重啟后文件丟失
1.4.2 初始化容器(initcontainers)
1)概念
Init容器必須在應用程序容器啟動之前運行完成,而應用程序容器是並行運行的,所以Init容器能夠提供了一種簡單的阻塞或延遲應用容器的啟動的方法。Init容器與普通的容器非常像,除了以下兩點:
1.Init容器總是運行到成功完成為止
2.每個Init容器都必須在下一個 Init 容器啟動之前成功完成啟動和退出
如果 Pod 的 Init 容器失敗,k8s 會不斷地重啟該 Pod,直到 Init 容器成功為止。然而,如果 Pod 對應的重啟策略(restartPolicy)為 Never,它不會重新啟動
2)Init的容器作用
因為init容器具有與應用容器分離的單獨鏡像,其啟動相關代碼具有如下優勢:
1.Init 容器可以包含一些安裝過程中應用容器中不存在的實用工具或個性化代碼。例如,沒有必要僅為了在安裝過程中使用類似 sed、awk、python或dig這樣的工具而去FROM 一個鏡像來生成一個新的鏡像
2.Init容器可以安全地運行這些工具,避免這些工具導致應用鏡像的安全性降低
3.應用鏡像的創建者和部署者可以各自獨立工作,而沒有必要聯合構建一個單獨的應用鏡像
4.Init容器能以不同於Pod內應用容器的文件系統視圖運行。因此,Init容器可具有訪問 Secrets 的權限,而應用容器不能夠訪問
5.由於Init容器必須在應用容器啟動之前運行完成,因此Init容器提供了一種機制來阻塞或延遲應用容器的啟動,直到滿足了一組先決條件。一旦前置條件滿足,Pod內的所有的應用容器會並行啟動
1.4.3 應用容器(Maincontainer)
1.並行啟動
2.官網實例:https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
1.4.4 實例創建
vim demo1.yaml
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 apply -f demo1.yaml
kubectl get pods
kubectl describe pod myapp-pod
vim myservice.yaml
apiVersion: v1
kind: Service
metadata:
name: myservice
spec:
ports:
- protocol: TCP
port: 80
targetPort: 1111
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: 2222
kubectl create -f mydb.yaml
kubectl get pods
特別說明:
●在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容器的名稱必須唯一;與任何其它容器共享同一個名稱,會在驗證時拋出錯誤。
1.5 鏡像拉取策略(image PullPolicy)
1.5.1 概念
Pod的核心是運行容器,必須指定容器引擎,比如Docker,啟動容器時,需要拉取鏡像,k8s的鏡像拉取策略可以由用戶指定:
1、IfNotPresent:在鏡像已經存在的情況下,kubelet 將不再去拉取鏡像,僅當本地缺失時才從倉庫中拉取,默認的鏡像拉取策略
2、Always:每次創建 Pod 都會重新拉取一次鏡像
3、Never:Pod 不會主動拉取這個鏡像,僅使用本地鏡像。
注意:對於標簽為“:latest”的鏡像文件,其默認的鏡像獲取策略即為“Always”;而對於其他標簽的鏡像,其默認策略則為“IfNotPresent”
1.5.2 創建測試案例
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
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
===========================================================
kubectl delete -f pod1.yaml
kubectl create -f pod1.yaml
kubectl get pods -o wide
kubectl describe pod pod-test1
1.6 pod的重啟策略
1.6.1 三種策略
Pod 在遇到故障之后重啟的動作
1.Always:當容器終止退出后,總是重啟容器,默認策略 2.OnFailure:當容器異常退出(退出狀態碼非0)時,重啟容器;正常退出則不重啟容器
3.Never:當容器終止退出,從不重啟容器
注:K8S 中不支持重啟 Pod 資源,只有刪除重建
1.6.2 實例創建
vim pod2.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod2
spec:
containers:
- name: busybox
image: busybox
args:
- /bin/sh
- -c
- sleep 5; exit 3
===========================================================
kubectl apply -f pod2.yaml
kubectl get pods
vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod3
spec:
containers:
- name: busybox
image: busybox
args:
- /bin/sh
- -c
- sleep 10; exit 3
restartPolicy: Never #注意:跟container同一個級別
===========================================================
kubectl apply -f pod3.yaml
//容器進入error狀態不會進行重啟
kubectl get pods -w
二、部署harbor創建私有項目(憑據令牌)
2.1 環境准備
#關閉防火牆和安全功能
systemctl stop firewalld.service
systemctl disable firewalld.service
setenforce 0
2.2 安裝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
docker version
2.3 上傳docker-compose和harbor軟件包
cd /opt
上傳 docker-compose 和 harbor-offline-installer-v1.2.2.tgz 到 /opt 目錄中
chmod +x docker-compose
mv docker-compose /usr/local/bin/
2.4 部署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 #安裝
2.5 在 Harbor 中創建一個新項目
1.瀏覽器訪問:http://192.168.80.14 登錄 Harbor WEB UI 界面,默認的管理員用戶名和密碼是 admin/Harbor12345
2.輸入用戶名和密碼登錄界面后可以創建一個新項目。點擊“+項目”按鈕
3.填寫項目名稱為“gxd-project”,點擊“確定”按鈕,創建新項目
2.6 在每個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
2.7 在每個node節點登錄harbor私有倉庫
docker login -u admin -p Harbor12345 http://192.168.80.14
2.8 在一個node節點下載nginx鏡像進行推送
docker pull nginx:1.14
docker images
docker tag nginx:1.14 192.168.80.14/gxd-project/nginx:111
docker images
docker push 192.168.80.14/gxd-project/nginx:111
2.9 查看登陸憑據
cat /root/.docker/config.json | base64 -w 0 #base64 -w 0:進行 base64 加密並禁止自動換行
...
...
2.10 在主節點創建harbor登錄憑據資源清單
vim harbor-pull-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: harbor-pull-secret
data:
.dockerconfigjson: ewoJImF1dGhzIjogewoJCSIxOTIuMTY4LjgwLjE0IjogewoJCQkiYXV0aCI6ICJZV1J0YVc0NlNHRnlZbTl5TVRJek5EVT0iCgkJfSwKCQkiaHViLmd4ZC5jb20iOiB7CgkJCSJhdXRoIjogIllXUnRhVzQ2U0dGeVltOXlNVEl6TkRVPSIKCQl9Cgl9Cn0= #復制粘貼上述查看的登陸憑據
type: kubernetes.io/dockerconfigjson
===========================================================
創建 secret 資源
kubectl create -f harbor-pull-secret.yaml
//查看 secret 資源
kubectl get secret
2.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/gxd-project/nginx:111 #指定 harbor 中的鏡像名
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: my-nginx
spec:
type: NodePort
ports:
- port: 8888
targetPort: 80
nodePort: 31111
selector:
app: my-nginx
2.12 在node節點上刪除之前下載的nginx鏡像
docker rmi -f nginx:1.14
docker rmi -f 192.168.80.14/gxd-project/nginx:111
docker images
2.13 創建資源
kubectl create -f nginx-deployment.yaml
kubectl get pods
2.14 查看Pod的描述信息
//發現鏡像時從 harbor 下載的
kubectl describe pod my-nginx-69867795cc-7zklx
//刷新harbor頁面,可以看到鏡像的下載次數增加了
三、總結
1.pod運行方式
1.控制器管理的pod∶有自愈能力(Pod被刪除后會重啟拉起新的pod)
2.自主式pod∶沒有自愈能力
2.pod中有幾種容器∶3種
1.基礎容器(pause)∶初始化容器環境,開啟pid=1的init進程來管理其它容器的生命周期,提供網絡和存儲空間的共享環境基礎
2.init容器∶是在基礎容器之后,應用容器之前運行的容器,多個init容器是串行運行,Init容器必須在上一個init容器成功運行和退出后才會運行
3.應用容器(main c)∶運行業務的容器,在Init容器都成功運行和退出后運行的,多個應用容器是並行運行的
注:在一個pod中,init容器和應用容器的名稱都是唯一的
3.pod鏡像拉取策略imagePullPolicy(配置 containers 字段下面一層)
1.IfNotPresent∶是帶有指定標簽的鏡像的默認拉取策略。本地有則用本地鏡像,本地沒有則從倉庫拉取鏡像
2.Always∶ 是沒有標簽的鏡像或者使用latest標簽的鏡像的默認拉取策略。 創建Pod總是從倉庫拉取鏡像
3.Never∶不從倉庫拉取鏡像,僅使用本地鏡像
4.pod重啟策略 restartPolicy (配置跟 containers 字段同一層)
1.Always ∶默認的重啟策略。容器退出時,總是重啟容器
2.Never ∶容器退出,從不重啟容器
3.OnFailure ∶只有容器異常退出(非0狀態碼退出)時,才會重啟容器