remove outdated content
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服务网格网络中显示总网络流量。
|
||||
|
||||
在集群级别(如下所示),您可以可视化内部网格的流量。通过设置警告和错误级别警报,当应用程序出现问题时可以被快速检测出来。
|
||||
|
||||
![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/)
|
|
@ -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 相关概念
|
||||
|
||||
## 部署
|
||||
|
||||
先看部署效果图:
|
||||
|
||||
![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
|
|
@ -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)一节。
|
|
@ -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 基础课程,其中包括文字加视频讲解,覆盖全面,课后还有自主测试,内容最新最完整。
|
||||
|
||||
![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)的视频号上查看合集。
|
|
@ -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不是通过控制服务之间的通信机制来解决这个问题,而是通过在服务实例之上添加一个抽象层来解决的。
|
||||
|
||||
![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/)
|
Loading…
Reference in New Issue