碼上歡樂
相關內容    簡體    繁體

k8s的pod資源管理與配置使用憑證的harbor倉庫

本文轉載自   查看原文   2021-11-04 20:58   95    k8s

k8s 里的pod 資源

目錄

一： Pod 的基礎概念

1.1 pod 是什么

Pod是kubernetes中最小的資源管理組件，Pod也是最小化運行容器化應用的資源對象。

一個Pod代表着集群中運行的一個進程。

kubernetes中其他大多數組件都是圍繞着Pod來進行支撐和擴展Pod功能的，例如，用於管理Pod運行的StatefulSet和Deployment等控制器對象，用於暴露Pod應用的Service和Ingress對象，為Pod提供存儲的PersistentVolume存儲資源對象等。



1.2 pod 的兩種使用（運行方式）

  • 一個Pod中運行一個容器。

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

  • 在一個Pod中同時運行多個容器。

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

1.3 工作方式


一個Pod下的容器必須運行於同一節點上。現代容器技術建議一個容器只運行一個進程，該進程在容器中PID命令空間中的進程號為1，可直接接收並處理信號，進程終止時容器生命周期也就結束了。

若想在容器內運行多個進程，需要有一個類似Linux操作系統init進程的管控類進程，以樹狀結構完成多進程的生命周期管理。

運行於各自容器內的進程無法直接完成網絡通信，這是由於容器間的隔離機制導致，k8s中的Pod資源抽象正是解決此類問題，Pod對象是一組容器的集合，這些容器共享Network、UTS及IPC命令空間，因此具有相同的域名、主機名和網絡接口，並可通過IPC直接通信。



1.4 pause 容器的功能

1.4.1 提供pid命名空間，作為pid等於1的init進程

Pod資源中針對各容器提供網絡命令空間等共享機制的是底層基礎容器pause，基礎容器（也可稱為父容器）pause就是為了管理Pod容器間的共享操作，這個父容器需要能夠准確地知道如何去創建共享運行環境的容器，還能管理這些容器的生命周期。為了實現這個父容器的構想，kubernetes中，用pause容器來作為一個Pod中所有容器的父容器。

pause容器有兩個核心的功能，一是它提供整個Pod的Linux命名空間的基礎。二來啟用PID命名空間，它在每個Pod中都作為PID為1進程（init進程），並回收僵屍進程。

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

  • 網絡

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

  • 存儲：

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

img



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

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


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

img



1.6 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容器分類

2.1 基礎容器（infrastructure container）

維護整個 Pod 網絡和存儲空間

啟動一個容器時，k8s會自動啟動一個基礎容器

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

 
#在mster上創建pod
[root@master ~]# kubectl create deployment nginx-demo1 --image=nginx:1.14

#查看pod 被調度在哪個node節點上
[root@master ~]# kubectl get pod nginx-demo1-7bf84576d8-nhv9n  -o wide 

#在node01節點上，查看容器，發現自動創建了pause容器
[root@node01 ~]# docker ps  | grep nginx-demo1

image-20211104150826740

image-20211104150940236



2.2 初始化容器（init 容器）initcontainers

Init容器必須在應用程序容器啟動之前運行完成，而應用程序容器是並行運行的，所以Init容器能夠提供了一種簡單的阻塞或延遲應用容器的啟動的方法。

2.2.1 init 容器與普通容器的區別

Init 容器與普通的容器非常像，除了以下兩點：

  • Init 容器總是運行到成功完成為止
  • 每個 Init 容器都必須在下一個 Init 容器啟動之前成功完成啟動和退出
    如果 Pod 的 Init 容器失敗，k8s 會不斷地重啟該 Pod，直到 Init 容器成功為止。然而，如果 Pod 對應的重啟策略（restartPolicy）為 Never，它不會重新啟動。

2.2.2 Init 容器的作用

