一、Pod基礎概念
- 1.1//在Kubrenetes集群中Pod有如下兩種使用方式：
- 1.2pause容器使得Pod中的所有容器可以共享兩種資源：網絡和存儲。
- 1.3kubernetes中的pause容器主要為每個容器提供以下功能：
- 1.4Kubernetes設計這樣的Pod概念和特殊組成結構有什么用意？？？？？
- 1.5通常把Pod分為以下幾類：
- 1.6Pod容器的分類：
- - 1、基礎容器（infrastructure container）
  - 2、初始化容器（initcontainers）
  - 3、應用容器（Maincontainer）
- 1.7鏡像拉取策略（imagePullPolicy）
- 1.8部署 harbor 創建私有項目

一、Pod基礎概念

Pod是kubernetes中最小的資源管理組件，Pod也是最小化運行容器化應用的資源對象。一個Pod代表著集群中運行的一個進程。kubernetes中其他大多數組件都是圍繞著Pod來進行支撐和擴展Pod功能的，例如，用于管理Pod運行的StatefulSet和Deployment等控制器對象，用于暴露Pod應用的Service和Ingress對象，為Pod提供存儲的PersistentVolume存儲資源對象等。

1.1//在Kubrenetes集群中Pod有如下兩種使用方式：

●一個Pod中運行一個容器。“每個Pod中一個容器”的模式是最常見的用法；在這種使用方式中，你可以把Pod想象成是單個容器的封裝，kuberentes管理的是Pod而不是直接管理容器。

●在一個Pod中同時運行多個容器。一個Pod中也可以同時封裝幾個需要緊密耦合互相協作的容器，它們之間共享資源。這些在同一個Pod中的容器可以互相協作成為一個service單位，比如一個容器共享文件，另一個“sidecar”容器來更新這些文件。Pod將這些容器的存儲資源作為一個實體來管理。

一個Pod下的容器必須運行于同一節點上。現代容器技術建議一個容器只運行一個進程，該進程在容器中PID命名空間中的進程號為1，可直接接收并處理信號，進程終止時容器生命周期也就結束了。若想在容器內運行多個進程，需要有一個類似Linux操作系統init進程的管控類進程，以樹狀結構完成多進程的生命周期管理。運行于各自容器內的進程無法直接完成網絡通信，這是由于容器間的隔離機制導致，k8s中的Pod資源抽象正是解決此類問題，Pod對象是一組容器的集合，這些容器共享NET、MNT、UTS及IPC命名空間，因此具有相同的域名、主機名和網絡接口，并可通過IPC直接通信。

Pod資源中針對各容器提供網絡命名空間等共享機制的是底層基礎容器pause，基礎容器（也可稱為父容器）pause就是為了管理Pod容器間的共享操作，這個父容器需要能夠準確地知道如何去創建共享運行環境的容器，還能管理這些容器的生命周期。為了實現這個父容器的構想，kubernetes中，用pause容器來作為一個Pod中所有容器的父容器。這個pause容器有兩個核心的功能，一是它提供整個Pod的Linux命名空間的基礎。二來啟用PID命名空間，它在每個Pod中都作為PID為1進程（init進程），并回收僵尸進程。

1.2pause容器使得Pod中的所有容器可以共享兩種資源：網絡和存儲。

●網絡：

每個Pod都會被分配一個唯一的IP地址。Pod中的所有容器共享網絡空間，包括IP地址和端口。Pod內部的容器可以使用localhost互相通信。Pod中的容器與外界通信時，必須分配共享網絡資源（例如使用宿主機的端口映射）。

●存儲：

Pod可以指定多個共享的Volume。Pod中的所有容器都可以訪問共享的Volume。Volume也可以用來持久化Pod中的存儲資源，以防容器重啟后文件丟失。

1.3kubernetes中的pause容器主要為每個容器提供以下功能：

●在pod中擔任Linux命名空間（如網絡命令空間）共享的基礎；
●啟用PID命名空間，開啟init進程。

1.4Kubernetes設計這樣的Pod概念和特殊組成結構有什么用意？？？？？

●原因一：在一組容器作為一個單元的情況下，難以對整體的容器簡單地進行判斷及有效地進行行動。比如，一個容器死亡了，此時是算整體掛了么？那么引入與業務無關的Pause容器作為Pod的基礎容器，以它的狀態代表著整個容器組的狀態，這樣就可以解決該問題。

●原因二：Pod里的多個應用容器共享Pause容器的IP，共享Pause容器掛載的Volume，這樣簡化了應用容器之間的通信問題，也解決了容器之間的文件共享問題。

1.5通常把Pod分為以下幾類：

●自主式Pod

這種Pod本身是不能自我修復的，當Pod被創建后（不論是由你直接創建還是被其他Controller），都會被Kuberentes調度到集群的Node上。直到Pod的進程終止、被刪掉、因為缺少資源而被驅逐、或者Node故障之前這個Pod都會一直保持在那個Node上。Pod不會自愈。如果Pod運行的Node故障，或者是調度器本身故障，這個Pod就會被刪除。同樣的，如果Pod所在Node缺少資源或者Pod處于維護狀態，Pod也會被驅逐。

