十月 2017

CI/CD 工具链的分分合合

作案动机

一种对 ci/cd 工具的轻量化和解耦的尝试?

Jenkins 的传统集群方式,是使用不同环境的服务器构成不同能力的 Jenkins 节点,由主节点根据任务 环节的需要,调度不同能力的子节点来完成构建或部署任务。

进入容器云时代,情况发生了变化,我们可以使用不同能力的 Jenkins 镜像,使用 Kubernetes 插件来 完成这种任务的拆分和调度,为此,我构建了一个包含所有我们平时用到的工具的 Jenkins 镜像,简化了 节点的扩展和选择过程。

然而随着学习和应用的深入,我意识到这种做法有几个问题:

  • DevOps 中隐含着发挥个人能力的愿景,工具链的所谓大而全,只不过是在画一个比较大的圈,使用这样的 一套 Jenkins,还是要被其中所包含的仅有的工具中进行选择,对身陷其中的技术人员绝不能说是友好,也 绝不是鼓励各展所长的态度。

  • 现有的功能测试、接口测试、压力测试等工具,越来越专业化,往往会有各自的工作集群调度甚至是托管方案, 例如 selenium grid、JMeter 集群等。

非缺省域名下 Istio 的使用

Kubernetes 缺省的域名为 cluster.local,好死不死的,istio 的缺省安装也沿用了这一设定, 并且文档中并没有明确指出这一假设。Istio 中使用了大量的 FQDN 进行服务的甄别,域名不一致这样 的问题可以说是后患无穷。经过 101 号 issue 的讨论,得知 proxy 和 pilot 组件提供了域名的设置功能, 大致用法如下:

Pilot

kubectl edit deploy istio-pilot -n istio-system 或者编辑官方的 istio.yaml,查找 docker.io/istio/pilot:0.2.9 的容器,并在 args 一节中加入如下的两行:

Istio 的频率限制

本来这个应该是作为第三天“零散功能点”介绍的,结果目标规则部分遇到一个 bug 一直没得到修正,就拖 着了——然后后来发现自己这个想法挺无知的——零散的功能点非常多,非常大,而且文档非常弱,很难搞,只好 逐个介绍了。

简介

调用频率限制这个功能其实也是比较常见的东西了。这里就不多做介绍了。下面简单粗暴的介绍一下测试要完 成的目标。

测试中我们将使用两个服务,服务叫 workload,客户端叫 sleep,workload 服务正常返回群众喜闻乐见 的 “Hello World”,而 sleep 仅用来做 Shell 方便测试。

测试过程将为 workload 建立规则:

  • 对于任意访问,十秒钟之内仅能访问两次;
  • 对于来自 sleep 的访问,十秒钟之内仅能访问一次

下面所有内容都在 default 命名空间进行

建立测试环境

编辑 workload.yaml 以及 sleep.yaml 之后, 我们使用如下命令运行(这两部分源码,只有些乌七八糟的标签和命名有点问题,其他很普通。 见最后页)

Istio 0.2 发布:增强的 Service Mesh 以及多环境支持

在 2017 年 5 月 24 日,我们启动了 Istio —— 一个为微服务提供连接、监控和安全支持的平台。互联 网对我们投入了巨大的关注,开发、运维和合作伙伴的社区日益壮大,这一切让我们诚惶诚恐。0.1 版本 展示了 Kubernetes 环境下 Istio 的所有概念。

今天我们高兴的宣布 0.2 版,这一版本在稳定和性能方面有了增强,在 Kubernetes 中提供了全集群范围内 的部署和 Sidecar 的自动注入功能,为 TCP 提供了策略和认证支持,Service Mesh 的扩展能力进一步 覆盖到了虚拟机上。另外,Istio 现在可以在 Kubernetes 之外的环境运行,例如 Consul/Nomad 或者 Eureka。除了核心功能之外,Istio 还为第三方公司和个人提供了扩展开发的能力。

0.2 版本亮点

提高可用性

  • 多命名空间支持:响应 0.1 版本的用户呼声,Istio 可以在集群范围内的多个命名空间内运行。

  • TCP 服务的策略和安全支持:除了 HTTP 服务之外,我们为 TCP 服务加入了双向 TLS 认证以及 策略支持。这使得我们所提供的观测、策略以及安全能力能够覆盖到更多 Kubernetes 应用之中。