3种Ansible Roles分步指南,教你如何使用Weave Scope探索微服务通信和服务网格

Istio小数 发表了文章 • 0 个评论 • 72 次浏览 • 6 天前 • 来自相关话题

 
 作者:Roger CARHUATOCTO 

翻译:张晔

原文:Using Weave Scope to explore Microservices Communication and Service Mesh 

原文地址:https://holisticsecurity.io/20 ... erral



如果你正在使用ESB、消息代理、BPMS、SOA或微服务,就会注意到,你正在以不同的方式解决相同的独立应用程序问题,因为它们都是不同类型的分布式应用程序。这些问题是:

用户管理、认证和授权

日志记录、调试、监视和报警

集群、高可用性、负载均衡等


什么是服务网格

服务网格是另一种类型的分布式应用程序,在这其中服务、微服务或者APIs都是相互关联的。







基于容器化和编排平台的服务网格

一般来说,基于微服务和/或APIs的服务网格是由多个容器来部署的,这些容器是用Kubernetes 来编排的。在这种情况下,我们需要面对新的挑战,比如临时基础设施、零信任网络、网络分割或者采用新的方法来测试、监控、部署、操作等等。这就是我们所说的DevOps。



容器部署模式

与 EIP (企业集成模式)和软件设计模式一样,在容器化的平台上部署服务网格也有一定的模式。Google、Microsoft、Netflix 等建议使用一些模式来实现上述问题的解决方案。


例如,Google解释了三种很好的模式:
 
Sidecar模式Ambassador模式适配器模式

它们都支持基于容器的服务网格的构建。欲知详情,请阅读:

《基于容器的分布式系统的设计模式》by 布伦丹·伯恩斯&大卫·奥本海默

PDF下载:https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45406.pdf 



什么是Istio

摘录自 Istio.io :

Istio是一个开放的平台,提供了一种统一的方式来连接、管理微服务,保证微服务安全。Istio支持管理微服务之间的交通流、执行访问策略和聚合遥测数据,这些都不需要对微服务代码进行更改。

Istio 给你:
自动负载平衡HTTP、gRPC WebSocket,TCP流量;
 
细粒度控制的交通行为与丰富的路由规则,重试,故障转移,故障注入;
 
可插入策略层和配置API支持访问控制,速度和配额限制;
 
自动度量、日志和跟踪所有流量在一个集群,包括集群入口和出口;


在集群中的服务之间,通过强身份断言,实现服务对服务的安全认证。







为什么使用Istio

    摘录自 Istio.io :

Istio解决了开发人员和运维人员在向分布式微服务架构过渡时所面临的诸多挑战。服务网格作为一个术语,通常用于描述组成此类应用程序的微服务网络和它们之间的交互。随着服务网格的规模和复杂性的增长,它会变得越来越难以理解和管理。它的需求包括发现、负载均衡、故障恢复、度量和监控,以及更复杂的操作需求,如A/B测试、canary发布、速率限制、访问控制和端到端验证。


Istio提供了一个完整的解决方案,通过行为洞察和对整个服务网格的操作控制,来满足微服务应用程序的不同需求。它在服务网络中统一提供了许多关键功能:
 
交通管理。控制服务之间的流量和API调用,使调用更加可靠,并使网络在面对不利条件时更加健壮。
 
可观测性。了解服务之间的依赖关系和它们之间的流量之间的关系,提供快速识别问题的能力。
 
政策执行。将组织策略应用于服务之间的交互,确保执行访问策略,并且在用户中公平地分配资源。策略更改不必通过更改应用程序代码来实现,而是通过配置网格。
 
标识和安全服务。在网格中提供可验证身份的服务,并提供保护服务流量的能力,因为它在不同程度的trustability网络中流动。


基于容器的服务网格与Istio

为了轻松得到一个极简 OpenShift 集群,我创建了3个 Ansible Roles--Weave Scope 、Istio 和 BookInfo 应用(基于容器的 API 和微服务) 来理解我们必须面对的挑战。3个 Ansible Roles是:

1. Minishift Ansible Role

    地址:https://github.com/chilcano/ansible-role-minishift

在虚拟机中通过 Minishift 获得 OpenShift 集群。


2. Weave Scope Ansible Role

   地址:https://github.com/chilcano/an ... scope

在 OpenShift 中部署本地运行的 Weave Scope 应用。


3. Istio Ansible Role

    地址:https://github.com/chilcano/ansible-role-istio

在本地运行的 OpenShift 中部署和配置 Istio,部署 BookInfo 应用,并注入 Sidecar 代理(Envoy Proxy)。


我还创建了一些示例,可以测试并快速尝试上述角色的环境。

Weave Scope 将在这里发挥重要作用,它能够对整个基于容器的服务网格进行监控、可视化、故障诊断和轻松管理。

一旦完成了分步指南,你将获得下一个:

