云原生实战课大纲_云原生课程大纲-优快云博客

1. 云原生是什么 原生应用（java,python） 上云的过程
  应用上云遇到的问题
  1.微服务的拆分  微服务的访问关系
   应用的架构
 云原生适合什么样的人去学
 具备什么样的前提条件
 云原生要学习什么
 docker  k8s  devlops  server mesh  jks  k8s监控
 吧自己的微服务部署上云
 另外一种微服务架构  server mesh
 监控k8s平台  比如说告警日志信息

在这里插入图片描述

#拉取镜像
docker pull nginx 
#查看镜像
docker images

在这里插入图片描述

docker rmi  删除镜像 基于镜像做的crud
下载镜像后，让镜像启动起来
启动容器  docker run 启动容器
docker ps 查看正在运行的容器
docker  stop  停止应用

在这里插入图片描述

--restart=always  容器开启自启动  -p端口映射

在这里插入图片描述

 docker ps 就可以查看状态 完成nginx的启动

在这里插入图片描述

我现在启动一个nginx 应用并且可以访问到
接下来 如果我想修改nginx的内容该怎么做
修改nginx的页面
 1. exec 进入容器 进行修改
 2. -v挂载出来

在这里插入图片描述

echo

在这里插入图片描述

 我此时再来访问nginx 的时候首页就会发生变化  

我修改完毕之后 我把我修改过后的nginx 提交至本地改名为 guigu的的 v1版本
我可以指定一个镜像之后 docker commit 保存在本地

在这里插入图片描述

相当于linux 的快照 
git的本地commit 
假设我有一天我容器宕机了 我直接rm删除  然后再启动shangguigu 的v1版本
相当于此时生成一个快照机制  此时我基于本地构建一个docker的镜像
我就用我之前的nginx 镜像 我相当于对nginx 镜像做了一个定制化

在这里插入图片描述

相当于在本地构建一个镜像，我修改了原来的镜像可以commit 提交至本地


镜像的共享  >1  save load

我可以把我的镜像通过docker save 命令保存为tar 包
然后 scp （文件传输）进行复制到另外一个主机上  之后 docker load执行
docker load 之后  docker run 执行
这种适合于离线场景 比如说我此时不便于对接公网

在这里插入图片描述

>我可以把我的镜像进行推送 比如说推送到docker hub仓库  docker push
>共享dockerhub  规避了底层的复杂度
也就是说我不必知道你是怎么改的 我只需要 docker run 启动起来就可以了

在这里插入图片描述

我们能登录到仓库的话 我们就需要 docke push  将我们的镜像push到远程

在这里插入图片描述

docker -v 挂载
docker -v  将配置文件 以及数据文件挂载到外面
我们以前改nginx 的内容,需要docker exec 进入之后进行修改
每次都要进去改 有些麻烦 
将容器中的文件 挂载出来
ro 是只读模式  代表容器内部的文件是不允许修改的 是只读模式

在这里插入图片描述

docker ps   -v 将nginx中的配置文件挂载出来

在这里插入图片描述

保证主机目录下有页面index.html
包括nginx 的配置文件 也可以挂载出来   卷挂载
docker 命令 有了挂载之后 修改东西就很方便了
docker logs   可以看到这个容器的运行日志(启动日志)  我们可以排错用

在这里插入图片描述

 nginx 的页面挂载出来  还有nginx的config 也挂载出来

在这里插入图片描述

docker cp 可以把容器的文件复制到本机  复制出来

在这里插入图片描述

然后docker -v 再进行挂载

在这里插入图片描述

 反向写 可以把容器外面复制到我docker容器中

docker 命令
如果我们要安装nginx 并且修改 之后上传至docker hub
docker search 
docker pull 
ducker run 
docker commit  {将本地修改后的 打包成一个镜像}
docker tag  {按照远程仓库的命名规则}
docker push 

----------------<<<<<<<<<<<<,,
docker search 
docker pull 
ducker run 
docker commit  {将本地修改后的 打包成一个镜像}
docker save 
docker load

