Kubernetes指南
Linux性能优化实战
eBPF 核心技术与实战
SDN指南
个人博客
搜索文档…
中文
序言
基础入门
Kubernetes 简介
Kubernetes 基本概念
Kubernetes 101
Kubernetes 201
Kubernetes 集群
核心原理
核心原理
架构原理
设计理念
核心组件
资源对象
部署配置
部署指南
kubectl 安装
单机部署
特性开关
最佳配置
版本支持
集群部署
附加组件
Kubernetes-The-Hard-Way
插件扩展
API 扩展
访问控制
Scheduler 扩展
网络插件
运行时插件 CRI
存储插件
网络策略
Ingress Controller
Cloud Provider 扩展
Device 插件
服务治理
服务治理
一般准则
滚动升级
Helm
Operator
Service Mesh
Linkerd
Linkerd2
Istio
Devops
实践案例
实践概览
资源控制
集群高可用
应用高可用
调试
端口映射
端口转发
用户管理
GPU
HugePage
安全
审计
备份恢复
证书轮换
大规模集群
大数据与机器学习
Serverless
排错指南
排错概览
集群排错
Pod 排错
网络排错
PV 排错
Windows 排错
云平台排错
排错工具
社区贡献
开发指南
单元测试和集成测试
社区贡献
附录
生态圈
学习资源
国内镜像
如何贡献
参考文档
由
GitBook
提供支持
Service Mesh
Service Mesh(服务网格)是一个用于保证服务间安全、快速、可靠通信的网络代理组件,是随着微服务和云原生应用兴起而诞生的基础设施层。它通常以轻量级网络代理的方式同应用部署在一起(比如sidecar方式,如下图所示)。Serivce Mesh可以看作是一个位于TCP/IP之上的网络模型,抽象了服务间可靠通信的机制。但与TCP不同,它是面向应用的,为应用提供了统一的可视化和控制。
为了保证服务间通信的可靠性,Service Mesh需要支持熔断机制、延迟感知的负载均衡、服务发现、重试等一些列的特性。比如Linkerd处理一个请求的流程包括
查找动态路由确定请求的服务
查找该服务的实例
Linkerd跟响应延迟等因素选择最优的实例
将请求转发给最优实例,记录延迟和响应情况
如果请求失败或实例实效,则转发给其他实例重试(需要是幂等请求)
如果请求超时,则直接失败,避免给后端增加更多的负载
记录请求的度量和分布式跟踪情况
为什么Service Mesh是必要的
将服务治理与实际服务解耦,避免微服务化过程中对应用的侵入
加速传统应用转型微服务或云原生应用
Service Mesh并非一个全新的功能,而是将已存在于众多应用之中的相关功能分离出来,放到统一的组件来管理。特别是在微服务应用中,服务数量庞大,并且可能是基于不同的框架和语言构建,分离出来的Service Mesh组件更容易管理和协调它们。
常见的 Service Mesh 框架包括
Istio
Conduit
Linkerd
以前
Operator
下一个
Linkerd
最近更新
2yr ago
复制链接