diff --git a/README.md b/README.md index d855a8237..5a61310bd 100644 --- a/README.md +++ b/README.md @@ -2,6 +2,8 @@ [Kubernetes](http://kubernetes.io)是Google基于[Borg](https://research.google.com/pubs/pub43438.html)开源的容器编排调度引擎,作为[CNCF](https://cncf.io)(Cloud Native Computing Foundation)最重要的组件之一,它的目标不仅仅是一个编排系统,而是提供一个规范,可以让你来描述集群的架构,定义服务的最终状态,Kubernetes可以帮你将系统自动地达到和维持在这个状态。Kubernetes作为云原生应用的基石,相当于一个云操作系统,其重要性不言而喻。 +云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括**容器**、**服务网格**、**微服务**、**不可变基础设施**和**声明式API**。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。——CNCF(云原生计算基金会)。 + ## 关于本书

@@ -16,7 +18,7 @@

-本书起始于2017年3月,记录了本人从零开始学习和使用Kubernetes的心路历程,着重于经验分享和总结,同时也会有相关的概念解析,希望能够帮助大家少踩坑,少走弯路,还会指引大家关注Kubernetes生态周边,如微服务构建、DevOps、大数据应用、[Service Mesh](https://jimmysong.io/posts/what-is-a-service-mesh/)、Cloud Native等领域。 +本书开源于2017年3月,是第一本系统整理的开源中文版Kubernetes参考资料,记录了本人从零开始学习和使用Kubernetes的历程,着重于总结和资料分享,同时也会有相关的概念解析,希望能够帮助大家少踩坑,少走弯路,还会指引大家关注Kubernetes生态周边,如微服务构建、DevOps、大数据应用、[Service Mesh](https://jimmysong.io/blog/what-is-a-service-mesh/)、Cloud Native等领域。 ### 开始之前 @@ -35,7 +37,6 @@ - 云原生开源组件 - 云原生应用与微服务架构 - 基于Kubernetes的Service Mesh架构 -- Kubernetes与微服务结合实践 起初写作本书时,安装的所有组件、所用示例和操作等皆基于 **Kubernetes 1.6+** 版本,同时我们也将密切关注Kubernetes的版本更新,随着它的版本更新升级,本书中的Kubernetes版本和示例也将随之更新。 @@ -49,7 +50,7 @@ - 按照[说明](https://github.com/rootsongjc/kubernetes-handbook/blob/master/CODE_OF_CONDUCT.md)自行编译成离线版本 - Fork 一份添加你自己的笔记自行维护,有余力者可以一起参与进来 -**注意:本书中的 Service Mesh 相关内容已不再维护,请转至 [istio-handbook](https://www.servicemesher.com/istio-handbook) 浏览。** +**注意:Service Mesh 已成立独立的 [istio-handbook](https://www.servicemesher.com/istio-handbook),本书中的 Service Mesh 相关内容已不再维护。** ## 快速开始 @@ -77,18 +78,14 @@ ## 社区&读者交流 -- **与我联系**:加入云原生社区群,扫描[我的微信二维码](https://jimmysong.io/about),添加时请备注姓名-公司/学校/组织/机构等。 -- **Slack**:全球中文用户可以加入[Kubernetes官方Slack](http://slack.k8s.io)中文频道**cn-users channel** +- **云原生社区**:添加 *jimmysongio* 微信,备注姓名-公司/学校/组织/机构等,并注明加入云原生社区。 - **知乎专栏**:[云原生应用架构](https://zhuanlan.zhihu.com/cloud-native) +- **与我联系**: -- **ServiceMesher社区**:ServiceMesher 社区是由一群拥有相同价值观和理念的志愿者们共同发起,成立于 2018 年 4 月。社区关注领域有:Kubernetes、微服务、Service Mesh、Serverless,拥抱开源和云原生,致力于推动 Service Mesh 在中国的蓬勃发展。[加入组织](https://www.servicemesher.com/contact/)。 -

- ServiceMesher微信公众号二维码 -

## 云原生出版物 -以下为本人参与出版云原生相关的图书。 +以下为本人参与出版的云原生相关图书。 - [Cloud Native Go](https://jimmysong.io/book/cloud-native-go/) - 基于Go和React的web云原生应用构建指南(Kevin Hoffman & Dan Nemeth著 宋净超 吴迎松 徐蓓 马超 译),电子工业出版社,2017年6月出版 - [Python云原生](https://jimmysong.io/book/cloud-native-python/) - 使用Python和React构建云原生应用(Manish Sethi著,宋净超译),电子工业出版社,2018年6月出版 @@ -97,8 +94,8 @@ ## 推荐 -- [极客时间专栏《深入剖析 Kubernetes》](https://tva1.sinaimg.cn/large/006y8mN6ly1g7vf4p12rpj30u01hdjwp.jpg) -- [MOSN](https://github.com/mosn/mosn) - 一款使用 Go 语言开发的开源的 Service Mesh 数据平面代理,旨在为服务提供分布式、模块化、可观察和智能化的代理能力。 +- 快速入门学习 Kubernetes,请阅读[极客时间专栏《深入剖析 Kubernetes》](https://tva1.sinaimg.cn/large/006y8mN6ly1g7vf4p12rpj30u01hdjwp.jpg) +- 学习 Service Mesh,请加入 [ServiceMesher 社区](https://www.servicemesher.com) ## 支持本书 diff --git a/SUMMARY.md b/SUMMARY.md index 69c01f201..baccbbb66 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -1,4 +1,4 @@ -# Summary +# 目录 ## 前言 @@ -206,15 +206,11 @@ * [总结](usecases/service-mesh-conclusion.md) * [Istio](usecases/istio.md) * [安装并试用Istio service mesh](usecases/istio-installation.md) - * [配置请求的路由规则](usecases/configuring-request-routing.md) - * [安装和拓展Istio service mesh](usecases/install-and-expand-istio-mesh.md) - * [集成虚拟机](usecases/integrating-vms.md) * [Istio中sidecar的注入规范及示例](usecases/sidecar-spec-in-istio.md) * [如何参与Istio社区及注意事项](usecases/istio-community-tips.md) - * [Istio教程](usecases/istio-tutorial.md) * [Istio免费学习资源汇总](usecases/istio-tutorials-collection.md) - * [深入理解Istio Service Mesh中的Envoy Sidecar注入与流量劫持](usecases/understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md) - * [深入理解Istio Service Mesh中的Envoy Sidecar代理的路由转发](usecases/envoy-sidecar-routing-of-istio-service-mesh-deep-dive.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) * [Linkerd](usecases/linkerd.md) * [Linkerd 使用指南](usecases/linkerd-user-guide.md) * [Conduit](usecases/conduit.md) @@ -224,17 +220,14 @@ * [Envoy的架构与基本术语](usecases/envoy-terminology.md) * [Envoy作为前端代理](usecases/envoy-front-proxy.md) * [Envoy mesh教程](usecases/envoy-mesh-in-kubernetes-tutorial.md) - * [SOFAMesh](usecases/sofamesh.md) - * [SOFAMesh中的Dubbo on x-protocol](usecases/dubbo-on-x-protocol-in-sofa-mesh.md) - * [MOSN](usecases/sofamosn.md) - * [使用 MOSN 构建 SOFAMesh](usecases/sofamosn-in-sofamesh.md) * [大数据](usecases/big-data.md) * [Spark standalone on Kubernetes](usecases/spark-standalone-on-kubernetes.md) * [运行支持Kubernetes原生调度的Spark程序](usecases/running-spark-with-kubernetes-native-scheduler.md) * [Serverless架构](usecases/serverless.md) * [理解Serverless](usecases/understanding-serverless.md) - * [FaaS-函数即服务](usecases/faas.md) + * [FaaS(函数即服务)](usecases/faas.md) * [OpenFaaS快速入门指南](usecases/openfaas-quick-start.md) + * [Knative](usecases/knative.md) * [边缘计算](usecases/edge-computing.md) * [人工智能](usecases/ai.md) @@ -282,7 +275,7 @@ * [Kubernetes1.15更新日志](appendix/kubernetes-1.15-changelog.md) * [Kubernetes及云原生年度总结及展望](appendix/summary-and-outlook.md) * [Kubernetes与云原生2017年年终总结及2018年展望](appendix/kubernetes-and-cloud-native-summary-in-2017-and-outlook-for-2018.md) - * [Kubernetes与云原生2018年年中总结及2019年展望](appendix/kubernetes-and-cloud-native-summary-in-2018-and-outlook-for-2019.md) + * [Kubernetes与云原生2018年年终总结及2019年展望](appendix/kubernetes-and-cloud-native-summary-in-2018-and-outlook-for-2019.md) * [CNCF年度报告解读](appendix/cncf-annual-report.md) * [CNCF 2018年年度报告解读](appendix/cncf-annual-report-2018.md) * [Kubernetes认证服务提供商(KCSP)说明](appendix/about-kcsp.md) diff --git a/book.json b/book.json index 918cc6747..49d614de5 100644 --- a/book.json +++ b/book.json @@ -5,15 +5,8 @@ "author": "Jimmy Song(宋净超)", "links": { "sidebar": { - "Jimmy Song": "https://jimmysong.io", + "回到主页": "https://jimmysong.io", "Awesome Cloud Native": "https://jimmysong.io/awesome-cloud-native", - "ServiceMesher社区": "https://www.servicemesher.com", - "Istio Handbook - Istio服务网格进阶实战": "https://www.servicemesher.com/istio-handbook", - "Serverless Handbook - 无服务器架构实践手册": "https://jimmysong.io/serverless-handbook", - "Cloud Native Go - 基于Go和React的web云原生应用构建指南": "https://jimmysong.io/book/cloud-native-go", - "Cloud Native Python(Python云原生) - 使用Python和React构建云原生应用": "https://jimmysong.io/book/cloud-native-python", - "Cloud Native Java(云原生Java)- Spring Boot、Spring Cloud与CloudFoundry弹性系统设计": "https://jimmysong.io/book/cloud-native-java", - "未来架构——从服务化到云原生": "https://jimmysong.io/book/future-architecture/" } }, "plugins": [ @@ -57,7 +50,7 @@ "size": "small" }, "tbfed-pagefooter": { - "copyright": "

极客时间专栏推荐《深入剖析 Kubernetes》 | MOSN - 开源代理 | 点击关注【云原生应用架构】公众号回复【加群】加入学习群

Copyright © 2017-2019 | Distributed under CC BY 4.0 | jimmysong.io", + "copyright": "

快速入门 Kubernetes,就看极客时间专栏《深入剖析 Kubernetes》 | 点击关注【云原生应用架构】公众号回复【加群】加入云原生社区

Copyright © 2017-2020 | Distributed under CC BY 4.0 | jimmysong.io", "modify_label": " Updated at ", "modify_format": "YYYY-MM-DD HH:mm:ss" }, diff --git a/favicon.ico b/favicon.ico index 03a87a1f2..73ee32732 100644 Binary files a/favicon.ico and b/favicon.ico differ diff --git a/images/envoy-arch.png b/images/envoy-arch.png index a1dd849f1..1eb47c0ce 100644 Binary files a/images/envoy-arch.png and b/images/envoy-arch.png differ diff --git a/images/istio-arch.png b/images/istio-arch.png new file mode 100644 index 000000000..d99c1b1ab Binary files /dev/null and b/images/istio-arch.png differ diff --git a/images/mosn-with-service-mesh.png b/images/mosn-with-service-mesh.png new file mode 100644 index 000000000..7fd436adb Binary files /dev/null and b/images/mosn-with-service-mesh.png differ diff --git a/usecases/ai.md b/usecases/ai.md index 8917909f9..0460e39d6 100644 --- a/usecases/ai.md +++ b/usecases/ai.md @@ -2,6 +2,10 @@ Kubernetes 在人工智能领域的应用。 -## TBD +## KubeFlow -- [kubeflow](https://github.com/kubeflow/kubeflow) - Kubernetes 机器学习工具箱 +[Kubeflow](https://github.com/kubeflow/kubeflow)项目致力于使机器学习(ML)工作流在Kubernetes上的部署简单,可移植且可扩展。KubeFlow的目标不是重新创建其他服务,而是提供一种直接的方式来将ML的同类最佳的开源系统部署到各种基础结构中。在运行Kubernetes的任何地方都应该能够运行Kubeflow。官网:。 + +## ElasticDL + +[ElasticDL](https://github.com/sql-machine-learning/elasticdl) 是一个基于 TensorFlow2.0 的 Kubenretes 原生深度学习框架,官网:[https://elasticdl.org](https://elasticdl.org/)。 \ No newline at end of file diff --git a/usecases/comparing-service-mesh-technologies.md b/usecases/comparing-service-mesh-technologies.md index ed6a00d57..4791570b9 100644 --- a/usecases/comparing-service-mesh-technologies.md +++ b/usecases/comparing-service-mesh-technologies.md @@ -1,7 +1,5 @@ # Service Mesh技术对比 -**注意:本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** - 这一章主要讲解Service Mesh技术之间的区别,Service Mesh与其他相关技术之间的区别,读者可以直接浏览该网站来查看对比:http://layer5.io/service-meshes/ 为什么有了如Kubernetes这样的容器编排我们还需要Service Mesh呢,下表是对容器编排调度器的核心功能和缺少的服务级别能力对比。 diff --git a/usecases/envoy-front-proxy.md b/usecases/envoy-front-proxy.md index a2b72dbfd..13389fc70 100644 --- a/usecases/envoy-front-proxy.md +++ b/usecases/envoy-front-proxy.md @@ -1,7 +1,5 @@ # Envoy 作为前端代理 - **注意:本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** - 本文是使用 Envoy 作为前端代理的介绍,仅使用 docker 容器和 docker-compose 做编排在单机中运行,帮助我们从更底层了解 Envoy,当我们将 Envoy 作为 Istio Service Mesh 的 data panel 的时候将更加游刃有余。 ## 快速开始 diff --git a/usecases/envoy-mesh-in-kubernetes-tutorial.md b/usecases/envoy-mesh-in-kubernetes-tutorial.md index cf7dd245a..5a79141d5 100644 --- a/usecases/envoy-mesh-in-kubernetes-tutorial.md +++ b/usecases/envoy-mesh-in-kubernetes-tutorial.md @@ -1,7 +1,5 @@ # Envoy mesh 教程 - **注意:本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** - 本文是在 Kubernetes 集群中,使用 Envoy 来做 mesh,来为一个简单的使用 Python 编写的 Flask 应用程序做反向代理和负载均衡。 **注**:本教程中的示例来自 [envoy-steps](https://github.com/datawire/envoy-steps),本文中使用的所有的代码和 YAML 配置见 [envoy-tutorial](https://github.com/rootsongjc/envoy-tutorial)。 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 index f4e2c10db..1d6a84b00 100644 --- a/usecases/envoy-sidecar-routing-of-istio-service-mesh-deep-dive.md +++ b/usecases/envoy-sidecar-routing-of-istio-service-mesh-deep-dive.md @@ -1,8 +1,8 @@ # 深入理解Istio Service Mesh中的Envoy Sidecar代理的路由转发 -**注意:本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** +**注意:本文基于 Istio 1.0。** -本文以 Istio 官方的 bookinfo 示例来讲解在进入 Pod 的流量被 iptables 转交给 Envoy sidecar 后,Envoy 是如何做路由转发的,详述了 Inbound 和 Outbound 处理过程。关于流量拦截的详细分析请参考[理解 Istio Service Mesh 中 Envoy 代理 Sidecar 注入及流量劫持](https://jimmysong.io/posts/envoy-sidecar-injection-in-istio-service-mesh-deep-dive/)。 +本文以 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。 @@ -364,6 +364,6 @@ Endpoint 可以是一个或多个,Envoy 将根据一定规则选择适当的 E ## 参考 -- [理解 Istio Service Mesh 中 Envoy 代理 Sidecar 注入及流量劫持 - jimmysong.io](https://jimmysong.io/posts/envoy-sidecar-injection-in-istio-service-mesh-deep-dive/) +- [理解 Istio Service Mesh 中 Envoy 代理 Sidecar 注入及流量劫持 - jimmysong.io](understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md) - [Istio流量管理实现机制深度解析 - zhaohuabing.com](https://zhaohuabing.com/post/2018-09-25-istio-traffic-management-impl-intro/) diff --git a/usecases/envoy-terminology.md b/usecases/envoy-terminology.md index 458ffb4d5..2668985e6 100644 --- a/usecases/envoy-terminology.md +++ b/usecases/envoy-terminology.md @@ -1,7 +1,5 @@ # Envoy 的架构与基本术语 - **注意:本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** - 在了解一门技术之前一开始就要了解其中的基本概念和术语,只有融入了该语境才能理解这门技术。本文将为大家介绍 Envoy 中的基本术语和重点概念。 ## 架构 diff --git a/usecases/envoy.md b/usecases/envoy.md index df8dd52ec..2a303d915 100644 --- a/usecases/envoy.md +++ b/usecases/envoy.md @@ -1,10 +1,8 @@ # Envoy - **注意:本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** - [Envoy](https://github.com/envoyproxy/envoy) 是一款由 Lyft 开源的,使用 C++ 编写的 L7 代理和通信总线,目前是 [CNCF](https://cncf.io) 旗下的开源项目且已经毕业,代码托管在 GitHub 上,它也是 [Istio](https://istio.io) service mesh 中默认的 data plane。 -ServiceMesher 共同联合翻译了 [Envoy 最新版本的官方文档](https://www.envoyproxy.io/docs/envoy/latest/),翻译的代码托管在 ,Envoy 官方文档中文版地址:。 +ServiceMesher 共同联合翻译了 [Envoy 最新版本的官方文档](https://www.envoyproxy.io/docs/envoy/latest/),翻译的代码托管在 ,Envoy 官方文档中文版地址:。 ## 特性 @@ -40,4 +38,4 @@ Matt Klein 是在他的文章中指出 sidecar 模式的 proxy 将取代另外 - [Introduction to modern network load balancing and proxying](https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236) - 更多信息请参考 [Envoy 官网](https://www.envoyproxy.io/) -- [Envoy官方文档中文版](http://www.servicemesher.com/envoy/) +- [Envoy官方文档中文版](https://www.servicemesher.com/envoy/) diff --git a/usecases/faas.md b/usecases/faas.md index 574b47eb6..2784f3e3a 100644 --- a/usecases/faas.md +++ b/usecases/faas.md @@ -1,4 +1,4 @@ -# FaaS-函数即服务 +# FaaS(函数即服务) FaaS(Functions as a Service)函数即服务,FaaS是无服务器计算的一种形式,当前使用最广泛的是AWS的Lambada。 @@ -15,5 +15,6 @@ FaaS(Functions as a Service)函数即服务,FaaS是无服务器计算的 - [nuclio](https://github.com/nuclio/nuclio) - High-Performance Serverless event and data processing platform - [OpenFaaS](https://github.com/openfaas/faas) - OpenFaaS - Serverless Functions Made Simple for Docker & Kubernetes [https://blog.alexellis.io/introducing-functions-as-a-service/](https://blog.alexellis.io/introducing-functions-as-a-service/) - [OpenWhisk](http://openwhisk.incubator.apache.org/) - Apache OpenWhisk (Incubating) is a serverless, open source cloud platform that executes functions in response to events at any scale. +- [Knative](https://knative.dev/) - Kubernetes-based platform to deploy and manage modern serverless workloads. 关于整个Cloud Native开源生态,请参考[awesome-cloud-native](https://jimmysong.io/awesome-cloud-native)。 diff --git a/usecases/istio-installation.md b/usecases/istio-installation.md index 7992f667a..27f148ade 100644 --- a/usecases/istio-installation.md +++ b/usecases/istio-installation.md @@ -1,8 +1,8 @@ # 安装并试用Istio service mesh -**注意:本文档已失效,请浏览 [Istio 官方文档](https://istio.io/)。本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** +**注意:本文基于 Istio 1.0。** -官方文档地址 [快速开始](https://istio.io/docs/setup/kubernetes/)。 +请参考 Istio 官方文档地址 [快速开始](https://istio.io/docs/setup/kubernetes/)。 本文根据官网的文档整理而成,步骤包括安装**istio 0.5.1**并创建一个bookinfo的微服务来测试istio的功能。 diff --git a/usecases/istio-tutorials-collection.md b/usecases/istio-tutorials-collection.md index 397d433c6..cd9c7dc5e 100644 --- a/usecases/istio-tutorials-collection.md +++ b/usecases/istio-tutorials-collection.md @@ -2,7 +2,7 @@ **注意:本文档已失效,请浏览 [Istio 官方文档](https://istio.io)。本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** -8月1日0点,[Istio 1.0发布,已生产就绪!](http://www.servicemesher.com/blog/announcing-istio-1.0/)大家都已经跃跃欲试了,几天前我发布了[一键在本地搭建运行Istio 1.0的分布式Kubernetes集群](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster)教程,在本地搭建起来还是有些门槛,稍显复杂,现在我推荐几个可以在线上学习的地方。这是目前搜集的比较完整的Isito学习环境和包含代码的示例教程有如下几个: +2018年8月1日0点,[Istio 1.0发布,已生产就绪!](http://www.servicemesher.com/blog/announcing-istio-1.0/)大家都已经跃跃欲试了,几天前我发布了[一键在本地搭建运行Istio 1.0的分布式Kubernetes集群](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster)教程,在本地搭建起来还是有些门槛,稍显复杂,现在我推荐几个可以在线上学习的地方。这是目前搜集的比较完整的Isito学习环境和包含代码的示例教程有如下几个: 目前搜集的比较完整的Isito学习环境和包含代码的示例教程有如下几个: @@ -68,10 +68,7 @@ GitHub地址:https://github.com/IBM/microservices-traffic-management-using-ist ## ServiceMesher社区 -网址:http://www.servicemesher.com/ - -GitHub:https://github.com/servicemesher - -微信群:入群请[联系我](https://jimmysong.io/about) - -Twitter: https://twitter.com/servicemesher +- 网址:https://www.servicemesher.com/ +- GitHub:https://github.com/servicemesher +- 微信群:入群请[联系我](https://jimmysong.io/about) +- Twitter: https://twitter.com/servicemesher \ No newline at end of file diff --git a/usecases/istio.md b/usecases/istio.md index 380cf5d81..35e09b541 100644 --- a/usecases/istio.md +++ b/usecases/istio.md @@ -1,7 +1,5 @@ # Istio简介 -**注意:Istio 1.10于2018年8月1日发布1.0,关于Istio的更多信息请见Istio官方文档:,本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** - [Istio](https://istio.io)是由Google、IBM和Lyft开源的微服务管理、保护和监控框架。Istio为希腊语,意思是”起航“。 **TL;DR** 关于Istio中的各个组件和一些关键信息请参考下面的mindmap。 @@ -10,9 +8,11 @@ ## 简介 -使用istio可以很简单的创建具有负载均衡、服务间认证、监控等功能的服务网络,而不需要对服务的代码进行任何修改。你只需要在部署环境中,例如Kubernetes的pod里注入一个特别的sidecar proxy来增加对istio的支持,用来截获微服务之间的网络流量。 +Istio 解决了开发人员和运维人员所面临的从单体应用向分布式微服务架构转变的挑战。了解它是如何做到这一点的可以让我们更详细地理解 Istio 的服务网格。 -目前版本的istio只支持kubernetes,未来计划支持其他其他环境。 +术语**服务网格**用来描述组成这些应用程序的微服务网络以及它们之间的交互。随着服务网格的规模和复杂性不断的增长,它将会变得越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、度量和监控等。服务网格通常还有更复杂的运维需求,比如 A/B 测试、金丝雀发布、速率限制、访问控制和端到端认证。 + +Istio 提供了对整个服务网格的行为洞察和操作控制的能力,以及一个完整的满足微服务应用各种需求的解决方案。 另外,Istio的前身是IBM开源的Amalgam8,追本溯源,我们来看下它的特性。 @@ -37,34 +37,68 @@ Amalgam8是一款基于内容和版本的路由布局,用于集成多语言异 未来将支持多种平台,不论是kubernetes、Mesos、还是云。同时可以集成已有的ACL、日志、监控、配额、审计等。 +## 设计目标 + +几个关键的设计目标形成了 Istio 的架构。这些目标对于使系统能够大规模和高性能地处理服务是至关重要的。 + +- **透明度最大化**:为了采用 Istio,运维人员或开发人员需要做尽可能少的工作,才能从系统中获得真正的价值。为此,Istio 可以自动将自己注入到服务之间的所有网络路径中。Istio 使用 sidecar 代理来捕获流量,并在可能的情况下,在不更改已部署的应用程序代码的情况下,自动对网络层进行配置,以实现通过这些代理来路由流量。在 Kubernetes 中,代理被注入到pods中,通过编写‘iptables’规则来捕获流量。一旦 sidecar 代理被注入以及流量路由被编程,Istio 就可以协调所有的流量。这个原则也适用于性能。当将 Istio 应用于部署时,运维人员会看到所提供功能的资源成本增加地最小。组件和 API 的设计必须考虑到性能和可伸缩性。 +- **可扩展性**:随着运维人员和开发人员越来越依赖于 Istio 提供的功能,系统必须随着他们的需求而增长。当我们继续添加新特性时,最大的需求是扩展策略系统的能力,与其他策略和控制源的集成,以及将关于网格行为的信号传播到其他系统进行分析的能力。策略运行时支持用于接入其他服务的标准扩展机制。此外,它允许扩展其词汇表,允许根据网格生成的新信号执行策略。 +- **可移植性**:使用 Istio 的生态系统在许多方面都有所不同。Istio 必须在任何云环境或本地环境中通过最小的努力就能运行起来。将基于 Istio 的服务移植到新环境的任务必须是容易实现的。使用 Istio,您可以操作部署到多个环境中的单个服务。例如,可以在多个云上部署来实现冗余。 +- **策略一致性**:将策略应用于服务之间的 API 调用提供了对网格行为的大量控制。然而,将策略应用在区别于 API 层上的资源也同样重要。例如,在机器学习训练任务消耗的 CPU 数量上应用配额比在发起任务的请求调用上应用配额更有用。为此,Istio 使用自己的 API 将策略系统维护为一个独立的服务,而不是将策略系统集成到 sidecar 代理中,从而允许服务根据需要直接与之集成。 + ## 架构 -下面是Istio的架构图。 +Istio 服务网格从逻辑上分为数据平面和控制平面。 -![Istio架构图](../images/istio-arch.jpg) +- **数据平面**由一组智能代理([Envoy](https://www.envoyproxy.io/))组成,被部署为 sidecar。这些代理通过一个通用的策略和遥测中心(Mixer)传递和控制微服务之间的所有网络通信。 +- **控制平面**管理并配置代理来进行流量路由。此外,控制平面配置 Mixer 来执行策略和收集遥测数据。 + +下图展示了组成每个平面的不同组件: + +![Istio架构图](../images/istio-arch.png) Istio架构分为控制平面和数据平面。 - **数据平面**:由一组智能代理(Envoy)作为sidecar部署,协调和控制所有microservices之间的网络通信。 - **控制平面**:负责管理和配置代理路由流量,以及在运行时执行的政策。 -## Envoy +### Envoy -Istio使用Envoy代理的扩展版本,该代理是以C++开发的高性能代理,用于调解service mesh中所有服务的所有入站和出站流量。 Istio利用了Envoy的许多内置功能,例如动态服务发现,负载平衡,TLS终止,HTTP/2&gRPC代理,断路器,运行状况检查,基于百分比的流量拆分分阶段上线,故障注入和丰富指标。 +Istio使用Envoy代理的扩展版本,该代理是以C++开发的高性能代理,用于调解service mesh中所有服务的所有入站和出站流量。 + +Envoy 代理被部署为服务的 sidecar,在逻辑上为服务增加了 Envoy 的许多内置特性,例如: + +- 动态服务发现 +- 负载均衡 +- TLS 终端 +- HTTP/2 与 gRPC 代理 +- 熔断器 +- 健康检查 +- 基于百分比流量分割的分阶段发布 +- 故障注入 +- 丰富的指标 Envoy在kubernetes中作为pod的sidecar来部署。 这允许Istio将大量关于流量行为的信号作为属性提取出来,这些属性又可以在Mixer中用于执行策略决策,并发送给监控系统以提供有关整个mesh的行为的信息。 Sidecar代理模型还允许你将Istio功能添加到现有部署中,无需重新构建或重写代码。 -## Mixer +### Mixer -Mixer负责在service mesh上执行访问控制和使用策略,并收集Envoy代理和其他服务的遥测数据。代理提取请求级属性,发送到mixer进行评估。有关此属性提取和策略评估的更多信息,请参见[Mixer配置](https://istio.io/docs/concepts/policy-and-control/mixer-config.html)。 混音器包括一个灵活的插件模型,使其能够与各种主机环境和基础架构后端进行接口,从这些细节中抽象出Envoy代理和Istio管理的服务。 +Mixer 是一个平台无关的组件。Mixer 在整个服务网格中执行访问控制和策略使用,并从 Envoy 代理和其他服务收集遥测数据。代理提取请求级别属性,并将其发送到 Mixer 进行评估。 -## Istio Manager +Mixer 包括一个灵活的插件模型。该模型使 Istio 能够与各种主机环境和后端基础设施进行交互。因此,Istio 从这些细节中抽象出 Envoy 代理和 Istio 管理的服务。 -Istio-Manager用作用户和Istio之间的接口,收集和验证配置,并将其传播到各种Istio组件。它从Mixer和Envoy中抽取环境特定的实现细节,为他们提供独立于底层平台的用户服务的抽象表示。 此外,流量管理规则(即通用4层规则和七层HTTP/gRPC路由规则)可以在运行时通过Istio-Manager进行编程。 +### Pilot -## Istio-auth +Pilot 为 Envoy sidecar 提供服务发现、用于智能路由的流量管理功能(例如,A/B 测试、金丝雀发布等)以及弹性功能(超时、重试、熔断器等)。 -Istio-Auth提供强大的服务间和最终用户认证,使用相互TLS,内置身份和凭据管理。它可用于升级service mesh中的未加密流量,并为运营商提供基于服务身份而不是网络控制的策略的能力。 Istio的未来版本将增加细粒度的访问控制和审计,以使用各种访问控制机制(包括属性和基于角色的访问控制以及授权hook)来控制和监控访问你服务、API或资源的人员。 +Pilot 将控制流量行为的高级路由规则转换为特定于环境的配置,并在运行时将它们传 + +### Citadel + +Citadel 通过内置的身份和证书管理,可以支持强大的服务间以及最终用户的身份验证。您可以使用 Citadel 来升级服务网格中的未加密流量。使用 Citadel,operator 可以执行基于服务身份的策略,而不是相对不稳定的 3 层或 4 层网络标识。从 0.5 版开始,您可以使用 Istio 的授权特性来控制谁可以访问您的服务。 + +### Galley + +Galley 是 Istio 的配置验证、提取、处理和分发组件。它负责将其余的 Istio 组件与从底层平台(例如 Kubernetes)获取用户配置的细节隔离开来。 ## 参考 diff --git a/usecases/knative.md b/usecases/knative.md new file mode 100644 index 000000000..36a81bbfa --- /dev/null +++ b/usecases/knative.md @@ -0,0 +1,38 @@ +# Knative + +![Knative logo](https://tva1.sinaimg.cn/large/006y8mN6ly1g7pg0iwbzfj30d8080dfp.jpg) + +[Knative](https://github.com/knative) 开源于 2018 年 7 月 24 日,由 Pivotal、Google、IBM 等公司共同发起,从以 K 打头的名字上就可以看出来 Knative 是用以扩展 Kubernetes 的。 + +## 组件 + +Knative 最初包含以下 3 个组件: + +- Build*:提供了一种从源代码构建容器的可插拔模型。它以 Google 的容器构建服务为基础。 +- Eventing:提供用来使用和生成符合 CloudEvents 规范的事件的构建块。它包括对来自事件源的信息流的抽象,以及通过由可插拔发布/订阅代理服务提供支持的消息传递通道实现交付解耦。 +- Serving:可缩放至零、请求驱动的计算运行环境,利用 Istio 在各版本之间路由流量。Serving 的目标是为 Kubernetes 提供扩展功能,用于部署和运行 Serverless 工作负载。 + +> **[warning] 注意** +> +> Knative 自 0.8 版本起去掉了 Build 组件,转而使用 [tekoncd/pipeline](https://github.com/tektoncd/pipeline) 取代,只保留了 Eventing 和 Serving 组件。 + +## 受众 + +不同受众参与和使用 Knative 的方式不同,如下图所示。 + +![Knative 受众(图片来自 knative.dev)](https://tva1.sinaimg.cn/large/006y8mN6ly1g7po5i7cgqj31ap0u075l.jpg) + +## Knative 特性 + +- 对于常用应用用例的更高级别抽象 +- 安全、无状态、可扩展应用的秒级启动 +- 功能松耦合,可任意组装 +- 组件可拔插,你可以使用自己的日志、监控、网络和服务网格 +- 可移植:在任意 Kubernetes 集群上运行,无需担心供应商锁定 +- 顺应开发者习惯,支持如 GitOps、DockerOps、ManualOps 等通用模式 +- 可以与通用工具及框架一起使用,如 Django、Ruby on Rails、Spring 等 + +## 参考 + +- +- \ No newline at end of file diff --git a/usecases/linkerd.md b/usecases/linkerd.md index 81e045d14..75911276d 100644 --- a/usecases/linkerd.md +++ b/usecases/linkerd.md @@ -120,4 +120,4 @@ Linkerd 自己最令人称道的是它在每台主机上只安装一个 Pod, - [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/) -- [Istio:用于微服务的服务啮合层](http://www.infoq.com/cn/news/2017/05/istio) +- [Istio:一个用于微服务间通信的服务网格开源项目](http://www.infoq.com/cn/news/2017/05/istio) diff --git a/usecases/service-mesh-adoption-and-evolution.md b/usecases/service-mesh-adoption-and-evolution.md index 170a01c9e..cc809b20f 100644 --- a/usecases/service-mesh-adoption-and-evolution.md +++ b/usecases/service-mesh-adoption-and-evolution.md @@ -1,7 +1,5 @@ ## 采纳和演进 -**注意:本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** - 没有人会一下子采纳Service Mesh架构的所有组件,或者一次性将所有的应用都改造成Service Mesh的,都是渐渐式采纳,从非核心系统开始改造。采纳Service Mesh就两种路径: - 全盘采纳:通常对于新应用来说才会这样做,也叫做Greenfiled项目 diff --git a/usecases/service-mesh-conclusion.md b/usecases/service-mesh-conclusion.md index 0fd219acd..d50eb7544 100644 --- a/usecases/service-mesh-conclusion.md +++ b/usecases/service-mesh-conclusion.md @@ -1,7 +1,5 @@ # 总结 -**注意:本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** - 最后是对全书的总结,2018年必然是一场服务网格或者说Proxy的战争。 ### 用还是不用 diff --git a/usecases/service-mesh-customization-and-integration.md b/usecases/service-mesh-customization-and-integration.md index 5efc5a1cc..d2c360984 100644 --- a/usecases/service-mesh-customization-and-integration.md +++ b/usecases/service-mesh-customization-and-integration.md @@ -1,7 +1,5 @@ # 定制和集成 -**注意:本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** - 例如Istio这样的Service Mesh中有很多地方可以给大家定制,例如作为数据平面的sidecar,虽然默认使用的是Envoy,但是你可以开发自己的sidecar代理;还有Mixer中的各种adpater,你也可以开发自己的adapter来扩展遥测和鉴权功能,[Consul Connect](http://www.servicemesher.com/blog/consul-1-2-service-mesh/)就是个例子。 当前可选择的开源的代理可以在[landscape](http://layer5.io/landscape/)里找到,例如使用nginMesh替代Envoy作为数据平面。下图是使用nginMesh作为sidecar的架构图。 @@ -14,13 +12,13 @@ ![Mixer adapter](../images/006tNbRwly1fucplat3l9j30vo0lw43l.jpg) -**SOFAMosn** +**MOSN** -还有蚂蚁金服开源的Go语言版的数据平面[SOFAMosn](https://github.com/sofastack/sofa-mosn),这是也兼容Istio的SOFAMesh的一部分,也可以单独作为代理使用,详见:[SOFAMesh & SOFA MOSN—基于Istio构建的用于应对大规模流量的Service Mesh解决方案](https://jimmysong.io/posts/sofamesh-and-mosn-proxy-sidecar-service-mesh-by-ant-financial/)。 +还有蚂蚁金服开源的Go语言版的数据平面[MOSN](https://github.com/mosn/mosn),这是也兼容Istio的SOFAMesh的一部分,也可以单独作为代理使用,详见:[蚂蚁金服开源SOFAMesh](https://jimmysong.io/blog/sofamesh-and-mosn-proxy-sidecar-service-mesh-by-ant-financial/)。 -![SOFAMesh](../images/006tNbRwly1fucpano6gsj31kw1biq98.jpg) +![SOFAMesh](../images/mosn-with-service-mesh.png) -[SOFAMosn](https://github.com/sofastack/sofa-mosn)的模块架构图。 +[MOSN](https://github.com/mosn/mosn)的模块架构图。 ![SOFAMosn模块架构图](../images/006tNbRwly1fucpc5fn8wj31kw0sfdnu.jpg) diff --git a/usecases/service-mesh-fundamental.md b/usecases/service-mesh-fundamental.md index 87fda384f..3cc2bb4a5 100644 --- a/usecases/service-mesh-fundamental.md +++ b/usecases/service-mesh-fundamental.md @@ -1,7 +1,5 @@ # Service Mesh基础 -**注意:本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** - > 本文是对[The Enterprise Path to Service Mesh Architecutures](https://www.nginx.com/resources/library/the-enterprise-path-to-service-mesh-architectures/)一书的解读。 微服务将原先的单体架构中的应用内通信,转变为基于RPC的远程通信,虽然这样提高了研发效率,提高了开发语言选择的多样性,但是随着单体应用的解体,原先的巨石散落为石块变得四处都是,如何管理这些微服务就成了难题。当微服务的个数少的时候还可以通过人工配置的方式去管理,但随着业务规模的增大,微服务的数量也可能呈指数级增长,如何协调管理成百上千的服务,这就需要有一套设计良好的框架。 diff --git a/usecases/sidecar-spec-in-istio.md b/usecases/sidecar-spec-in-istio.md index 6f8bb7fa9..90b0ea678 100644 --- a/usecases/sidecar-spec-in-istio.md +++ b/usecases/sidecar-spec-in-istio.md @@ -1,6 +1,6 @@ # Istio 中 sidecar 的注入及示例 -**注意:本文档已失效,请浏览 [Istio 官方文档](https://istio.io)。本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** +**注意:本文基于 Istio 1.0。** 我们知道 Istio 通过向 Pod 中注入一个 sidecar 容器来将 Pod 纳入到 Istio service mesh 中的,那么这些 sidecar 容器的注入遵循什么样的规范,需要给每个 Pod 增加哪些配置信息才能纳入 Istio service mesh 中呢?这篇文章将给您答案。 diff --git a/usecases/the-enterprise-path-to-service-mesh-architectures.md b/usecases/the-enterprise-path-to-service-mesh-architectures.md index ffc92bee6..7d73a6398 100644 --- a/usecases/the-enterprise-path-to-service-mesh-architectures.md +++ b/usecases/the-enterprise-path-to-service-mesh-architectures.md @@ -1,7 +1,5 @@ # 企业级服务网格架构之路 -**注意:本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** - 本节是根据由Nginx赞助,O’Reilly出版社出品的关于服务网格的书籍总结而来,本书标题是 _The Enterprise Path to Service Mesh_ ,还有个副标题 _Decoupling at Layer 5_ ,第一版发行于2018年8月8日。这本书一共61页,本文是我对该书的一些解读,读者可以在[Nginx的网站](https://www.nginx.com/resources/library/the-enterprise-path-to-service-mesh-architectures/)上免费下载阅读完整内容。 追本溯源,Service Mesh实际上是一种SDN,等同于OSI模型中的会话层。 每一次技术变革,必然要导致生产力和生产关系的变革,我们看到这种趋势正在加速。本书中给出了企业上Service Mesh的路径,可供广大技术和管理人员参考。 diff --git a/usecases/understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md b/usecases/understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md index 65e72632a..b1d50ed8d 100644 --- a/usecases/understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md +++ b/usecases/understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md @@ -1,6 +1,6 @@ # 深入理解Istio Service Mesh中的Envoy Sidecar注入与流量劫持 -**注意:本书中的 Service Mesh 章节已不再维护,请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。** +**注意:本文基于 Istio 1.0。** 在讲解 Istio 如何将 Envoy 代理注入到应用程序 Pod 中之前,我们需要先了解以下几个概念: @@ -23,10 +23,6 @@ productpage istio-proxy 使用 Sidecar 模式部署服务网格时,无需在节点上运行代理(因此您不需要基础结构的协作),但是集群中将运行多个相同的 Sidecar 副本。从另一个角度看:我可以为一组微服务部署到一个服务网格中,你也可以部署一个有特定实现的服务网格。在 Sidecar 部署方式中,你会为每个应用的容器部署一个伴生容器。Sidecar 接管进出应用容器的所有流量。在 Kubernetes 的 Pod 中,在原有的应用容器旁边运行一个 Sidecar 容器,可以理解为两个容器共享存储、网络等资源,可以广义的将这个注入了 Sidecar 容器的 Pod 理解为一台主机,两个容器共享主机资源。 -例如下图 [SOFAMesh & SOFA MOSN—基于Istio构建的用于应对大规模流量的Service Mesh解决方案](https://jimmysong.io/posts/sofamesh-and-mosn-proxy-sidecar-service-mesh-by-ant-financial/)的架构图中描述的,MOSN 作为 Sidecar 的方式和应用运行在同一个 Pod 中,拦截所有进出应用容器的流量,[SOFAMesh](https://github.com/sofastack/sofa-mesh) 兼容 Istio,其中使用 Go 语言开发的 [SOFAMosn](https://github.com/sofastack/sofa-mosn) 替换了 Envoy。 - -![SOFAMesh架构图](../images/006tNbRwgy1fuyr4vizzwj31kw1biq98.jpg) - **注意**:下文中所指的 Sidecar 都是指的 Envoy 代理容器。 ## Init 容器 @@ -41,7 +37,7 @@ Init 容器使用 Linux Namespace,所以相对应用程序容器来说具有 在所有的 Init 容器没有成功之前,Pod 将不会变成 `Ready` 状态。Init 容器的端口将不会在 Service 中进行聚集。 正在初始化中的 Pod 处于 `Pending` 状态,但应该会将 `Initializing` 状态设置为 true。Init 容器运行完成以后就会自动终止。 -关于 Init 容器的详细信息请参考 [Init 容器 - Kubernetes 中文指南/云原生应用架构实践手册](https://jimmysong.io/kubernetes-handbook/concepts/init-containers.html)。 +关于 Init 容器的详细信息请参考 [Init 容器 - Kubernetes 中文指南/云原生应用架构实践手册](../concepts/init-containers.md)。 ## Sidecar 注入示例分析 @@ -708,7 +704,6 @@ envoy 11 istio-proxy 63u IPv4 338525 0t0 TCP productpage-v1-745ffc55 ## 参考 -- [SOFAMesh & SOFA MOSN—基于Istio构建的用于应对大规模流量的Service Mesh解决方案 - jimmysong.io](https://jimmysong.io/posts/sofamesh-and-mosn-proxy-sidecar-service-mesh-by-ant-financial/ - jimmysong.io) - [Init 容器 - Kubernetes 中文指南/云原生应用架构实践手册 - jimmysong.io](https://jimmysong.io/kubernetes-handbook/concepts/init-containers.html) - [JSONPath Support - kubernetes.io](https://kubernetes.io/docs/reference/kubectl/jsonpath/) - [iptables 命令使用说明 - wangchujiang.com](https://wangchujiang.com/linux-command/c/iptables.html)