我们java+redis 使用docker怎么部署
我们Springboot项目+redis 部署在docker中

1.  使用docker 部署redis
启动redis
docker run redis  先用docker 部署redis  先部署redis  redis的配置文件和数据文件
可以docke -v 挂载出去
docker run redis -v挂载， 启动redis 让redis产生数据之后
部署redis结束

2.
springboot项目 redis的incr命令

在这里插入图片描述

springboot+redis 应用 基于dockerfile文件打包为镜像，部署在docker上运行

以前如果没有docker上 我们的SpringBoot项目是怎么部署在服务器上的
我们的项目通过maven打包成jar包，然后上传至服务器之后 java -jar执行

在这里插入图片描述

我服务器还要装java 环境  如果有新的服务器我还得搞java 环境
如果我是python应用的化，我还得安装python环境
如果我是一个前端应用的化，我还得安装前端

在这里插入图片描述

我可以把我服务器装docker,我任何应用都是以docker的镜像运行的
这样屏蔽了底层
我不管是运行 前端。java应用，python应用我都可以
docker run 来运行镜像就可以了

基于docker的方式将jar包打包成镜像

在这里插入图片描述

docker file 执行怎么打包,每一个应用都要有一个dockerFile文件 ，编写dockerFile文件

在这里插入图片描述

jar包以及dockerfile文件   依照jar--->构建镜像
docker build -t .
jar 如果在服务器上运行 还得装java环境  太麻烦了
有了dockerFile  怎么吧jar 制作成镜像

在这里插入图片描述

docker build -t 构建镜像 基于 java项目（dockerFile文件） 构建镜像
然后我们docker images 就可以看到我们构建的镜像了

在这里插入图片描述

315mb  因为jdk 既有288mb
docker run 构建镜像

在这里插入图片描述

docker ps 查看进程
docker logs
  我们启动以及排错日志

在这里插入图片描述

我们之前自己把我们的镜像打包在我们的机器上了
如果我新的机器想要跑我们的应用  我可以吧这个镜像第一步推送到我镜像仓库
docker tag 
docker push 
吧我们的新镜像推送上去

在这里插入图片描述

k8s  
1。什么是k8s 他的出现是为了解决什么问题的 
2.应用完成开发后想要部署的三个时期

3.我们k8s能帮助我们实现什么  k8s 的功能

k8s 架构
master node
worker node(1)
worker node(2) 
工作模式

在这里插入图片描述

k8s的架构，以及k8s中每个节点 是干嘛的 各个组件的作用

在这里插入图片描述

k8s 是怎么工作的  以及k8s架构
都是基于apiService 访问呢
apiService 进行隐藏
将我们的项目部署在k8s上,可以部署多个节点. 以达到高负载

在这里插入图片描述

安装k8s
kubeadm  init 
kubeadm  join 
主节点中的 工作进程
工作节点中的 工作进程
k8s的集群规划
################
docker  容器的运行环境
docker安装完毕后 让每一台机器都 启动docker
k8s 安装集群的第一步  docker（容器运行环境）


设置hostname
k8s-master_(主机)
k8s-node1_(节点1)
k8s-node2_(节点2)

k8s 查看内存

在这里插入图片描述

建立1个node 2个work的集群.可以在集群中加入主节点和work节点
kubectl get nodes //获取节点

在这里插入图片描述

pod 是k8s中的最小单元  
kubectl  get  pods  -A  //查看k8s中部署的Pod

在这里插入图片描述

运行中的应用在docker中叫容器， 在k8s中叫做pod
docker ps  kubectl get pods  ..可以看到我正在运行的容器
kubectl  get pods- A 可以看到我集群中的每一个应用的名字
k8s 拉的pod 如果挂了 会自动拉的  重新部署



1. 基于kubectl -f  执行文件 
2. kubectl create 执行命令

在这里插入图片描述

namespace 做资源隔离的 类似于nacos 是做资源隔离的
prod 的namespace  //生产
dev  的namespace  //dev

在这里插入图片描述

