Kubernetes——滚动更新和数据管理

k8s——滚动更新
滚动更新就是一次只更新一小部分副本,更新成功之后再更新更多的副本,最终完成所有副本的更新。
滚动更新最大的好处是零停机,整个更新的过程中始终有副本运行,从而保证了业务的连续性。
kubectl create deploy httpd3 --image=httpd  --dry-run -o yaml > httpd3.yaml
或者手动编写yaml文件:

vim httpd3.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
 labels:
  app: httpd3
 name: httpd3
spec:
 replicas: 3
 selector:
  matchLabels:
   app: httpd3
 template:
  metadata:
   labels:
    app: httpd3
  spec:
   containers:
   - image: httpd:2.2.31
     name: httpd
    
kubectl apply -f httpd3.yaml
kubectl get deploy -o wide  #可以查看image的版本信息
kubectl get rs -o wide    #可以查看iamge的版本信息
kubectl get po -o wide      #使用这种方式来查看image的版本信息是不可以的,查看不到

然后替换httpd的版本:

apiVersion: apps/v1
kind: Deployment
metadata:
 labels:
  app: httpd3
 name: httpd3
spec:
 replicas: 3
 selector:
  matchLabels:
   app: httpd3
 template:
  metadata:
   labels:
    app: httpd3
  spec:
   containers:
   - image: httpd:2.2.32
     name: httpd

kubectl apply -f httpd3.yaml
kubectl get deploy -o wide   #发现版本变更了,但是deploy实际上没有发生变化
kubectl get rs               #发现rs变了,生成了新的rs
kubectl get rs -o wide    #查看新的httpd版本

实现回滚操作:
kubectl delete -f httpd3.yaml
然后准备三个(或多个)yaml文件,分别对应三个(或多个)版本镜像的httpd
只需要修改镜像的版本即可,其他无需更改。
执行:
kubectl apply -f httpd31.yaml --record
kubectl get po   #查看相应的信息
依次执行:
kubectl apply -f httpd32.yaml --record
kubectl apply -f httpd33.yaml --record
实现滚动更新:
kubectl rollout history deploy httpd3  #查看记录的历史,可以看到REVISON的编号
kubectl get rs -o wide       #可以看到历史的各rs和对应的iamges
回滚:
kubectl rollout undo deploy httpd --to-revision=1
kubectl get rs -o wide     #发现对应的rs已经起来了
再次查看历史:
kubectl rollout history deploy httpd3  #发现revision的编号已经从1、2、3滚到了2、3、4,会依次往下叠加
kubectl get po

如果要查看滚动的详细过程:
kubectl apply -f httpd31.yaml
kubectl apply -f httpd32.yaml
然后立马查看pod的情况
kubectl get po  -w
kubectl describe deploy httpd3  #查看Events返回信息可以看出是一次只更新一个副本,成功之后再更新下一个。
始终维持3个预期值,过程是一个一个更新替换。

k8s——数据卷管理
数据卷:emptyDir hostPath nfs pv/pvc
实际上pod的生命周期可能很短,会被频繁地销毁和创建,容器销毁时,保存在容器内部文件系统中的数据都会被删除。
为了数据的持久化,可以使用kubernetes volume
volume的生命周期独立于容器,pod中的容器可能被销毁,但是volume会被保存下来。
本质而言k8s volume是一个目录,这一点也docker volume类似。当volume mount 到pod,pod中的所有容器都可以访问这个volume
kubernetes volume支持多种backend类型,包括哟emptydir 、hostpath 、GCE persistent Disk、nfs 、ceph等
volume提供了对各种backend的抽象,容器在使用volume读写数据时,无需关心数据是存到本地文件系统中还是云硬盘上,对它来说,所有类型的
volume就是一个目录。

EmptyDir volume

emptydir是最基础的volume类型,实际上就是host上的一个空目录。
emptydir volume对于容器来说是持久的,但是对于pod则不是,当pod从节点中删除时,volume的内容也会被删除,但如果只是容器被销毁,pod还在
那么volume不受影响。也就是说emptydir volume与pod的生命周期一致。
pod中的所有容器都可以共享volume,它们可以指定各自的mount路径。

