• k8s相关的概念


    1.1 K8S YAML文件详解

    K8S Yaml 配置文件主要分为:基本标签、元数据标签、资源内容 三个部分,要想对K8S熟练的掌握,必须要了解YAML配置文件中常见的参数和指令的含义。
    1)基本标签主要是在文件起始位置,例如:

    apiVersion: v1 #版本号,例如v1;
    kind: Namespace #类型或者控制器;
    
    • 1
    • 2

    2)元数据标签主要是在文件中部位置,例如:

    metadata:    #数据标签
      name: nginx-deployment
      labels:		 #子标签
        app: nginx	#业务容器
    
    • 1
    • 2
    • 3
    • 4

    3)资源内容主要是在文件末尾位置,例如:

    spec:         #Pod中容器的详细定义
      containers:      #Pod中容器列表
      - name: nginx     #容器名称
        image: nginx    #容器的镜像名称
        imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像,否则下载镜像,Nerver表示仅使用本地镜像
        command: nginx    #容器的启动命令列表,如不指定,使用打包时使用的启动命令
        args: -g daemon off     #容器的启动命令参数列表
        workingDir: /root/     #容器的工作目录
        volumeMounts:    #挂载到容器内部的存储卷配置
        - name: nginx     #引用pod定义的共享存储卷的名称,需用volumes[]部分定义的的卷名
          mountPath: /usr/share/nginx/html    #存储卷在容器内mount的绝对路径
          readOnly: boolean    #是否为只读模式
        ports:       #需要暴露的端口库号列表
        - name: nginx     #端口号名称
          containerPort: 80   #容器需要监听的端口号
          hostPort: 80    #容器所在主机需要监听的端口号,默认与Container相同
          protocol: TCP     #端口协议,支持TCP和UDP,默认TCP
        env:       #容器运行前需设置的环境变量列表
        - name: WEB     #环境变量名称
          value: www.jfedu.net    #环境变量的值
        resources:       #资源限制和请求的设置
          limits:      #资源限制的设置
            cpu: 1000m    #Cpu的限制,单位为core数,将用于docker run --cpu-shares参数
            memory: 1024m     #内存限制,单位可以为Mib/Gib,将用于docker run --memory参数
          requests:      #资源请求的设置
            cpu: 100m    #Cpu请求,容器启动的初始可用数量
            memory: 1024m     #内存清楚,容器启动的初始可用数量
        livenessProbe:     #对Pod内个容器健康检查的设置,当探测无响应几次后将自动重启该容器,检查方法有exec、httpGet和tcpSocket,对一个容器只需设置其中一种方法即可
          exec:      #对Pod容器内检查方式设置为exec方式
            command: [string]  #exec方式需要制定的命令或脚本
          httpGet:       #对Pod内个容器健康检查方法设置为HttpGet,需要制定Path、port
            path: string
            port: number
            host: string
            scheme: string
            HttpHeaders:
            - name: string
              value: string
          tcpSocket:     #对Pod内个容器健康检查方式设置为tcpSocket方式
             port: number
           initialDelaySeconds: 0  #容器启动完成后首次探测的时间,单位为秒
           timeoutSeconds: 0   #对容器健康检查探测等待响应的超时时间,单位秒,默认1秒
           periodSeconds: 0    #对容器监控检查的定期探测时间设置,单位秒,默认10秒一次
           successThreshold: 0
           failureThreshold: 0
           securityContext:
             privileged:false
        restartPolicy: [Always | Never | OnFailure]#Pod的重启策略,Always表示一旦不管以何种方式终止运行,kubelet都将重启,OnFailure表示只有Pod以非0退出码退出才重启,Nerver表示不再重启该Pod
        nodeSelector: obeject  #设置NodeSelector表示将该Pod调度到包含这个label的node上,以key:value的格式指定
        imagePullSecrets:    #Pull镜像时使用的secret名称,以key:secretkey格式指定
        - name: string
        hostNetwork:false      #是否使用主机网络模式,默认为false,如果设置为true,表示使用宿主机网络
        volumes:       #在该pod上定义共享存储卷列表
        - name: string     #共享存储卷名称 (volumes类型有很多种)
          emptyDir: {}     #类型为emtyDir的存储卷,与Pod同生命周期的一个临时目录。为空值
          hostPath: string     #类型为hostPath的存储卷,表示挂载Pod所在宿主机的目录
            path: string     #Pod所在宿主机的目录,将被用于同期中mount的目录
          secret:      #类型为secret的存储卷,挂载集群与定义的secre对象到容器内部
            scretname: string  
            items:     
            - key: string
              path: string
          configMap:     #类型为configMap的存储卷,挂载预定义的configMap对象到容器内部
            name: string
            items:
            - key: string
              path: string
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54
    • 55
    • 56
    • 57
    • 58
    • 59
    • 60
    • 61
    • 62
    • 63
    • 64
    • 65
    • 66
    • 67

    1.2 Kubectl常见指令操作

    K8S云计算平台部署&创建完成后,可以通过Kubeclt指令,查看Pods和Service的详细信息:

    #查看K8S集群所有的节点信息;
    kubectl get nodes
    #删除K8S集群中某个特定节点;
    kubectl delete nodes/10.0.0.123
    #获取K8S集群命名空间;
    kubectl  get  namespace
    #获取K8S所有命名空间的有哪些部署;
    kubectl  get  deployment --all-namespaces
    #查看Nginx部署详细的信息;
    kubectl describe deployments/nginx -n default
    #将Nginx部署的镜像更新至Nginx1.19版本;
    kubectl -n default set image deployments/nginx nginx=nginx:v1.19
    #将Nginx部署的POD组容器副本数调整为3个;
    kubectl patch deployment nginx -p '{"spec":{"replicas":3}}' -n default
    #获取Nginx 部署的yaml配置,输出到nginx.yaml文件;
    kubectl get deploy nginx -o yaml --export >nginx.yaml
    #修改nginx.yaml文件,重新应用现有的nginx部署;
    kubectl apply -f nginx.yaml
    #获取所有命名空间的详细信息、VIP、运行时间等;
    kubectl  get  svc  --all-namespaces
    #获取所有pod所属的命名空间;
    kubectl  get  pods  --all-namespaces
    #获取所有命名空间Pod详细IP信息;
    kubectl get pods -o wide --all-namespaces
    #查看dashboard服务详细信息;
    kubectl  describe  service/kubernetes-dashboard  --namespace="kube-system"
    #获取dashboard容器详细信息;
    kubectl  describe  pod/kubernetes-dashboard-530803917-816df --namespace="kube-system"
    #强制删除dashboard容器资源;
    kubectl  delete pod/kubernetes-dashboard-530803917-816df --namespace="kube-system" --grace-period=0 --force
    #强制删除一个Node上面所有的容器、服务、部署,不再接受新的pod进程资源创建;
    kubectl drain 10.0.0.122 --force --ignore-daemonsets --delete-local-data
    #恢复Node上接受新的pod进程资源创建;
    kubectl uncordon 10.0.0.122
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34

    在这里插入图片描述
    在这里插入图片描述
    通过google浏览器访问:http://10.0.0.122:8080/如图所示:
    在这里插入图片描述
    然后访问:http://10.0.0.122:8080/ui/,如图所示:
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    3. K8S开启IPVS模块

    早期的kubernetes版本kube-proxy采用的是netfilter模块方式实现Service服务转发和代理。Kubernetes从1.8.版本开始,kube-proxy正式引入了IPVS模式,IPVS模式与iptables同样基于netfilter框架。

    Ipvs是采用的hash表,当Service数量达到一定规模时hash查表的速度优势就会显现出来了,从而提高Service转发性能。

    1)修改Kube-proxy的configmap,在config.conf中找到mode参数,改为mode: “ipvs”。操作方法和指令如下:

    kubectl -n kube-system get cm kube-proxy -o yaml | sed 's/mode: ""/mode: "ipvs"/g' | kubectl replace -f - 
    #或者手动修改
    kubectl -n kube-system edit cm kube-proxy
    kubectl -n kube-system get cm kube-proxy -o yaml | grep mode
        mode: "ipvs"
    #重启kube-proxy pod        
    kubectl -n kube-system delete pods -l k8s-app=kube-proxy
    #确认ipvs模式开启成功
    kubectl -n kube-system logs -f -l k8s-app=kube-proxy | grep ipvs
    日志中打印出Using ipvs Proxier,说明ipvs模式已经开启。
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10

    2)修改完成之后,可以通过ipvsadm工具来查看Service转发后端的Pods容器列表信息,如下:
    ipvsadm -L -n
    在这里插入图片描述

    4. Kubernetes 容器升级概念

    传统的网站升级更新,通常是将服务全部下线,业务停止后再更新版本和配置,然后重新启动并提供服务。这样的模式已经完全不能满足发展需求了。

    高并发、高可用系统普及的今天,服务的升级更新至少要做到“业务不中断”。而滚动更新(Rolling-update)恰是满足这一需求的一种系统更新升级方案。

    滚动更新就是针对多实例服务的一种不中断服务的更新升级方式。一般情况,对于多实例服务,滚动更新采用对各个实例逐个进行单独更新而非同一时刻对所有实例进行全部更新的方式。

    对于Kubernetes集群部署的Service来说,Rolling update就是指一次仅更新一个Pod,然后逐个进行更新,而不是在同一时刻将该Service下面的所有Pod shutdown,然后去更新,逐个更新可以避免将业务中断;
    kubernetes在kubectl cli工具中仅提供了对Replication Controller的rolling-update支持,通过kubectl -help查看指令信息;
    在这里插入图片描述

    5. Kubernetes 容器升级实战

    1)查看部署列表,获取部署应用名称;

    kubectl get deployments -n default
    
    • 1

    在这里插入图片描述
    2)查看正在运行的pod;

    kubectl get pods -n default
    
    • 1

    在这里插入图片描述

    3)通过pod描述,查看部署程序的当前映像版本;

    kubectl describe pods -n default
    
    • 1

    在这里插入图片描述
    4)仓库源中提前制作最新更新的镜像,执行如下指令,升级镜像版本即可;(升级之前一定要保证仓库源中有最新提交的镜像)

    kubectl -n default set image deployments/nginx-v1 nginx-v1=docker.io/nginx:v1
    
    • 1

    在这里插入图片描述

    6. Kubernetes 容器升级测试

    1)Nginx原始容器列表;
    在这里插入图片描述
    在这里插入图片描述
    2)更新完成之后,Nginx容器列表如下:
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    7 Kubernetes 容器升级验证

    1)检查K8s更新rollout状态;
    kubectl -n default rollout status deployments/nginx-v1
    在这里插入图片描述
    2)检查pod详情;

    kubectl describe pods -n default
    
    • 1

    在这里插入图片描述
    在这里插入图片描述

    8 Kubernetes 容器升级回滚

    1)K8S容器回滚指令如下;

    kubectl -n default rollout undo deployments/nginx-v1
    
    • 1

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    2)查看已经部署的版本;

    kubectl rollout history deploy/nginx-v1
    
    • 1

    在这里插入图片描述
    3)查看某个版本详细信息;

    kubectl rollout history deployment/nginx-v1 --revision=8
    
    • 1

    在这里插入图片描述
    4)k8s完美支持回滚至某个版本,并且还可以通过资源文件进行配置保留的历史版次量。K8S回滚某个版本命令如下:
    kubectl -n default rollout undo deployment/nginx-v1 --to-revision=8
    在这里插入图片描述
    在这里插入图片描述
    k8s精确地控制着整个发布过程,分批次有序地进行着滚动更新,直到把所有旧的副本全部更新到新版本。实际上k8s是通过两个参数来精确地控制着每次滚动的pod数量:

    • maxSurge ,滚动更新过程中运行操作期望副本数的最大pod数,可以为绝对数值(eg:5),但不能为0,也可以为百分数(eg:10%),默认为25%;
    • maxUnavailable ,滚动更新过程中不可用的最大pod数,可以为绝对数值(eg:5),但不能为0,也可以为百分数(eg:10%),默认为25%;
    • 如果未指定这两个可选参数,则k8s会使用默认配置,查找默认配置指令如下:
    kubectl -n default get deployment nginx-v1 -o yaml
    
    • 1

    在这里插入图片描述
    在这里插入图片描述
    1)查看剖析部署概况;
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    • DESIRED 最终期望处于READY状态的副本数;
    • CURRENT 当前的副本总数;
    • UP-TO-DATE 当前完成更新的副本数;
    • AVAILABLE 当前可用的副本数;
      2)查看部署的信息效果;
    kubectl -n default describe deployment nginx-v1
    
    • 1

    在这里插入图片描述

    3)整个滚动过程是通过控制两个副本集来完成的;

    • 新副本集:nginx-v1-224846633;
    • 旧副本集:nginx-v1-44819141;
      在这里插入图片描述
      4)理想状态下的滚动过程;
    • 创建了一个新的副本集,并为其分配3个新版本的pod,使副本总数达到11,一切正常。
    • 通知旧副本集,销毁2个旧版本的pod,使可用副本总数保持到8,一起正常。
    • 当两个副本销毁成功后,通知新副本集,再新增2个新版本的pod,使副本总数达到11,一切正常。
    • 只要销毁成功,新副本集就会创造新的pod,一直循环,直到旧的副本集pod数量为0。
      5)滚动升级一个服务,实际是创建一个新的RS,然后逐渐将新RS中副本数增加到理想状态,将旧RS中的副本数减小到0的复合操作;

    无论理想还是不理想,k8s最终都会使应用程序全部更新到期望状态,都会始终保持最大的副本总数和可用副本总数的不变性。

  • 相关阅读:
    CentOS 使用线程库Pthread 库
    以小窥大:IO 卡顿探寻文件系统
    如何查看硬盘对应的主板接口属性
    移动和pc端的微信支付和支付宝支付(持续更新)
    使用python生成文字视频
    剑指 Offer 68 - 二叉树的最近公共祖先
    selenium+python web自动化测试框架项目实战实例教程
    react_13
    代码随想录动态规划——编辑距离
    Gateway 接口参数加解密
  • 原文地址:https://blog.csdn.net/weixin_44681349/article/details/133787064