基于名称空间ns 创建资源 pod， 基于ns 下对pod 的crud
docker ps 查看应用
kubectl get pods

在这里插入图片描述

pod是k8s中最小的运行单位，k8s 启动pod就可以，pod可以启动多个容器,一个pod中可以有多个容器

在这里插入图片描述

kubectl run mynginx --image=nginx 
// 我启动了一个nginx 的pod
给pod 起一个名字  依据于nginx的镜像启动pod

在这里插入图片描述

pod  启动容器 pod 底层是依靠于 docker拉取的

可以基于kubectl describe pod mynginx 来查看pod的信息 以及pod的调度

在这里插入图片描述

 可以查看调度到那个机子上

在这里插入图片描述

我们使用了一个命令创建了k8s 的一个pod
查看pod 
kubectl get pod

在这里插入图片描述

k8s 描述pod  kubectl describe pod //描述pod的信息
pod 在前面创建好了  kubectl  delete pod //删除pod

在这里插入图片描述

kubectl  describe pod 描述pod  ，比如说pod 调度到那个节点上，pod在部署的过程中出现什么问题 我们都可以基于 这个命令来排查和定位

在这里插入图片描述

我们基于配置文件创建的pod

在这里插入图片描述

pod 的命令

在这里插入图片描述

我们使用docker 部署的nignx 我们更改他的首页 还可以访问
我们现在用k8s 的pod 部署的nginx 怎么访问  
pod 是有ip的

在这里插入图片描述

pod 就可以访问我们nignx的首页 因为默认是 80的port,我们基于docker 部署的nignx 我们可以exec it 进入容器中去改.现在我们可以

在这里插入图片描述

kubectl  exec 进入nginx 容器 修改主页

在这里插入图片描述

我们的应用是在k8s 中以pod 来部署的,pod是k8s中最小的单位，每一个pod 都有一个ip  基于ip:port 就可以访问

在这里插入图片描述

1个pod中部署多个应用,比如说一个pod中有nginx和tomcat2个容器,pod 中容器不一样 基于端口号去访问对应的容器

在这里插入图片描述

如果nginx和tomcat 在同一个pod中内部 nging访问tomcat　怎么访问只需要　127.0.0.1：8080 就可以访问 因为同一个pod,我在nginx中访问pod 访问127.0.0.1 就可以访问到，同样我在tomcat中访问nginx 也是只需要访问127.0.0.1 就可以访问到，因为我nginx和tomcat在同一个pod中
同一个pod属于同一个网络空间 127.0.0.1 就可以访问

在这里插入图片描述

k8s 中deployment,管理pod,我做一次部署 我需要100个Pod

在这里插入图片描述

kubectl run pod 删除之后就没有了
我kubectl create deployment  删除之后 可以继续拉pod
deployment 是控制pod的，让pod具备负载均衡的能力
基于deployment创建的pod 是删除不了的
我基于deployment 创建的pod  路由到node2上 ,这个时候node2  宕机了我就得重新拉pod 
我们使用deployment 部署的应用 我们不怕应用崩溃或者机器down 
因为应用崩溃或者机器down，我们k8s 会重新拉取

我们基于deploy 创建一个应用部署，底层还是会给我们启动pod  但是他是有自愈能力的 
我们就不能直接删除pod了。 我们需要删除这一次部署

在这里插入图片描述

多副本能力 我可以把一个应用同时部署很多份，以达到具备高并发的能力.
我这次部署我要启动3个pod,我们使用deploy的话快速得到一个副本能力,
我们部署的一个应用可以有多个副本
我只有把这次部署应用删除了，我才可以把对应的pod删除了。你的应用或者节点宕机后，我可以在别的机器上拉一份
这就是我们使用deploy的功能，可以部署多副本容器

在这里插入图片描述

我们基于配置文件也可以构建多副本pod
然后kubectl -f 也可以执行

在这里插入图片描述

我们pod的创建，deploy的多副本能力
deploy 和pod的区别
如果我们想要部署一个应用， 我们以前使用kubectl run pod 启动一个pod
这种方式功能简单

