Linkerd + Namerd,实现Kubernetes 集群的灰度发布
2017-02-07 10:36
811 查看
主要内容源于 https://blog.buoyant.io/2016/11/04/a-service-mesh-for-kubernetes-part-iv-continuous-deployment-via-traffic-shifting/ ,砍掉了 Jenkins 等附加部分,更换了更加易于理解的示例应用,以保证主干突出。
Kubernetes 所提供的 rolling-update 功能提供了一种渐进式的更新过程,然而其滚动过程并不容易控制,对于灰度发布的需要来说,仍稍显不足,这里介绍一种利用 Linkerd 方案进行流量切换的思路。
官网介绍:linker∙d is a transparent proxy that adds service discovery, routing, failure handling, and visibility to modern software applications。
本文从实际操作入手,上线两个版本的简单应用,利用这一组合完成流量的切换和测试过程。
同时上线两个版本的应用。两个应用均可工作,利用不同输出进行区分。
动态调整分配给两个版本的流量。
利用 CURL 进行流量分配的测试。
这里利用一个 1.2 以上版本的 Kubernetes 集群进行演示:
API Server / Registry:10.211.55.62
Node:10.211.66.63
另外因某些原因,需要有能力获取 Dockerhub 的镜像。
例子程序很简单,用一个 PHP 文件显示环境变量中的内容:
Docker file 继承自
利用 Docker build 创建镜像,这里命名为 lamp:gray,备用。
做一个简单的 yaml 文件来加载蓝绿两组应用,名字、环境变量和端口三个位置需要更改:
利用
另外这里的端口命名很重要,这一名称会被后面的规则引用到。
注意,这里 NodePort 并非必须,仅为测试方便。
此处 yaml 主要来自于官网 https://raw.githubusercontent.com/BuoyantIO/linkerd-examples/master/k8s-daemonset/k8s/namerd.yml 为适应本地环境,将原有 Loadbalancer 类型的服务改为 NodePort
略微做一下讲解。
整个 yaml 由四部分组成:
这部分被用于做 Namerd 的存储后端。
作为 Namerd 的配置,其中定义了这样几个内容(详情可参见 https://linkerd.io/config/0.8.5/namerd/index.html#introduction): 管理端口 9990
storage:存储定义,通过 8001 端口同 Kube Api Server 通信,完成在 ThrdPartyResource 中的访问(8001 端口由 kubectl proxy 指令开通)
namer:定义服务发现能力由 Kubernetes 提供。
interface 部分则是定义了两种支持协议。其中 HTTP Controller 可以接收 namerctl 的控制指令。
这部分不新鲜,除了 namerd 之外,还利用 kubectl proxy 提供通信端口给 namerd,颇有蛇足之嫌。正确的打开方式应该是直接和 Kube API Server 进行通信。
这里注意服务类型的变更( LoadBalancer -> NodePort ),需要暴露 4180 和 9990 两个端口,分别作为控制端口和界面端口。
利用 kubectl 启用之后,就可以在指定的端口查看管理界面了。此时的管理界面没有做任何配置,因此比较单薄。
下面来安装 namerd 的控制工具,namerctl
接下来创建一条规则:
这段代码表示该服务同时连接 blue 和 green 两个后端服务,按照 80/20 的比例进行流量分配。
利用
接下来就能够看到管理界面上显示出新的规则了。
这里同样基于官方的 https://raw.githubusercontent.com/BuoyantIO/linkerd-examples/master/k8s-daemonset/k8s/linkerd-namerd.yml
需要注意的是,官方给出的 yaml 文件中有一处 bug,使得这个 yaml 只能在缺省的 namespace 和 domain suffix 下运行。需要纠正对 namerd 的访问方式,删除 Namerd 后面的
同样的,他的服务端口和管理端口都应该改用 NodePort 方式进行暴露。
运行后,同样可以看到 Linkerd 的管理界面。
下面可以做一个简单的测试,来证明流量分配的有效性:
可以看到,随着循环次数的增加,其结果越来越趋近于 80/20 的分配比例。
接下来,我们修改上面的 dtab 为如下内容:
重新进行测试,就可以看到,流量分配已经发生了变化。另外,还可以在 Linkerd 的管理界面上看到网络流量的变化情况。
这一组合基本能够满足流量渐变分配的功能需求,同时也有如豆瓣这样的大厂使用,但他的 dtab 还是个相对复杂的东西,如果在生产上进行使用,还是需要进一步的学习。
另外,按照其文档中所陈述的功能范围内容来看,仅用来做流量分配还是颇有点大材小用的味道,从个人来说,我倾向于一些更轻量级的解决方法。
作者:崔总
本文:Linkerd + Namerd,实现Kubernetes 集群的灰度发布
Kubernetes 所提供的 rolling-update 功能提供了一种渐进式的更新过程,然而其滚动过程并不容易控制,对于灰度发布的需要来说,仍稍显不足,这里介绍一种利用 Linkerd 方案进行流量切换的思路。
官网介绍:linker∙d is a transparent proxy that adds service discovery, routing, failure handling, and visibility to modern software applications。
本文从实际操作入手,上线两个版本的简单应用,利用这一组合完成流量的切换和测试过程。
测试目标
同时上线两个版本的应用。两个应用均可工作,利用不同输出进行区分。动态调整分配给两个版本的流量。
利用 CURL 进行流量分配的测试。
准备工作
这里利用一个 1.2 以上版本的 Kubernetes 集群进行演示:API Server / Registry:10.211.55.62
Node:10.211.66.63
另外因某些原因,需要有能力获取 Dockerhub 的镜像。
例子程序很简单,用一个 PHP 文件显示环境变量中的内容:
<?php echo getenv("VAR_LABEL");
Docker file 继承自
dustise/lamp:latest,文件内容如下:
FROM dustise/lamp COPY index.php /web/codebase
利用 Docker build 创建镜像,这里命名为 lamp:gray,备用。
创建工作负载
做一个简单的 yaml 文件来加载蓝绿两组应用,名字、环境变量和端口三个位置需要更改:--- kind: ReplicationController apiVersion: v1 metadata: name: green # 此处省略若干 env: - name: VAR_LABEL value: 'green' --- kind: Service apiVersion: v1 # 此处省略若干 type: NodePort ports: - protocol: TCP nodePort: 32001 port: 80 targetPort: 80 name: http selector: name: green
利用
kubectl create -f green.yaml( 以及 blue.yaml )之后,可以利用 curl 或者浏览器检查运行情况,如果正常,两个端口的访问应该分别会返回
green和
blue。
另外这里的端口命名很重要,这一名称会被后面的规则引用到。
注意,这里 NodePort 并非必须,仅为测试方便。
运行 Namerd
此处 yaml 主要来自于官网 https://raw.githubusercontent.com/BuoyantIO/linkerd-examples/master/k8s-daemonset/k8s/namerd.yml 为适应本地环境,将原有 Loadbalancer 类型的服务改为 NodePort略微做一下讲解。
整个 yaml 由四部分组成:
ThirdPartyResource
这部分被用于做 Namerd 的存储后端。
Configmap
作为 Namerd 的配置,其中定义了这样几个内容(详情可参见 https://linkerd.io/config/0.8.5/namerd/index.html#introduction): 管理端口 9990storage:存储定义,通过 8001 端口同 Kube Api Server 通信,完成在 ThrdPartyResource 中的访问(8001 端口由 kubectl proxy 指令开通)
namer:定义服务发现能力由 Kubernetes 提供。
interface 部分则是定义了两种支持协议。其中 HTTP Controller 可以接收 namerctl 的控制指令。
RC
这部分不新鲜,除了 namerd 之外,还利用 kubectl proxy 提供通信端口给 namerd,颇有蛇足之嫌。正确的打开方式应该是直接和 Kube API Server 进行通信。
Service
这里注意服务类型的变更( LoadBalancer -> NodePort ),需要暴露 4180 和 9990 两个端口,分别作为控制端口和界面端口。利用 kubectl 启用之后,就可以在指定的端口查看管理界面了。此时的管理界面没有做任何配置,因此比较单薄。
添加规则
下面来安装 namerd 的控制工具,namerctlgo get -u github.com/buoyantio/namerctl go install github.com/buoyantio/namerctl
接下来创建一条规则:
/host=>/#/io.l5d.k8s/default/http; /http/*/*/*=>8*/host/blue&2*/host/green;
这段代码表示该服务同时连接 blue 和 green 两个后端服务,按照 80/20 的比例进行流量分配。
利用
namerctl dtab create [file name] --base-url这里 base-url 取值就是我们给 namerd 设置的 Nodeport。
接下来就能够看到管理界面上显示出新的规则了。
运行 Linkerd
这里同样基于官方的 https://raw.githubusercontent.com/BuoyantIO/linkerd-examples/master/k8s-daemonset/k8s/linkerd-namerd.yml 需要注意的是,官方给出的 yaml 文件中有一处 bug,使得这个 yaml 只能在缺省的 namespace 和 domain suffix 下运行。需要纠正对 namerd 的访问方式,删除 Namerd 后面的
default.svc.cloud.local即可。
同样的,他的服务端口和管理端口都应该改用 NodePort 方式进行暴露。
运行后,同样可以看到 Linkerd 的管理界面。
测试
下面可以做一个简单的测试,来证明流量分配的有效性:for ((i=1;i<=300;i++)); do curl -s "http://10.211.55.63:30001/";echo ""; done | grep -i blue| wc -l
可以看到,随着循环次数的增加,其结果越来越趋近于 80/20 的分配比例。
接下来,我们修改上面的 dtab 为如下内容:
/host=>/#/io.l5d.k8s/default/http; /http/*/*/*=>8*/host/blue&8*/host/green;
重新进行测试,就可以看到,流量分配已经发生了变化。另外,还可以在 Linkerd 的管理界面上看到网络流量的变化情况。
结语
这一组合基本能够满足流量渐变分配的功能需求,同时也有如豆瓣这样的大厂使用,但他的 dtab 还是个相对复杂的东西,如果在生产上进行使用,还是需要进一步的学习。另外,按照其文档中所陈述的功能范围内容来看,仅用来做流量分配还是颇有点大材小用的味道,从个人来说,我倾向于一些更轻量级的解决方法。
作者:崔总
本文:Linkerd + Namerd,实现Kubernetes 集群的灰度发布
相关文章推荐
- 直播 | Kubernetes使用集群联邦实现多集群管理
- 【云星数据---Nik(精品版)】:通过ansible playbook实现自动化部署 KUBERNETES 集群
- kubernetes集群中利用etcd和grpc实现golang服务间通信
- Traefik实现Kubernetes集群服务外部https访问
- 按照官方文档,安装minikube,kubectl,实现Kubernetes集群部署(采坑记)
- Kubernetes使用集群联邦实现多集群管理
- Kubernetes使用集群联邦实现多集群管理
- 跨集群服务——如何利用Kubernetes 1.3实现跨区高可用
- 【微信群分享预告】Kubernetes结合LVS实现高可用负载均衡与集群外服务访问
- [k8s]jenkins配合kubernetes插件实现k8s集群构建的持续集成
- IBM WAS ND 分布式网络环境的理解与集群的实现
- 集群系统实现方案详解
- web集群服务的负载均衡方案选择与实现
- 基于MySQL的数据库集群系统的实现
- 负载均衡--大型在线系统实现的关键(下篇)(服务器集群架构的设计与选择)
- 集群系统实现方案详解
- 轻松实现Apache,Tomcat集群和负载均衡
- Linux 服务器集群系统实现方案详解
- 轻松实现Apache,Tomcat集群和负载均衡
- 轻松实现Apache,Tomcat集群和负载均衡