本文是为那些刚开始使用 Istio 速率限制功能,希望了解基于请求路径的速率限制如何工作的人而写的。它源于我的实践,并澄清了关于rate_limit操作中 AND/OR 操作的困惑。我花了比预期更多的时间来弄清楚我将在这里为你总结的内容,以便你在几分钟内学习。 基础知识 Istio 在 Envoy
Envoy 是一个用 C++ 开发的高性能代理,Envoy 是一种 L7 代理和通信总线,专为大型的现代面向服务的架构而设计。核心能力Envoy 的诞生源于以下理念:网络对于应用程序来说应该是透明的,当网络和应用程序出现问题时,应该很容易确定问题的源头。当然要实现上述目标是非常困难的。Envoy 试
前面我们和大家学习了 Envoy 的基础知识,使用静态配置来认识了 Envoy,但实际上 Envoy 的闪光点在于其动态配置,动态配置主要有基于文件和 API 两种方式。基于文件的动态配置Envoy 除了支持静态配置之外,还支持动态配置,而且动态配置也是 Envoy 重点关注的功能,本节我们将学习如
Envoy作为容器sidecar被注入应用Pod内的主要流程如下:主要的组件就是Listener和Cluster,Listener负责监控Downstream发送的请求,最终由Cluster来选择Upstream中的某个节点来处理该请求。 Envoy会从控制面或者静态配置中获取路由的集群信息,保存
本篇文章主要介绍 XDS 如何在 Envoy 中使用. XDS 是一组用于配置管理的协议,特别是在云原生环境中,XDS 中的 "X" 代表不同的配置类型,例如 LDS(监听器配置)、RDS(路由配置)、CDS(集群配置)、EDS(端点配置)等。这些协议被广泛用于管理服务间的通信、负载均衡、流量控制等
Envoy 是一个开源边缘和服务代理,专为云原生应用程序而设计。基于对Nginx、HAProxy、硬件负载均衡器和云负载均衡器等解决方案的学习,Envoy 与每个应用程序一起运行,并通过以与平台无关的方式提供通用功能来抽象网络。 在 Ubuntu 20.04 LTS Focal Fossa 上安装
5.请求首部条件路由正常情况下从客户端请求的流量会发送到sidecar-proxy(eneoy),请求发送到上游的pod,而后响应到envoy,并从envoy响应给客户端。在这个过程中,客户端到envoy是不能够被修改的,只有从envoy到上游serrvice中才是可以被操作的,因为这段报文是由en
Istio 为网格中的微服务提供了较为完善的安全加固功能,在不影响代码的前提下,可以从多个角度提供安全支撑,官方文档做了较为详细的介绍,但是也比较破碎,这里尝试做个简介兼索引,实现过程还是要根据官方文档进行。 Istio 的安全功能主要分为三个部分的实现: 双向 TLS 支持。 基于黑白名单的访问
正如我之前所说的,在如此短的时间内,Envoy 带来的兴奋既神奇又震撼人心。我经常问自己:envoy 的哪些方面导致了我们所看到的异常的社区增长?虽然 Envoy 具有很多引人注目的特征,但最终我认为有三个主要特征在共同推动: 性能:在具备大量特性的同时,Envoy 提供极高的吞吐量和低尾部延迟差
Envoy Lyft 本文为翻译文章,点击查看原文。 关键要点 在过去的四年中,Lyft 已从单体架构转变为数百个微服务。随着微服务数量的增加,由于级联故障或意外内部拒绝服务导致的中断次数也在增加。 今天,这些故障情况在 Lyft 基础设施中已经基本解决。Lyft 部署的每项服务都通过使用 E
以往有很多文章讲解 Istio 是如何做 Sidecar 注入的,但是没有讲解注入之后 Sidecar 工作的细节。本文将带大家详细了解 Istio 是如何将 Envoy 作为 Sidecar 的方式注入到应用程序 Pod 中,及 Sidecar 是如何做劫持流量的。 在讲解 Istio 如何将
本文为翻译文章,点击查看原文。 Envoy 通过查询文件或管理服务器来动态发现资源。概括地讲,对应的发现服务及其相应的 API 被称作 xDS 。Envoy 通过订阅( subscription )方式来获取资源,如监控指定路径下的文件、启动 gRPC 流或轮询 REST-JSON URL。后两种方
Cilium Kubernetes 本文为翻译文章,点击查看原文。 我们很高兴地宣布Cilium 1.3发布了。这个版本加入了几个新特性。主要的亮点是实现了Cassandra和带有策略执行能力的Memcached协议解析器,作为Envoy的Go语言扩展包。 和往常一样,整个Cilium社区的开发
本文为翻译文章,点击查看原文。 Envoy是专为Cloud Native应用设计的轻量级服务代理,也是为数不多的支持gRPC的代理之一。gRPC是一个基于HTTP/2的高性能RPC(远程过程调用)框架,支持多种语言。 Envoy 在这篇文章中,我们将使用gRPC和Protocol Bu
本文为翻译文章,点击查看原文。 如果你刚接触“Service Mesh“和“Envoy”,我这里有一篇文章可以帮你入门。 这是Envoy service mesh下的可观测性系列的第二篇文章,你可以在这里阅读第一篇关于分布式追踪的文章。 在微服务中谈及监控时,你可不能被蒙在鼓里,至少要知道问题出在哪
这是我在Envoy架构系列中的第3篇文章。这篇文章基于以前关于Envoy的线程模型和热重启功能的帖子。如果您还没有阅读这些帖子,请先阅读。 需要指出的是,随着预演的结束,我们现在可以进入更有趣的话题! 统计概述 到目前为止,Envoy所做的最重要的事情是为分布式系统的可观测性提供了一个健壮的平台。这
如果你是初次接触服务网格和Envoy,我这里有一篇文章可以帮助你入门。 在微服务架构中,可观测性变得越加重要。我认为这是选择微服务这条路的必要条件之一。我的一位前同事列出了一份非常棒的需求清单,如果你想做微服务,那么你需要满足提到的这些要求。 可观测性有许多事要做: 监控 报警 日志集中化 分布式
本文以 Istio 官方的 bookinfo 示例来讲解在进入 Pod 的流量被 iptables 转交给 Envoy sidecar 后,Envoy 是如何做路由转发的,详述了 Inbound 和 Outbound 处理过程。关于流量拦截的详细分析请参考理解 Istio Service Mesh
Envoy 是 Istio Service Mesh 中默认的 Sidecar,Istio 在 Enovy 的基础上按照 Envoy 的 xDS 协议扩展了其控制平面,在讲到 Envoy xDS 协议之前还需要我们先熟悉下 Envoy 的基本术语。下面列举了 Envoy 里的基本术语及其数据结构解析
本文为翻译文章,点击查看原文。 编者注:原文于 2017 年 7 月 30 日发布于 Envoy 博客上。 关于 Envoy 代码库的底层技术文档目前相当稀少。 为了纠正这个问题,我打算做一系列关于各种子系统的博客文章。 由于这是第一篇文章,请让我知道您的想法以及您希望了解的其他主题。 我经常看