为了方便部署 我们基于deploy来部署

k8s扩缩容  kubectl scale 
我刚开始deploy部署了2个pod,但是随着我们运行过程中我发现2个pod是不足以满足我们的业务需求的
我此时想多要2个pod 我就得扩容

在这里插入图片描述

流量高峰过去之后 我们也可以让这些pod 下线 然后给我们腾出一些资源  我们把这个过程 叫做缩容

在这里插入图片描述

我们把这个过程叫做扩缩容，我们以后k8s也能做到动态扩缩容
就是让k9s自己来判断pod的负载过高 我就扩容  负载低了 我就缩容（基于pod内存或者cpu来做）

在这里插入图片描述

我们以前部署一个应用叫做my_dep  ,然后我监控一下 watch  -n 1 每秒执行一次

在这里插入图片描述

我此时给他扩容

在这里插入图片描述

我此时新加pod 加2个pod,如果此时的流量高峰期过去后 我们可以给他缩容

在这里插入图片描述

这个就叫扩缩容的过程.扩缩容的过程

在这里插入图片描述

depooyment 的自愈以及故障转移,我们还是在k8s中使用deploy部署一个应用，比如说我们此时部署了3个pod
但是应用在运行过程中,可能会宕机，比如说node节点挂了，或者pod宕机了
我们希望这种故障的话k8s集群可以感知到，那个pod出现的问题，然后我就可以自我修复

pod挂了 首先k8s会尝试重启，重启可以了就算是可以了，如果node宕机了，我们集群感知到node宕机后
就会在其他node中拉起一份 进行故障转移

在这里插入图片描述

我们看下我们以前部署的Pod 并且我们可以看到我们的Pod 部署在哪一个机器上了
我们来模拟第一种情况，我把node1上的第一个容器给kill   类似于我pod发生故障了

在这里插入图片描述

我停止了这个pod

在这里插入图片描述

过一会 我k8s 就会重新启动， 这种情况我们叫做k8s 的自愈能力,
当我们应用上线后，那些容器出现故障，我们k8s就会重启，所以我们把这个叫做自愈能力

在这里插入图片描述

当我们node1机器直接宕机了 会怎么办  整个集群会怎么处理的

在这里插入图片描述

故障转移 我们第一个pod应用应该从node1节点，此时转到node2 节点上
在k8s中只要有pod出现问题，我就会认为你以前的3个pod,就一定会有3个POD,deploy就会保证我们的副本数量

k8s的滚动更新

在这里插入图片描述

此时我们基于deployment部署了3个pod,我们此时是v1版本，然而我们想要升级成为v2版本
先升级一个pod的v2,等v2的版本pod运行成功了，再替换
灰度发布 可以实现我们不停机安装

在这里插入图片描述

以前是我们把旧的pod全部杀了，再启动新的pod,这样就会导致，如果我新的pod有问题，我们的请求就会有问题
我们的滚动更新杀死一个老版本，启动一个新的版本其他的老版本都还在
一旦新版本有问题，第一个有问题的话，其他还是可以处理的 ，并且此时是支持回滚的
这就是我们不停机维护

我们之前部署的my_dep 部署的Pod 使用的是nginx 的nginx　最新版本的镜像.
我此时要把容器的nginx镜像改成1.16.1

在这里插入图片描述

--recoed 我要记录下来 启动一个新pod 杀死一个旧pod  的先启动再杀死, k8s 做到了不停机维护

在这里插入图片描述

可以基于命令查看整个过程。我们把这个叫做滚动更新  此时我们就可以实现不停机更新

在这里插入图片描述

改这里就可以了
k8s的版本回退，我们之前部署一个版本，然后我们进行一个镜像升级，又产生一个版本，我们的应用会经常升级
我这次不满意 我想回退到之前的某一个状态 类似于git 记录

在这里插入图片描述

我们可以看到我们my_dep部署的历史情况

在这里插入图片描述

他以前产生了多少次的版本改变 --record=true 所以我们记录下来了
但是我某一次不满意  我想回到我的某一个版本中