因為init容器具有與應用容器分離的單獨鏡像，其啟動相關代碼具有如下優勢：

  • Init 容器可以包含一些安裝過程中應用容器中不存在的實用工具或個性化代碼。例如，沒有必要僅為了在安裝過程中使用類似 sed、 awk、 python 或 dig 這樣的工具而去FROM 一個鏡像來生成一個新的鏡像。
  • Init 容器可以安全地運行這些工具，避免這些工具導致應用鏡像的安全性降低。
  • 應用鏡像的創建者和部署者可以各自獨立工作，而沒有必要聯合構建一個單獨的應用鏡像。
  • Init 容器能以不同於Pod內應用容器的文件系統視圖運行。因此，Init容器可具有訪問 Secrets 的權限，而應用容器不能夠訪問。
  • 由於 Init 容器必須在應用容器啟動之前運行完成，因此 Init 容器提供了一種機制來阻塞或延遲應用容器的啟動，直到滿足了一組先決條件。一旦前置條件滿足，Pod內的所有的應用容器會並行啟動。



2.3 應用容器(業務容器你) （Maincontainer）

平時最常使用的容器

並行啟動



2.4 示例

官網示例：https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

2.4.1 聲明式啟動應用容器

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

[root@master ~]# 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 create -f demo1.yaml

2.4.2 查看信息

kubectl get  all

image-20211104154321812


#查看容器的詳細信息
kubectl describe pod myapp-pod

image-20211104154550818


#查看日志
kubectl logs myapp-pod -c init-myservice

image-20211104154716366


2.4.3 創建啟動myservice，查看日志 

[root@master ~]#vim myservice.yaml
apiVersion: v1
kind: Service
metadata:
#注意，name定義的名字需要是myservice
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

kubectl create -f myservice.yaml

[root@master ~]# kubectl  get svc
1NAME               TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
myservice          ClusterIP   10.1.49.69     <none>        80/TCP           4s


[root@master ~]# kubectl get pods
NAME                           READY   STATUS     RESTARTS   AGE
myapp-pod                      0/1     Init:1/2   0          15m

image-20211104155711278


2.4.4查看容器mydb日志

#查看容器init-mydb日志
kubectl logs myapp-pod -c init-mydb

image-20211104155930617


2.4.5 創建啟動容器mydb，查看應用容器的狀態

[root@master ~]# vim mydb.yaml
apiVersion: v1
kind: Service
metadata:
#name字段，值需要是mydb
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

[root@master ~]#kubectl create -f mydb.yaml


[root@master ~]# kubectl get pods 
NAME                           READY   STATUS    RESTARTS   AGE
myapp-pod                      1/1     Running   0          23m

image-20211104160623288



2.5 特別說明

  • 在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）

3.1 鏡像拉取策略

Pod 的核心是運行容器，必須指定容器引擎，比如 Docker，啟動容器時，需要拉取鏡像，k8s 的鏡像拉取策略可以由用戶指定：

  1. IfNotPresent：在鏡像已經存在的情況下，kubelet 將不再去拉取鏡像，僅當本地缺失時才從倉庫中拉取，默認的鏡像拉取策略
  2. Always：每次創建 Pod 都會重新拉取一次鏡像；
  3. Never：Pod 不會主動拉取這個鏡像，僅使用本地鏡像

注意：對於標簽為“:latest”的鏡像文件，或者無標簽的鏡像文件，其默認的鏡像獲取策略即為“Always”；而對於其他標簽的鏡像，其默認策略則為“IfNotPresent”。



3.2 示例

官方示例：
https://kubernetes.io/docs/concepts/containers/images

3.2.1 創建測試案例

[root@master ~]# vim pod1.yaml
#當kind： 的值為Pod，則表示創建自主式pod
apiVersion: v1
kind: Pod
metadata:
  name: pod-test1
spec:
  containers:
    - name: nginx
      image: nginx
      imagePullPolicy: Always
      #command字段可以定義容器啟動后的第一個命令
      command: [ "echo", "SUCCESS" ]

kubectl create -f pod1.yaml

kubectl get pods -o wide
pod-test1                         0/1     CrashLoopBackOff   2          2m17s

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

image-20211104163007646

image-20211104163646839


3.2.2 更新資源

#修改pod1.yaml文件
[root@master ~]#vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-test1
spec:
  containers:
    - name: nginx
    #修改 nginx 鏡像版本,指定標簽
      image: nginx:1.14				
      #注釋鏡像拉取策略
      #imagePullPolicy: Always
      #command: [ "echo", "SUCCESS" ]			#刪除

#刪除原有的資源
kubectl delete -f pod1.yaml 