●控制器管理的Pod

Kubernetes使用更高級的稱為Controller的抽象層，來管理Pod實例。Controller可以創建和管理多個Pod，提供副本管理、滾動升級和集群級別的自愈能力。例如，如果一個Node故障，Controller就能自動將該節點上的Pod調度到其他健康的Node上。雖然可以直接使用Pod，但是在Kubernetes中通常是使用Controller來管理Pod的。

●靜態Pod

靜態 Pod 直接由特定節點上的 kubelet 進程來管理，不通過 master 節點上的 apiserver 。無法與控制器 Deployment 或者 DaemonSet 進行關聯，它由 kubelet 進程自己來監控，當 pod 崩潰時重啟該 pod ， kubelete 也無法對他們進行健康檢查。靜態 pod 始終綁定在某一個 kubelet ，并且始終運行在同一個節點上。 kubelet 會自動為每一個靜態 pod 在 Kubernetes 的 apiserver 上創建一個鏡像 Pod（Mirror Pod），因此我們可以在 apiserver 中查詢到該 pod，但是不能通過 apiserver 進行控制（例如不能刪除）。

查看kubelet配置文件

/var/lib/kubelet/config.yaml
cat /var/lib/kubelet/config.yaml | grep staticPodPath
staticPodPath: /etc/kubernetes/manifests

也可以通過下面命令找到kubelet對應的啟動配置文件，修改node節點的kubelet配置文件，添加靜態Pod的環境變量配置 --pod-manifest-path 參數

systemctl status kubelet
/usr/lib/systemd/system/kubelet.service.d└─10-kubeadm.confvim /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allowprivileged=true"systemctl daemon-reload
systemctl restart kubelet

在靜態Pod文件的管理目錄下準備 Pod 的 Json 或者 Yaml 文件

vim /etc/kubernetes/manifests/static-web.yaml
apiVersion: v1
kind: Pod
metadata:name: static-weblabels:app: static
spec:containers:- name: webimage: nginxports:- name: webcontainerPort: 80

運行中的 kubelet 周期掃描配置的目錄下文件的變化，當這個目錄中有文件出現或消失時創建或刪除 pods。
在 Master 節點同樣也可以看到該 Pod，如果執行 kubectl delete pod static-web-node01 命令刪除該 Pod 發現，并不能刪除。

1.6Pod容器的分類：

1、基礎容器（infrastructure container）

維護整個 Pod 網絡和存儲空間
node 節點中操作
啟動一個Pod時，k8s會自動啟動一個基礎容器

cat /opt/kubernetes/cfg/kubelet
......
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"

每次創建 Pod 時候就會創建，運行的每一個Pod都有一個 pause-amd64 的基礎容器自動會運行，對于用戶是透明的

docker ps -a
registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0   "/pause"

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、應用容器（Maincontainer）

并行啟動

官網示例：

https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

piVersion: v1
kind: Pod
metadata:name: myapp-podlabels:app: myapp
spec:containers:- name: myapp-containerimage: busybox:1.28command: ['sh', '-c', 'echo The app is running! && sleep 3600']initContainers:- name: init-myserviceimage: busybox:1.28command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']- name: init-mydbimage: busybox:1.28command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

這個例子是定義了一個具有 2 個 Init 容器的簡單 Pod。第一個等待 myservice 啟動，第二個等待 mydb 啟動。一旦這兩個 Init容器都啟動完成，Pod 將啟動 spec 中的應用容器。

ubectl describe pod myapp-podkubectl logs myapp-pod -c init-myservicevim myservice.yaml
apiVersion: v1
kind: Service
metadata:name: myservice
spec:ports:- protocol: TCPport: 80targetPort: 9376kubectl create -f myservice.yamlkubectl get svckubectl get pods -n kube-systemkubectl get podsvim mydb.yaml
apiVersion: v1
kind: Service
metadata:name: mydb
spec:ports:- protocol: TCPport: 80targetPort: 9377kubectl create -f mydb.yamlkubectl 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.7鏡像拉取策略（imagePullPolicy）

Pod 的核心是運行容器，必須指定容器引擎，比如 Docker，啟動容器時，需要拉取鏡像，k8s 的鏡像拉取策略可以由用戶指定：
- 1、IfNotPresent：在鏡像已經存在的情況下，kubelet 將不再去拉取鏡像，僅當本地缺失時才從倉庫中拉取，默認的鏡像拉取策略
- 2、Always：每次創建 Pod 都會重新拉取一次鏡像；
- 3、Never：Pod 不會主動拉取這個鏡像，僅使用本地鏡像。
  注意：對于標簽為“:latest”的鏡像文件，其默認的鏡像獲取策略即為“Always”；而對于其他標簽的鏡像，其默認策略則為“IfNotPresent”。

官方示例：

https://kubernetes.io/docs/concepts/containers/images

bectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:name: private-image-test-1
spec:containers:- name: uses-private-imageimage: $PRIVATE_IMAGE_NAMEimagePullPolicy: Alwayscommand: [ "echo", "SUCCESS" ]
EOF//master01 上操作
kubectl edit deployment/nginx-deployment
......template:metadata:creationTimestamp: nulllabels:app: nginxspec:containers:- image: nginx:1.15.4imagePullPolicy: IfNotPresent							#鏡像拉取策略為 IfNotPresentname: nginxports:- containerPort: 80protocol: TCPresources: {}terminationMessagePath: /dev/termination-logterminationMessagePolicy: FilednsPolicy: ClusterFirstrestartPolicy: Always										#Pod的重啟策略為 Always，默認值schedulerName: default-schedulersecurityContext: {}terminationGracePeriodSeconds: 30
......

//創建測試案例

mkdir /opt/demo
cd /opt/demovim pod1.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-test1
spec:containers:- name: nginximage: nginximagePullPolicy: Alwayscommand: [ "echo", "SUCCESS" ]kubectl create -f pod1.yamlkubectl get pods -o wide
pod-test1                         0/1     CrashLoopBackOff   4          3m33s

//此時 Pod 的狀態異常，原因是 echo 執行完進程終止，容器生命周期也就結束了

kubectl describe pod pod-test1
......
Events:Type     Reason     Age                 From                    Message----     ------     ----                ----                    -------Normal   Scheduled  2m10s               default-scheduler       Successfully assigned default/pod-test1 to 192.168.80.11Normal   Pulled     46s (x4 over 119s)  kubelet, 192.168.80.11  Successfully pulled image "nginx"Normal   Created    46s (x4 over 119s)  kubelet, 192.168.80.11  Created containerNormal   Started    46s (x4 over 119s)  kubelet, 192.168.80.11  Started containerWarning  BackOff    19s (x7 over 107s)  kubelet, 192.168.80.11  Back-off restarting failed containerNormal   Pulling    5s (x5 over 2m8s)   kubelet, 192.168.80.11  pulling image "nginx"
//可以發現 Pod 中的容器在生命周期結束后，由于 Pod 的重啟策略為 Always，容器再次重啟了，并且又重新開始拉取鏡像//修改 pod1.yaml 文件
cd /opt/demo
vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-test1
spec:containers:- name: nginximage: nginx:1.14							#修改 nginx 鏡像版本imagePullPolicy: Always#command: [ "echo", "SUCCESS" ]			#刪除//刪除原有的資源
kubectl delete -f pod1.yaml //更新資源
kubectl apply -f pod1.yaml //查看 Pod 狀態
kubectl get pods -o wide
NAME                              READY   STATUS    RESTARTS   AGE   IP            NODE            NOMINATED NODE
pod-test1                         1/1     Running   0          33s   172.17.36.4   192.168.80.11   <none>//在任意 node 節點上使用 curl 查看頭部信息
curl -I http://172.17.36.4
HTTP/1.1 200 OK
Server: nginx/1.14.2
......

1.8部署 harbor 創建私有項目

//在 Docker harbor 節點（192.168.80.30）上操作

systemctl stop firewalld.service
systemctl disable firewalld.service
setenforce 0yum 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
//上傳 docker-compose 和 harbor-offline-installer-v1.2.2.tgz 到 /opt 目錄中
cd /opt
chmod +x docker-compose
mv docker-compose /usr/local/bin///部署 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.30cd /usr/local/harbor/
./install.sh

在 Harbor 中創建一個新項目

（1）瀏覽器訪問：http://192.168.80.10 登錄 Harbor WEB UI 界面，默認的管理員用戶名和密碼是 admin/Harbor12345
（2）輸入用戶名和密碼登錄界面后可以創建一個新項目。點擊“+項目”按鈕
（3）填寫項目名稱為“kgc-project”，點擊“確定”按鈕，創建新項目

//在每個 node 節點配置連接私有倉庫（注意每行后面的逗號要添加）

cat > /etc/docker/daemon.json <<EOF
{"registry-mirrors": ["https://6ijb8ubo.mirror.aliyuncs.com"],"insecure-registries":["192.168.80.30"]
}
EOFsystemctl daemon-reload
systemctl restart docker//在每個 node 節點登錄 harbor 私有倉庫
docker login -u admin -p harbor12345 http://192.168.80.30//在一個 node 節點下載 Tomcat 鏡像進行推送
docker pull tomcat:8.0.52
docker imagesdocker tag tomcat:8.0.52 192.168.80.30/kgc-project/tomcat:v1
docker imagesdocker push 192.168.80.30/kgc-project/tomcat:v1//查看登陸憑據
cat /root/.docker/config.json | base64 -w 0			#base64 -w 0：進行 base64 加密并禁止自動換行
ewoJImF1dGhzIjogewoJCSIxOTIuMTY4LjE5NS44MCI6IHsKCQkJImF1dGgiOiAiWVdSdGFXNDZTR0Z5WW05eU1USXpORFU9IgoJCX0KCX0sCgkiSHR0cEhlYWRlcnMiOiB7CgkJIlVzZXItQWdlbnQiOiAiRG9ja2VyLUNsaWVudC8xOS4wMy41IChsaW51eCkiCgl9Cn0=