在这里插入图片描述

我们就可以回退到某一个历史版本 这次回退也是一个滚动更新的过程
我们可以kubectl get pod -w 进行监听

先创建一个新的pod, 新的创建起来就会杀死一个旧的pod 也是进行的滚动更新

在这里插入图片描述

呢我们怎么能确定恢复到之前的版本了  我们可以查看他此时的nginx版本

在这里插入图片描述

因为我们最后一次部署使用的nginx 是1.61 来部署的
这个就是版本回退功能
我们之前说了使用deploy部署一个应用带来的诸多优点
以后我们也要考虑使用deploy来部署应用而不是使用kubectl run 部署

在这里插入图片描述

我们不会直接部署pod 我们会使用deploy来部署pod,这样的Pod 功能会比较强大

k8s 的服务service  k8s做服务发现功能的,如果我此时用deploy 部署了3个pod
比如说后台管理系统，
我们现在都是前后端分离的项目 vue--->springboot项目,vue请求后端的时候是有一个ip：port
以前我们可以部署放pod的ip,我们前后端分离的项目 vue--->springboot项目
一组服务就成为一个service

在这里插入图片描述

 我还希望service 提供负载均衡的能力,前端访问service的时候，可以做到负载均衡，访问到各个pod
 pod宕机了 还可以发现 就像nacos一样  这个就是服务发现

我先用deploy 部署3个nginx 的pod
我更改3个pod 的nginx 首页
111
222
333
然后我curl 发送到service  我就可以看到负载均衡的效果

在这里插入图片描述

kubectl expose deploy my_dep
我访问3个pod 这就是我们目前默认访问pod 是这个样子
service 是基于deploy 暴露服务的

在这里插入图片描述

kubectl get service 就会有个ip:port

在这里插入图片描述

我基于service我就可以实现负载均衡的效果
depose 暴露

在这里插入图片描述

我们也可以基于yaml来做

在这里插入图片描述

service是基于标签来筛选pod的，默认是在集群内部来访问
service 基于标签选中一组pod 把他们统一暴露服务
我们的type默认是clusterIP

在这里插入图片描述

ClusterIp 集群Ip 也就是说我暴露的这些东西只能在集群内访问
我们使用service把一组pod对外暴露统一进行服务，我们以后只需要访问service就可以负载均衡的访问pod了
并且还具备服务发现 ，可以动态感知到应用的下线，在负载均衡的时候就不会将流量打给下线的应用了
service的clusterIP 集群ip 模式 只能在集群内部访问
我们也可以采用nodePort的模式进行集群外访问

在这里插入图片描述

30948 k8s对外暴露的接口是30948,我们用宿主机的ip：30948就可以实现了

在这里插入图片描述

具备负载均衡的功能  master/node1/node2
使用任意一台集群ip:port 就可以负载均衡的访问了  我们这些pod

ingress
我们使用service 有2种方式
clusterIp 暴露在集群内进行访问
nodePort 每一个机器的ip：port 访问
在k8s中 希望ingress 成为整个集群的唯一入口
所有的请求流量都先进入ingress 统一网关入口
service是pod的入口， service负责对pod进行负载均衡
所有请求流量进入ingress,由ingress转交给service,再由service负载均衡到pod

我们 order, user,product 服务，各自部署的pod打的标签是不一样的

在这里插入图片描述

我们现在利用k8s集群就把我们商城服务部署好了,有订单服务 用户服务 还有我的商品服务,我们这些服务要相互访问
比如说我用户下单，order--->product(发起rpc调用)  会发请求到对应的service中 因为service提供了pod
的统一入口，具备负载均衡的功能

pod 发请求到service, 由service负载均衡到对应的pod

ingress 是service的统一网关入口，根据域名配置upstream路由到各个service中
基于ingress 路由到各个service中

比如说
order.atguigu.com
user.atguigu.com

所有的请求先经过ingress来进行判断，基于ingress来负载到那个service  service再交到那个pod

ingress底层是基于nginx来做的
基于yaml下载ingress  kubectl apply -f xxx.yaml 就可以下载到ingress