(操作步骤详见:https://github.com/chilcano/an ... urity)






































 希望这篇文章对你能有所帮助。 查看全部

微信图片_20180116164346.jpg

 
 作者:Roger CARHUATOCTO 

翻译:张晔

原文:Using Weave Scope to explore Microservices Communication and Service Mesh 

原文地址:https://holisticsecurity.io/20 ... erral



如果你正在使用ESB、消息代理、BPMS、SOA或微服务,就会注意到,你正在以不同的方式解决相同的独立应用程序问题,因为它们都是不同类型的分布式应用程序。这些问题是:

用户管理、认证和授权

日志记录、调试、监视和报警

集群、高可用性、负载均衡等


什么是服务网格

服务网格是另一种类型的分布式应用程序,在这其中服务、微服务或者APIs都是相互关联的。

1.png



基于容器化和编排平台的服务网格

一般来说,基于微服务和/或APIs的服务网格是由多个容器来部署的,这些容器是用Kubernetes 来编排的。在这种情况下,我们需要面对新的挑战,比如临时基础设施、零信任网络、网络分割或者采用新的方法来测试、监控、部署、操作等等。这就是我们所说的DevOps。



容器部署模式

与 EIP (企业集成模式)和软件设计模式一样,在容器化的平台上部署服务网格也有一定的模式。Google、Microsoft、Netflix 等建议使用一些模式来实现上述问题的解决方案。


例如,Google解释了三种很好的模式:
 
  • Sidecar模式
  • Ambassador模式
  • 适配器模式


它们都支持基于容器的服务网格的构建。欲知详情,请阅读:

《基于容器的分布式系统的设计模式》by 布伦丹·伯恩斯&大卫·奥本海默

PDF下载:https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45406.pdf 



什么是Istio

摘录自 Istio.io :

Istio是一个开放的平台,提供了一种统一的方式来连接、管理微服务,保证微服务安全。Istio支持管理微服务之间的交通流、执行访问策略和聚合遥测数据,这些都不需要对微服务代码进行更改。

Istio 给你:
  • 自动负载平衡HTTP、gRPC WebSocket,TCP流量;

 
  • 细粒度控制的交通行为与丰富的路由规则,重试,故障转移,故障注入;

 
  • 可插入策略层和配置API支持访问控制,速度和配额限制;

 
  • 自动度量、日志和跟踪所有流量在一个集群,包括集群入口和出口;



在集群中的服务之间,通过强身份断言,实现服务对服务的安全认证。

2.png



为什么使用Istio

    摘录自 Istio.io :

Istio解决了开发人员和运维人员在向分布式微服务架构过渡时所面临的诸多挑战。服务网格作为一个术语,通常用于描述组成此类应用程序的微服务网络和它们之间的交互。随着服务网格的规模和复杂性的增长,它会变得越来越难以理解和管理。它的需求包括发现、负载均衡、故障恢复、度量和监控,以及更复杂的操作需求,如A/B测试、canary发布、速率限制、访问控制和端到端验证。


Istio提供了一个完整的解决方案,通过行为洞察和对整个服务网格的操作控制,来满足微服务应用程序的不同需求。它在服务网络中统一提供了许多关键功能:
 
  • 交通管理。控制服务之间的流量和API调用,使调用更加可靠,并使网络在面对不利条件时更加健壮。

 
  • 可观测性。了解服务之间的依赖关系和它们之间的流量之间的关系,提供快速识别问题的能力。

 
  • 政策执行。将组织策略应用于服务之间的交互,确保执行访问策略,并且在用户中公平地分配资源。策略更改不必通过更改应用程序代码来实现,而是通过配置网格。

 
  • 标识和安全服务。在网格中提供可验证身份的服务,并提供保护服务流量的能力,因为它在不同程度的trustability网络中流动。



基于容器的服务网格与Istio

为了轻松得到一个极简 OpenShift 集群,我创建了3个 Ansible Roles--Weave Scope 、Istio 和 BookInfo 应用(基于容器的 API 和微服务) 来理解我们必须面对的挑战。3个 Ansible Roles是:

1. Minishift Ansible Role

    地址:https://github.com/chilcano/ansible-role-minishift

在虚拟机中通过 Minishift 获得 OpenShift 集群。


2. Weave Scope Ansible Role

   地址:https://github.com/chilcano/an ... scope

在 OpenShift 中部署本地运行的 Weave Scope 应用。


3. Istio Ansible Role

    地址:https://github.com/chilcano/ansible-role-istio

在本地运行的 OpenShift 中部署和配置 Istio,部署 BookInfo 应用,并注入 Sidecar 代理(Envoy Proxy)。


我还创建了一些示例,可以测试并快速尝试上述角色的环境。

Weave Scope 将在这里发挥重要作用,它能够对整个基于容器的服务网格进行监控、可视化、故障诊断和轻松管理。

一旦完成了分步指南,你将获得下一个:

(操作步骤详见:https://github.com/chilcano/an ... urity



3.png


4.png


5.png


6.png


7.png


8.png


9.png


 希望这篇文章对你能有所帮助。

专题 | A Service Mesh for Kubernetes第3期:DogFood环境,Ingress和Edge路由

Linkerd小数 发表了文章 • 0 个评论 • 16 次浏览 • 22 小时前 • 来自相关话题

 概述

在这篇文章中,我们将向您展示如何使用Linkerd实现的Service Mesh来处理Kubernetes上的入口流量,在Service Mesh中的每个实例上分发流量。我们还将通过一个完整的例子来介绍Linkerd的高级路由功能:如何将特定的请求路由到较新版本的应用实例上,比如用于内部测试的、预发布的应用版本。

这篇文章是关于使用Linkerd作为到Kubernetes网络流量的入口点。 从0.9.1开始,Linkerd直接支持Kubernetes的Ingress资源,这对于本文中的一些用例来说是一个可替代的,也是更简单的起点。

注意: 这是关于Linkerd、Kubernetes和service mesh的系列文章其中一篇,其余部分包括:

1.Top-line service metrics
2.Pods are great, until they’re not
3.Encrypting all the things
4.Continuous deployment via traffic shifting
5.Dogfood environments, ingress, and edge routing(本文)
6.Staging microservices without the tears
7.Distributed tracing made easy
8.Linkerd as an ingress controller
9.gRPC for fun and profit
10.The Service Mesh API
11.Egress
12.Retry budgets, deadline propagation, and failing gracefully
13.Autoscaling by top-line metrics

在本系列的前几个部分,我们向您展示了如何使用Linkerd来捕获top-line的服务指标,在服务中透明地添加TLS以及执行蓝绿发布。这些文章展示了如Kubernetes这样的环境中如何使用Linkerd作为Service Mesh的组件,为内部服务到服务调用中添加了一层弹性和性能的保障,在本篇文章中,我们将这个模型扩展到入口路由。

虽然这篇文章以Kubernetes为例,但我们不会使用Kubernetes内置的Ingress资源对象。虽然Ingress提供了一种便捷的基于宿主机和基本路径的路由方法,但在本文撰写时,Kubernetes Ingress的功能是相当有限的。在下面的例子中,我们将远远超出Ingress提供的范围。



1、发布Linkerd Service Mesh

从以前文章中基本的Linkerd Service Mesh配置开始,我们进行两个更改来支持Ingress:我们将修改Linkerd的配置用以添加一个额外的逻辑路由器,我们在Kubernetes Service资源对象中调整VIP在Linkerd中的范围。

在Linkerd的实例提供了一个新的逻辑路由器,用于处理入口流量并将其路由到相应的服务:
yaml routers: - protocol: http  label: ingress  dtab: |    /srv                    => /#/io.l5d.k8s/default/http ;    /domain/world/hello/www => /srv/hello ;    /domain/world/hello/api => /srv/api ;    /host                  => /$/io.buoyant.http.domainToPathPfx/domain ;    /svc                    => /host ;  interpreter:    kind: default    transformers:    - kind: io.l5d.k8s.daemonset      namespace: default      port: incoming      service: l5d  servers:  - port: 4142    ip: 0.0.0.0在这个配置中,我们使用Linkerd的路由语法,dtabs将请求从域名传递到服务——在这种情况下从api.hello.world传递到api服务,从www.hello.world到hello服务。为了简单起见,我们已经为每个域添加了一个规则,但是对于更复杂的设置,也可以轻松地生成映射规则。

我们已经将这个入口路由器添加到每个Linkerd实例中 - 以真正Service Mesh的方式,我们将在这些实例中完全分配入口流量,使得应用不存在单点故障。

我们还需要修改Kubernetes Service对象,以在端口80上用非入口VIP替换出口的VIP——这将允许我们直接将出口流量发送到Linkerd的Service Mesh中,主要是用于调试的目的,因为这个流量在到达Linkerd之前不会被审查(在下一步,我们将解决这个问题)。

对Kubernetes Service修改如下:
apiVersion: v1 kind: Service metadata:  name: l5d spec:  selector:    app: l5d  type: LoadBalancer  ports:  - name: ingress    port: 80    targetPort: 4142  - name: incoming    port: 4141  - name: admin    port: 9990
以上所有的修改都可以通过简单运行一个命令就能生效,细节请查看:
$ kubectl apply -f https://raw.githubusercontent. ... s.yml





2、部署服务

对于此例中的Service,我们将使用早先发布的博客使用到的例子hello and world configs,并且我们会添加两个新的service:一个api service,其用来调用hello和world,还有world service的新版本:world-v2,其将会返回一个“earth”而非“world”——我们扩大黑客团队已经向我们保证,他们的A/B测试显示这一变化将使参与度提高10倍。

下面的命令将会把hello world services部署在default命名空间下。这些应用依赖于Kubernetes downward API提供的节点名来发现Linkerd。为了检查你的集群是否支持节点名,你可以运行该测试任务:k
ubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/node-name-test.yml 
然后看它的日志信息:kubectl logs node-name-test如果你看到了IP,那就非常棒,接着使用如下命令部署hello world应用:$ kubectl apply -f https://raw.githubusercontent. ... d.yml $ kubectl apply -f https://raw.githubusercontent. ... i.yml $ kubectl apply -f https://raw.githubusercontent. ... 2.yml如果你看到的是“server can’t find…”这样的报错信息,请部署hello-world遗留版本,该版本依赖于hostIP而不是节点名:$ kubectl apply -f https://raw.githubusercontent. ... y.yml $ kubectl apply -f https://raw.githubusercontent. ... y.yml $ kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/world-v2.yml 
 
这时我们应该能够通过入口Kubernetes VIP发送流量来测试设备,在没有使用DNS的情况下,我们将在请求中手动设置一个Host Header:
$ INGRESS_LB=$(kubectl get svc l5d -o jsonpath="{.status.loadBalancer.ingress[0].*}") $ curl -s -H "Host: www.hello.world" $INGRESS_LB Hello (10.0.5.7) world (10.0.4.7)!! $ curl -s -H "Host: api.hello.world" $INGRESS_LB {"api_result":"api (10.0.3.6) Hello (10.0.5.4) world (10.0.1.5)!!"}
或者如果集群不支持外部负载均衡器,请使用hostIP:$ INGRESS_LB=$(kubectl get po -l app=l5d -o jsonpath="{.items[0].status.hostIP}"):$(kubectl get svc l5d -o 'jsonpath={.spec.ports[0].nodePort}')成功了!
我们已经将Linkerd设置为入口控制器,并且我们已经使用它将不同域中收到的请求路由到不同的服务。正如您所见,生产流量正冲击world-v1服务——我们还没准备要将world-v2推出。



3、Nginx层

至此ingress已经可以使用了。但还不能用于生产环境中。因为我们的ingress路由器不能将header从请求中提取出来。这就意味着我们不能接收包含header的外部请求。例如,Linkerd允许设置15d-dtab头部以按请求应用路由规则,这对于新服务的临时分级是一个有用的功能,但这可能不适合于来自外部的请求。

例如,我们可以使用15d-dtab请求头覆盖路由逻辑来使用world-v2而不是world-v1来服务外部请求:$ curl -H "Host: www.hello.world" -H "l5d-dtab: /host/world => /srv/world-v2;" $INGRESS_LB Hello (10.100.4.3) earth (10.100.5.5)!!当earth作为响应,意味着这是world-v2服务的结果。

我们通过添加nginx来解决这个问题(或者其他问题如服务静态文件)。如果我们在代理请求到linkerd ingress路由之前配置nginx来提取输入的header,我们将会两全其美:有能力安全处理外部流量的ingress层并且Linkerd做动态的、基于服务的路由。

让我们添加nginx到集群中。使用this nginx conf来配置它。我们将在www.hello.world和api.hello.world虚拟服务器下使用proxy_pass命令来发送请求给Linkerd实例,并且我们将使用Headers More模块提供的more_clear_input_headers命令来提取linkerd's context headers。

对于linkerd 0.9.0,我们可以通过在ingress路由器服务器上设置clearContext:true来清除输入的15d-*请求头。然而,nginx有许多我们可以使用到的特性,所以使用nginx连接Linkerd很有价值。

我们已经发布了一个安装了Headers More模块的Docker镜像:buoyantio/nginx:1.11.5。
我们用该配置部署这个镜像:
$ kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/nginx.yml 
 
在等待外部IP出现后,我们可以通过点击nginx.conf中的简单测试端点来测试nginx是否启动:$ INGRESS_LB=$(kubectl get svc nginx -o jsonpath="{.status.loadBalancer.ingress[0].*}") $ curl $INGRESS_LB 200 OK
或者如果集群的外部负载均衡器不可用,使用
hostIP:$ INGRESS_LB=$(kubectl get po -l app=nginx -o jsonpath="{.items[0].status.hostIP}"):$(kubectl get svc nginx -o 'jsonpath={.spec.ports[0].nodePort}')
 
我们现在应用已经可以通过nginx发送流量给我们的服务了:$ curl -s -H "Host: www.hello.world" $INGRESS_LB Hello (10.0.5.7) world (10.0.4.7)!! $ curl -s -H "Host: api.hello.world" $INGRESS_LB {"api_result":"api (10.0.3.6) Hello (10.0.5.4) world (10.0.1.5)!!"}
 
最后,让我们尝试直接与world-v2服务通信:$ curl -H "Host: www.hello.world" -H "l5d-dtab: /host/world => /srv/world-v2;" $INGRESS_LB Hello (10.196.1.8) world (10.196.2.13)!!没有earth,Nginx正在净化外部流量。



4、简述Dogfood

好了,到了重点部分:让我们使用world-v1服务来配置dogfood的环境,不过这仅针对一些流量。

为简化问题,我们只关注设置了特殊cookiespecial_employee_cookie的流量。在实践中,你可能想要比这更复杂的情况如验证它,要求它来自公司网络IP范围等。

用nginx和Linkerd安装,完成这个相当简单。我们将会使用nginx来检查该cookie是否存在,为linkerd设置一个dtab覆盖头来调整其路由。有关的nginx配置如下:
if ($cookie_special_employee_cookie ~* "dogfood") {  set $xheader "/host/world => /srv/world-v2;"; } proxy_set_header 'l5d-dtab' $xheader;
如果你已经按以上步骤做了,被部署的nginx已经包含了这个配置。我们可以用如下来进行测试:
$ curl -H "Host: www.hello.world" --cookie "special_employee_cookie=dogfood" $INGRESS_LB Hello (10.196.1.8) earth (10.196.2.13)!!
系统已经工作了。当这个cookie被设置了,你将置于dogfood模式下。如果没有它,你将置于常规生产流量模式。最重要的是,dogfood模式可以包含在service stack到处出现的service的新版本,甚至很多层——只要服务代码转发Linkerd的上下文头,Linkerd服务网格将负责其余部分。



结束语

在本文中,我们看到了如何使用Linkerd给Kubernetes集群提供有力而又灵活的入口。我们已经演示了如何部署名义上的生产就绪设置,使用Linkerd进行服务路由。我们已经演示了如何使用Linkerd的一些高级路由功能来将流量服务拓扑从部署拓扑结构中分离出来,从而允许创建dogfood环境而不需要单独的集群或部署时间复杂性。 查看全部
 概述

在这篇文章中,我们将向您展示如何使用Linkerd实现的Service Mesh来处理Kubernetes上的入口流量,在Service Mesh中的每个实例上分发流量。我们还将通过一个完整的例子来介绍Linkerd的高级路由功能:如何将特定的请求路由到较新版本的应用实例上,比如用于内部测试的、预发布的应用版本。

这篇文章是关于使用Linkerd作为到Kubernetes网络流量的入口点。 从0.9.1开始,Linkerd直接支持Kubernetes的Ingress资源,这对于本文中的一些用例来说是一个可替代的,也是更简单的起点。

注意: 这是关于Linkerd、Kubernetes和service mesh的系列文章其中一篇,其余部分包括:

1.Top-line service metrics
2.Pods are great, until they’re not
3.Encrypting all the things
4.Continuous deployment via traffic shifting
5.Dogfood environments, ingress, and edge routing(本文)
6.Staging microservices without the tears
7.Distributed tracing made easy
8.Linkerd as an ingress controller
9.gRPC for fun and profit
10.The Service Mesh API
11.Egress
12.Retry budgets, deadline propagation, and failing gracefully
13.Autoscaling by top-line metrics

在本系列的前几个部分,我们向您展示了如何使用Linkerd来捕获top-line的服务指标,在服务中透明地添加TLS以及执行蓝绿发布。这些文章展示了如Kubernetes这样的环境中如何使用Linkerd作为Service Mesh的组件,为内部服务到服务调用中添加了一层弹性和性能的保障,在本篇文章中,我们将这个模型扩展到入口路由。

虽然这篇文章以Kubernetes为例,但我们不会使用Kubernetes内置的Ingress资源对象。虽然Ingress提供了一种便捷的基于宿主机和基本路径的路由方法,但在本文撰写时,Kubernetes Ingress的功能是相当有限的。在下面的例子中,我们将远远超出Ingress提供的范围。



1、发布Linkerd Service Mesh

从以前文章中基本的Linkerd Service Mesh配置开始,我们进行两个更改来支持Ingress:我们将修改Linkerd的配置用以添加一个额外的逻辑路由器,我们在Kubernetes Service资源对象中调整VIP在Linkerd中的范围。

在Linkerd的实例提供了一个新的逻辑路由器,用于处理入口流量并将其路由到相应的服务:
yaml routers: - protocol: http  label: ingress  dtab: |    /srv                    => /#/io.l5d.k8s/default/http ;    /domain/world/hello/www => /srv/hello ;    /domain/world/hello/api => /srv/api ;    /host                  => /$/io.buoyant.http.domainToPathPfx/domain ;    /svc                    => /host ;  interpreter:    kind: default    transformers:    - kind: io.l5d.k8s.daemonset      namespace: default      port: incoming      service: l5d  servers:  - port: 4142    ip: 0.0.0.0在这个配置中,我们使用Linkerd的路由语法,dtabs将请求从域名传递到服务——在这种情况下从api.hello.world传递到api服务,从www.hello.world到hello服务。为了简单起见,我们已经为每个域添加了一个规则,但是对于更复杂的设置,也可以轻松地生成映射规则。

我们已经将这个入口路由器添加到每个Linkerd实例中 - 以真正Service Mesh的方式,我们将在这些实例中完全分配入口流量,使得应用不存在单点故障。

我们还需要修改Kubernetes Service对象,以在端口80上用非入口VIP替换出口的VIP——这将允许我们直接将出口流量发送到Linkerd的Service Mesh中,主要是用于调试的目的,因为这个流量在到达Linkerd之前不会被审查(在下一步,我们将解决这个问题)。

对Kubernetes Service修改如下:
apiVersion: v1 kind: Service metadata:  name: l5d spec:  selector:    app: l5d  type: LoadBalancer  ports:  - name: ingress    port: 80    targetPort: 4142  - name: incoming    port: 4141  - name: admin    port: 9990
以上所有的修改都可以通过简单运行一个命令就能生效,细节请查看:
$ kubectl apply -f https://raw.githubusercontent. ... s.yml





2、部署服务

对于此例中的Service,我们将使用早先发布的博客使用到的例子hello and world configs,并且我们会添加两个新的service:一个api service,其用来调用hello和world,还有world service的新版本:world-v2,其将会返回一个“earth”而非“world”——我们扩大黑客团队已经向我们保证,他们的A/B测试显示这一变化将使参与度提高10倍。

下面的命令将会把hello world services部署在default命名空间下。这些应用依赖于Kubernetes downward API提供的节点名来发现Linkerd。为了检查你的集群是否支持节点名,你可以运行该测试任务:k
ubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/node-name-test.yml 
然后看它的日志信息:kubectl logs node-name-test如果你看到了IP,那就非常棒,接着使用如下命令部署hello world应用:$ kubectl apply -f https://raw.githubusercontent. ... d.yml $ kubectl apply -f https://raw.githubusercontent. ... i.yml $ kubectl apply -f https://raw.githubusercontent. ... 2.yml如果你看到的是“server can’t find…”这样的报错信息,请部署hello-world遗留版本,该版本依赖于hostIP而不是节点名:$ kubectl apply -f https://raw.githubusercontent. ... y.yml $ kubectl apply -f https://raw.githubusercontent. ... y.yml $ kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/world-v2.yml 
 
这时我们应该能够通过入口Kubernetes VIP发送流量来测试设备,在没有使用DNS的情况下,我们将在请求中手动设置一个Host Header:
$ INGRESS_LB=$(kubectl get svc l5d -o jsonpath="{.status.loadBalancer.ingress[0].*}") $ curl -s -H "Host: www.hello.world" $INGRESS_LB Hello (10.0.5.7) world (10.0.4.7)!! $ curl -s -H "Host: api.hello.world" $INGRESS_LB {"api_result":"api (10.0.3.6) Hello (10.0.5.4) world (10.0.1.5)!!"}
或者如果集群不支持外部负载均衡器,请使用hostIP:$ INGRESS_LB=$(kubectl get po -l app=l5d -o jsonpath="{.items[0].status.hostIP}"):$(kubectl get svc l5d -o 'jsonpath={.spec.ports[0].nodePort}')成功了!
我们已经将Linkerd设置为入口控制器,并且我们已经使用它将不同域中收到的请求路由到不同的服务。正如您所见,生产流量正冲击world-v1服务——我们还没准备要将world-v2推出。



3、Nginx层

至此ingress已经可以使用了。但还不能用于生产环境中。因为我们的ingress路由器不能将header从请求中提取出来。这就意味着我们不能接收包含header的外部请求。例如,Linkerd允许设置15d-dtab头部以按请求应用路由规则,这对于新服务的临时分级是一个有用的功能,但这可能不适合于来自外部的请求。

例如,我们可以使用15d-dtab请求头覆盖路由逻辑来使用world-v2而不是world-v1来服务外部请求:$ curl -H "Host: www.hello.world" -H "l5d-dtab: /host/world => /srv/world-v2;" $INGRESS_LB Hello (10.100.4.3) earth (10.100.5.5)!!当earth作为响应,意味着这是world-v2服务的结果。

我们通过添加nginx来解决这个问题(或者其他问题如服务静态文件)。如果我们在代理请求到linkerd ingress路由之前配置nginx来提取输入的header,我们将会两全其美:有能力安全处理外部流量的ingress层并且Linkerd做动态的、基于服务的路由。

让我们添加nginx到集群中。使用this nginx conf来配置它。我们将在www.hello.world和api.hello.world虚拟服务器下使用proxy_pass命令来发送请求给Linkerd实例,并且我们将使用Headers More模块提供的more_clear_input_headers命令来提取linkerd's context headers。

对于linkerd 0.9.0,我们可以通过在ingress路由器服务器上设置clearContext:true来清除输入的15d-*请求头。然而,nginx有许多我们可以使用到的特性,所以使用nginx连接Linkerd很有价值。

我们已经发布了一个安装了Headers More模块的Docker镜像:buoyantio/nginx:1.11.5。
我们用该配置部署这个镜像:
$ kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/nginx.yml 
 
在等待外部IP出现后,我们可以通过点击nginx.conf中的简单测试端点来测试nginx是否启动:$ INGRESS_LB=$(kubectl get svc nginx -o jsonpath="{.status.loadBalancer.ingress[0].*}") $ curl $INGRESS_LB 200 OK
或者如果集群的外部负载均衡器不可用,使用
hostIP:$ INGRESS_LB=$(kubectl get po -l app=nginx -o jsonpath="{.items[0].status.hostIP}"):$(kubectl get svc nginx -o 'jsonpath={.spec.ports[0].nodePort}')
 
我们现在应用已经可以通过nginx发送流量给我们的服务了:$ curl -s -H "Host: www.hello.world" $INGRESS_LB Hello (10.0.5.7) world (10.0.4.7)!! $ curl -s -H "Host: api.hello.world" $INGRESS_LB {"api_result":"api (10.0.3.6) Hello (10.0.5.4) world (10.0.1.5)!!"}
 
最后,让我们尝试直接与world-v2服务通信:$ curl -H "Host: www.hello.world" -H "l5d-dtab: /host/world => /srv/world-v2;" $INGRESS_LB Hello (10.196.1.8) world (10.196.2.13)!!没有earth,Nginx正在净化外部流量。



4、简述Dogfood

好了,到了重点部分:让我们使用world-v1服务来配置dogfood的环境,不过这仅针对一些流量。

为简化问题,我们只关注设置了特殊cookiespecial_employee_cookie的流量。在实践中,你可能想要比这更复杂的情况如验证它,要求它来自公司网络IP范围等。

用nginx和Linkerd安装,完成这个相当简单。我们将会使用nginx来检查该cookie是否存在,为linkerd设置一个dtab覆盖头来调整其路由。有关的nginx配置如下:
if ($cookie_special_employee_cookie ~* "dogfood") {  set $xheader "/host/world => /srv/world-v2;"; } proxy_set_header 'l5d-dtab' $xheader;
如果你已经按以上步骤做了,被部署的nginx已经包含了这个配置。我们可以用如下来进行测试:
$ curl -H "Host: www.hello.world" --cookie "special_employee_cookie=dogfood" $INGRESS_LB Hello (10.196.1.8) earth (10.196.2.13)!!
系统已经工作了。当这个cookie被设置了,你将置于dogfood模式下。如果没有它,你将置于常规生产流量模式。最重要的是,dogfood模式可以包含在service stack到处出现的service的新版本,甚至很多层——只要服务代码转发Linkerd的上下文头,Linkerd服务网格将负责其余部分。



结束语

在本文中,我们看到了如何使用Linkerd给Kubernetes集群提供有力而又灵活的入口。我们已经演示了如何部署名义上的生产就绪设置,使用Linkerd进行服务路由。我们已经演示了如何使用Linkerd的一些高级路由功能来将流量服务拓扑从部署拓扑结构中分离出来,从而允许创建dogfood环境而不需要单独的集群或部署时间复杂性。

Ambassador和Istio:边缘代理和服务网格

Istio小数 发表了文章 • 0 个评论 • 10 次浏览 • 3 小时前 • 来自相关话题

 作者:Richard Li

翻译:王斌


原文:Ambassador and Istio: Edge proxy and service mesh




Ambassador(https://www.getambassador.io)是一个 Kubernetes 原生的微服务 API 网关,它部署在网络边缘,将传入网络的流量路由到相应的内部服务(也被称为“南北”流量)。Istio 是微服务的服务网格,旨在将L7的可观察性、路由和弹性加入到从服务到服务的流量中(也被称为“东西”流量)。 Istio 和 Ambassador底层都使用了 Envoy。

Ambassador 和 Istio 可以一起部署在 Kubernetes 上。在这种部署方式下,来自集群外部的入站流量首先会经过 Ambassador,再由 Ambassador将流量路由到 Istio。Ambassador 主要处理认证、边缘路由、TLS终结,以及一些传统的边缘功能。

这种部署方式能让运维人员得到一个高性能、现代化的边缘服务(Ambassador)与最先进的服务网格(Istio)相结合的网络。虽然 Istio 本身就有一个基本入口控制器,但其功能非常有限,并且不支持身份验证以及 Ambassador所拥有的许多功能。







Ambassador和 Istio 协同工作

要让 Ambassador 与 Istio 协同工作其实很简单,我们以 Istio 的bookinfo示例来举个例子:





1. 首先,在 Kubernetes 上安装 Istio。

参考指南:https://istio.io/docs/setup/ku ... .html

2. 然后,安装 Bookinfo 示例应用。

参考指南:https://istio.io/docs/guides/bookinfo.html

3. 验证示例是否按预期正常工作。




Bookinfo 示例默认使用的是 Istio 的入口控制器,要使用 Ambassador,我们还需要进行以下操作:

1. 安装Ambassador。

参考指南:https://www.getambassador.io/u ... arted

2. 更新 bookinfo.yaml 清单以包含必要的Ambassador注解,操作如下:


apiVersion: v1
kind: Service
metadata:
 name: productpage
 labels:
   app: productpage
 annotations:
   getambassador.io/config: |
      ---
     apiVersion: ambassador/v0
     kind: Mapping
     name: productpage_mapping
     prefix: /productpage/
     rewrite: /productpage
     service: productpage:9080
spec:
 ports:
 - port: 9080
   name: http
 selector:
   app: productpage


输入kubectl delete ingress gateway命令,这将会删除bookinfo.yaml 清单中的入口控制器。此步骤为可选。




访问$AMBASSADOR_IP/productpage/,测试 Ambassador 是否已经起作用。可以通过 kubectl get services ambassador 命令来获取 Ambassador 的实际IP地址。







Sidecar注入

新版本的 Istio 支持 Kubernetes 初始化程序自动注入Istio Sidecar。有了Ambassador,你不再需要注入Istio Sidecar,因为 Ambassador 的 Envoy 实例将自动路由到相应的服务。如果你正在使用的是自动Sidecar注入方式,那么需要将 Istio 配置成不要自动为 Ambassador pods 注入Sidecar。具体操作方法可以参阅这份说明文档。

文档链接:https://istio.io/docs/setup/ku ... tions


点击阅读原文,即可查看文档



  查看全部
 作者:Richard Li

翻译:王斌


原文:Ambassador and Istio: Edge proxy and service mesh




Ambassador(https://www.getambassador.io)是一个 Kubernetes 原生的微服务 API 网关,它部署在网络边缘,将传入网络的流量路由到相应的内部服务(也被称为“南北”流量)。Istio 是微服务的服务网格,旨在将L7的可观察性、路由和弹性加入到从服务到服务的流量中(也被称为“东西”流量)。 Istio 和 Ambassador底层都使用了 Envoy。

Ambassador 和 Istio 可以一起部署在 Kubernetes 上。在这种部署方式下,来自集群外部的入站流量首先会经过 Ambassador,再由 Ambassador将流量路由到 Istio。Ambassador 主要处理认证、边缘路由、TLS终结,以及一些传统的边缘功能。

这种部署方式能让运维人员得到一个高性能、现代化的边缘服务(Ambassador)与最先进的服务网格(Istio)相结合的网络。虽然 Istio 本身就有一个基本入口控制器,但其功能非常有限,并且不支持身份验证以及 Ambassador所拥有的许多功能。







Ambassador和 Istio 协同工作

要让 Ambassador 与 Istio 协同工作其实很简单,我们以 Istio 的bookinfo示例来举个例子:





1. 首先,在 Kubernetes 上安装 Istio。

参考指南:https://istio.io/docs/setup/ku ... .html

2. 然后,安装 Bookinfo 示例应用。

参考指南:https://istio.io/docs/guides/bookinfo.html

3. 验证示例是否按预期正常工作。




Bookinfo 示例默认使用的是 Istio 的入口控制器,要使用 Ambassador,我们还需要进行以下操作:

1. 安装Ambassador。

参考指南:https://www.getambassador.io/u ... arted

2. 更新 bookinfo.yaml 清单以包含必要的Ambassador注解,操作如下:


apiVersion: v1
kind: Service
metadata:
 name: productpage
 labels:
   app: productpage
 annotations:
   getambassador.io/config: |
      ---
     apiVersion: ambassador/v0
     kind: Mapping
     name: productpage_mapping
     prefix: /productpage/
     rewrite: /productpage
     service: productpage:9080
spec:
 ports:
 - port: 9080
   name: http
 selector:
   app: productpage


输入kubectl delete ingress gateway命令,这将会删除bookinfo.yaml 清单中的入口控制器。此步骤为可选。




访问$AMBASSADOR_IP/productpage/,测试 Ambassador 是否已经起作用。可以通过 kubectl get services ambassador 命令来获取 Ambassador 的实际IP地址。







Sidecar注入

新版本的 Istio 支持 Kubernetes 初始化程序自动注入Istio Sidecar。有了Ambassador,你不再需要注入Istio Sidecar,因为 Ambassador 的 Envoy 实例将自动路由到相应的服务。如果你正在使用的是自动Sidecar注入方式,那么需要将 Istio 配置成不要自动为 Ambassador pods 注入Sidecar。具体操作方法可以参阅这份说明文档。

文档链接:https://istio.io/docs/setup/ku ... tions


点击阅读原文,即可查看文档