k8s的pod资源管理与配置使用凭证的harbor仓库
文章目錄
- 一: Pod 的基礎概念
- 1.1 pod 是什么
- 1.2 pod 的兩種使用(運行方式)
- 1.3 工作方式
- 1.4 pause 容器的功能
- 1.4.1 提供pid命名空間,作為pid等于1的init進程
- 1.4.2 pause容器使得Pod中的所有容器可以共享 網絡和存儲資源。
- 1.5 Kubernetes設計這樣的Pod概念和特殊組成結構有什么用意
- 1.6 pod 的分類
- 二: Pod容器分類
- 2.1 基礎容器(infrastructure container)
- 2.2 初始化容器(init 容器)initcontainers
- 2.2.1 init 容器與普通容器的區別
- 2.2.2 Init 容器的作用
- 2.3 應用容器(業務容器你) (Maincontainer)
- 2.4 示例
- 2.4.1 聲明式啟動應用容器
- 2.4.2 查看信息
- 2.4.3 創建啟動myservice,查看日志
- 2.4.4查看容器mydb日志
- 2.4.5 創建啟動容器mydb,查看應用容器的狀態
- 2.5 特別說明
- 三:鏡像拉取策略(image PullPolicy)
- 3.1 鏡像拉取策略
- 3.2 示例
- 3.2.1 創建測試案例
- 3.2.2 更新資源
- 四 Pod的重啟策略
- 4.1 pod 的重啟策略
- 4.2 示例
- 4.2.1 創建啟動一個pod,查看狀態
- 4.2.2 修改yaml 文件,設置重啟策略為Never
- 總結
- 五: 部署harbor 創建私有項目,使用憑證登錄
- 5.1 在docker harbor 上(192.168.23.10)上環境準備
- 5.2 部署harbor
- 5.3 登錄harbor,創建項目
- 5.4 每個node節點登錄harbor ,上傳鏡像
- 5.5 配置憑據
一: 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中的存儲資源,以防容器重啟后文件丟失
1.5 Kubernetes設計這樣的Pod概念和特殊組成結構有什么用意
原因一:在一組容器作為一個單元的情況下,難以對整體的容器簡單地進行判斷及有效地進行行動。比如,一個容器死亡了,此時是算整體掛了么?那么引入與業務無關的Pause容器作為Pod的基礎容器,以它的狀態代表著整個容器組的狀態,這樣就可以解決該問題。
原因二:Pod里的多個應用容器共享Pause容器的IP,共享Pause容器掛載的Volume,這樣簡化了應用容器之間的通信問題,也解決了容器之間的文件共享問題。
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-demo12.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.yamlapiVersion: 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;'] #聲明式啟動 kubectl create -f demo1.yaml2.4.2 查看信息
kubectl get all #查看容器的詳細信息 kubectl describe pod myapp-pod #查看日志 kubectl logs myapp-pod -c init-myservice2.4.3 創建啟動myservice,查看日志
[root@master ~]#vim myservice.yaml apiVersion: v1 kind: Service metadata: #注意,name定義的名字需要是myservicename: myservice spec:ports:- protocol: TCPport: 80targetPort: 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 15m2.4.4查看容器mydb日志
#查看容器init-mydb日志 kubectl logs myapp-pod -c init-mydb2.4.5 創建啟動容器mydb,查看應用容器的狀態
[root@master ~]# vim mydb.yaml apiVersion: v1 kind: Service metadata: #name字段,值需要是mydbname: mydb spec:ports:- protocol: TCPport: 80targetPort: 9377 [root@master ~]#kubectl create -f mydb.yaml [root@master ~]# kubectl get pods NAME READY STATUS RESTARTS AGE myapp-pod 1/1 Running 0 23m2.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 的鏡像拉取策略可以由用戶指定:
注意:對于標簽為“: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: nginximage: nginximagePullPolicy: Always#command字段可以定義容器啟動后的第一個命令command: [ "echo", "SUCCESS" ] kubectl create -f pod1.yamlkubectl get pods -o wide pod-test1 0/1 CrashLoopBackOff 2 2m17s#此時 Pod 的狀態異常,原因是 echo 執行完進程終止,容器生命周期也就結束了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四 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: busyboximage: busyboxargs:- /bin/sh- -c- sleep 20; exit 3 #創建pod kubectl apply -f pod3.yaml#查看pod狀態 kubectl get pods4.2.2 修改yaml 文件,設置重啟策略為Never
[root@master ~]# vim pod3.yaml apiVersion: v1 kind: Pod metadata:name: foo spec:containers:- name: busyboximage: busyboxargs:- /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總結
- 自主式pod:沒有自愈能力
- 控制器管理pod: 有自愈能力(Pod被刪除后會重新拉起新pod)
- 基礎容器(pause):
-
- 初始化容器環境,開啟pid=1的init進程來管理其他容器的生命周期
- 提供網絡和存儲空間的共享環境基礎
- init 容器
-
- 是在基礎容器之后,應用容器之前運行的容器
- 多個容器是串行運行
- init 容器必須在上一init容器運行成功且退出后才會運行
- 應用容器(main c)
-
- 運行業務的容器
- 在init容器都成功運行和退出后運行的
- 多個應用容器是并行運行的
- IfNotPresent
-
- 是帶有指定標簽的鏡像的默認拉取測試。
- 本地有,則用本地鏡像。本地沒有則從倉庫中拉取鏡像
- Always
-
- 是沒有標簽的鏡像或者使用哦latest標簽的鏡像拉取策略
- 創建pod總是從倉庫拉取鏡像
- Never
-
- 不從倉庫拉取鏡像,僅使用本地鏡像
- Always
-
- 默認的重啟策略。
- 容器退出時總是重啟容器
- Never
-
- 容器退出,從不重啟容器
- OnFailure
-
- 只有容器異常退出(非0狀態碼退出),才會重啟容器
五: 部署harbor 創建私有項目,使用憑證登錄
5.1 在docker harbor 上(192.168.23.10)上環境準備
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 version5.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.10cd /usr/local/harbor/ ./install.sh5.3 登錄harbor,創建項目
/#在 Harbor 中創建一個新項目 (1)瀏覽器訪問:http://192.168.23.10 登錄 Harbor WEB UI 界面,默認的管理員用戶名和密碼是 admin/Harbor12345 (2)輸入用戶名和密碼登錄界面后可以創建一個新項目。點擊“+項目”按鈕 (3)填寫項目名稱為“kgc-project”,點擊“確定”按鈕,創建新項目5.4 每個node節點登錄harbor ,上傳鏡像
#在每個 node 節點配置連接私有倉庫(注意每行后面的逗號要添加) cat > /etc/docker/daemon.json <<EOF {"registry-mirrors": ["https://6ijb8ubo.mirror.aliyuncs.com"],"insecure-registries":["192.168.23.10"] } EOFsystemctl 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 imagesdocker tag tomcat:8.0.52 192.168.23.10/kgc-project/tomcat:v1 docker imagesdocker push 192.168.23.10/kgc-project/tomcat:v15.5 配置憑據
#查看登陸憑據 #base64 -w 0:進行 base64 加密并禁止自動換行 cat /root/.docker/config.json | base64 -w 0 ewoJImF1dGhzIjogewoJCSIxOTIuMTY4LjIzLjEwIjogewoJCQkiYXV0aCI6ICJZV1J0YVc0NlNHRnlZbTl5TVRJek5EVT0iCgkJfSwKCQkiaHViLmNvbSI6IHsKCQkJImF1dGgiOiAiWVdSdGFXNDZTR0Z5WW05eU1USXpORFU9IgoJCX0KCX0KfQ== #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: 2template:metadata:labels:app: my-tomcatspec:imagePullSecrets: #添加拉取 secret 資源選項- name: harbor-pull-secret #指定 secret 資源名稱containers:- name: my-tomcatimage: 192.168.80.30/kgc-project/tomcat:v1 #指定 harbor 中的鏡像名ports:- containerPort: 80 --- apiVersion: v1 kind: Service metadata:name: my-tomcat spec:type: NodePortports:- port: 8080targetPort: 8080nodePort: 31111selector: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.yamlkubectl get pods#查看 Pod 的描述信息,可以發現鏡像時從 harbor 下載的 kubectl describe pod my-tomcat-5487585446-d8j2h#刷新 harbor 頁面,可以看到鏡像的下載次數增加了總結
以上是生活随笔為你收集整理的k8s的pod资源管理与配置使用凭证的harbor仓库的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: kubernetes(k8s)使用声明式
- 下一篇: 虚拟化概念和KVM简述