#更新資源
kubectl apply -f pod1.yaml

[root@master ~]# kubectl get pods -o wide
NAME                           READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
myapp-pod                      1/1     Running   0          61m   10.244.2.47   node02   <none>           <none>
nginx-demo1-7bf84576d8-nhv9n   1/1     Running   0          96m   10.244.1.61   node01   <none>           <none>
pod-test1                      1/1     Running   0          35s   10.244.1.65   node01   <none>           <none>


#使用edit 在線修改，查看資源配置
[root@master ~]# kubectl edit pod pod-test1

image-20211104164454826



四 Pod的重啟策略

4.1 pod 的重啟策略

重啟策略(restartPolicy) : Pod在遇到故障之后重啟的動作

  • Always:當容器終止退出后,總是重啟容器,默認策略
  • OnFailure:當容器異常退出(退出狀態碼非0)時,重啟容器;正常退出則不重啟容器
  • Never:當容器終止退出,從不重啟容器。

注意: K8s中不支持重啟Pod資源,只有刪除重建

4.2 示例

4.2.1 創建啟動一個pod，查看狀態

[root@master ~]# vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 20; exit 3


#創建pod
kubectl apply -f pod3.yaml

#查看pod狀態
kubectl get pods

image-20211104170912743


4.2.2 修改yaml 文件，設置重啟策略為Never

[root@master ~]# vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 20; exit 3
  #設置重啟策略為從不
  restartPolicy: Never                            

[root@master ~]# kubectl delete -f pod3.yaml

[root@master ~]# kubectl apply  -f pod3.yaml


#在74s后，即使過了 20s 也沒有新的狀態出現.因為重啟策略是Never，所以，不會重啟
[root@master ~]# kubectl get pods foo -w
NAME   READY   STATUS              RESTARTS   AGE
foo    0/1     ContainerCreating   0          40s
foo    1/1     Running             0          54s
foo    0/1     Error               0          74s


#新開一個終端查看狀態
[root@master ~]# kubectl get pods foo 
NAME   READY   STATUS   RESTARTS   AGE
foo    0/1     Error    0          103s

image-20211104171752239



總結

  1. pod 的運行方式有兩種：
  • 自主式pod：沒有自愈能力
  • 控制器管理pod： 有自愈能力（Pod被刪除后會重新拉起新pod）

  1. pod 中有 3 種容器：

  • 基礎容器（pause）：

    • 初始化容器環境，開啟pid=1的init進程來管理其他容器的生命周期
    • 提供網絡和存儲空間的共享環境基礎

  • init 容器

    • 是在基礎容器之后，應用容器之前運行的容器
    • 多個容器是串行運行
    • init 容器必須在上一init容器運行成功且退出后才會運行

  • 應用容器（main c）

    • 運行業務的容器
    • 在init容器都成功運行和退出后運行的
    • 多個應用容器是並行運行的

  1. 在 一個pod 中，init 容器和應用容器的名稱都是唯一的


  2. pod 的鏡像拉取策略 imagePullPolicy，配置在Containers字段的下面，是它的子字段

  • IfNotPresent

    • 是帶有指定標簽的鏡像的默認拉取測試。
    • 本地有，則用本地鏡像。本地沒有則從倉庫中拉取鏡像

  • Always

    • 是沒有標簽的鏡像或者使用哦latest標簽的鏡像拉取策略
    • 創建pod總是從倉庫拉取鏡像

  • Never

    • 不從倉庫拉取鏡像，僅使用本地鏡像

  1. pod 重啟策略 restartPolicy ，配置在containers字段同一層，和containers同屬 spec的子字段

  • Always

    • 默認的重啟策略。
    • 容器退出時總是重啟容器

  • Never

    • 容器退出，從不重啟容器

  • OnFailure

    • 只有容器異常退出（非0狀態碼退出）,才會重啟容器



五： 部署harbor 創建私有項目，使用憑證登錄

5.1 在docker harbor 上（192.168.23.10）上環境准備

systemctl stop firewalld.service
systemctl disable firewalld.service
setenforce 0

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

5.2 部署harbor

#上傳 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 +5 /usr/local/harbor/harbor.cfg
--5行--修改，設置為Harbor服務器的IP地址或者域名
hostname = 192.168.23.10