编写yaml文件:
kubectl get po -n kube-system
vim nginx.yaml
apiVersion:apps/v1
kind: Deployment
metadata:
 name: nginx2
spec:
 replicas: 2
 template:
  metadata:
   lables:
    run: nginx
  spec:
   containers:
   - name: nginx
     image: nginx
     iamgePullPolicy: IfNotPresent
     volumeMounts:
     - name: nginx
       mountPath: /usr/share/nginx/html    #容器的目录
   volumes:
   - name: nginx
     emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
 name: nginx-sve
spec:
 selector:
  run: nginx
 type:NodePort
 ports:
 - port:80
   targetPort:80
   nodePort:30008
  
kubectl apply -f nginx.yaml
kubectl get po -o wide
kubectl get svc

通过外网访问pod:显示时403
kubectl get po -o wide    找到pod所在的node上线测试网站
#去对应pod执行:
docker ps
docker inspect container-id   #找到binds,查询绑定的随机目录,然后进入该目录写入echo “hello world” > index.html
然后外网访问,就能够访问到相应的内容了。然后可以上线测试网站,按正常上线网站的操作流程操作即可。

HostPath volume
使用hostpath可以指定宿主机的目录
hostpath volume的作用是将docker host文件系统中已经存在的目录mount给pod中的容器。大部分应用不会使用hostpath,因为这实际上增加了pod
与node的耦合,限制了pod的使用灵活性。不过哪些需要访问k8s和docker内部数据的应用需要使用hostpath。
从节点需要准备相应的目录。
只需要在empthdir的基础上略作修改即可:
vim nginx-hp.yaml
apiVersion:apps/v1
kind: Deployment
metadata:
 name: nginx2
spec:
 replicas: 2
 template:
  metadata:
   lables:
    run: nginx
  spec:
   containers:
   - name: nginx
     image: nginx
     iamgePullPolicy: IfNotPresent
     volumeMounts:
     - name: nginx
       mountPath: /usr/share/nginx/html    #容器的目录
   volumes:
   - name: nginx
     hostPath:
    path: /ken
---
apiVersion: v1
kind: Service
metadata:
 name: nginx-sve
spec:
 selector:
  run: nginx
 type:NodePort
 ports:
 - port:80
   targetPort:80
   nodePort:30008

kubectl apply -f ngnix-hp.yaml
#这需要你的每一个节点都要有/ken 目录,这个/ken目录实际在pod运行的node上。
然后再/ken这个目录下上线你的网站即可。

Nfs volume

nfs——yaml文件编写
只需要略作修改:
apiVersion:apps/v1
kind: Deployment
metadata:
 name: nginx2
spec:
 replicas: 2
 template:
  metadata:
   lables:
    run: nginx
  spec:
   containers:
   - name: nginx
     image: nginx
     iamgePullPolicy: IfNotPresent
     volumeMounts:
     - name: nginx
       mountPath: /usr/share/nginx/html    #容器的目录
   volumes:
   - name: nginx
     nfs:
    path: /ken     #只需要nfs节点有这个ken目录就可以
    server: 192.168.27.20    #写上你自己的nfs共享目录
---
apiVersion: v1
kind: Service
metadata:
 name: nginx-sve
spec:
 selector:
  run: nginx
 type:NodePort
 ports:
 - port:80
   targetPort:80
   nodePort:30008

kubectl apply -f nginx-nfs.yaml

然后在你的server节点上部署nfs即可。
#值得注意得是nfs的配置文件/etc/exports 中的几个内容:
#all_squash   把每个节点访问nfs的用户全部映射为nfsnobody
#root_squash  把访问nfs的root用户映射为nfsnobody
#no_root_squash  把访问nfs的非root用户映射为nfsnobody

nfs部署成功之后,在你的共享目录之中上线你的网站。当你删除你的pod的时候,你的数据是保存下来的。

