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 的机制再来体会一下容器编列在其他方面的威力。

获取更多相关材料：

qrcode.ceba.ceshiren.com/link?name=a…