公司简介模板word,seo关键词快速排名,超级简历免费模板,建设网站证书文章目录 一.pod相关概念#xff11;.Pod基础概念#xff12;.Kubrenetes集群中Pod两种使用方式#xff13;.pause容器的Pod中的所有容器共享的资源#xff14;.kubernetes中的pause容器主要为每个容器提供功能#xff1a;#xff15;.Kubernetes设计这样的Pod概念和特殊… 文章目录 一.pod相关概念.Pod基础概念.Kubrenetes集群中Pod两种使用方式.pause容器的Pod中的所有容器共享的资源.kubernetes中的pause容器主要为每个容器提供功能.Kubernetes设计这样的Pod概念和特殊组成结构有什么用意.Pod分为两类 二.Pod容器的分类1.基础容器infrastructure container1作用2配置 2.初始化容器initcontainers1概念2Init 容器与普通的容器的差异3Init 的容器作用 3、应用容器Maincontainer1概念2示例 三.镜像拉取策略image PullPolicy1.概念2.用户指定的方式 四.重启策略1.重启策略概念2.重启策略分类3.重启策略示例 五.部署harbor创建私有项目1.部署前操作2.部署 Harbor 服务3.在 Harbor 中创建一个新项目4.登录测试5.创建凭证并查看上传镜像 一.pod相关概念
.Pod基础概念
Pod是kubernetes中最小的资源管理组件Pod也是最小化运行容器化应用的资源对象。一个Pod代表着集群中运行的一个进程。kubernetes中其他大多数组件都是围绕着Pod来进行支撑和扩展Pod功能的例如用于管理Pod运行的StatefulSet和Deployment等控制器对象用于暴露Pod应用的Service和Ingress对象为Pod提供存储的PersistentVolume存储资源对象等。
总pod是k8s 最小的创建和运行单元.Kubrenetes集群中Pod两种使用方式
一个Pod中运行一个容器。“每个Pod中一个容器”的模式是最常见的用法在这种使用方式中你可以把Pod想象成是单个容器的封装kuberentes管理的是Pod而不是直接管理容器。
在一个Pod中同时运行多个容器。一个Pod中也可以同时封装几个需要紧密耦合互相协作的容器它们之间共享资源。这些在同一个Pod中的容器可以互相协作成为一个service单位比如一个容器共享文件另一个“sidecar”容器来更新这些文件。Pod将这些容器的存储资源作为一个实体来管理。
一个Pod下的容器必须运行于同一节点上。现代容器技术建议一个容器只运行一个进程该进程在容器-中PID命令空间中的进程号为1可直接接收并处理信号进程终止时容器生命周期也就结束了。若想在容器内运行多个进程需要有一个类似Linux操作系统init进程的管控类进程以树状结构完成多进程的生命周期管理。运行于各自容器内的进程无法直接完成网络通信这是由于容器间的隔离机制导致k8s中的Pod资源抽象正是解决此类问题Pod对象是一组容器的集合这些容器共享Network、UTS及IPC命令空间因此具有相同的域名、主机名和网络接口并可通过IPC直接通信。
Pod资源中针对各容器提供网络命令空间等共享机制的是底层基础容器pause基础容器也可称为父容器pause就是为了管理Pod容器间的共享操作这个父容器需要能够准确地知道如何去创建共享运行环境的容器还能管理这些容器的生命周期。为了实现这个父容器的构想kubernetes中用pause容器来作为一个Pod中所有容器的父容器。这个pause容器有两个核心的功能一是它提供整个Pod的Linux命名空间的基础。二来启用PID命名空间它在每个Pod中都作为PID为1进程init进程并回收僵尸进程。
总一个pod包含几个容器————————一个根容器/父容器/基础容器
pod里面容器共享目前使用的经常使用的有net uts ipc 命名空间 除此之外还有mnt、pid、user
pause容器里面有一个或者多个应用容器/业务容器.pause容器的Pod中的所有容器共享的资源
网络 每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间包括IP地址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器与外界通信时必须分配共享网络资源例如使用宿主机的端口映射。
存储 Pod可以指定多个共享的Volume。Pod中的所有容器都可以访问共享的Volume。Volume也可以用来持久化Pod中的存储资源以防容器重启后文件丢失。
总每个Pod都有一个特殊的被称为“基础容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分除了Pause容器每个Pod还包含一个或者多个紧密相关的用户应用容器。.kubernetes中的pause容器主要为每个容器提供功能
在pod中担任Linux命名空间如网络命令空间共享的基础 启用PID命名空间开启init进程。
.Kubernetes设计这样的Pod概念和特殊组成结构有什么用意
原因一在一组容器作为一个单元的情况下难以对整体的容器简单地进行判断及有效地进行行动。比如一个容器死亡了此时是算整体挂了么那么引入与业务无关的Pause容器作为Pod的基础容器以它的状态代表着整个容器组的状态这样就可以解决该问题。
原因二Pod里的多个应用容器共享Pause容器的IP共享Pause容器挂载的Volume这样简化了应用容器之间的通信问题也解决了容器之间的文件共享问题。
.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的。
总k8创建pod分为两种1自主式/静态pod不被控制器管理的pod没有自愈能力一旦pod挂了不会被重新拉起而且副本数量也不会因为达不到期望值而创建新的pod2控制器管理的pod被控制器管理的pod有自愈能力一旦pod挂了会重新拉起而且副本数量会因为达不到期望值而创建新的pod二.Pod容器的分类
1.基础容器infrastructure container
1作用
维护整个 Pod 网络和存储空间
2配置
#node 节点中操作
#启动一个Pod时k8s会自动启动一个基础容器
cat /opt/kubernetes/cfg/kubelet
......
--pod-infra-container-imageregistry.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 /pause2.初始化容器initcontainers
1概念
Init容器必须在应用程序容器启动之前运行完成而应用程序容器是并行运行的所以Init容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法。
2Init 容器与普通的容器的差异
●Init 容器总是运行到成功完成为止
●每个 Init 容器都必须在下一个 Init 容器启动之前成功完成启动和退出 如果 Pod 的 Init 容器失败k8s 会不断地重启该 Pod直到 Init 容器成功为止。然而如果 Pod 对应的重启策略restartPolicy为 Never它不会重新启动。
3Init 的容器作用
因为init容器具有与应用容器分离的单独镜像其启动相关代码具有如下优势 ●Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。例如没有必要仅为了在安装过程中使用类似 sed、 awk、 python 或 dig 这样的工具而去FROM 一个镜像来生成一个新的镜像。
●Init 容器可以安全地运行这些工具避免这些工具导致应用镜像的安全性降低。
●应用镜像的创建者和部署者可以各自独立工作而没有必要联合构建一个单独的应用镜像。
●Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此Init容器可具有访问 Secrets 的权限而应用容器不能够访问。
●由于 Init 容器必须在应用容器启动之前运行完成因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动 直到满足了一组先决条件。一旦前置条件满足Pod内的所有的应用容器会并行启动。
3、应用容器Maincontainer
1概念
初始化完成之后才启动启动完成之后会启动业务是并行启动
官网示例 https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/init-containers/
2示例
#为了实验环境简洁将之前创建的pod删除
#查看目前有的pod
kubectl get pod
#删除之前创建的pod
kubectl delete deployments.apps --allcd /opt/
mkdir pod
cd pod/
#创建pod资源
vim demo01.yamlapiVersion: v1
kind: Pod
metadata: # 配置 Pod 的元数据例如名称和标签name: myapp-podlabels:app: myapp
spec: #配置 Pod 的规范containers: #定义 Pod 中的容器- name: myapp-container #容器的名称。image: busybox:1.28 #容器使用的镜像command: [sh, -c, echo The app is running! sleep 3600] #容器启动时要执行的命令myapp-container 容器执行的命令是会首先输出一个消息 The app is running!然后让容器休眠 3600 秒initContainers: #定义 Pod 中的初始化容器这些容器在其他容器启动之前运行- name: init-myservice #初始化容器的名称image: busybox:1.28 #初始化容器使用的镜像command: [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;] #初始化容器启动时要执行的命令这些命令会检查 myservice 和 mydb 的 DNS 记录是否可用如果不可用则等待 2 秒钟然后继续检查直到可用。这个例子是定义了一个具有 2 个 Init 容器的简单 Pod。 第一个等待 myservice 启动 第二个等待 mydb 启动。 一旦这两个 Init容器都启动完成Pod 将启动 spec 中的应用容器。
#创建
kubectl apply -f demo01.yaml#查看创建的pod
kubectl get pod
NAME READY STATUS RESTARTS AGE
myapp-pod 0/1 Init:0/2 0 8m28s#这里的输出结果 Pod 当前的状态是未就绪状态其中 Init 容器的运行状态是未就绪。
Pod 的就绪状态READY是指 Pod 中所有的容器都已经启动并且准备好接收请求。在您的输出中Pod 中只有一个容器myapp-container的就绪状态为0/1这意味着该容器目前还没有启动就绪。
另一方面Init 容器是在主容器myapp-container启动之前运行的一组容器。在您的输出中Init 容器有两个init-myservice 和 init-mydb。而 Init 容器的运行状态为 0/2表示两个 Init 容器都还没有完成运行。
这些状态可能由多种因素造成比如 Init 容器出错、容器镜像无法拉取、或是缺少资源。可以使用 kubectl describe pod myapp-pod 命令来获取有关 Pod 状态的详细信息以便确定具体的问题和解决方法。kubectl describe pod myapp-pod#查看相关日志
kubectl logs myapp-pod -c init-myservice#排查首先看k8s是否起来
kubectl get pods -n kube-system
#查看后running域名解析正常但还是解析不正常缺少解析需创建解析#创建解析
vim demo01_svc.yamlapiVersion: v1
kind: Service
metadata:name: myservice
spec:ports:- protocol: TCPport: 80targetPort: 9376kubectl apply -f demo01_svc.yaml
或
kubectl create -f demo01_svc.yamlkubectl get pod,svckubectl get pods -n kube-system
kubectl get pods#再次查看创建的过程
kubectl describe pod myapp-pod#创建mydb的解析
vim demo01_svc-mydb.yamlapiVersion: v1
kind: Service
metadata:name: mydb
spec:ports:- protocol: TCPport: 80targetPort: 9377kubectl create -f demo01_svc-mydb.yamlkubectl get pods
或
kubectl get pod,svc#在创建的过程中如果遇到起不来的pod可以使用查看相关的操作过程
kubectl describe pod myapp-pod
kubectl logs myapp-pod -c init-myservice
#如果遇到镜像拉取不下来的话查看节点状态是否Ready
kubectl get node特别说明 ●在Pod启动过程中Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出。 ●如果由于运行时或失败退出将导致容器启动失败它会根据Pod的restartPolicy指定的策略进行重试。然而如果Pod的restartPolicy设置为AlwaysInit容器失败时会使用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容器的名称必须唯一与任何其它容器共享同一个名称会在验证时抛出错误。 总三种容器总括1pause容器给pod中的所有应用容器提供网络共享ip和存储共享存储资源的共享作为PID1的进程INIT进程管理整个中容器组的生命周期2初始化容器init容器阻塞或者延迟应用的容器的启动可以为应用事先提供好运行环境和工具。多个int容器时是串行的启动的每个init容器必须在下一个int容器启动前完成启动和退出3应用容器(main容器)在所有的INIT容器成功启动和退出后应用容器才会启动并行启动提供应用程序的业务三.镜像拉取策略image PullPolicy
1.概念
Pod 的核心是运行容器必须指定容器引擎比如 Docker启动容器时需要拉取镜像k8s 的镜像拉取策略可以由用户指定
2.用户指定的方式
1IfNotPresent在镜像已经存在的情况下kubelet 将不再去拉取镜像仅当本地缺失时才从仓库中拉取默认的镜像拉取策略 2Always每次创建 Pod 都会重新拉取一次镜像 3NeverPod 不会主动拉取这个镜像仅使用本地镜像。 注意对于标签为“:latest”的镜像文件其默认的镜像获取策略即为“Always”而对于其他标签的镜像其默认策略则为“IfNotPresent”。 官方示例 https://kubernetes.io/docs/concepts/containers/images
vim demo02.yamlapiVersion: v1
kind: Pod
metadata:name: pod-demo02
spec:containers:- name: nginximage: nginx:1.14imagePullPolicy: IfNotPresentcommand: [ sh,-c,echo, SUCCESS ]kubectl apply -f demo02.yaml #查看拉取策略指定策略类型默认需要修改默认方式
kubectl edit pod pod-demo02#master01 上操作操作之前确保自己的上面有nginx的pod如没有可创建
vim nginx.yamlapiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentnamespace: defaultlabels:app: rnginx
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14ports:- containerPort: 80
---apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:type: NodePortports:- port: 80targetPort: 80nodePort: 32355selector:app: nginxkubectl apply -f nginx.yaml #创建好之后再做修改
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.yamlapiVersion: 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 2 100s 10.244.2.37 node01 none none#此时 Pod 的状态异常原因是 echo 执行完进程终止容器生命周期也就结束了
kubectl describe pod pod-test1可以发现 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 READINESS GATESpod-test1 1/1 Running 0 40s 10.244.2.39 node01 none none #在任意 node 节点上使用 curl 查看头部信息
curl -I http://10.244.2.39
HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Thu, 14 Sep 2023 09:00:41 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 04 Dec 2018 14:44:49 GMT
Connection: keep-alive
ETag: 5c0692e1-264
Accept-Ranges: bytes总pod镜像拉取策略 (imagePullPolicy3种 1 IfNotPresent:优先使用本地已存在的镜像如本地没有则从从库拉取镜像 2Always:总是从仓库拉取镜像无论本地是否已存在镜像 3Never:总是不从仓库拉取镜像仅使用本地的镜像 注意: image nginx:latest 镜像的标签为latest或者无标签默认的饶像拉取的策略为Always nginx:1.14 镜像的标签为非latest默认的镜像拉取的策略为 IfNotPresent 四.重启策略
1.重启策略概念
当 Pod 中的容器退出时通过节点上的 kubelet 重启容器。适用于 Pod 中的所有容器。
2.重启策略分类
1Always当容器终止退出后总是重启容器默认策略 2OnFailure当容器异常退出退出状态码非0时重启容器正常退出则不重启容器 3Never当容器终止退出从不重启容器。 #注意K8S 中不支持重启 Pod 资源只有删除重建
#查看重启策略
kubectl edit pod myapp-pod
......restartPolicy: Always3.重启策略示例
vim pod3.yamlapiVersion: v1
kind: Pod
metadata:name: foo
spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 30; exit 3kubectl apply -f pod3.yaml#查看Pod状态等容器启动后30秒后执行exit退出进程进入error状态就会重启次数加1
kubectl get podskubectl delete -f pod3.yamlvim pod3.yamlapiVersion: v1
kind: Pod
metadata:name: foo
spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 30; exit 3restartPolicy: Never#注意跟container同一个级别kubectl apply -f pod3.yaml#容器进入error状态不会进行重启
kubectl get pods -w总pod重启策略restartPolicy3种跟container字段在同一层 1Always容器退出时总是重启容器不管返回的状态码如何默认的pod容器重启策略 2Never容器退出时从不重启容器不管返回的状态码如何 3OnFailure:仅在容器异常退出时 (返回状态码为非0时) 会重启容器 五.部署harbor创建私有项目
因企业是在私网中拉去镜像创建项目安全
开发给了镜像包和yaml文件运维上传到Harbor私有仓库看yaml文件拉去的是否是私有仓库还是本地仓库私有就在harbor本地就将包放入到node节点
1.部署前操作
相关安装包再资源的此博客的K8Skubeadm搭建K8SHarbor 私有仓库中有
#在 Docker harbor 节点192.168.198.14上操作
systemctl stop firewalld.service
systemctl disable firewalld.service
setenforce 0yum install -y yum-utils device-mapper-persistent-data lvm2
如下载慢可以用
#阿里云源快速
curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repoyum-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/2.部署 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.198.14
ui_url_protocol httpcd /usr/local/harbor/
./install.sh
docker-compose ps3.在 Harbor 中创建一个新项目
1浏览器访问http://192.168.198.14 登录 Harbor WEB UI 界面默认的管理员用户名和密码是 admin/Harbor12345
2输入用户名和密码登录界面后可以创建一个新项目。点击“项目”按钮 3填写项目名称为“summer-project”点击“确定”按钮创建新项目 #在每个 node 节点配置连接私有仓库注意每行后面的逗号要添加
vim /etc/docker/daemon.json
#进入修改地址
http://192.168.198.14systemctl daemon-reload
systemctl restart docker4.登录测试
#在每个 node 节点登录 harbor 私有仓库
docker login -u admin -p Harbor12345 http://192.168.198.14#在一个 node01 节点下载 Tomcat 镜像进行推送
docker pull tomcat:8.0.52
docker imagesdocker tag tomcat:8.0.52 192.168.198.14/summer-project/tomcat:v1
docker imagesdocker push 192.168.198.14/summer-project/tomcat:v15.创建凭证并查看上传镜像
node01节点操作
cat /root/.docker/config.json | base64 -w 0 ewoJImF1dGhzIjogewoJCSIxOTIuMTY4LjE5OC4xNCI6IHsKCQkJImF1dGgiOiAiWVdSdGFXNDZTR0Z5WW05eU1USXpORFU9IgoJCX0sCgkJImh1Yi5ibHVlLmNvbSI6IHsKCQkJImF1dGgiOiAiWVdSdGFXNDZTR0Z5WW05eU1USXpORFU9IgoJCX0KCX0KfQmaster01操作
#创建 harbor 登录凭据资源清单用于 K8S 访问 Harbor 私服拉取镜像所需要的密钥权限凭证 secret 资源
vim harbor-pull-secret.yaml
apiVersion: v1
kind: Secret
metadata:name: harbor-pull-secret
data:.dockerconfigjson: ewoJImF1dGhzIjogewoJCSIxOTIuMTY4LjE5OC4xNCI6IHsKCQkJImF1dGgiOiAiWVdSdGFXNDZTR0Z5WW05eU1USXpORFU9IgoJCX0sCgkJImh1Yi5ibHVlLmNvbSI6IHsKCQkJImF1dGgiOiAiWVdSdGFXNDZTR0Z5WW05eU1USXpORFU9IgoJCX0KCX0KfQ #复制粘贴上述查看的登陆凭据
type: kubernetes.io/dockerconfigjson#创建 secret 资源
kubectl create -f harbor-pull-secret.yaml#查看 secret 资源
kubectl get secret#创建资源从 harbor 中下载镜像
cd /opt/demo
vim tomcat-deployment.yamlapiVersion: apps/v1
kind: Deployment
metadata:name: my-tomcat
spec:replicas: 2selector:matchLabels:app: my-tomcattemplate:metadata:labels:app: my-tomcatspec:imagePullSecrets: #添加 K8S 访问 Harbor 私服拉取镜像所需要的 secret 资源选项- name: harbor-pull-secret #指定 secret 资源名称ntainers:- name: my-tomcatimage: 192.168.198.14/summer-project/tomcat:v1 #指定 harbor 中的镜像名ports:- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:name: my-tomcat
spec:type: NodePortports:- port: 8080targetPort: 8080nodePort: 31111selector:app: my-tomcatnode01节点操作
#删除之前在 node 节点下载的 Tomcat 镜像
docker rmi tomcat:8.0.52
docker rmi 192.168.198.14/summer-project/tomcat:v1
docker imagesmaster节点操作
#创建资源
kubectl create -f tomcat-deployment.yamlkubectl get pods#查看 Pod 的描述信息可以发现镜像时从 harbor 下载的
kubectl describe pod my-tomcat-d55b94fd-29qk2#刷新 harbor 页面可以看到镜像的下载次数增加了
