diff --git a/README.md b/README.md index e169ce67e..fe261d991 100644 --- a/README.md +++ b/README.md @@ -91,7 +91,7 @@ Kubernetes Handbook 项目始于 2016 年底，开源于 2017 年 3 月，作为

- 加入云原生社区 + 加入云原生社区

diff --git a/SUMMARY.md b/SUMMARY.md index 3e99e96ca..2a3933b90 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -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) diff --git a/appendix/kubernetes-and-cloud-native-summary-in-2018-and-outlook-for-2019.md b/appendix/kubernetes-and-cloud-native-summary-in-2018-and-outlook-for-2019.md index 45803e403..435e33bdc 100644 --- a/appendix/kubernetes-and-cloud-native-summary-in-2018-and-outlook-for-2019.md +++ b/appendix/kubernetes-and-cloud-native-summary-in-2018-and-outlook-for-2019.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 diff --git a/cloud-native/quick-start.md b/cloud-native/quick-start.md index 1b4ec8ce0..2167ea9c0 100644 --- a/cloud-native/quick-start.md +++ b/cloud-native/quick-start.md @@ -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 的一些优秀的监控工具。 diff --git a/concepts/crd.md b/concepts/crd.md index 7340634b2..86c4c0348 100644 --- a/concepts/crd.md +++ b/concepts/crd.md @@ -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） diff --git a/images/github-banner.jpg b/images/github-banner.jpg new file mode 100644 index 000000000..f80515357 Binary files /dev/null and b/images/github-banner.jpg differ diff --git a/practice/vistio-visualize-your-istio-mesh.md b/practice/vistio-visualize-your-istio-mesh.md deleted file mode 100644 index 8f4b95498..000000000 --- a/practice/vistio-visualize-your-istio-mesh.md +++ /dev/null @@ -1,137 +0,0 @@ -# 使用Vistio监控Istio服务网格中的流量 - -Vistio GitHub地址： - -[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来渲染服务网格。访问您应该会看到类似下列的输出。 - -![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) - -使用屏幕右上方的过滤器可以快速过滤出错误率较高的应用程序。通过高级配置，当错误率超过特定值时，也可以触发警报。警报将显示给定应用程序的当前错误率趋势。 - -### 问题排查 - -访问，如果您从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 -- [Vistio—使用Netflix的Vizceral可视化Istio service mesh](https://servicemesher.github.io/blog/vistio-visualize-your-istio-mesh-using-netflixs-vizceral/) diff --git a/usecases/conduit.md b/usecases/conduit.md deleted file mode 100644 index c0f542c6e..000000000 --- a/usecases/conduit.md +++ /dev/null @@ -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/ diff --git a/usecases/dubbo-on-x-protocol-in-sofa-mesh.md b/usecases/dubbo-on-x-protocol-in-sofa-mesh.md deleted file mode 100644 index e3fcf9c42..000000000 --- a/usecases/dubbo-on-x-protocol-in-sofa-mesh.md +++ /dev/null @@ -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 8080/TCP 10s -e2e-dubbo-provider ClusterIP 192.168.1.62 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 diff --git a/usecases/envoy-sidecar-routing-of-istio-service-mesh-deep-dive.md b/usecases/envoy-sidecar-routing-of-istio-service-mesh-deep-dive.md deleted file mode 100644 index c89e673ea..000000000 --- a/usecases/envoy-sidecar-routing-of-istio-service-mesh-deep-dive.md +++ /dev/null @@ -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)一节。 \ No newline at end of file diff --git a/usecases/envoy.md b/usecases/envoy.md index dcb02b9ce..aa09f037c 100644 --- a/usecases/envoy.md +++ b/usecases/envoy.md @@ -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/) diff --git a/usecases/integrating-vms.md b/usecases/integrating-vms.md index 9ff108478..06df7ee9c 100644 --- a/usecases/integrating-vms.md +++ b/usecases/integrating-vms.md @@ -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 的方式操控。 diff --git a/usecases/istio-community-tips.md b/usecases/istio-community-tips.md index 0d396a308..4c5285c12 100644 --- a/usecases/istio-community-tips.md +++ b/usecases/istio-community-tips.md @@ -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：一些杂项 diff --git a/usecases/istio-tutorial.md b/usecases/istio-tutorial.md index d6de52191..b3e912d9e 100644 --- a/usecases/istio-tutorial.md +++ b/usecases/istio-tutorial.md @@ -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。 diff --git a/usecases/istio-tutorials-collection.md b/usecases/istio-tutorials-collection.md deleted file mode 100644 index 136b9e6ef..000000000 --- a/usecases/istio-tutorials-collection.md +++ /dev/null @@ -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)的视频号上查看合集。 \ No newline at end of file diff --git a/usecases/istio.md b/usecases/istio.md index 99e36b98d..171964ec4 100644 --- a/usecases/istio.md +++ b/usecases/istio.md @@ -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/) diff --git a/usecases/linkerd.md b/usecases/linkerd.md deleted file mode 100644 index ae9dd4315..000000000 --- a/usecases/linkerd.md +++ /dev/null @@ -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/)