pv/pvc volume
persistentvolume是外部存储系统中的一块存储空间,由管理员创建和维护,pv具有持久性,生命周期独立于pod。
persistentvolumeclaim实际上就是对pv的申请(claim)pvc通常由普通用户来创建和维护。当需要为pod分配存储资源的时候,用户可以创建一个pvc
指明存储资源的容量大小和访问模式(如只读)等信息,k8s会查找并提供满足条件的pv。
有了pvc,用户只需要告诉k8s需要什么样的存储资源,而不必关心正真的空间从哪儿分配,如何访问等底层细节,这些storage provider的底层信息
交给管理员来处理,只有管理员才应该关心创建pv的细节信息。

k8s支持多种类型的pv,如AWS EBS ceph nfs等。
本文使用nfs来创建pv
首先搭建nfs共享文件系统。
然后创建pv

这里编写yaml文件的时候需要用到accessModes,它有三种模式:
ReadWriteOnce——相应的volume可以以可读可写的形式被挂载到一个node
ReadOnlyMany——相应的volume可以以只读的形式被挂载到多个node
ReadWriteMany——相应的volume可以以读写被挂载到多个node

vim pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
 name: pv1
spec:
 capacity:
  storage: 1Gi
 accessModes:
 - ReadWriteMany
 nfs:
  path: /ken3
  server: 192.168.27.30
  
kubectl apply -f pv.yaml
kubectl get pv     #只有状态为available时才能申请pvc

编写yaml文件申请pvc
vim pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pvc1
spec:
 volumeName: pv1
 accessModes:
 - ReadWriteMany
 resources:
  requests:
   storage: 1Gi
kubectl apply -f pvc.yaml

kubectl get pv   #状态为bond
kubectl get pvc   #状态为bond

然后在创建pod的时候使用pvc1
vim nginx.yaml

apiVersion:apps/v1
kind: Deployment
metadata:
 name: nginx2
spec:
 replicas: 2
 template:
  metadata:
   lables:
    run: nginx
  spec:
   containers:
   - name: nginx
     image: nginx
     iamgePullPolicy: IfNotPresent
     volumeMounts:
     - name: nginx
       mountPath: /usr/share/nginx/html    #容器的目录
   volumes:
   - name: nginx
     persistentVolumeClaim:
    claimName: pvc1
---
apiVersion: v1
kind: Service
metadata:
 name: nginx-sve
spec:
 selector:
  run: nginx
 type:NodePort
 ports:
 - port:80
   targetPort:80
   nodePort:30008
    
kubectl apply -f nginx.yaml

kubectl get po   #找到pod并进入pod
kubectl exec -it nginx2-sdhoga21gw-ehr12 bash
然后写入一些内容,如果权限被拒绝了,那么就修改nfs的共享目录/ken3的属主属组为nfsnobody即可。

删除pv和pvc
pv的状态为available的时候才可用。
kubectl delete -f nginx.yaml
kubectl delete -f pvc.yaml
kubectl get pv    #此时的状态为released,这个状态实际上不能申请pvc
kubectl delete -f pv.yaml
kubectl apply -f pv.yaml
kubectl get pv    #此时的状态为available,可以申请pvc
然后再进入nfs共享目录/ken3,发现以前写入pod的数据被保存了下来,实现了数据的持久化。

原文地址:https://www.cnblogs.com/getbird/p/11665757.html

时间: 2024-08-30 17:03:59

Kubernetes——滚动更新和数据管理的相关文章

kubernetes 滚动更新

示例: 创建一个app:kubectl create deployment nginx --image=nginx:1.11 创建service kubectl expose deployment nginx --port=80 --type=NodePort 扩缩容:kubectl scale deployment nginx --replicas=5 修改镜像,滚动更新:kubectl set image deployment nginx nginx=nginx:1.10 或者kubectl

kubernetes 滚动更新发布及回滚

基本命令 记录历史 --record kubectl  apply -f **** --record 查看当前状态 kubectl rollout status deployment/demo -w 查看历史 kubectl rollout history deployment/demo 回滚到指定版本 kubectl rollout undo deployment/demo --to-revision=2 原文地址:https://www.cnblogs.com/zhangeamon/p/82

