remove outdated content

pull/464/head
Jimmy Song 2022-03-09 17:19:33 +08:00
parent a02790894e
commit a275b0a1f1
No known key found for this signature in database
GPG Key ID: CBA666E6EF8B2C3A
17 changed files with 16 additions and 658 deletions

View File

@ -91,7 +91,7 @@ Kubernetes Handbook 项目始于 2016 年底,开源于 2017 年 3 月,作为
<p align="center">
<a href="https://cloudnative.to">
<img src="https://res.cloudinary.com/jimmysong/image/upload/v1594445787/images/github-banner.jpg" alt="加入云原生社区" title="加入云原生社区">
<img src="./images/github-banner.jpg" alt="加入云原生社区" title="加入云原生社区">
</a>
</p>

View File

@ -225,9 +225,7 @@
* [使用 Istio 前需要考虑的问题](usecases/before-using-istio.md)
* [Istio 中 sidecar 的注入规范及示例](usecases/sidecar-spec-in-istio.md)
* [如何参与 Istio 社区及注意事项](usecases/istio-community-tips.md)
* [Istio 免费学习资源汇总](usecases/istio-tutorials-collection.md)
* [Sidecar 的注入与流量劫持](usecases/understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md)
* [Envoy Sidecar 代理的路由转发](usecases/envoy-sidecar-routing-of-istio-service-mesh-deep-dive.md)
* [Istio 如何支持虚拟机](usecases/how-to-integrate-istio-with-vm.md)
* [Istio 支持虚拟机的历史](usecases/istio-vm-support.md)
* [Envoy](usecases/envoy.md)

View File

