remove outdated content
Jimmy Song
parent
a02790894e
commit
a275b0a1f1
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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 的一些优秀的监控工具。
|
||||
|
||||
|
|
|
|||
|
|
@ -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/)。
|
||||
|
||||
## 创建 CRD（CustomResourceDefinition）
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 57 KiB |
|
|
@ -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服务网格网络中显示总网络流量。
|
||||
|
||||
在集群级别（如下所示），您可以可视化内部网格的流量。通过设置警告和错误级别警报，当应用程序出现问题时可以被快速检测出来。
|
||||
|
||||
|
||||
|
||||
### 在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`，应该会看到多个条目。
|
||||
|
||||
|
||||
|
||||
### 部署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**
|
||||
|
||||
在另一个命令行终端中，暴露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/)您将会看到类似下图的输出。
|
||||
|
||||
|
||||
|
||||
### 探索
|
||||
|
||||
在全局范围内，您将看到Istio网格内所有请求的总和。如果您部署了istio-ingressgateway，则可以选择显示通过其他配置从网格外部接收的流量，参考[使用Ingress Gateway部署Vistio](https://github.com/nmnellis/vistio#deploy-vistio-with-istio-ingress-gateway-helm)。
|
||||
|
||||
如果您点击istio-mesh气泡，您将能够查看您的网状网络。
|
||||
|
||||
|
||||
|
||||
在您的Istio网格中，您可以使用许多可视化工具来帮助您查明故障的应用程序。
|
||||
|
||||
|
||||
|
||||
使用屏幕右上方的过滤器可以快速过滤出错误率较高的应用程序。通过高级配置，当错误率超过特定值时，也可以触发警报。警报将显示给定应用程序的当前错误率趋势。
|
||||
|
||||
### 问题排查
|
||||
|
||||
访问<http://localhost:9091/graph>，如果您从vistio-api中看到以下输出，表示某些功能无法正常工作。正确的输出显示在教程上面。
|
||||
|
||||
|
||||
|
||||
**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/)
|
||||
|
|
@ -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月在得克萨斯州的Asdin，KubeCon和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 GitHub：https://github.com/runconduit/conduit
|
||||
- 关于Conduit的更多资源请参考官方网站：https://conduit.io/
|
||||
|
|
@ -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 相关概念
|
||||
|
||||
## 部署
|
||||
|
||||
先看部署效果图：
|
||||
|
||||
|
||||
|
||||
本示例中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-v1，dubo-provider-v2。并控制流量分配比例为 v1：20%，v2：80%。
|
||||
|
||||
配置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
|
||||
|
|
@ -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。
|
||||
|
||||
|
||||
|
||||
请读者参考 ServiceMesher 社区出品的 Istio Handbook 中的 [Sidecar 流量路由机制分析](https://www.servicemesher.com/istio-handbook/concepts/sidecar-traffic-route.html)一节。
|
||||
|
|
@ -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/)
|
||||
|
|
|
|||
|
|
@ -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 的方式操控。
|
||||
|
||||
|
|
|
|||
|
|
@ -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 Committee：ToC管理的文档
|
||||
- Misc：一些杂项
|
||||
|
|
|
|||
|
|
@ -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。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,63 +0,0 @@
|
|||
# Istio 学习资源汇总
|
||||
|
||||
在本地搭建起来还是有些门槛，稍显复杂，本文中将向你推荐几个可以在线上学习 Istio 的地方。
|
||||
|
||||
## Tetrate 提供的 Istio 基础课程
|
||||
|
||||
推荐指数：⭑⭑⭑⭑⭑
|
||||
|
||||
推荐原因：Tetrate 是企业级服务网格提供商，是 Istio 的核心贡献者之一，Tetrate 提供的免费的 Istio 基础课程，其中包括文字加视频讲解，覆盖全面，课后还有自主测试，内容最新最完整。
|
||||
|
||||
|
||||
|
||||
该基础教程已推出[英文版](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)。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
只要傻瓜式操作就可以部署一个 Istio 出来，同时还提供了 Weave scope 可以对服务网格的中的服务关系做可视化呈现。
|
||||
|
||||
|
||||
|
||||
同时还能提供部分监控功能，比如服务状态，CPU 和内存使用情况。
|
||||
|
||||
## 红帽提供的 Istio 教程
|
||||
|
||||
推荐指数：⭑⭑⭑⭑
|
||||
|
||||
推荐原因：教程章节划分简洁得当，红帽大力加持，[查看详情](https://developers.redhat.com/topics/service-mesh)。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## IBM 的 Istio 示例教程
|
||||
|
||||
推荐指数：⭑⭑⭑
|
||||
|
||||
推荐原因：IBM 作为 Istio 项目的早期参与者，在 Istio 中也有大量的积淀，[查看详情](https://developer.ibm.com/code/patterns/manage-microservices-traffic-using-istio)。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 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)的视频号上查看合集。
|
||||
|
|
@ -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/)
|
||||
|
|
|
|||
|
|
@ -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不是通过控制服务之间的通信机制来解决这个问题，而是通过在服务实例之上添加一个抽象层来解决的。
|
||||
|
||||
|
||||
|
||||
Linkerd负责跨服务通信中最困难、易出错的部分，包括延迟感知、负载平衡、连接池、TLS、仪表盘、请求路由等——这些都会影响应用程序伸缩性、性能和弹性。
|
||||
|
||||
## 如何运行
|
||||
|
||||
Linkerd作为独立代理运行，无需特定的语言和库支持。应用程序通常会在已知位置运行linkerd实例，然后通过这些实例代理服务调用——即不是直接连接到目标服务，服务连接到它们对应的linkerd实例，并将它们视为目标服务。
|
||||
|
||||
在该层上，linkerd应用路由规则，与现有服务发现机制通信，对目标实例做负载均衡——与此同时调整通信并报告指标。
|
||||
|
||||
通过延迟调用linkerd的机制，应用程序代码与以下内容解耦：
|
||||
|
||||
- 生产拓扑
|
||||
- 服务发现机制
|
||||
- 负载均衡和连接管理逻辑
|
||||
|
||||
应用程序也将从一致的全局流量控制系统中受益。这对于多语言应用程序尤其重要，因为通过库来实现这种一致性是非常困难的。
|
||||
|
||||
Linkerd实例可以作为sidecar（既为每个应用实体或每个主机部署一个实例）来运行。 由于linkerd实例是无状态和独立的，因此它们可以轻松适应现有的部署拓扑。它们可以与各种配置的应用程序代码一起部署，并且基本不需要去协调它们。
|
||||
|
||||
## 详解
|
||||
|
||||
Linkerd 的基于 Kubernetes 的 Service Mesh 部署方式是使用 Kubernetes 中的 **DaemonSet** 资源对象，如下图所示。
|
||||
|
||||
|
||||
|
||||
这样 Kubernetes 集群中的每个节点都会运行一个 Linkerd 的 Pod。
|
||||
|
||||
但是这样做就会有几个问题：
|
||||
|
||||
- 节点上的应用如何发现其所在节点上的 Linkerd 呢？
|
||||
- 节点间的 Linkerd 如何路由的呢？
|
||||
- Linkerd 如何将接收到的流量路由到正确的目的应用呢？
|
||||
- 如何对应用的路有做细粒度的控制？
|
||||
|
||||
这几个问题在 Buoyant 公司的这篇博客中都有解答：[A Service Mesh for Kubernetes, Part II: Pods are great until they’re 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 配置，通过这些配置来管理路有规则，实现微服务的流量管理。
|
||||
|
||||
|
||||
|
||||
如果将 Linkerd 作为*边缘节点*还可以充当 Ingress controller，如下图所示。
|
||||
|
||||
|
||||
|
||||
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 they’re 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/)
|
||||
Loading…
Reference in New Issue