Kubernetes集群中Service的滚动更新

Kubernetes集群中Service的滚动更新 二月 9, 2017 0 条评论 在移动互联网时代,消费者的消费行为已经"全天候化",为此,商家的业务系统也要保持7×24小时不间断地提供服务以满足消费者的需求.很难想像如今还会有以"中断业务"为前提的服务系统更新升级.如果微信官方发布公告说:每周六晚23:00~次日凌晨2:00进行例行系统升级,不能提供服务,作为用户的你会怎么想.怎么做呢?因此,各个平台在最初设计时就要考虑到服务的更新升级问题,部署在Kubern

Kubernetes Pod应用的滚动更新(八)

一.环境准备 我们紧接上一节的环境,进行下面的操作,如果不清楚的,可以先查看上一篇博文. 滚动更新是一次只更新一小部分副本,成功后,再更新更多的副本,最终完成所有副本的更新.滚动更新的最大的好处是零停机,整个更新过程始终有副本在运行,从而保证了业务的连续性. 二.更新 我们查看一下上一节的配置文件mytest-deploy.yaml. apiVersion: extensions/v1beta1 kind: Deployment metadata: name: mytest spec: repl

kubernetes学习(一) Scale应用 & 滚动更新

一.Scale应用 默认请款下应用只会运行一个副本,可通过kubectl get deployments 查看副本数. ~$ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE blogtest 1 1 1 1 3d kubernetes-bootcamp 1 1 1 1 3d 1.使用scale增加pod数量 执行如下命令,可将副本数增加到3个. ~$ kubectl scale deployments/b

深入玩转K8S之智能化的业务弹性伸缩和滚动更新操作

在上篇我们讲到了较为傻瓜初级的弹性伸缩和滚动更新,那么接下来我们来看看较为高级的智能的滚动更新.本节的知识点呢是K8S的liveness和readiness探测,也就是说利用健康检查来做更为智能化的弹性扩容和滚动更新. 那为什么说是比较智能化呢,因为在实际生产环境中会遇到这样那样的问题,比如:容器里面应用挂了或者说新启动的容器里面应用还没有就绪等等,所以说就需要进行探测来检验容器是否满足需求. 那么一般的检测分为几种,比如:进程检测.业务检测. 进程检测呢很好理解,也就是说通过检测容器进程来验证

详细聊聊k8s deployment的滚动更新(二)

一.知识准备 ● 本文详细探索deployment在滚动更新时候的行为 ● 相关的参数介绍: ??livenessProbe:存活性探测.判断pod是否已经停止 ??readinessProbe:就绪性探测.判断pod是否能够提供正常服务 ??maxSurge:在滚动更新过程中最多可以存在的pod数 ??maxUnavailable:在滚动更新过程中最多不可用的pod数 二.环境准备 组件 版本 OS Ubuntu 18.04.1 LTS docker 18.06.0-ce 三.准备镜像.yam

Log4j2中RollingFile的文件滚动更新机制

一.什么是RollingFile RollingFileAppender是Log4j2中的一种能够实现日志文件滚动更新(rollover)的Appender. rollover的意思是当满足一定条件(如文件达到了指定的大小,达到了指定的时间)后,就重命名原日志文件进行归档,并生成新的日志文件用于log写入.如果还设置了一定时间内允许归档的日志文件的最大数量,将对过旧的日志文件进行删除操作. RollingFile实现日志文件滚动更新,依赖于TriggeringPolicy和RolloverStr

如何滚动更新 Service?- 每天5分钟玩转 Docker 容器技术(102)

在前面的实验中,我们部署了多个副本的服务,本节将讨论如何滚动更新每一个副本. 滚动更新降低了应用更新的风险,如果某个副本更新失败,整个更新将暂停,其他副本则可以继续提供服务.同时,在更新的过程中,总是有副本在运行的,因此也保证了业务的连续性. 下面我们将部署三副本的服务,镜像使用 httpd:2.2.31,然后将其更新到 httpd:2.2.32. 创建服务: docker service create --name my_web --replicas=3 httpd:2.2.31 将 serv