@ -80,14 +80,14 @@ Kubernetes 并不直接对外提供业务能力,而是作为应用运行的底
- 2018 年 5 月 30 日,[Envoy 最新官方文档中文版发布 —— 由 Service Mesh 爱好者倾情奉献](https://www.servicemesher.com/envoy/)。
- 2018 年 6 月 21 日,[启用新的社区 logo](https://mp.weixin.qq.com/s?__biz=MzIwNDIzODExOA==&mid=2650165956&idx=2&sn=8ef0f080fd428b6307389fce4546103a&chksm=8ec1ce8db9b6479b846b37e0fdffbc0f1a6b23c17329032af7e1b9e6dc6412966f42edcf08f9&scene=21#wechat_redirect)。
- 2018 年 6 月 30 日,[开启新域名 servicemesher.com](https://www.servicemesher.com/)。
- 2018 年 6 月 30 日,举办了第一届 Service Mesh Meetup 杭州站,见 [ServiceMesher 杭州 Meetup 圆满完成](https://www.servicemesher.com/blog/hangzhou-meetup-20180630/)。
- 2018 年 6 月 30 日,举办了第一届 Service Mesh Meetup 杭州站,见 [ServiceMesher 杭州 Meetup 圆满完成](https://cloudnative.to/blog/hangzhou-meetup-20180630/)。
- 2018 年 7 月ServiceMesher 社区成为 [Istio 社区中国合作伙伴](https://istio.io/about/community/)。
- 2018 年 7 月 29 日,举办了第二届 Service Mesh Meetup 北京站,见[第二届 Service Mesh Meetup 北京站回顾、视频回放和资料下载](https://www.servicemesher.com/blog/beijing-meetup-20180729/)。
- 2018 年 8 月 25 日,举办了第三届 Service Mesh Meetup 深圳站,见 [Service Mesh Meetup 深圳站回顾、视频回放及 PPT 资料分享](https://www.servicemesher.com/blog/service-mesh-meetup-shenzhen-20180825/)。
- 2018 年 7 月 29 日,举办了第二届 Service Mesh Meetup 北京站,见[第二届 Service Mesh Meetup 北京站回顾、视频回放和资料下载](https://cloudnative.to/blog/beijing-meetup-20180729/)。
- 2018 年 8 月 25 日,举办了第三届 Service Mesh Meetup 深圳站,见 [Service Mesh Meetup 深圳站回顾、视频回放及 PPT 资料分享](https://cloudnative.to/blog/service-mesh-meetup-shenzhen-20180825/)。
- 2018 年 9 月 19 日,开始了开源电子书 [istio-handbook](https://github.com/rootsongjc/istio-handbook/) 的创作。
- 2018 年 11 月 13 日,[ServiceMesher 社区成员聚首 KubeCon&CloudNativeCon 上海](https://jimmysong.io/blog/kubecon-cloudnativecon-china-2018/)。
- 2018 年 11 月 25 日,举办了第四届 Service Mesh Meetup 上海站,见[第四届 Service Mesh Meetup 上海站活动回顾与资料下载](https://www.servicemesher.com/blog/service-mesh-meetup-shanghai-20181125/)。
- 2019 年 1 月 6 日,举办了第五届 Service Mesh Meetup 广州站,见[第五届 Service Mesh Meetup 广州站活动回顾与资料下载](https://www.servicemesher.com/blog/service-mesh-meetup-guangzhou-20190106/)。
- 2018 年 11 月 25 日,举办了第四届 Service Mesh Meetup 上海站,见[第四届 Service Mesh Meetup 上海站活动回顾与资料下载](https://cloudnative.to/blog/service-mesh-meetup-shanghai-20181125/)。
- 2019 年 1 月 6 日,举办了第五届 Service Mesh Meetup 广州站,见[第五届 Service Mesh Meetup 广州站活动回顾与资料下载](https://cloudnative.to/blog/service-mesh-meetup-guangzhou-20190106/)。
## Serverless

View File

@ -116,7 +116,7 @@ kubectl 是一个命令行工具,用于与 Kubernetes 集群和其中的 pod
如果没有服务网格,对容器来说这项工作将十分繁琐,因为这涉及到逐一更改所有其他容器上的配置,将它们所包含的服务从 Container1 指向 Container2然后在测试失败后将它们全部改回来。
在前面这部分 Kubernetes 指南中,我们介绍了一些与 Kubernetes 网络相关的概念。Kubernetes 中的网络可能很棘手,很难理解,如果你刚刚开始,你可能需要一些实践来理解这里。关于服务网格的更多内容请参考 [Istio Handbook——Istio 服务网格进阶实战](https://www.servicemesher.com/istio-handbook)。
在前面这部分 Kubernetes 指南中,我们介绍了一些与 Kubernetes 网络相关的概念。Kubernetes 中的网络可能很棘手,很难理解,如果你刚刚开始,你可能需要一些实践来理解这里。关于服务网格的更多内容请参考 [《Istio 服务网格》](https://jimmysong.io/istio-handbook/)。
在下一部分中,我们将展开更多关于 Kubernetes 的话题:如何开始学习 Kubernetes如何在本地安装和测试 Kubernetes以及 Kubernetes 的一些优秀的监控工具。

View File

@ -2,7 +2,7 @@
本文是如何创建 CRD 来扩展 Kubernetes API 的教程。CRD 是用来扩展 Kubernetes 最常用的方式,在 Service Mesh 和 Operator 中也被大量使用。因此读者如果想在 Kubernetes 上做扩展和开发的话,是十分有必要了解 CRD 的。
在阅读本文前您需要先了解[使用自定义资源扩展 API](custom-resource.md) 以下内容译自 [Kubernetes 官方文档](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/),有删改,推荐阅读[如何从零开始编写一个 Kubernetes CRD](https://www.servicemesher.com/blog/kubernetes-crd-quick-start/)。
在阅读本文前您需要先了解[使用自定义资源扩展 API](custom-resource.md) 以下内容译自 [Kubernetes 官方文档](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/),有删改,推荐阅读[如何从零开始编写一个 Kubernetes CRD](https://cloudnative.to/blog/kubernetes-crd-quick-start/)。
## 创建 CRDCustomResourceDefinition

Binary file not shown.

After

Width:  |  Height:  |  Size: 57 KiB

View File

@ -1,137 +0,0 @@
# 使用Vistio监控Istio服务网格中的流量
Vistio GitHub地址<https://github.com/nmnellis/vistio>
[Vizceral](https://github.com/Netflix/vizceral)是Netflix发布的一个开源项目用于近乎实时地监控应用程序和集群之间的网络流量。Vistio是使用Vizceral对Istio和网格监控的改进。它利用Istio Mixer生成的指标然后将其输入Prometheus。Vistio查询Prometheus并将数据存储在本地以允许重播流量。
Vizceral有两个可视化级别全局可视化和集群级别可视化。在全局范围内如上所示您可以通过Istio Ingress Gateway等入口点将从Internet到Istio服务网格网络的网络流量可视化或者您可以在Istio服务网格网络中显示总网络流量。
在集群级别(如下所示),您可以可视化内部网格的流量。通过设置警告和错误级别警报,当应用程序出现问题时可以被快速检测出来。
![Vistio的集群级别可视化](../images/00704eQkgy1fshft5oxlwj318g0pe0wp.jpg)
### 在Istio服务网格中安装Vistio
**依赖**
- Prometheus
- Istio 0.7或更高版本
**假设**
以下Demo使得这些假设更容易部署。如果您的环境设置不同则可能需要将代码下载到本地并编辑一些文件。
- Prometheus部署在`istio-system` namespace下可以通过`http://prometheus.istio-system:9090`地址访问
- Istio mixer启用了`istio_request_count` metric
- Kubernetes集群包含有`standard` StorageClass
- 为了便于部署已安装了Helm可选
**前言**
如果您还尚未部署服务网格可以按照Istio Bookinfo Demo 中的说明部署Istio及其示例应用程序。您需要能够在应用程序之间生成流量。要测试指标是否从Mixer正确发送到Prometheus您可以运行以下Prometheus查询`istio_request_count`,应该会看到多个条目。
![Prometheus查询](../images/00704eQkgy1fshg0vw25ij318g0jzqjq.jpg)
### 部署Vistio
我们直接使用kubectl命令来部署。
**使用kubectl部署**
```bash
kubectl apply -f https://raw.githubusercontent.com/rootsongjc/kubernetes-handbook/master/manifests/vistio/vistio-mesh-only.yaml -n default
```
### 验证和暴露Vistio Web/API
验证应用程序已经启动并在运行。使用`kubectl port-forward`命令暴露应用程序。
**验证vistio-api**
```bash
kubectl describe statefulset vistio-api -n default
```
**日志检查(可选的)**
您应该能够从vistio-api的日志中查看是否存在与Prometheus的连接/查询相关的错误。
```bash
kubectl logs -n default -c vistio-api $(kubectl -n default get pod -l app=vistio-api -o jsonpath='{.items[0].metadata.name}')
```
**验证vistio-web**
```bash
kubectl describe deployment vistio-web -n default
```
**暴露vistio-api**
我们使用`kubectl port-forward`将vistio-api暴露到[http://localhost:9191](http://localhost:9191/)。
```bash
kubectl -n default port-forward $(kubectl -n default get pod -l app=vistio-api -o jsonpath='{.items[0].metadata.name}') 9091:9091 &
```
**验证visito-api**
vistio-web调用vistio-api来渲染服务网格。访问<http://localhost:9091/graph>您应该会看到类似下列的输出。
![vistio-api的期望输出](../images/00704eQkgy1fshi61t04oj310q17c0y1.jpg)
**暴露Vistio**
在另一个命令行终端中暴露Vizcera UI到[http://localhost:8080](http://localhost:8080/)。
```bash
kubectl -n default port-forward $(kubectl -n default get pod -l app=vistio-web -o jsonpath='{.items[0].metadata.name}') 8080:8080 &
```
**访问Vistio**
如果一切都已经启动并准备就绪您就可以访问Vistio UI开始探索服务网格网络访问[http://localhost:8080](http://localhost:8080/)您将会看到类似下图的输出。
![Vistio主页面](../images/00704eQkgy1fshi98duzgj318g0l2406.jpg)
### 探索
在全局范围内您将看到Istio网格内所有请求的总和。如果您部署了istio-ingressgateway则可以选择显示通过其他配置从网格外部接收的流量参考[使用Ingress Gateway部署Vistio](https://github.com/nmnellis/vistio#deploy-vistio-with-istio-ingress-gateway-helm)。
如果您点击istio-mesh气泡您将能够查看您的网状网络。
![istio mesh的网络流量](../images/00704eQkgy1fshibdwcj3j318g0p8th1.jpg)
在您的Istio网格中您可以使用许多可视化工具来帮助您查明故障的应用程序。
![查明网络问题](../images/00704eQkgy1fshicc7or1j318g0p8ahr.jpg)
使用屏幕右上方的过滤器可以快速过滤出错误率较高的应用程序。通过高级配置,当错误率超过特定值时,也可以触发警报。警报将显示给定应用程序的当前错误率趋势。
### 问题排查
访问<http://localhost:9091/graph>如果您从vistio-api中看到以下输出表示某些功能无法正常工作。正确的输出显示在教程上面。
![vistio api的不正确输出](../images/00704eQkgy1fshie7wxkyj30ks0f4myd.jpg)
**1.** 检查vistio-api日志中是否有错误——在大多数情况下vistio-api将记录与Prometheus通信时遇到的任何问题。
```bash
kubectl logs -n default -c vistio-api $(kubectl -n default get pod -l app=vistio-api -o jsonpath='{.items[0].metadata.name}')
```
**2.** 验证Prometheus查询——vistio-api使用以下查询检索其数据。您应该确保Prometheus内部的数据都存在。
```bash
# Global Level Query
sum(rate(istio_request_count[1m])) by (response_code)
# Cluster Level Query
sum(rate(istio_request_count[1m])) by (source_service,destination_service,response_code)
```
**3.** 提交Issue——如果遇到问题无法解决请提交Issue<https://github.com/nmnellis/vistio/issues>
## 参考
- https://github.com/nmnellis/vistio
- [Vistio—使用Netflix的Vizceral可视化Istio service mesh](https://servicemesher.github.io/blog/vistio-visualize-your-istio-mesh-using-netflixs-vizceral/)

View File

@ -1,16 +0,0 @@
# Conduit - 基于Kubernetes的轻量级Service Mesh
> **注意**Conduit在发布0.5版本后已经停止开发而是合并入Linkerd 2.0,详见[Conduit 0.5发布—以及R.I.P. Conduit](http://www.servicemesher.com/blog/rip-conduit/)。
2017年12月在得克萨斯州的AsdinKubeCon和CloudNativeCon上创造了Service Mesh这个词汇并开源了[Linkerd](https://linkerd.io)的公司[Buoyant](https://buoyant.io)又开源了一款针对Kubernetes的超轻量Service Sesh——[Conduit](https://github.com/runconduit/conduit)。它可以透明得管理服务运行时之间的通信使得在Kubernetes上运行服务更加安全和可靠它还具有不用修改任何应用程序代码即可改进应用程序的可观测性、可靠性及安全性等方面的特性。
Condiut与[Linkerd](https://linkerd.io)的设计方式不同,它跟[Istio](https://istio.io)一样使用的是Sidecar模式但架构又没Istio那么复杂。Conduit只支持Kubernetes且只支持HTTP2包括gRPC协议。
Conduit使用Rust和Go语言开发GitHub地址 https://github.com/runconduit/conduit
安装Conduit必须使用Kubernetes1.8以上版本。
## 参考
- Conduit GitHubhttps://github.com/runconduit/conduit
- 关于Conduit的更多资源请参考官方网站https://conduit.io/

View File

@ -1,292 +0,0 @@
# SOFAMesh中运行Dubbo on x-protocol
**注意:本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。**
原文作者彭泽文阿里巴巴UC事业部高级开发工程师有改动。
X-protocol 的定位是云原生、高性能、低侵入性的通用 Service Mesh 落地方案,依托 Kubernetes 基座,利用其原生的服务注册和服务发现机制,支持各种私有 RPC 协议低成本、易扩展的接入,快速享受 Service Mesh 所带来的红利。
本文将以 [Dubbo](https://dubbo.incubator.apache.org/) 为例,演示 Dubbo on x-protocol 场景下 Service Mesh 路由功能,涵盖 Version route 、Weighted route 功能。
关于 x-protocol 的介绍请参考 [蚂蚁金服开源的 SOFAMesh 的通用协议扩展解析](http://www.servicemesher.com/blog/ant-financial-sofamesh-common-protocol-extension/)。
## 前期准备
1. 部署 Kubernetes 集群,建议使用 https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster
2. 安装 kubectl 命令行工具,请参考 [https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl)
3. 安装 VM Driver推荐安装 Virtual Box、Mac 用户也可以选择 hyperkit
4. 了解 Istio Traffic Management 相关概念
## 部署
先看部署效果图:
![Mosn x-protocol部署图](../images/1536291419546-2aa160de-69cd-497f-a280-fae20a1f87a3.png)
本示例中dubbo-consumer的部署方式采用直连模式即不走注册中心完全依托kubernetes平台提供的服务注册及服务发现能力。
### 1. 安装 Kubernetes
安装 kubectl 命令行工具
推荐使用 Kubernetes 1.10 版本,并使用合适的 VM Driver推荐使用默认的 VirtualBox。
```bash
minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.10.0 \
--extra-config=controller-manager.cluster-signing-cert-file="/var/lib/localkube/certs/ca.crt" \
--extra-config=controller-manager.cluster-signing-key-file="/var/lib/localkube/certs/ca.key"
```
Mac OSX 用户使用的 hyperkit 需要特别指定:
```bash
minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.10.0 \
--extra-config=controller-manager.cluster-signing-cert-file="/var/lib/localkube/certs/ca.crt" \
--extra-config=controller-manager.cluster-signing-key-file="/var/lib/localkube/certs/ca.key" \
--vm-dirver=hyperkit
```
等待 Kubernetes 启动完毕,通过 kubectl 命令检查
```bash
kubectl get pods --namespace=kube-system
```
### 2. 部署 SOFAMesh
本示例演示从源代码的 master 分支直接安装最新的 SOFAMesh安装过程使用 Helm 完成。
从 GitHub 拉取最新代码:
```bash
git clone https://github.com/sofastack/sofa-mesh.git
cd sofa-mesh
```
创建 SOFAMesh 需要的 CRD
```bash
kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml
kubectl apply -f install/kubernetes/helm/istio/charts/certmanager/templates/crds.yaml
```
使用 Helm 安装 SOFAMesh
```bash
kubectl apply -f install/kubernetes/helm/helm-service-account.yaml
helm init --service-account tiller
helm install install/kubernetes/helm/istio --name istio --namespace istio-system
```
安装 istioctl 命令行工具:
```bash
# 使用 make 工具安装 istioctl
make istioctl-install
```
### 3. 创建示例的命名空间
以下示例都将运行在 e2e-dubbo 命名空间下,如无 e2e-dubbo 命名空间,需先创建该命名空间:
```bash
kubectl apply -f samples/e2e-dubbo/platform/kube/e2e-dubbo-ns.yaml
```
### 4. 注入 MOSN
部署 dubbo-consumer 和 dubbo-provider部署前需要先使用 istioctl 进行 sidecar 注入,以下示例采用手动注入方式,也可以通过 istio namespace inject 功能来自动注入。
```bash
# mosn sidecar inject and deploy
kubectl apply -f <(istioctl kube-inject -f samples/e2e-dubbo/platform/kube/dubbo-consumer.yaml)
kubectl apply -f <(istioctl kube-inject -f samples/e2e-dubbo/platform/kube/dubbo-provider-v1.yaml)
kubectl apply -f <(istioctl kube-inject -f samples/e2e-dubbo/platform/kube/dubbo-provider-v2.yaml)
```
### 5. 部署示例应用
部署 dubbo consumer service 及 dubbo provider service。
```bash
# http service for dubbo consumer
kubectl apply -f samples/e2e-dubbo/platform/kube/dubbo-consumer-service.yaml
# dubbo provider service
kubectl apply -f samples/e2e-dubbo/platform/kube/dubbo-provider-service.yaml
```
检查部署状态:
```bash
#kubectl get pods -n e2e-dubbo
NAME READY STATUS RESTARTS AGE
e2e-dubbo-consumer-589d8c465d-cp7cx 2/2 Running 0 13s
e2e-dubbo-provider-v1-649d7cff94-52gfd 2/2 Running 0 13s
e2e-dubbo-provider-v2-5f7d5ff648-m6c45 2/2 Running 0 13s
#kubectl get svc -n e2e-dubbo
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
e2e-dubbo-consumer ClusterIP 192.168.1.7 <none> 8080/TCP 10s
e2e-dubbo-provider ClusterIP 192.168.1.62 <none> 12345/TCP 10s
```
e2e-dubbo-consumer 是一个 Dubbo 客户端应用,它暴露了一个 8080 端口的 HTTP 服务方便我们进行验证e2e-dubbo-provider 是一个 Dubbo 应用。
当 e2e-dubbo-consumer 通过 12345 端口调用 e2e-dubbo-provider 时,流量会被 IPtable 规则拦截,导流给 MOSN。
## 验证路由能力
本示例将验证 Version route 和 Weighted route 能力。
### 1. 验证 Version Route 能力
本例将演示控制 dubbo-consumer的所有请求指向 dubo-provider-v1
配置DestinationRule:
```bash
istioctl create -f samples/e2e-dubbo/platform/kube/dubbo-consumer.destinationrule.yaml
```
`dubbo-consumer.destinationrule.yaml` 内容如下:
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: e2e-dubbo-provider
namespace: e2e-dubbo
spec:
host: e2e-dubbo-provider
subsets:
- name: v1
labels:
ver: v1
- name: v2
labels:
ver: v2
```
配置VirtualService
```bash
istioctl create -f samples/e2e-dubbo/platform/kube/dubbo-consumer.version.vs.yaml
```
`dubbo-consumer.version.vs.yaml` 内容如下:
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: e2e-dubbo-provider
namespace: e2e-dubbo
spec:
hosts:
- e2e-dubbo-provider
http:
- route:
- destination:
host: e2e-dubbo-provider
subset: v1
```
路由策略已经生效,可以 http 请求 dubbo consumer 来触发 rpc 请求观察效果,由于使用 Minikube 的关系,需要启动一个 Pod 用来测试
```bash
# 启动一个 busybox Pod 并登陆
kubectl run -i -t busybox --image=yauritux/busybox-curl --restart=Never
# 使用 e2e-dubbo-consumer 的域名访问服务
curl e2e-dubbo-consumer.e2e-dubbo.svc.cluster.local:8080/sayHello?name=dubbo-mosn
```
清理路由策略:
```bash
istioctl delete -f samples/e2e-dubbo/platform/kube/dubbo-consumer.destinationrule.yaml
istioctl delete -f samples/e2e-dubbo/platform/kube/dubbo-consumer.version.vs.yaml
```
退出 Minikube shell
### 2. 验证 Weight Route 能力
本例将演示控制 dubbo-consumer 的请求指向 dubo-provider-v1dubo-provider-v2。并控制流量分配比例为 v120%v280%。
配置DestinationRule:
```bash
# 如果在上一示例中已经创建好了,请跳过这一步
istioctl create -f samples/e2e-dubbo/platform/kube/dubbo-consumer.destinationrule.yaml
```
`dubbo-consumer.destinationrule.yaml` 内容如下:
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: e2e-dubbo-provider
namespace: e2e-dubbo
spec:
host: e2e-dubbo-provider
subsets:
- name: v1
labels:
ver: v1
- name: v2
labels:
ver: v2
```
配置 VirtualService
```bash
istioctl create -f samples/e2e-dubbo/platform/kube/dubbo-consumer.weight.vs.yaml
```
`dubbo-consumer.weight.vs.yaml` 内容如下:
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: e2e-dubbo-provider
namespace: e2e-dubbo
spec:
hosts:
- e2e-dubbo-provider
http:
- route:
- destination:
host: e2e-dubbo-provider
subset: v1
weight: 20
- destination:
host: e2e-dubbo-provider
subset: v2
weight: 80
```
路由策略已经生效,可以 http 请求 dubbo consumer 来触发 rpc 请求观察效果:
```bash
# 启动一个 busybox Pod 并登陆
kubectl run -i -t busybox --image=yauritux/busybox-curl --restart=Never
# 使用 e2e-dubbo-consumer 的域名访问服务
curl e2e-dubbo-consumer.e2e-dubbo.svc.cluster.local:8080/sayHello?name=dubbo-mosn
```
清理路由策略:
```bash
istioctl delete -f samples/e2e-dubbo/platform/kube/dubbo-consumer.destinationrule.yaml
istioctl delete -f samples/e2e-dubbo/platform/kube/dubbo-consumer.weight.vs.yaml
```
SOFAMesh Github 地址https://github.com/sofastack/sofa-mesh
## 参考文档
- [蚂蚁金服开源的 SOFAMesh 的通用协议扩展解析 - servicemesher.com](http://www.servicemesher.com/blog/ant-financial-sofamesh-common-protocol-extension/)
- [Dubbo quick start - dubbo.incubator.apache.org](https://dubbo.incubator.apache.org/en-us/docs/user/quick-start.html)
- 关于SOFAMesh的更多信息请访问 https://www.sofastack.tech

View File

@ -1,11 +0,0 @@
# 深入理解Istio Service Mesh中的Envoy Sidecar代理的路由转发
**注意:本文基于 Istio 1.5。**
本文以 Istio 官方的 bookinfo 示例来讲解在进入 Pod 的流量被 iptables 转交给 Envoy sidecar 后Envoy 是如何做路由转发的,详述了 Inbound 和 Outbound 处理过程。关于流量拦截的详细分析请参考[理解 Istio Service Mesh 中 Envoy 代理 Sidecar 注入及流量劫持](understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md)。
下面是 Istio 官方提供的 bookinfo 的请求流程图,假设 bookinfo 应用的所有服务中没有配置 DestinationRule。
![Bookinfo 示例](../images/006tNbRwgy1fvlwjd3302j31bo0ro0x5.jpg)
请读者参考 ServiceMesher 社区出品的 Istio Handbook 中的 [Sidecar 流量路由机制分析](https://www.servicemesher.com/istio-handbook/concepts/sidecar-traffic-route.html)一节。

View File

@ -36,3 +36,4 @@ Matt Klein 是在他的文章中指出 sidecar 模式的 proxy 将取代另外
- [Introduction to modern network load balancing and proxying - blog.envoyproxy.io](https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236)
- [Envoy 官方文档中文版 - cloudnative.to](https://cloudnative.to/envoy/)
- [Envoy 基础教程 - jimmysong.io](https://jimmysong.io/envoy-handbook/)

View File

@ -1,6 +1,6 @@
# 集成虚拟机
**注意:本文档已失效,请浏览 [Istio 官方文档](https://istio.io)。本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。**
**注意:本文档已失效,请浏览 [Istio 官方文档](https://istio.io)。本书中的服务网格章节已不再维护,请转到 [istio-handbook](https://jimmysong.io/istio-handbook) 中浏览。**
该示例跨越 Kubernetes 集群和一组虚拟机上部署 Bookinfo 服务,描述如何使用 Istio service mesh 将此基础架构以单一 mesh 的方式操控。

View File

@ -35,7 +35,7 @@ Istio 的代码规范沿用 [CNCF 社区的代码规范](https://github.com/cncf
### 设计文档
所有的设计文档都保存在 [Google Drive](https://drive.google.com/drive/u/0/folders/0AIS5p3eW9BCtUk9PVA) 中,其中包括以下资源:
所有的设计文档都保存在 [Google Drive](https://drive.google.com/drive/folders/0ADmbrU7ueGOUUk9PVA) 中,其中包括以下资源:
- Technical Oversight CommitteeToC管理的文档
- Misc一些杂项

View File

@ -1,6 +1,6 @@
# Istio 教程
**注意:本文档已失效,请浏览 [Istio 官方文档](https://istio.io)。本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。**
**注意:本文档已失效,请浏览 [Istio 官方文档](https://istio.io)。本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://jimmysong.io/istio-handbook/) 中浏览。**
本文是 Istio 管理 Java 微服务的案例教程,使用的所有工具和软件全部基于开源方案,替换了 [redhat-developer-demos/istio-tutorial](https://github.com/redhat-developer-demos/istio-tutorial) 中的 minishift 环境,使用 [kubernetes-vagrant-centos-cluster](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster) 替代,沿用了原有的微服务示例,使用 Zipkin 做分布式追踪而不是 Jaeger。

View File

@ -1,63 +0,0 @@
# Istio 学习资源汇总
在本地搭建起来还是有些门槛,稍显复杂,本文中将向你推荐几个可以在线上学习 Istio 的地方。
## Tetrate 提供的 Istio 基础课程
推荐指数:⭑⭑⭑⭑⭑
推荐原因Tetrate 是企业级服务网格提供商,是 Istio 的核心贡献者之一Tetrate 提供的免费的 Istio 基础课程,其中包括文字加视频讲解,覆盖全面,课后还有自主测试,内容最新最完整。
![Tetrate Istio 基础教程](../images/tetrate-istio-fundamentals.png)
该基础教程已推出[英文版](https://academy.tetrate.io/courses/istio-fundamentals)和[中文版](https://academy.tetrate.io/courses/istio-fundamentals-zh)。
## Katacode 上的 Istio 学习环境
推荐指数:⭑⭑⭑⭑
推荐原因:使用简单,使用官方示例,免费,快速,无需注册,可直接通过互联网访问示例应用页面,支持最新版的 Istio。
你[查看Katacoda 已支持 Istio 的学习环境](https://www.katacoda.com/courses/istio/deploy-istio-on-kubernetes)。
![katacoda](../images/006tNc79gy1ftwe77v4u5j31kw0ziwtw.jpg)
![weavescope](../images/006tNc79gy1ftwhtmzhfej31kw0ziww1.jpg)
只要傻瓜式操作就可以部署一个 Istio 出来,同时还提供了 Weave scope 可以对服务网格的中的服务关系做可视化呈现。
![weavescope](../images/006tNc79gy1ftwhvtu1vxj31kw0zitvc.jpg)
同时还能提供部分监控功能比如服务状态CPU 和内存使用情况。
## 红帽提供的 Istio 教程
推荐指数:⭑⭑⭑⭑
推荐原因:教程章节划分简洁得当,红帽大力加持,[查看详情](https://developers.redhat.com/topics/service-mesh)。
![Red Hat](../images/006tNc79gy1ftwiolw1tyj31kw0zib29.jpg)
![Red Hat developers](../images/006tNc79gy1ftwjyxiw1pj31kw0zi4qp.jpg)
## IBM 的 Istio 示例教程
推荐指数:⭑⭑⭑
推荐原因IBM 作为 Istio 项目的早期参与者,在 Istio 中也有大量的积淀,[查看详情](https://developer.ibm.com/code/patterns/manage-microservices-traffic-using-istio)。
![IBM developerWorks](../images/006tNc79gy1ftweryj0zrj31kw0zix6q.jpg)
![IBM developers](../images/006tNc79gy1ftwesjg1e2j31kw0s8woq.jpg)
## Istio Handbook
推荐指数:⭑⭑⭑⭑⭑
推荐原因:由 ServiceMesher 共同撰写的开源 Istio 电子书,这本书是社区经验的结晶,你可以[查看本书的预览版](https://www.servicemesher.com/istio-handbook/),实体书将于 2022 年春季上市。
## Istio Workshop 视频教程
推荐指数:⭑⭑⭑⭑⭑
推荐原因:由笔者出品,图文并茂的定期更新 Istio 视频教程,你可以在 [Bilibili](https://space.bilibili.com/515485124/channel/collectiondetail?sid=184924) 或者[云原生社区](https://cloudnative.to)的视频号上查看合集。

View File

@ -1,4 +1,4 @@
# Istio简介
# Istio
[Istio](https://istio.io) 是由 Google、IBM 和 Lyft 开源的微服务管理、保护和监控框架。Istio 为希腊语,意思是”起航“。
@ -112,6 +112,6 @@ Galley 是 Istio 的配置验证、提取、处理和分发组件。它负责将
## 参考
- [Istio一个用于微服务间通信的服务网格开源项目](https://www.infoq.cn/article/2017/05/istio)
- [Istio 是什么?](https://istio.io/docs/concepts/what-is-istio/)
- [Istio Handbook —— Istio 服务网格进阶实战](https://www.servicemesher.com/istio-handbook)
- [Istio一个用于微服务间通信的服务网格开源项目 - infoq.cn](https://www.infoq.cn/article/2017/05/istio)
- [Istio 是什么?- istio.io](https://istio.io/docs/concepts/what-is-istio/)
- [Istio 服务网格—— 云原生应用网络构建指南 - jimmysong.io](https://jimmysong.io/istio-handbook/)

View File

@ -1,122 +0,0 @@
# Linkerd简介
> **注意**Linkerd最初版本是使用Scala开发的现在已开始开发Linkerd2使用Go语言开发该公司的另一款轻量级Service Mesh conduit也寿终正寝合并入Linkerd 2.0,详见[Conduit 0.5发布—以及R.I.P. Conduit](http://www.servicemesher.com/blog/rip-conduit/)。
Linkerd是一个用于云原生应用的开源、可扩展的service mesh服务网格
## Linkerd是什么
Linkerd的出现是为了解决像twitter、google这类超大规模生产系统的复杂性问题。Linkerd不是通过控制服务之间的通信机制来解决这个问题而是通过在服务实例之上添加一个抽象层来解决的。
![source https://linkerd.io](../images/diagram-individual-instance.png)
Linkerd负责跨服务通信中最困难、易出错的部分包括延迟感知、负载平衡、连接池、TLS、仪表盘、请求路由等——这些都会影响应用程序伸缩性、性能和弹性。
## 如何运行
Linkerd作为独立代理运行无需特定的语言和库支持。应用程序通常会在已知位置运行linkerd实例然后通过这些实例代理服务调用——即不是直接连接到目标服务服务连接到它们对应的linkerd实例并将它们视为目标服务。
在该层上linkerd应用路由规则与现有服务发现机制通信对目标实例做负载均衡——与此同时调整通信并报告指标。
通过延迟调用linkerd的机制应用程序代码与以下内容解耦
- 生产拓扑
- 服务发现机制
- 负载均衡和连接管理逻辑
应用程序也将从一致的全局流量控制系统中受益。这对于多语言应用程序尤其重要,因为通过库来实现这种一致性是非常困难的。
Linkerd实例可以作为sidecar既为每个应用实体或每个主机部署一个实例来运行。 由于linkerd实例是无状态和独立的因此它们可以轻松适应现有的部署拓扑。它们可以与各种配置的应用程序代码一起部署并且基本不需要去协调它们。
## 详解
Linkerd 的基于 Kubernetes 的 Service Mesh 部署方式是使用 Kubernetes 中的 **DaemonSet** 资源对象,如下图所示。
![Linkerd 部署架构图片来自https://buoyant.io/2016/10/14/a-service-mesh-for-kubernetes-part-ii-pods-are-great-until-theyre-not/](https://buoyant.io/wp-content/uploads/2017/07/buoyant-k8s-daemonset-mesh.png)
这样 Kubernetes 集群中的每个节点都会运行一个 Linkerd 的 Pod。
但是这样做就会有几个问题:
- 节点上的应用如何发现其所在节点上的 Linkerd 呢?
- 节点间的 Linkerd 如何路由的呢?
- Linkerd 如何将接收到的流量路由到正确的目的应用呢?
- 如何对应用的路有做细粒度的控制?
这几个问题在 Buoyant 公司的这篇博客中都有解答:[A Service Mesh for Kubernetes, Part II: Pods are great until theyre not](https://buoyant.io/2016/10/14/a-service-mesh-for-kubernetes-part-ii-pods-are-great-until-theyre-not/),我们下面将简要的回答上述问题。
### 节点上的应用如何发现其所在节点上的 Linkerd 呢?
简而言之,是使用环境变量的方式,如在应用程序中注入环境变量 `http_proxy`
```yaml
env:
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: http_proxy
value: $(NODE_NAME):4140
args:
- "-addr=:7777"
- "-text=Hello"
- "-target=world"
```
这要求应用程序必须支持该环境变量,为应用程序所在的 Pod 设置了一个代理,实际上对于每种不同的协议 Linkerd 都监听不同的端口。
- 4140 for HTTP
- 4240 for HTTP/2
- 4340 for gRPC
关于 Linkerd 作为 Service Mesh 的详细配置请参考 [serivcemesh.yml](https://github.com/rootsongjc/kubernetes-handbook/blob/master/manifests/linkerd/servicemesh.yml)。
### 节点间的 Linkerd 如何路由的以及 Linkerd 如何将接收到的流量路由到正确的目的应用呢?
通过 **transformer** 来确定节点间的 Linkerd 路由,参考下面的配置:
```yaml
routers:
- protocol: http
label: outgoing
interpreter:
kind: default
transformers:
- kind: io.l5d.k8s.daemonset
namespace: default
port: incoming
service: l5d
```
Router 定义 Linkerd 如何实际地处理流量。Router 监听请求并在这些请求上应用路有规则代理这些请求到正确的目的地。Router 是与协议相关的。对于每个 Router 都需要定义一个 incoming router 和一个 outcoming router。预计该应用程序将流量发送到 outcoming router该 outcoming router 将其代理到目标服务节点上运行的 Linkerd 的 incoming router。Incoming router 后将请求代理给目标应用程序本身。我们还定义了 HTTP 和 HTTP/2 incoming router它们充当 Ingress controller 并基于 Ingress 资源进行路由。
### 如何对路由规则做细粒度的控制呢?
路由规则配置是在 namerd 中进行的,例如:
```ini
$ namerctl dtab get internal
# version MjgzNjk5NzI=
/srv => /#/io.l5d.k8s/default/http ;
/host => /srv ;
/tmp => /srv ;
/svc => /host ;
/host/world => /srv/world-v1 ;
```
Namerd 中存储了很多 dtab 配置,通过这些配置来管理路有规则,实现微服务的流量管理。
![基于 dtab 的路由规则配置阶段发布](https://buoyant.io/wp-content/uploads/2017/07/buoyant-4_override.png)
如果将 Linkerd 作为*边缘节点*还可以充当 Ingress controller如下图所示。
![Linkerd ingress controller](https://buoyant.io/wp-content/uploads/2017/07/buoyant-k8s-hello-world-ingress-controller-1.png)
Linkerd 自己最令人称道的是它在每台主机上只安装一个 Pod如果使用 Sidecar 模式会为每个应用程序示例旁都运行一个容器,这样会导致过多的资源消耗。[Squeezing blood from a stone: small-memory JVM techniques for microservice sidecars](https://buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/) 这篇文章中详细说明了 Linkerd 的资源消耗与性能。
## 参考
- [A Service Mesh for Kubernetes, Part II: Pods are great until theyre not](https://buoyant.io/2016/10/14/a-service-mesh-for-kubernetes-part-ii-pods-are-great-until-theyre-not/)
- [Squeezing blood from a stone: small-memory JVM techniques for microservice sidecars](https://buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/)
- [Buoyant发布服务网格Linkerd的1.0版本](http://www.infoq.com/cn/news/2017/05/buoyant-release-ver-1-of-linkerd)
- [Linkerd documentation](https://linkerd.io/documentation/)