Istio最佳实战-克里斯汀·波斯塔 里诺·马洛库
- 书名： Istio最佳实战
- 作者： 克里斯汀·波斯塔 里诺·马洛库
- 简介： Istio作为服务网格技术最具代表性的产品，历经多年发展已日渐成熟，并受到越来越多开发者的青睐。本书以 Istio 服务网格为核心，内容包括基本概念、核心功能、运维、企业级落地四大部分，从基本的安装部署到功能实践，从底层原理分析到故障排查，从进阶操作到企业级实战，由浅入深地介绍了 Istio 服务网格的各个方面。本书适合正在使用或关注 Istio 的开发工程师、运维工程师、架构师等云原生领域从业者阅读。无论你是服务网格技术的初学者，还是该领域的专家，都能从本书中寻找到有借鉴意义的理论及实践指导。
- 出版时间 2023-07-01 00:00:00
- ISBN： 9787121457395
- 分类： 计算机-理论知识
- 出版社： 电子工业出版社
高亮划线
封面
版权信息
内容简介
文前
译者序
序言
前言
致谢
关于本书
关于作者
关于封面插图
第1部分 理解Istio
1 Istio服务网格
-
📌 它描述了一个由数据平面和控制平面组成的架构，数据平面使用应用层代理来管理网络流量，控制平面用于管理代理。 ^13-1398-1450
- ⏱ 2023-11-07 07:55:42
-
📌 Istio的数据平面由基于Envoy的服务代理组成，这些服务代理与应用程序共存。它们作为应用程序之间的中介，并根据控制平面发送的配置影响网络行为。 ^13-1698-1771
- ⏱ 2023-11-07 07:56:33
1.1 快速迭代带来的挑战
1.1.1 不可靠的云基础设施
1.1.2 服务通信需要弹性
1.1.3 实时可观测性
1.2 使用应用程序库解决问题
1.3 基础设施的解决思路
1.3.1 应用程序感知服务代理
1.3.2 认识Envoy代理
1.4 什么是服务网格
1.5 Istio服务网格简介
- 📌 Istio的数据平面使用Envoy代理配置应用程序，该代理被部署在应用程序旁边。Istio的控制平面由几个组件组成——这些组件为最终用户/运维人员提供API、代理的配置API、安全设置、策略声明等。 ^23-609-708
- ⏱ 2023-11-07 08:23:06
1.5.1 服务网格与企业服务总线的关系
1.5.2 服务网格与API网关的关系
1.5.3 在非微服务架构中使用Istio
1.5.4 在分布式架构中使用Istio
1.5.5 使用服务网格的缺点
本章小结
2 Istio的第一步
2.1 在Kubernetes上部署Istio
2.1.1 使用Docker Desktop来演示样例
2.1.2 获取Istio发行版
2.1.3 将Istio组件安装到Kubernetes中
2.2 了解Istio控制平面
2.2.1 istiod简介
2.2.2 入口网关和出口网关
2.3 在服务网格中部署你的第一个应用程序
2.4 Istio的可观测性、弹性和流量路由
2.4.1 Istio与可观测性
2.4.2 Istio与弹性
2.4.3 Istio与流量路由
本章小结
3 Istio的数据平面：Envoy
3.1 什么是Envoy代理
3.1.1 Envoy的核心功能
3.1.2 Envoy与其他代理的比较
3.2 配置Envoy
3.2.1 静态配置
3.2.2 动态配置
3.3 Envoy实战
3.3.1 Envoy的Admin API
3.3.2 Envoy的请求重试
3.4 Envoy与Istio的融合
本章小结
第2部分 保护、观察和控制服务网格中的流量
4 Istio网关：将流量导入集群
4.1 流量入口概念
4.1.1 虚拟IP地址：简化服务访问
4.1.2 虚拟主机：来自单个接入点的多个服务
- 📌 我们需要一种方法来决定将特定请求路由到哪个虚拟主机。对于HTTP/1.1，我们可以使用Host头；对于HTTP/2，我们可以使用：authority头；对于TCP连接，我们可以依赖TLS的服务器名称指示(SNI)。 ^60-1045-1152
- ⏱ 2023-11-09 07:56:15
4.2 Istio入口网关
4.2.1 声明Gateway资源
4.2.2 虚拟服务的网关路由
4.2.3 流量整体视图
4.2.4 对比Istio入口网关与Kubernetes Ingress
-
📌 当在Kubernetes上运行应用时，你可能会问，“为什么Istio不直接使用Kubernetes Ingress v1资源来指定入口？”Istio确实支持Kubernetes Ingress v1资源，但是Kubernetes Ingress v1规范有很多的限制。首先，Kubernetes Ingress v1是一个非常简单的针对HTTP工作负载的规范。有Kubernetes Ingress的实现（如Nginx和Traefik）；但是，它们都面向HTTP通信。事实上，Ingress规范只将80端口和443端口视为入口点。这严重限制了集群运营者允许进入服务网格的流量类型。例如，如果有Kafka或NATS.io工作负载，你可能希望向这些消息传递系统公开TCP连接，但Kubernetes Ingress不允许这样做。 ^65-479-870
- ⏱ 2023-11-09 12:47:10
-
📌 其次，Kubernetes Ingress v1资源没有被指定。没有通用的方法来指定复杂的流量路由规则、流量分割或类似于流量跟踪的方法。这方面缺乏规范，导致每个供应商都要重新思考如何最好地实现每种Ingress（HAProxy、Nginx等）的配置。最后，由于没有详细说明，大多数供应商都选择通过Deployment上的定制注解公开配置。供应商之间的注解各不相同，而且不可移植，如果Istio继续这一趋势，将会有更多的注解用来解释Envoy作为边缘网关的所有能力。最终，Istio决定重新构建入口网关，并将第4层（传输层）和第5层（会话层）的属性从第7层（应用层）路由关注点中分离出来。Istio的Gateway处理第4层和第5层的问题，而VirtualService处理第7层的问题。许多网格和网关的提供商也都为入口构建了自己的API，而且Kubernetes社区正在开发修订后的Ingress API。 ^65-899-1360
- ⏱ 2023-11-09 12:47:04