在业界容器编排的范畴当中, K8S当下属于事实标准, 它差不多是所有云原生架构的优先选择项。如今, 伴随云原生架构愈发流行起来, 对于测试开发人员而言, 掌握K8S技术栈已然变成了越发迫切的一种需求。始于2014年开源, 它是谷歌历经10多年的大规模容器管理系统Borg的开源版本, 这个单词在首字母K与尾字母s之间存在8个字母, 所以称作K8S, 这种称谓形式和i18n方式相同, 要是做过本地化国际化的人员应该对i18n此种叫法颇为熟悉, 对于刚接触容器的初学者而言, 弄清楚容器编排到底是什么, 弄清楚K8S究竟是什么是极为不容易的事, 编排两字赋予了它诸多意义。多数人认为K8S是管理容器集群的技术, 这样的描绘并不全面, 要是K8S仅仅是管理多台节点上容器的软件, 那业界直接叫容器集群就行, 而不会像当下称它为容器编排领域的事实标准谷歌和Linux也不会因它共同创办CNCF云原生基金会, 所以K8S除是容器集群管理软件外, 还具备针对容器的网络、调度、权限、资源、安全、硬件等方面管理及设计的能力。 接下来通过 2 个案例来带大家体验一下其中的奥妙。01在实际去介绍K8S的容器编排实例以前, 得先去了解一下K8S里最基本的资源类型------POD。能够讲POD是K8S里面最为重要的资源, 其他的所有资源都是围绕着POD并且为其去提供服务的。用一句话来阐明POD的定义: POD是那个由多个容器所组成的逻辑概念, 这些容器共同协作对外提供服务, 与此同时POD是K8S中最小的调度单位, POD中的那些容器必须调度在同一台机器之上, 不可开分割。最后句子还要标点符号。这样讲是比较抽象的呀, 咱呢要用一个实际事例去展示一下 POD 究竟是什么, 那就是通过下载以及进行配置, 在K8S里的插件去打通其间的通信, 进而让在运行的时候能够动态地于K8S中创建POD。并且在其中一个容器里借助jnlp动态地创建以及往注册 slave 节点容器, 后续此中所有的任务全都将会在这POD里的容器处执行。依靠这样子的机制达成了更为强大的高可用以及负载均衡架构。从此达成了在K8S里面能够进行动态创建的, 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上面呈现的, 是动态创建POD的配置文件, 在此当中, 为了能够更便利地阐释情况, 我将许多其他会产生干扰的项目予以删除, 仅仅保留了最为需要着重关注的内容部分。能够观察到, 字段之内定义了两个容器。其中, 名字是jnlp的那个容器, 是由给定内容提供, 用以与另一对象建立通信, 并且用于注册slave节点的。针对slave节点配置相当熟悉的那些人, 对于此情况应该并不会感到陌生, 除了jnlp之外, 它还支持像ssh这样协议形式的slave通信机制。有一个容器, 其另外一个名字是 , 所用的是官方供应的 镜像。它的职责在于去开展测试方面的任务。换句话讲就是, 在这个POD里, 分工是清晰明确的。jnlp容器承担的是注册 slave节点, 并且和其维持通信。而 容器具备 的执行环境, 因而在获取代码之后, 能够去运行像 这种类型的测试任务。事实上若有需求能够定义更多的容器, 比如说在要对一款 sdk 的兼容性做测试之际, 可以再去定义一个.6 的容器, 凭借此在当中能够借助切换不一样的容器达成转变运行环境的目标, 进而对 sdk 在特定条件和具体方面上的兼容性展开测试。下面我贴一下 中的定义还是照例删减了其他干扰项。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 } } } } } } } }经由上面所提及的配置能够瞧见, 借助指令, 能够于其中随意地切换容器运行环境以达成兼容性测试。于此或许有人会发问, 运行环境能够借助切换容器来达成, 然而各个容器之间究竟是怎样共享文件以及代码的? 毕竟要开展测试必然得先获取代码, 那么这些容器是怎样获取代码去执行测试的, 又是凭借何种方式合并每个容器里的测试报告的? 这个问题能够被抽象成一个POD中的容器是怎样共享文件的。学习之际, 晓得启动容器之时, 能够借由 -v 此参数, 把容器内的某一目录亦或是文件挂载至宿主机上, 并且在 POD 里的操作方式与之相仿。返回到上面所启动的 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里头关乎数据卷的一段定义, 能够看到, 在创建的POD定义之中会自动放入一个临时的共享目录, 并且POD内部所有的容器都将于此目录挂上, 借由如此这般的形式达成了所有容器共享文件的目的, 而且此目录即为所示的相应内容心里假定熟悉这块的人对于该目录肯定不会觉得陌生。mpdir.jpg ‘’)实际上, 多个容器之间的合作, 不但能够共享目录, 还能够共享网络, 又或者是共享进程名称空间。还记得学习之际所使用的网络模式吗? 实际上, POD 当中的容器都是默认借助该模式把网络连接起来的。许多软件应用诸如 mock、流量复制、mesh等, 都是通过在 POD里额外定义一个 proxy 容器来劫持业务容器的网络。如果你打算运用 jvm- 这种字节码注入工具的话, 还能够经由打开 POD 中 e 这个参数, 来共享进程名称空间, 致使 jvm- 容器当中能够瞧见业务容器的进程, 并且以 jvm- 的方式开展字节码注入。并且, 这种借助启动多个容器相互协作配合的玩法, 存在一个专业名词叫做side car。那么回过头去瞧瞧, 什么是 POD, 什么是容器编排? 从这里的视角瞧, POD 是容器相互间的一种协作样式, 多个容器构成一个 POD, 并且一个 POD 供给了多种机制, 包含但不限于共享以及限制目录、网络、进程、资源等机制, 借此让容器相互间的协作更为顺畅, 而这同样是容器编排的表现之一, 并非仅仅是运行, 而是多个容器协同在一起更优地运行。期望借助这篇文章, 你能够对于K8S容器编排拥有了初步的认知, 并在下篇文章里头, 则是我们将会借助介绍K8S之中专门用以运行批处理程序的资源类型: JOB的机制再度去感受一番容器编排在其他领域的强大力量。