在这里插入图片描述

ingress 是一个nginx  会对外暴露2个端口  一个是http端口 一个是https端口  http:80  https:443

在这里插入图片描述

以后我们所有的请求都是从ingress进来的  呢么怎么把ingress像配置nginx中 基于请求或者域名 到对应service
ingress 安装好了给我们暴露了2个端口，一个是处理http请求的，一个是处理https请求的

从ingress----->service 基于域名可以路由

###test
基于deploy部署2个pod,用hellow.service：8080 做hellow的service 
基于deploy部署2个pod,用nginx.service：8080 做nginx的service 

##  我的诉求是
当我访问hellow.atguigu.com 把请求转给hellow.service
访问 nginx.atguigu.com 把请求转给 nginx.servic

###
外部流量进来先打给我们的ingress,ingress的规则配置
访问hello.atguigu.com --------->hellow.service
访问nginx.atguigu.com --------->nginx.service
我们可以配置ingress  然后apply -f 启动他  此时 就是当访问hellow.atguigu.com 就会跳转到hello-service的服务中 继而 负载均衡到各个pod中
访问规则类似于gateway  或者upstream

在这里插入图片描述

我们可以	查看我们配置的ingress

在这里插入图片描述

然后我配置hosts

在这里插入图片描述

我接下来访问hollow.atguigu.com -------->hellowservice
我接下来访问nginx.atguigu.com -------->nginx service

在这里插入图片描述

当我们访问hollo.atguigu.com 就会访问到hellow.service
当我们访问demo.atguigu.com 就会访问到demo.service
这就是我们基于ingress的优点 所有请求流量一进来 ingress先处理
在k8s的ingress中基于域名规则来访问对应的服务  在ingress中我们还可以做流量限制 做限流

在这里插入图片描述

我们可以做流量限制  每秒做限流    每秒放1 个 
我们Kubectl　get ingress 可以看到

在这里插入图片描述

我们访问haha.atguigu.com 此时是做了限流  可以看到 当流速过大的时候此时会做限流处理
如果刷新比较快的话 就会响应503 报错
我们做了限流了  我们也可以更改这个状态码

在这里插入图片描述

我们的ingress 就实战操作完成了,我们接下来就总结下K8s的网络模型

我可以在ingress上层在做一个负载
@Lb随机发送到一个node的ip:port,发送到任意一台Ingress
一组pod要提供访问 我们会把他们抽象成一个service,呢么我们的网路流量，首先来到3台机器的任何一个 80/443的
nodePort(基于ingress)
然后ingress再根据域名配置 将请求路由到不同的service中，基于service做负载均衡就可以到pod中了

我们的k8s 会产生3层网路  
第一层是所有的pod层
第二层是service层
第三层是ingress

ingress----->service------>pod


我们的请求流量先到达我们的ingress--->service-->pod
这是我们的网络模型
外部的请求流量优先通过ingress 往下进行转发 
ingress是一个总网关

在这里插入图片描述

k8s 中的存储对象
我现在用deploy 部署了3个pod,pod中有一些数据要挂载到外面，方便修改 就像docker -v一样
pod 运行容器中的 /data 数据挂载到主机的/a位置 我们以后在主机的/a位置进行修改就可以了

在这里插入图片描述

其他pod也一样

在这里插入图片描述

这是我们以前 如果用docker 起容器的话  可以这么来做
如果用k8s的话，如果这么做会有一些问题
如果pod down 机了，k8s感觉pod挂了，按照故障转移的说法，k8s会把这个pod在别的机器上起来

在这里插入图片描述

比如说黑色的，3号机器上内容在2号机器上是没有的，当我发生故障转移的时候，我的pod再要重新挂到主机的目录时候
由于机器已经发生了变，所以之前的/temp是找不到的
所以我们此时虽然启动了一个pod 但是里面是没有数据的，如果pod是mysql的话 就完蛋了
我们希望吧我们的整个数据挂载层 统一进行管理---存储层 类似于分布式存储
存储层使用的技术很多

