DevOps CI/CD 分析(三)之K8S yaml模版配置详解

前面我们讲解了Dockerfile基础命令、编写Dockerfile，因为整个DevOps CI/CD过程所涉及的知识面比较多，所以本节我们则开始总结Kubernetes(K8S) yaml模版配置，当我们比较熟悉Kubernetes(K8S) yaml模版内容时候，那最终在编写gitlab-ci.yml文件时候就游刃有余了！

---

Kubernetes Service&Deployment

# 版本号
apiVersion: v1
# Kubernetes资源类型，服务类型
kind: Service
# 元数据
metadata:
  # 该资源Service类型的名称
  name: {{.appName}}
  # 该资源Service所属的命名空间
  namespace: {{.namespace}}
  # 自定义的标签列表,key-value键值对
  labels:
    app: {{.appName}}
# 该Service资源详细定义
spec:
  #该Service访问的类型，NodePort类型可以对外暴露，让外部访问这个集群
  type: NodePort
  # 该Service对外暴露的端口列表
  ports:
  # Service服务监听的端口，Service在集群内部暴露的端口
  - port: 80
    # 端口名称/标示类型
    name: http
    # 需要转发到pod的端口号，需要与容器监听端口一致，不然会导致访问不到
    # 它用来确定提供该服务的容器所暴露的端口号，即具体业务的进程在容器内的targetPort上提供TCP/IP
    # 内部端口映射到Pod暴露出的端口
    targetPort: {{.contrainerPort}}
    # 对外暴露的端口号，如果不指定则随机生成一个端口号
    nodePort: {{.nodePort}}
  # 标签选择器配置，将具有以下标签的Pod都归属于当前Service管理
  selector:
    #指定label中app: {{.appName}}的Pod归属于当前Service
    app: {{.appName}}
#这个代表一个yaml模版配置中包含多个Kubernetes资源类型，所以用 --- 进行分割
#kind: Deployment、kind: Service ......
---
#版本号，可以通过 kubectl api-versions 命令进行获取当前支持的版本
apiVersion: extensions/v1beta1
#Kubernetes资源类型，部署应用类型，为ReplicaSet和Pod的创建提供一种声明式的定义方法
#无需手动创建ReplicaSet/Replication Controller和Pod，使用Deployment支持滚动升级和回滚等特性
kind: Deployment
#该资源元数据
metadata:
  #该资源名称，决定了Pod的显示名称
  name: {{.appName}}
  #该资源所属的命名空间
  namespace: {{.namespace}}
