确定网站建设目标,西安网站制作费用,石家庄桥西区网站建设,沈阳关键词优化电话文章目录 概述卷卷的常用类型emptyDir边车容器 HostPathnfsPV/PVC静态供给 PV 和 PVC创建静态 PV创建 pvc创建 pod 应用 pvc 动态供给 PV 和 PVC创建 StorageClass创建 pvc创建 pod 使用 pvc PV 的生命周期 内置存储对象ConfigMapSecret 配置文件自动重新加载方案**1. 应用内动… 文章目录 概述卷卷的常用类型emptyDir边车容器 HostPathnfsPV/PVC静态供给 PV 和 PVC创建静态 PV创建 pvc创建 pod 应用 pvc 动态供给 PV 和 PVC创建 StorageClass创建 pvc创建 pod 使用 pvc PV 的生命周期 内置存储对象ConfigMapSecret 配置文件自动重新加载方案**1. 应用内动态检测文件变更****2. 通过信号触发重新加载****3. 使用 Reloader 或类似工具****4. 手动重启 Pod** 拉取镜像的脚本 概述
在虚拟机的环境中应用程序的数据通常存储在本地磁盘上即使重启虚拟机也不会数据丢失。但是在 pod 中。pod 的特点就是 “临时性” 随着 pod 的重建容器中的数据也会消失这将导致一些应用程序读不到之前的数据。因此 pod 引入了持久化这个概念也就是 “卷”
卷
卷是 pod 中存储数据和共享数据的一个抽象概念。它提供了一种将存储设备挂载进容器的机制。
卷的常用类型
卷的分类卷类型说明临时存储emptyDir用于 pod 中容器之间的共享本地存储hostPath将节点文件系统上的文件或者目录挂载到 pod 中对象存储ConfigMap,Secretk8s 内置的存储对象用于存储应用程序配置和敏感数据自建存储系统NFSCephISCSI将自建的存储系统挂载到 pod 中存储对象persistentVolumesClaim(PVC)与 PV 持久卷配合使用
emptyDir
empytDir 用于在 pod 中实现容器之间的数据共享与 pod 的生命周期一致当 pod 被删除时对应的目录也会销毁
[rootk8s-master ~]# cat emptyDir.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-emptydir
spec:containers:- image: docker.io/library/centos:latestimagePullPolicy: IfNotPresentname: appcommand: [/bin/sh,-c,for i in {1..10000};do echo $i /opt/file.txt;sleep 1;done]volumeMounts:- name: datamountPath: /opt- image: docker.io/library/centos:latestimagePullPolicy: IfNotPresentname: sidecar # 边车容器command: [/bin/sh,-c,tail -f /opt/file.txt]volumeMounts:- name: datamountPath: /optvolumes:- name: dataemptyDir: {}
[rootk8s-master ~]# kubectl apply -f emptyDir.yaml
pod/pod-emptydir created
[rootk8s-master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
pod-emptydir 2/2 Running 0 3s在上面的例子中我们定义了两个容器和一个 emptyDir 卷该卷被挂载到两个容器中的同一个目录下了因此该目录中的文件可以被彼此访问
[rootk8s-master ~]# kubectl exec -it pod-emptydir --container app -- /bin/bash
Defaulted container app out of: app, sidecar
[rootpod-emptydir /]# cd opt/
[rootpod-emptydir opt]# ls
file.txt[rootk8s-master ~]# kubectl exec -it pod-emptydir --container sidecar -- /bin/bash
[rootpod-emptydir /]# cd opt/
[rootpod-emptydir opt]# ls
file.txt边车容器
边车容器Sidecar Container是与主应用容器在同一个Pod中运行的辅助容器。它们通过提供额外的服务或功能如日志记录、监控、安全性或数据同步来增强或扩展主应用容器的功能而无需直接修改主应用代码。边车容器与主容器共享网络和存储命名空间使得它们能够紧密交互并共享资源。
除了边车容器Kubernetes还支持其他类型的容器包括 标准容器Application Containers这是最常见的容器类型用于运行主要的应用逻辑。 Init 容器这些容器在应用容器启动之前运行用于执行一些初始化任务比如设置配置文件或者等待外部服务就绪。Init 容器在Pod中的所有应用容器启动前完成执行并退出。 Ephemeral 容器这是一种临时性的容器它们缺少对资源或执行的保证并且永远不会自动重启。Ephemeral 容器主要用于调试目的允许用户加入一个临时容器到正在运行的Pod中用于调试。
HostPath
hostpath 卷用来将宿主机的目录挂载进容器这使得容器可以访问宿主机的数据由于挂载的是宿主机的目录因此在容器被销毁后数据并不会丢失。
但是在 k8s 卷的分类中我们还有一个专门做持久卷的名叫 PV/PVC 。那这两种挂载方式到底差距在哪呢:
HostPath:
直接挂载宿主机本地路径到容器适合单节点和开发环境。不支持跨节点存储数据与特定节点绑定。无自动扩展功能存储容量和管理完全依赖宿主机。没有 Kubernetes 对存储的生命周期管理容器删除后数据可能丢失。
PV/PVC:
Kubernetes 管理的持久化存储可以通过 PVC 请求动态存储资源。支持跨节点、云存储等多种后端具备高可用性和扩展性。具备自动扩展、容量管理和存储生命周期管理功能。支持不同存储策略如保留、删除等适用于生产环境。
那我们在 yaml 文件中如何挂载它呢
[rootk8s-master ~]# cat hostPath.yaml
apiVersion: v1
kind: Pod
metadata:name: hostpath-pod
spec:containers:- name: hostpath-containerimage: docker.io/library/nginx:latestimagePullPolicy: IfNotPresentvolumeMounts:- name: hostpath-volumemountPath: /usr/share/nginx/htmlvolumes:- name: hostpath-volumehostPath:path: /data # 这会挂载宿主机的 /data 目录到容器的 /usr/share/nginx/html 目录type: DirectoryOrCreate[rootk8s-master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
hostpath-pod 1/1 Running 0 4s在该 yaml 文件中我们将 /usr/share/nginx/html 挂载到容器里面的 data 目录下了
hostPath 所支持的卷的类型 (这些参数在 yaml 文件中有对应)
取值作用”“该字段为空或者未指定默认是 DirectoryOrCreateDirectoryOrCreate如果指定的目录不存在则会自动创建空目录并为其赋值 0755Directory指定的目录必须存在FileOrCreate和上面那个差不多在空文件被创建出来之后默认赋权 0644File指定文件必须存在Socket指定套接字文件必须存在CharDevice指定的字符设备必须存在BlockDevice指定的块设备必须存在
k8s 在 pod 启动时会检查路径是否与期望类型所匹配如果不匹配或者类型检查异常pod 会呈现 ContainerCreateing 状态
hostpath 卷不支持存储容器限制并且可使用的存储容量受主机文件系统限制
nfs
将 nfs 服务器挂载到 pod 中实现 pod 之间的数据共享。我们在之前还提到过一个 emptyDir 和 nfs 挂载的实现的功能是一致的那他们的区别在哪呢
NFS 和 emptyDir 的主要区别是
持久性 NFS数据持久化Pod 删除后数据保留。emptyDir数据临时存储Pod 删除时数据丢失。 共享范围 NFS可以跨多个节点和 Pod 共享数据。emptyDir仅限单个 Pod 内的容器共享数据。 适用场景 NFS需要跨 Pod 和节点共享数据的场景。emptyDir适合 Pod 内部容器间共享临时数据。
pv对接nfs共享使用静态创建的方式创建pvc
[rootk8s-master ~]# cat nginx.json
{apiVersion: apps/v1,kind: Deployment,metadata: {name: nginx},spec: {selector: {matchLabels: {app: nginx}},template: {metadata: {labels: {app: nginx}},spec: {containers: [{image: docker.io/library/nginx:latest,imagePullPolicy: IfNotPresent,name: nginx,volumeMounts: [{name: data,mountPath: /data}]}],volumes: [{name: data,nfs: {server: 192.168.142.139,path: /data/nfs}}]}}}
}mkdir -p /data/nfs
chmod 777 /data/nfs/
vim /etc/exports
/data/nfs *(no_root_squash,rw,no_all_squash)
systemctl restart nfs-server.service
showmount -e 192.168.142.139[rootk8s-slave1 ~]# df -h | grep 192.168.142.139:/data/nfs
df: /var/lib/kubelet/pods/6210f716-6da2-4a14-b320-33b169b684bc/volumes/kubernetes.io~nfs/mypv1: Stale file handle
192.168.142.139:/data/nfs 17G 6.3G 11G 38% /var/lib/kubelet/pods/fc2ccf93-693b-44b8-93f7-6d60f2f1b412/volumes/kubernetes.io~nfs/dataPV/PVC
在之前我们已经简单的介绍了一下 PV/PVC 与 hostPath 之间的对比也是知道了 PV/PVC 存在的意义那么什么是 PV 什么是 PVC
持久卷PV就是 Kubernetes 用来管理集群中存储的工具它让你不用关心底层存储的具体实现只要把它用作存储就行。简单来说就是让你的数据在 Pod 重启或销毁后还能保留下来。
持久卷声明PVC是用户申请存储的方式简单来说就是你向 Kubernetes 请求一个存储空间。PVC 就像是一个 “存储请求单”你告诉 Kubernetes 需要多大的存储空间Kubernetes 会找一个合适的持久卷PV来满足这个请求。
你可以把 PV 和 PVC 想象成 房子 和 租房合同 的关系 PV持久卷 就是一个已经建好的 房子它有一定的空间和资源可能是物理硬盘、NFS 共享或云存储等。 PVC持久卷声明 就是你去 租房向 Kubernetes 提出需要多大面积的房子Kubernetes 会找一个合适的 房子PV 给你。
所以PVC 是你用来申请 PV 的工具PVC 就像是租房合同PV 是你租到的房子。
在 PV/PVC 的世界里还有两个非常重要的概念PV 静态供给PV 动态供给 静态供给管理员手动创建好 PV持久卷然后用户通过 PVC持久卷声明 来请求匹配的 PV。这种方式下管理员负责管理存储资源。 动态供给当用户创建 PVC 时Kubernetes 会根据 StorageClass 自动创建一个符合要求的 PV。这种方式下管理员不需要事先创建 PVKubernetes 会自动提供存储。
下面是两个示例
静态供给 PV 和 PVC
创建静态 PV
[rootk8s-master ~]# cat pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:name: static-pv
spec:capacity:storage: 10GiaccessModes:- ReadWriteOnce # 只能被一个节点挂载persistentVolumeReclaimPolicy: Retain # PV 删除后数据保留storageClassName: standardhostPath:path: /data/static-pv # 宿主机路径persistentVolumeReclaimPolicy 参数有三个值可以选 Retain保留数据。PV 被释放后存储资源不会被回收管理员需要手动处理该 PV。数据保留在原位置可以进行手动清理或重新绑定到新的 PVC。 Recycle已弃用不再推荐使用回收数据。在这种模式下PV 被释放后Kubernetes 会尝试清除存储中的数据通常是执行 rm -rf /some-directory/* 操作然后将 PV 设置为可以重新绑定的状态。这种方式已被 Kubernetes 弃用。 Delete删除数据。PV 被释放后Kubernetes 会自动删除与 PV 相关联的存储资源如删除一个云存储卷。数据将被永久删除。
创建 pvc
[rootk8s-master ~]# cat pvc.yaml
# pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: static-pvc
spec:accessModes:- ReadWriteOnceresources:requests:storage: 10Gi # 请求10GB的存储storageClassName: standard创建 pod 应用 pvc
pull-image.sh 是我自己编写的脚本专门用来拉取镜像的如果小伙伴们也是 container 无法拉取镜像不妨可以试一试我这个脚本,脚本放到最后
[rootk8s-master ~]# ./pull-image.sh nginx:latest 192.168.142.139 192.168.142.140 192.168.142.141
镜像 nginx:latest 已存在于本地
Docker save nginx:latest
Docker save nginx:latest is successful
Sending nginx-latest.tar to 192.168.142.139
root192.168.142.139s password:
nginx-latest.tar 100% 187MB 947.0MB/s 00:00
Successfully sent nginx-latest.tar to 192.168.142.139
root192.168.142.139s password:
镜像 nginx:latest 已存在于 192.168.142.139
Sending nginx-latest.tar to 192.168.142.140
root192.168.142.140s password:
nginx-latest.tar 100% 187MB 355.8MB/s 00:00
Successfully sent nginx-latest.tar to 192.168.142.140
root192.168.142.140s password:
导入镜像到 192.168.142.140
root192.168.142.140s password:
unpacking docker.io/library/nginx:latest (sha256:466e72df2f0b10ecb0dc90dc99d523a1c6432b764ebcbcdab3f0a7ef5cd4e061)...done
ctr import nginx-latest.tar is successful on 192.168.142.140
Sending nginx-latest.tar to 192.168.142.141
root192.168.142.141s password:
nginx-latest.tar 100% 187MB 325.1MB/s 00:00 1
Successfully sent nginx-latest.tar to 192.168.142.141
root192.168.142.141s password:
导入镜像到 192.168.142.141
root192.168.142.141s password:
unpacking docker.io/library/nginx:latest (sha256:466e72df2f0b10ecb0dc90dc99d523a1c6432b764ebcbcdab3f0a7ef5cd4e061)...done
ctr import nginx-latest.tar is successful on 192.168.142.141[rootk8s-master ~]# cat pod1.yaml
# pod.yaml
apiVersion: v1
kind: Pod
metadata:name: static-pod
spec:containers:- name: nginximage: docker.io/library/nginx:latestimagePullPolicy: IfNotPresentvolumeMounts:- mountPath: /usr/share/nginx/htmlname: static-storagevolumes:- name: static-storagepersistentVolumeClaim:claimName: static-pvc[rootk8s-master ~]# kubectl apply -f pod1.yaml
pod/static-pod created
[rootk8s-master ~]# kubectl get pod
static-pod 1/1 Bound 0 5s以上就是静态供给了但是相较于静态供给还是动态供给香多了
动态供给 PV 和 PVC
在动态供给中管理员配置了存储类StorageClassKubernetes 会根据 PVC 的需求动态创建一个 PV。
创建 StorageClass
# storage-class.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: dynamic-storage
provisioner: kubernetes.io/aws-ebs # 使用 AWS EBS 或者可以是其他存储提供商
parameters:type: gp2创建 pvc
[rootk8s-master ~]# cat dynamic-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: dynamic-pvc
spec:accessModes:- ReadWriteOnceresources:requests:storage: 1GistorageClassName: dynamic-storage # 确保 PVC 引用正确的 StorageClass创建 pod 使用 pvc
[rootk8s-master ~]# cat pod-dynamic.yaml
# pod-dynamic.yaml
apiVersion: v1
kind: Pod
metadata:name: dynamic-pod
spec:containers:- name: nginximage: docker.io/library/nginx:latestimagePullPolicy: IfNotPresentvolumeMounts:- mountPath: /usr/share/nginx/htmlname: dynamic-storagevolumes:- name: dynamic-storagepersistentVolumeClaim:claimName: dynamic-pvc最后的结果和上面静态供给是差不多的
演示到这里pv / pvc 大概就是这么用的
PV 的生命周期
最后我们再来聊一聊 pv 的生命周期pv 的生命周期包含多个阶段
Provisioning PV 供给: 可以通过静态供给和动态供给创建 PVBinding 绑定: 在 PV 创建后并且处于 available 状态时PVC 与 PV 绑定此时 PV 就会转换成 BoundUsing 使用: 当 PVC 与 PV 成功绑定之后Pod 获取到 PV 的存储资源从而将容器中的数据存储到外部的存储系统中Releasing 释放: 当 PVC 被删除时 PV 也会随之被删除具体行为由回收策略决定。Reclaiming 回收: 释放后根据回收策略执行相应的操作具体的操作就是上面讲到的 Retain Recycle Delete
另外动态供给创建的 pv 回收策略默认使用的是 Delete但是这个可以在 StorageClass 的 yaml 文件中通过 reclaimPolicy 参数进行修改
内置存储对象
ConfigMap
它是一种专门用来存储各种配置文件的 pod它以键值对的形式存储保存数据。 例如 nginx 的配置文件等等
下面是一个简单的示例
[rootk8s-master ~]# cat nginx-proxy-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:name: nginx-config
data:a.conf: |server {listen 80;server_name a.example.com;location / {proxy_pass http://192.168.142.139:8080}}当我们看到 data 的时候是不是似曾相识这个就是 nginx 反向代理的配置文件
[rootk8s-master ~]# kubectl apply -f nginx-proxy-configmap.yaml
configmap/nginx-config created
[rootk8s-master ~]# kubectl get cm
NAME DATA AGE
kube-root-ca.crt 1 11d
nginx-config 1 7s那 ConfigMap 如何配合 PV 使用呢
# nginx-proxy-pod.yaml
apiVersion: v1
kind: Pod
metadata:name: nginx-proxy
spec:containers:- name: webimage: docker.io/library/nginx:latestimagePullPolicy: IfNotPresentvolumeMounts:- name: configmountPath: /etc/nginx/conf.d # 将 nginx 的配置文件挂载进容器volumes:- name: configconfigMap:name: nginx-config[rootk8s-master ~]# kubectl get pod
nginx-proxy 1/1 Running 0 46s[rootk8s-master ~]# kubectl exec nginx-proxy -- ls /etc/nginx/conf.d a.conf
/etc/nginx/conf.d:
a.conf每次挂载新的配置文件都有一个等待的过程在这个过程中存在一种自动更新的机制。kubelet 组件会定期检查 pod 挂载的 ConfigMap 对象中的数据是否发生变更如果发生变更就会将最新的配置文件再次加载到容器中去以确保 pod 始终是最新的配置。
如果只想挂载指定的 键 或者 文件名我们还可以这样
volumes:
- name: configconfigMap:name: nginx-configitems:- key: a.confpath: a.example.com.conf这样只有 ConfigMap 中键为 a.conf 的数据会被挂载到容器中。
还有一件事默认情况下 /etc/nginx/conf.d 目录下是会有一个 defalut.conf 文件的但是当我们将 a.conf 挂载进去之后它就不见了这其实是因为我们的挂载操作是覆盖操作。然而我们要如何避免这种事情呢
volumeMounts:
- name: configmountPath: /etc/nginx/conf.d/a/example.com.confsubPath: a.example.com.conf
volumes:
- name: configconfigMap:name: nginx-configitems:- key: a.confpath: a.example.com.conf但是要注意的是当我们使用了 subPath 之后kubelet 不会自动更新新的数据到 pod 中
Secret
它比较敏感因为它主要负责存储一些特别重要的信息比如找密码密钥证书等。
secret 支持三种类型 Opaque默认类型 描述最常用的 Secret 类型。用于存储任意的键值对数据这些数据会被以 base64 编码的形式存储。示例用途存储用户名和密码、API 密钥等。默认类型如果在 Secret 的定义中没有指定类型Kubernetes 会默认使用 Opaque 类型。
apiVersion: v1
kind: Secret
metadata:name: mysecret
type: Opaque
data:username: bXl1c2VybmFtZQ # base64 编码的用户名password: bXlwYXNzd29yZA # base64 编码的密码kubernetes.io//service-account-token 描述此类型的 Secret 存储的是服务账户的令牌它会自动由 Kubernetes 控制平面创建和管理。示例用途为 pod 提供与 Kubernetes API 通信所需的身份验证令牌。创建方式当你创建服务账户时Kubernetes 会自动创建与该账户关联的 Secret。
apiVersion: v1
kind: Secret
metadata:name: default-token-abcdeannotations:kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-token
data:token: base64 encoded tokenca.crt: base64 encoded ca.crt kubernetes.io//dockercfg 和 kubernetes.io//dockerconfigjson 描述这两种类型的 Secret 用于存储 Docker 配置文件通常用于存储 Docker 仓库的认证信息。示例用途在 Secret 中存储 Docker 的认证信息以便 Kubernetes 能够从私有 Docker 仓库拉取镜像。区别kubernetes.io/dockercfg 存储 .dockercfg 配置文件而 kubernetes.io/dockerconfigjson 存储的是 Docker 配置 JSON 文件更现代的格式。 示例 kubernetes.io/dockerconfigjson
apiVersion: v1
kind: Secret
metadata:name: my-docker-secret
type: kubernetes.io/dockerconfigjson
data:.dockerconfigjson: base64 encoded docker config json
当然在 k8s 的一些老版本中是这第三个docker-registry generic 以及 tls
Kubernetes 1.2 是 Secret 类型支持的重要版本Opaque默认类型、kubernetes.io/service-account-token 和 kubernetes.io/dockercfg 同时被引入。Kubernetes 1.9 开始推荐使用 kubernetes.io/dockerconfigjson这是更现代的私有镜像认证方式。当然这两种方式只是 不同表达方式它们并没有严格意义上的更新替换只是在文档和实践中有些变化。
配置文件自动重新加载方案
当 ConfigMap 和 Secret 以卷的方式被挂载到容器中时如果它们发生改变那么最新的数据也会被更新到 pod 中。为了使得最新的配置生效应用程序还需要有自动检测和处理变更的能力具体的实现方式有以下几种
1. 应用内动态检测文件变更
原理应用程序自行监控挂载文件的变更并动态加载最新内容。实现方式 使用文件监听工具如 inotify。定期轮询挂载路径检测文件更新。 适用场景轻量级服务业务逻辑明确适合直接修改应用代码。 2. 通过信号触发重新加载
原理监听指定信号如 SIGHUP触发配置重新加载。实现方式 在应用程序内设置信号处理器。配合文件挂载变更使用工具发送信号
kill -SIGHUP PID适用场景对应用进行小幅改动即可实现适合中等规模服务。 3. 使用 Reloader 或类似工具
原理借助外部工具监控 ConfigMap 或 Secret 变更触发 Pod 滚动更新。实现方式 部署 Reloader或类似工具。在 Pod 上配置注解
metadata:annotations:reloader.stakater.com/match: true适用场景需要在更新时完全重启服务适合大型分布式服务。 4. 手动重启 Pod
原理手动触发 Pod 滚动更新以应用最新配置。实现方式 修改 Deployment 或 StatefulSet 的 annotation
kubectl patch deployment name -p {spec:{template:{metadata:{annotations:{date:current-timestamp}}}}}适用场景非频繁更新情况下的简易方案。
拉取镜像的脚本
仅支持检测 tar 包具体的使用方法开袋即食跑完脚本就直接写 yaml 文件就可以了前提是我们要下 yaml 文件的 image 下再加一条 imagePullPolicy: IfNotPresent / Never 。然后还有一点要注意的就是如果本地有镜像并且已经 docker save 了那么镜像务必使 tar 结尾不然脚本会重新为你 docker save 然后就是具体的使用方法在上面已经有示范了
#!/bin/bash# 检查 Docker 是否安装
check_docker_installed() {if ! docker -v /dev/null 21; thenecho Docker is not installedexit 1fi
}# 检查是否提供了足够的参数
check_args() {if [ $# -lt 2 ]; thenecho Usage: $0 image-name host1 [host2 ...]exit 1fi
}# 检查本地是否存在指定的镜像
check_local_image() {local image_name$1if docker images --format {{.Repository}}:{{.Tag}} | grep -q $image_name; thenecho 镜像 $image_name 已存在于本地return 0elseecho 正在拉取 Docker 镜像 $image_name...if docker pull $image_name /dev/null 2 pull.log; thenecho Docker 镜像 $image_name 拉取成功return 0elseecho Docker 镜像 $image_name 拉取失败。详情查看 pull.log。exit 1fifi
}# 检查 tar 文件是否存在
check_tar_file() {local image_name$1local tar_file$2if [ -f $tar_file ]; thenecho 镜像文件 $tar_file 已经存在return 0elseecho Docker save $image_nameif docker save -o $tar_file $image_name 2 save.log; thenecho Docker save $image_name is successfulreturn 0elseecho Docker save $image_name failed. Check save.log for details.exit 1fifi
}# 发送和导入镜像到其他主机
send_and_import_image() {local image_name$1local tar_file$2shift 2 # 移动参数使得 $ 包含剩余的主机地址for host in $; doecho Sending $tar_file to $hostscp $tar_file root$host:/root/ echo Successfully sent $tar_file to $host || echo Failed to send $tar_file to $host# 检查目标主机上是否存在镜像if ssh root$host docker images --format {{.Repository}}:{{.Tag}} | grep -q $image_name; thenecho 镜像 $image_name 已存在于 $hostelseecho 导入镜像到 $hostif ssh root$host ctr -n k8s.io images import /root/$tar_file; thenecho ctr import $tar_file is successful on $hostelseecho ctr import $tar_file failed on $hostfifidone
}# 主函数
main() {check_docker_installedcheck_args $local image_name$1local iso${image_name//:/-}local tar_file$iso.tarcheck_local_image $image_namecheck_tar_file $image_name $tar_filesend_and_import_image $image_name $tar_file ${:2}
}# 调用主函数
main $