在这里插入图片描述

k8s 在存储层是开放的 用什么技术都可以
比如说我们使用nfs  做到数据共享  就像redis一样  这里我们使用的是nfs

我们先要搭建一个nfs 的网络文件系统 master  node1 node2
我在master中 /NFS/DATA中写了一个 文件

在这里插入图片描述

我在node3 和nod2节点中就可以获取到这个 数据

在这里插入图片描述

只是远程挂载，数据还是存储在master中，其他节点不存储数据的 换言之master挂了，其他就全部挂了
我们的nfs  做文件共享

我们的k8s如何利用nfs的文件系统进行挂载.
我们安装了nfs文件系统将来我们看如何使用原生的方式对pod 进行挂载

基于deploy 部署2个nginx  我直接把我们的nginx 中的/usr/share/nginx/html 挂载到nfs中的
/nfs/data/nginx-pv

在这里插入图片描述

我们的Pod是以为deploy的方式启动的,我只需要在nfs中更改页面.我pod 就相当于修改了
以后我们要启动一个pod，无论是通过deployment启动的,我们只要想要挂载,我们使用nfs就可以挂载

在这里插入图片描述

将我容器内部的/usr/share/nginx/html 挂载到/nfs/data/nginx-pv 路径，而且我外面是nfs 文件系统
我们使用原生方式挂载,我们在容器中标记我这个路径要挂载到nfs的那个路径下
这种方式会产生一些问题

1> 如果我此时挂载到了 /nfs/data/nginx-pv  文件夹我们自己要创建的
2>如果我pod不要的话，比如说delete删除pod, 我们之前挂载的文件夹里面的内容是不会被删除的

在这里插入图片描述

我们删除了我们的部署。 但是我们的部署还在 不会自动清理
我们启动了很多pod,但是pod以后要是删除了之后,我们希望 他能够自动清理调没有用的内容
我们这个pod挂载的这个目录，但是我们没有对他使用的空间做限制
我们希望在挂载的时候做一些 容量的限制 比如说10G 1mb之类的

我们可以采用pv-pvc的这种模式
1> 创建pv 池
2》 在pv池中创建pv 并且规划使用多大的内存

在这里插入图片描述

2.在pv池中创建pv

在这里插入图片描述

在pv池中创建pv创建了 3个pv,分别为10m, 1G, 3G {读写模式为可读可写}
我此时规定的01 文件夹只能用10m

在这里插入图片描述

我们可以使用kubectl get pv 查看我们创建的pv

在这里插入图片描述

这就是我们创建的pv 分别占用多大的容量
我想要使用的话  当我们pv创建好了 之后我们就可以创建pvc 进行绑定pv
pvc类似于申请书，意思是我想要多少内存 ，当pvc删除之后 对应的pv也会进行释放

在这里插入图片描述

创建pvc 我相当于写了一份 我要申请200mi的容量

在这里插入图片描述

这些pv 都是可用的 所以我接下来我写一份申请书pvc 
apply -f pvc.yml

在这里插入图片描述

可以看到我的1G的pv被这个pvc 绑定了

在这里插入图片描述

当删除pvc之后

在这里插入图片描述

当删除pvc之后我们的pv就释放了  此时我们基于deploy部署pod的时候就可以创建一个pvc,相当于我pod过来提交
一个申请书

在这里插入图片描述

相当于我们修改了pv 文件夹的内容,对应pod 的文件夹也会变化.
这就是我们写的申请书pvc以及这些pv,现在系统中有一些pv 以及这个申请书
这是我们的pvc和pv的关系
我们以后想要那个空间我可以先写一个申请书

在这里插入图片描述

pod 绑定pvc
我们此时只需要声明一下我们此时的挂载是使用这个申请书对应的名称空间 
apply -f

在这里插入图片描述

我们pv和pvc的绑定关系  这里我们的pv中是容量限制的
基于pv池中创建pv的时候式有容量限制的
我们现在使用的pv和pvc 静态供应， pv是在pv池中提前前建好的