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

现今, K8S在业界容器编排范畴是实际的标准, 是差不多随便哪种云原生架构中首要选择的对象。当下, 鉴于云原生架构愈发流行起来, 对于测试开发人员而言去掌握K8S技术框架已然变成越发急切的需求了。

开端起始予于二零一四年, 它属于谷歌超十年大规模容器管理体系所拥有的开源版本, 此单词于首部字母K跟尾部字母s当中存在八个字母, 进而称其为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- 的形式开展字符编排注入。而这类借助启动多个容器相互搭配协作的玩法, 存在一个专门的称谓, 叫作"边车应用服务工作形态"。

因此把目光转回到什么是POD上来, 那什么又是容器编排呢? 从这个方位去瞧, POD属于容器之间的一种协作样式, 多个容器共同构成一个POD, 并且一个POD给出了好些机制, 涵盖但不限于像共享以及限制目录、网络、进程、资源等这般的机制, 继而促使容器之间的协作得以变得更顺畅些, 然而这同样也是容器编排的呈现之一, 并非仅是运行而已, 却是多个容器协同起来能更优质地运行。

想着凭借这篇文章，你能够对K8S容器编排获取到初始阶段的认知 , 于紧接着的篇章里 , 依靠解说K8S内供运运行批处理程序的资源种类: JOB的机理再去领会一番容器编排在别的层面的影响力。