一文带你了解K8S 容器编排（上）

K8S目前是业界容器编排领域的事实标准，是几乎所有云原生架构的首选。目前随着云原生架构越来越流行，测试开发人员需要掌握K8S技术栈已经成为越来越迫切的需求。

Kubernetes 开源于 2014 年，是谷歌 10 多年大规模容器管理系统 Borg 的开源版本。Kubernetes 这个单词在首字母 K 和尾字母 s 之间有 8 个字母，因此称为 K8S。这种称谓方式和 i18n（internationalization）是一致的，如果做过本地化国际化的人应该对 i18n 这样的叫法很熟悉。对于一个刚刚接触容器的初学者来说，搞清楚容器编排是什么，搞清楚 K8S 是什么是一件非常不容易的事情，编排二字赋予了它非常多的意义。

大多数人理解 K8S 是容器集群的管理技术，这个描述是不完整的，如果 K8S 仅仅是一个管理多台节点上容器的管理软件的话，那么业界直接称呼为容器集群就好了。而不是像现在这样称其为容器编排领域的事实标准，谷歌和 Linux 也不会为了它一起创办了 CNCF 云原生基金会。所以 K8S 除了是一个容器集群管理软件外它还提供了针对容器的网络，调度，权限，资源，安全，硬件等管理和设计的能力。 接下来通过 2 个案例来带大家体验一下其中的奥妙。

01

在实际介绍 K8S 的容器编排实例前需要先了解一下 K8S 中最基本的资源类型－－POD。可以说 POD 是 K8S 中最重要的资源，其他一切的资源都是围绕着 POD 并为其提供服务的。用一句话说明 POD 的定义：POD 是由多个容器组成的逻辑概念，这些容器共同配合对外提供服务， 同时 POD 也是 K8S 中最小的调度单位，POD 中的容器必须调度在同一台机器上不可分割。这么说比较抽象，用一个实例来展示一下 POD 到底是什么。通过下载并配置 jenkins 中 K8S 的插件来打通两者之间的通信，使得 jenkins 在运行 pipeline 时可以动态的在 K8S 中创建 POD 并在其中一个容器中通过 jnlp 动态的创建并向 jenkins 注册 slave 节点（容器）， 后续这个 pipeline 中所有的任务都将在这个 POD 中的容器中执行。通过这样的机制实现了更强大的 jenkins pipeline 的高可用和负载均衡架构。从此实现了在 K8S 中可以动态创建 jenkins 的 slave 节点运行任务的能力， 并在任务结束后回收这些资源。

yaml
apiVersion: "v1"
kind: "Pod"
metadata:
  name: "sdk-test-109-hpf67-tr47k-95sch"
spec:
  containers:
  - command:
    - "cat"
    image: "registry.gaofei.com/qa/python3"
    name: "python3"
    tty: true
    volumeMounts:
    - mountPath: "/home/jenkins/agent"
      name: "workspace-volume"
      readOnly: false
    image: "registry.gaofei.com/tester_jenkins_slave:v1"
    name: "jnlp"
    volumeMounts:
    - mountPath: "/home/jenkins/agent"
      name: "workspace-volume"
      readOnly: false
  volumes:
  - emptyDir:
      medium: ""
    name: "workspace-volume"

上面是 jenkins 动态创建 POD 的配置文件，这其中为了更方便说明我删除了很多其他干扰项，只留下了最需要关注的部分。可以看到 containers 字段中定义两个容器。其中名字为 jnlp 的容器是由 jenkins 提供用来与 jenkins 建立通信并注册 slave 节点用的。对 jenkins slave 节点配置比较熟悉的人对此应该并不陌生，除了 jnlp 外 jenkins 还支持 ssh 等协议形式的 slave 通信机制。

另外一个名字为 python3 的容器使用的就是官方提供的 python3 镜像，它的任务是用来执行测试任务。也就是说在这个 POD 中分工是明确的，jnlp 容器负责注册 jenkins slave 节点并与之保持通信。而 python3 容器拥有 python 的执行环境所以可以在获取代码后运行诸如 pytest 这样的测试任务。实际上如果需要可以定义更多的容器，比如要测试一款 python sdk 的兼容性的时候， 可以再定义一个 python2.6 的容器，这样在 pipeline 中可以通过切换不同的容器达到切换运行环境的目的以便测试 sdk 在 python3 和 python2 上的兼容性。

下面我贴一下 jenkins pipeline 中的定义，还是照例删减了其他干扰项。

groovy
pipeline{
    parameters {
        choice(name: 'PLATFORM_FILTER', choices: ['python352', 'python368', 'python376','all'], description: '选择测试的 python 版本')
    }
    agent{
        kubernetes{
            yaml """
            apiVersion: v1
            kind: Pod
            metadata:
              labels:
                qa: python3
            spec:
              containers:
              - name: python352
                image: python:3.5.2
                command:
                - cat
                tty: true
              - name: python368
                image: python:3.6.8
                command:
                - cat
                tty: true
              - name: python376
                image: python:3.7.6
                command:
                - cat
                tty: true
              - name: jnlp
                image: registry.gaofie.com/tester_jenkins_slave:v1
            """
        }
    }
    stages{
        stage('sdk 兼容性测试'){
            matrix {
                when { anyOf {
                    expression { params.PLATFORM_FILTER == 'all' }
                } }
                axes {
                    axis {
                        name 'PLATFORM'
                        values 'python352', 'python368','python376'


                    }
                }
                stages{
                    stage('兼容性测试开始 '){
                        steps{
                          container("${PLATFORM}"){
                              echo "Testing planform ${PLATFORM}"
                              sh """
                              pip3 install -i http://pypi.xxx.com/4paradigm/dev/ --trusted-host pypi.xxx.com 'sdk[builtin-operators]'
                              pip3 install -r requirements.txt
                              cd test
                              python3 -m pytest -n 5
                              """
                          }
                        }
                    }
                }
            }


        }
    }
}

通过上面的 Pipeline 的配置可以看到通过 container 指令，可以在 pipeline 中任意的切换容器（运行环境）来完成 Python 的兼容性测试。这里可能有人可能会问运行环境可以通过切换容器来完成，但是各个容器之间是怎么共享文件和代码的呢？毕竟要执行测试必须先获取代码， 那这些容器是怎么获取代码执行测试的，又是通过什么方式合并每个容器中的测试报告的呢？这个问题可以抽象成一个 POD 中的容器是怎么共享文件的。在学习 Docker 的时候知道在启动容器的时候可以通过-v 这个参数来将容器中的某个目录或文件挂载到宿主机上， 而在 POD 中的玩法也类似。回到上面 Jenkins 启动的 POD 的定义中来：

yaml
    image: "registry.gaofei.com/tester_jenkins_slave:v1"
    name: "jnlp"
    volumeMounts:
    - mountPath: "/home/jenkins/agent"
      name: "workspace-volume"
      readOnly: false
  volumes:
  - emptyDir:
      medium: ""
    name: "workspace-volume"

上面是 POD 中关于数据卷的一段定义， 可以看到 jenkins 创建的 POD 定义中自动添加了一个临时的共享目录，而 POD 中所有的容器都会挂载这个目录。通过这样的形式达到了所有容器共享文件的目的。
而这个目录就是 Jenkins 的 Workspace。相信熟悉 Jenkins 的人对此目录不会感到陌生。

mpdir.jpg 'tempdir')

实际上多个容器间的合作不仅可以共享目录，也可以共享网络或者进程名称空间。还记得学习 Docker 的时候使用的 container 网络模式么， 实际上 POD 中的容器都是默认通过 container 模式将网络连接在一起的，很多软件应用比如 mock server，流量复制，service mesh 都是通过在 POD 中额外定义一个 proxy 容器劫持业务容器的网络。

而如果你想使用 jvm-sandbox 这种字节码注入工具的话还可以通过打开 POD 中 shareProcessNamespace 这个参数来共享进程名称空间，使得 jvm-sandbox 容器中可以看到业务容器的进程并以 jvm-attach 的方式进行字节码注入。而这种通过启动多个容器互相协作配合的玩法有一个专业名词叫"side car"。
所以回过头来看看什么是 POD，什么是容器编排？从这里的角度看 POD 是容器之间的一种协作模式，多个容器组成一个 POD，而一个 POD 提供了多种机制，包括但不限于共享和限制目录，网络，进程，资源等机制来让容器之间的协作更加顺畅， 而这也是容器编排的表现之一， 不仅仅是运行， 而是多个容器配合在一起更好的运行。

希望通过这篇文章，你能对K8S容器编排了有了初步的了解，在下篇文章中，我们将通过介绍 K8S 中专门运行批处理程序的资源类型：JOB 的机制再来体会一下容器编排在其他方面的威力。