#该资源的详细定义
spec:
  # 指定运行的Pod数量，它会根据selector来进行选择，会将选择到的Pod维持在{{.replicas}}个的数目量
  replicas: {{.replicas}}
  # 主要用于滚动升级Deployment，Kubernetes在等待设置的时间后才进行升级
  # 如果没有设置该值，Kubernetes会认为该容器启动起来后就提供服务了
  # 所以需要设置一个间隔时间，用来指定Pod可用状态的最小秒数
  minReadySeconds: {{.minReadySeconds}}
  # 更新策略/升级策略
  # 指定新Pod替换旧Pod的策略，type为rollingUpdate为使用滚动更新的方式更新Pod
  strategy:
    #默认为滚动升级
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2             # 滚动升级中，容器副本的最大数量，运行比replicas总共多多少个 pod
      maxUnavailable: 1       # 滚动升级中，允许的最大不可用的pod个数
  # set类型的选择器
  # 还有一个matchExpressions
  # 类似下面的配置方式
  # matchExpressions:
  #   - {key: app, operator: In, value: [nginx]}
  # 指明哪个pod被管理，这里我们指定了app: {{.appName}}
  selector:
    matchLabels:
      app: {{.appName}}
  # 扩容时创建Pod的模板
  template:
    #元数据
    metadata:
      #标签列表
      labels:
        app: {{.appName}}
        version: "{{.version}}"
    spec:
      # K8S将会给应用发送SIGTERM信号，用来优雅地关闭应用,默认为30秒
      terminationGracePeriodSeconds: 30 
      #优先级最高，先于其他容器启动，主要做一些初始化配置工作
      initContainers:
        - name: skywalking-agent
          command:
            - cp
            - '-r'
            - /skywalking/agent/
            - /data/agents/skywalking/
      # pod中的容器列表
      containers:
      # 容器名称
      - name: {{.appName}}
        # 容器镜像名称
        image: {{.image}}:{{.version}}
        # 获取镜像的策略，其中有Always,IfNotPresent,Never
        # Always=>每次都会重新下载镜像
        # IfNotPresent=>如果本地又镜像则使用，否则下载镜像
        # Never=>仅使用本地镜像
        imagePullPolicy: IfNotPresent
        # 容器启动命令列表，不指定会使用镜像打包时的启动命令
        command: ["java", "-jar", "-Xms{{.request_memory}}m", "-Xmx{{.limit_memory}}m", "server.jar"]
        # 容器启动命令时的参数列表
        args: ["--spring.profiles.active={{.env}}"]
        # 资源限制和资源请求的设置
        resources:
          # 通常我们会把request设置为一个比较小的数值，这个值根据项目情况而定，需求限制，也叫软限制
          requests:
            memory: {{.request_memory}}Mi
          #最大限制，也叫硬限制，通常requests和limits要一起配置，避免资源使用不合理出现问题
          limits:
            memory: {{.limit_memory}}Mi
        # 对Pod内容器健康检查的设置，当探测几次无反应后，将会自动重启该容器
        # livessProbe: 用于判断容器是否存活(running)，如果livessProbe探针探测到不健康，则kubelet会杀掉该容器，并根据容器的重启策略做相应的处理，不配置的话K8S会认为一直是Success
        # 其中有exec、httpGet、tcpSocket这3种配置
        # exec: 在容器内部执行一个命令，如果该命令返回码为0，则表明容器健康
        # httpGet: 通过容器的IP地址、端口号及路径通过用httpGet方法，如果响应的状态码stateCode大于等于200且小于400则认为容器健康
        # tcpSocket: 通过容器的IP地址和端口执行tcpSocket检查，如果能够建立tcpSocket连接，则表明容器健康
        # 判断是否存活，不存活则重启容器
        livenessProbe: 
          httpGet:
            # 健康检查路径，也就是应用的健康检查路径
            path: {{.checkHealthPath}}
            # 端口号
            port: {{.contrainerPort}}
            scheme: HTTP
          # 容器首次启动后首次进行健康检查的时间，秒/单位
          initialDelaySeconds: 60
          # 对容器健康检查等待响应时间的超时时间设置
          timeoutSeconds: 5
          # 将康检查成功后，最少连续将康检查成功多少次才被认定成功
          successThreshold: 1
          # 将康检查失败后，最少连续将康检查失败多少次才被认定为失败
          failureThreshold: 5
        # redinessProbe: 用于判断容器是否启动完成（ready），可以接收请求，如果该探针探测到失败，则Pod状态会被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器的所在Pod的Endpoint
        # kubernetes 判断容器是否启动成功,否可以接受外部流量
        readinessProbe: 
          httpGet:
            # 健康检查路径，也就是应用的健康检查路径
            path: {{.checkHealthPath}}
            # 端口号
            port: {{.contrainerPort}}
            scheme: HTTP
          #容器启动后第一次执行探测是需要等待多少秒
          initialDelaySeconds: 30
          #探测超时时间，默认1秒，最小1秒。
          timeoutSeconds: 5
          #最少连续成功次数之后才为成功
          successThreshold: 1
          #最少连续失败次数之后才为失败
          failureThreshold: 5
        # 容器需要暴露的端口号列表
        ports:
        # 端口的名称
        - name: http
          # 容器需要监听的端口
          containerPort: {{.contrainerPort}}
      # pull镜像时使用的secret名称，以name:secretkey格式指定
      imagePullSecrets:
      - name: {{.registry}}

通过代码块，可以看出整个模版配置是比较复杂的，可以结合着注释信息来看各个配置的作用，其中在代码块中，也许会看到很多诸如这样的写法{{.appName}} 这样的写法是用了GoLang中的模版语法，因为我们替换模版配置也是基于GoLang现有的模版库。GoLang实现的模版库会放到后续的章节进行讲解，大家也可以在网上搜索GoLang Yaml模版解析库，自己实现也行。

---

扩展事项

本节我们的K8S yaml模版是基于Kubernetes Service这个资源来进行的总结，该Service访问的类型有ClusterIP、NodePort、LoadBalancer等类型，默认的为ClusterIP类型

1. ClusterIP：只能通过集群的内部 IP 暴露服务，服务只能够在集群内部可以访问
2. NodePort：通过每个Node节点上的IP与静态端口spec. nodePort: {{.nodePort}} 暴露服务，NodePort服务会路由调用到ClusterIP服务,这样我们就可以对外提供服务了。
3. LoadBalancer：这个负载均衡服务基本我们不会涉及到，这个一般使用在诸如nginx-ingress-controller这样的容器组，本质也就是在NodePort的基础之上多了一步LoadBalancer过程，用户发起的请求会先到LoadBalancer，最终LoadBalancer会转发到NodePort服务。

当然我们在定义Kubernetes Service资源类型时候，一般都会配套定义Kubernetes Deployment资源类型，比如我们的网关项目。