rootsongjc
/
kubernetes-handbook
mirror of https://github.com/rootsongjc/kubernetes-handbook.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -91,7 +91,7 @@ Kubernetes Handbook 项目始于 2016 年底，开源于 2017 年 3 月，作为
<p align="center"> <p align="center">
<a href="https://cloudnative.to"> <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> </a>
</p> </p>

2
SUMMARY.md
View File

@ -225,9 +225,7 @@
* [使用 Istio 前需要考虑的问题](usecases/before-using-istio.md) * [使用 Istio 前需要考虑的问题](usecases/before-using-istio.md)
* [Istio 中 sidecar 的注入规范及示例](usecases/sidecar-spec-in-istio.md) * [Istio 中 sidecar 的注入规范及示例](usecases/sidecar-spec-in-istio.md)
* [如何参与 Istio 社区及注意事项](usecases/istio-community-tips.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) * [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/how-to-integrate-istio-with-vm.md)
* [Istio 支持虚拟机的历史](usecases/istio-vm-support.md) * [Istio 支持虚拟机的历史](usecases/istio-vm-support.md)
* [Envoy](usecases/envoy.md) * [Envoy](usecases/envoy.md)

10
appendix/kubernetes-and-cloud-native-summary-in-2018-and-outlook-for-2019.md
View File

@ -80,14 +80,14 @@ Kubernetes 并不直接对外提供业务能力，而是作为应用运行的底
- 2018 年 5 月 30 日，[Envoy 最新官方文档中文版发布 —— 由 Service Mesh 爱好者倾情奉献](https://www.servicemesher.com/envoy/)。 - 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 月 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 日，[开启新域名 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 月，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 年 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://www.servicemesher.com/blog/service-mesh-meetup-shenzhen-20180825/)。 - 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 年 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 月 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/)。 - 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://www.servicemesher.com/blog/service-mesh-meetup-guangzhou-20190106/)。 - 2019 年 1 月 6 日，举办了第五届 Service Mesh Meetup 广州站，见[第五届 Service Mesh Meetup 广州站活动回顾与资料下载](https://cloudnative.to/blog/service-mesh-meetup-guangzhou-20190106/)。
## Serverless ## Serverless

2
cloud-native/quick-start.md
View File

@ -116,7 +116,7 @@ kubectl 是一个命令行工具，用于与 Kubernetes 集群和其中的 pod
如果没有服务网格，对容器来说这项工作将十分繁琐，因为这涉及到逐一更改所有其他容器上的配置，将它们所包含的服务从 Container1 指向 Container2，然后在测试失败后，将它们全部改回来。 如果没有服务网格，对容器来说这项工作将十分繁琐，因为这涉及到逐一更改所有其他容器上的配置，将它们所包含的服务从 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 的一些优秀的监控工具。 在下一部分中，我们将展开更多关于 Kubernetes 的话题：如何开始学习 Kubernetes，如何在本地安装和测试 Kubernetes，以及 Kubernetes 的一些优秀的监控工具。

2
concepts/crd.md
View File

@ -2,7 +2,7 @@
本文是如何创建 CRD 来扩展 Kubernetes API 的教程。CRD 是用来扩展 Kubernetes 最常用的方式，在 Service Mesh 和 Operator 中也被大量使用。因此读者如果想在 Kubernetes 上做扩展和开发的话，是十分有必要了解 CRD 的。 本文是如何创建 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） ## 创建 CRD（CustomResourceDefinition）

BIN
images/github-banner.jpg 100644
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 57 KiB

137
practice/vistio-visualize-your-istio-mesh.md
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/)

16
usecases/conduit.md
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月在得克萨斯州的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/

292
usecases/dubbo-on-x-protocol-in-sofa-mesh.md
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-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

11
usecases/envoy-sidecar-routing-of-istio-service-mesh-deep-dive.md
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)一节。

1
usecases/envoy.md
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) - [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 官方文档中文版 - cloudnative.to](https://cloudnative.to/envoy/)
- [Envoy 基础教程 - jimmysong.io](https://jimmysong.io/envoy-handbook/)

2
usecases/integrating-vms.md
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 的方式操控。 该示例跨越 Kubernetes 集群和一组虚拟机上部署 Bookinfo 服务，描述如何使用 Istio service mesh 将此基础架构以单一 mesh 的方式操控。

2
usecases/istio-community-tips.md
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 Committee：ToC管理的文档 - Technical Oversight Committee：ToC管理的文档
- Misc：一些杂项 - Misc：一些杂项

2
usecases/istio-tutorial.md
View File

@ -1,6 +1,6 @@
# Istio 教程 # 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。 本文是 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。

63
usecases/istio-tutorials-collection.md
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)的视频号上查看合集。

8
usecases/istio.md
View File

@ -1,4 +1,4 @@
# Istio简介 # Istio
[Istio](https://istio.io) 是由 Google、IBM 和 Lyft 开源的微服务管理、保护和监控框架。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：一个用于微服务间通信的服务网格开源项目 - infoq.cn](https://www.infoq.cn/article/2017/05/istio)
- [Istio 是什么？](https://istio.io/docs/concepts/what-is-istio/) - [Istio 是什么？- istio.io](https://istio.io/docs/concepts/what-is-istio/)
- [Istio Handbook —— Istio 服务网格进阶实战](https://www.servicemesher.com/istio-handbook) - [Istio 服务网格—— 云原生应用网络构建指南 - jimmysong.io](https://jimmysong.io/istio-handbook/)

122
usecases/linkerd.md
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 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 配置，通过这些配置来管理路有规则，实现微服务的流量管理。
![基于 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 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/)