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类型，实际上就是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——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的数据被保存了下来，实现了数据的持久化。