cd /usr/local/harbor/
./install.sh



5.3 登錄harbor，創建項目

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

image-20211104185718895



5.4 每個node節點登錄harbor ，上傳鏡像

#在每個 node 節點配置連接私有倉庫（注意每行后面的逗號要添加）
cat > /etc/docker/daemon.json <<EOF
{
  "registry-mirrors": ["https://6ijb8ubo.mirror.aliyuncs.com"],
  "insecure-registries":["192.168.23.10"]
}
EOF

systemctl daemon-reload
systemctl restart docker



#在每個 node 節點登錄 harbor 私有倉庫
docker login -u admin -p harbor12345 http://192.168.23.10

#在一個 node 節點下載 Tomcat 鏡像進行推送
docker pull tomcat:8.0.52
docker images

docker tag tomcat:8.0.52 192.168.23.10/kgc-project/tomcat:v1
docker images

docker push 192.168.23.10/kgc-project/tomcat:v1

image-20211104190114828

image-20211104185737362

5.5 配置憑據

#查看登陸憑據
#base64 -w 0：進行 base64 加密並禁止自動換行
cat /root/.docker/config.json | base64 -w 0			
ewoJImF1dGhzIjogewoJCSIxOTIuMTY4LjIzLjEwIjogewoJCQkiYXV0aCI6ICJZV1J0YVc0NlNHRnlZbTl5TVRJek5EVT0iCgkJfSwKCQkiaHViLmNvbSI6IHsKCQkJImF1dGgiOiAiWVdSdGFXNDZTR0Z5WW05eU1USXpORFU9IgoJCX0KCX0KfQ==

image-20211104190259266

image-20211104190502016


#master 節點上 創建 harbor 登錄憑據資源清單
vim harbor-pull-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: harbor-pull-secret
data:
  .dockerconfigjson: ewoJImF1dGhzIjogewoJCSIxOTIuMTY4LjIzLjEwIjogewoJCQkiYXV0aCI6ICJZV1J0YVc0NlNHRnlZbTl5TVRJek5EVT0iCgkJfSwKCQkiaHViLmNvbSI6IHsKCQkJImF1dGgiOiAiWVdSdGFXNDZTR0Z5WW05eU1USXpORFU9IgoJCX0KCX0KfQ==		#復制粘貼上述查看的登陸憑據
type: kubernetes.io/dockerconfigjson


#創建 secret 資源
kubectl create -f harbor-pull-secret.yaml

#查看 secret 資源
kubectl get secret



#創建資源從 harbor 中下載鏡像
cd /opt/demo
vim tomcat-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-tomcat
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: my-tomcat
    spec:
      imagePullSecrets:						#添加拉取 secret 資源選項
      - name: harbor-pull-secret			#指定 secret 資源名稱
      containers:
      - name: my-tomcat
        image: 192.168.80.30/kgc-project/tomcat:v1		#指定 harbor 中的鏡像名
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-tomcat
spec:
  type: NodePort
  ports:
  - port: 8080
    targetPort: 8080
    nodePort: 31111
  selector:
    app: my-tomcat


#node節點刪除之前在 node 節點下載的 Tomcat 鏡像
docker rmi tomcat:8.0.52
docker rmi 192.168.23.10/kgc-project/tomcat:v1
docker images


#master 節點創建資源
kubectl create -f tomcat-deployment.yaml

kubectl get pods


#查看 Pod 的描述信息，可以發現鏡像時從 harbor 下載的
kubectl describe pod my-tomcat-5487585446-d8j2h


#刷新 harbor 頁面，可以看到鏡像的下載次數增加了

image-20211104190725720

image-20211104191019714

image-20211104191101175

image-20211104191242847


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 kubernetes(k8s)資源管理/清單配置基礎 k8s管理pod資源對象（上） K8S資源管理總結及dashboard創建 k8s資源管理(基礎操作) 從零開始入門 K8s | Kubernetes 調度和資源管理 k8s中的資源管理和調度 Kubernetes(2) k8s資源，以及使用配置文件部署 Pod資源 K8S(三)——部署docker環境，配置Harbor倉庫 k8s中pod的資源配置詳解 Kubernetes（k8s）常用資源的使用、Pod的常用操作
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM