共计 3971 个字符，预计需要花费 10 分钟才能阅读完成。
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 的机制再来领会一下容器编排在其余方面的威力。