Istio

1. 功能概述 Envoy启动时，会启动一个进程，并在这个进程中启动很多线程，这样，可以启动很多worker线程，一般worker线程数与核心数相同，每个worker线程处理所有已配置的listener上的请求，管理连接并处理filterchain，非阻塞；同时，在这个进程中会启动一个主线程，它负责启动和停止envoy，也是通过API提供配置管理的线程，同时它收集不同的指标，管理其它线程，也是非阻塞的。 2. 重要数据结构定义 2.1 Filter 过滤器，包括listener filter、network filter和http filter。Listener filter可以用于操作连接元数据，在新接收的套接字上进行操作，例如获取原始目的地址，重定向连接等；network filter主要负责数据读写；http filter主要负责数据处理。 2.2 Listener 监听器，envoy中支持在每个线程中配置任意数量的监听器，每个监听器独立配置一定数量的network filter，也可以选择性的配置listener filter，listener filter在连接建立之前处理，network filter在连接建立之后处理。 2.3 Worker 一个worker对应一个envoy的执行线程，将listener绑定在worker上，worker负责监听、过滤和转发

作者 | Drew Rothstein 策划 | Tina 当今，Kubernetes 已经成为容器编排领域的领导者。但是在 Coinbase 公司，却没有使用 Kubernetes。这是为什么？运行 Kubernetes 会产生哪些问题？ 本文要点：容器编排平台是一项复杂而令人惊叹的技术，它可以帮助一些企业和团队解决一系列的问题。然而，我们经常忽略的是，容器技术还带来了一系列的挑战，企业只有克服这些挑战才能避免失败。 https://github.com/hjacobs/kubernetes-failure-stories 1 历史 在讨论现状之前，让我们先了解下时至今日这项技术的发展历程。 1980 年代：chroot 1990 年代：jail 2000 年代（早期)：jail > FreeBSD 2000 年代（中期）：cgroups 2000 年代（后期）：LXC（Linux 容器) 2010 年代（早期）：Docker 2010 年代（后期）：Kubernetes 如果想进一步了解其历史，请查阅 Enterprise Docker 第七章。 https://www.oreilly.com/library/view/enterprise-docker/9781491994986/ 让我们从 10 年前说起，那时还没有现如今大家都知道的容器。那个时候，我们没有 / 不使用

《Istio Helm Chart 详解》系列的第五篇，介绍 Chart SidecarInjectorWebhook，负责对工作负载进行自动注入。 前言 这个 Chart 负责 Istio Sidecar 的自动注入操作相关配置。 关于自动注入操作的相关内容，可以参考官方文档中的相应章节，简单说来自动注入的两个先决条件： Kubernetes 版本大于 1.9。 启用了 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 。 还有一点，在 Kubernetes 1.10 版本中的 AlwaysPullImage 会和自动注入功能冲突 代码中可以看到，这一 Chart 生成了自动注入所需的 Deployment、Service，运行依赖的 RBAC 资源，以及自定义资源。 这个 Chart 会生成 MutatingWebhookConfiguration 类型的自定义资源，根据对命名空间以及 Pod 注解的监控对新生成的 Pod 进行注入。可以通过对这一自定义资源的修改，结合 ConfigMap istio-sidecar-injector 的内容对注入行为进行控制，后面将会进行讲解。 values.yaml 中的变量定义 sidecarInjectorWebhook: enabled: true replicaCount:

总第426 篇 2020年 第50篇 在私有云集群环境下建设 Service Mesh ，往往需要对现有技术架构做较大范围的改造，同时会面临诸如兼容困难、规模化支撑技术挑战大、推广困境多等一系列复杂性问题。本文会系统性地讲解在美团在落地 Service Mesh 过程中，我们面临的一些挑战及实践经验，希望能对大家有所启发或者帮助。 一、美团服务治理建设进展 1.1 服务治理发展史 首先讲一下 OCTO，此前美团技术团队博客也分享过很多相关的文章，它是美团标准化的服务治理基础设施，现应用于美团所有事业线。OCTO 的治理生态非常丰富，性能及易用性表现也很优异，可整体概括为 3 个特征： 属于公司级的标准化基础设施。技术栈高度统一，覆盖了公司 90% 以上的应用，日均调用量达数万亿次。 经历过较大规模的技术考验。覆盖数万个服务、数十万个节点。 治理能力丰富。协同周边治理生态，实现了 SET 化、链路级复杂路由、全链路压测、鉴权加密、限流熔断等治理能力。 回顾美团服务治理体系的发展史，历程整体上划分为四个阶段： 第一阶段是基础治理能力统一 。实现通信框架及注册中心的统一，由统一的治理平台支撑节点管理、流量管理、监控预警等运营能力。 第二阶段重点提升性能及易用性 。4 核 4GB 环境下使用 1KB 数据进行 echo 测试，QPS 从 2 万提升至接近 10 万，99 分位线 1ms

| 前言 本文内容整理自 5月25日 在 Kubernetes & Cloud Native Meetup 上海站发表的主题演讲，主要介绍了 Service Mesh 最新的产品动态，分析其发展趋势和未来走向；结合蚂蚁金服的上云实践，阐述在云原生背景下 Service Mesh 的核心价值，以及对云原生落地的关键作用。 内容主要有三个部分： Service Mesh 产品动态：介绍最近半年 Service Mesh 的产品动态，包括开源项目和云厂商推出的云上服务； Service Mesh 发展趋势：根据最近的产品动态，总结 Service Mesh 的发展趋势，推断未来的走向； Service Mesh 与云原生：结合云原生，更好的理解 Service Mesh 的价值和作用。 | Service Mesh 产品动态 Istio1.1 发布 Istio 是目前 Service Mesh 社区最引人注目的开源项目，在今年的 3月份 发布了期待已久的 Istio 1.1 版本，我们来看看 Istio 最近几个版本的发布情况： 2018年6月1日，Istio 发布了 0.8 版本，这是 Istio 历史上第一个 LTS 版本，也是 Istio 历史上变动最大的一个版本； 2018年7月31日，Istio 发布了 1.0 版本，号称 "Product Ready"； 然后就是漫长的等待

很多同学看到这个题目，一定会提这样的问题：RSocket是个协议，Envoy是一个 proxy，Istio是service mesh control plane + data plane。 这三种技术怎么能放在一起比较呢？ 的确，从技术定位的角度来讲，它们确实是有很大的差距。但是，如果我们用RSocket来治理微服务，会有哪些不同呢？ RSocket RSocket是一种应用层协议，不是一个传输层的协议。一方面，它可以包容和支持不同的传输层协议和相关技术，比如tcp 和 proto buf。另一方面，它的重点是把反应流的实现，提升到应用层上来。 其实在底层的协议中，就有反应流的实现，tcp的滑动窗口就是很好的例子。但是往上，这种好的机制不见了，给编程的工作造成很多的麻烦。很大一部分的线上故障是由于阻塞链接造成的。另一方面，很多应用层的网络软件，从设计的时候就开始避免这样的麻烦，造成结构臃肿，通讯效率底下。简单的例子是如果所有的通讯都是反应式的，那就不用熔断了。 基于RSocket 的应用不止是端到端通讯，Broker也是对这个协议水到渠成的应用。作为一个反应式的Broker，它同样是异步，非阻塞的通讯方式，主要维护与就近的各个应用的链接以及和其它Broker的链接。与其它协议相比，它是多路复用，同时支持长链接。 经过这样的解释，不难理解

地球对面的时间比我们这里晚一点，我们的 618 已经开始返场了，他们还在 618。 服务网格方面，在这一天有了两个发布： Envoy 发布了移动版 Istio 发布了 1.2 Envoy Mobile Envoy Mobile 是一个库，目的是可以直接将 Envoy 的功能封装到移动应用之中， 跨平台的底层网络支持：HTTP/2、QUIC、gRPC、推送、流、重试和超时策略等底层网络技术的实现以及跨平台都是需要付出大量努力来完成的事情，Evnoy Mobile 试图在客户端以一致的跨平台的方式提供这所有功能。 xDS 支持：Envoy 的最深套路就是 xDS 了，Envoy 一旦潜入移动应用，就可以通过 xDS 的方式，在服务端对客户端的网络行为作出控制。 API 的高级支持：用注解方式为 API 提供缓存、优先级等支持 这个项目还非常早期，但是我觉得非常有意思，强悍的 Envoy 用这种方式为移动应用提供了一个可控的网络抽象的能力，目前已经提供了 Java、Swift、OC 等支持，这会不会成为一种新的边缘能力？ Istio 1.2 补丁版本，没啥好说。 参考链接 https://docs.google.com/document/d/1N0ZFJktK8m01uqqgfDRVB9mpC1iEn9dqkQaa_yMn_kE/edit# https://istio.io/about

Istio在服务网格方面有很大的领先优势，但只在早期采用者中如此。根据云计算基金会（CNCF）的调查，在已经在生产中使用服务网格的用户中，63%的用户已经采用了Istio，这是linker的两倍多。其他的选择中，除了HashiCorp的Consul之外，占比都不超过10%。 如果考虑到它通常与Envoy一起部署的事实，Istio的优势就没有那么吓人了。Envoy最近无可否认做得很好。CNCF社区中Envoy项目的生产使用率从2019年的17%上升到2020年的24%。但评估该项目的人从35%下降到21%，这可能意味着许多组织考虑并拒绝了Envoy，这可能会对未来服务网格的采用产生影响。并不是每个人都将Envoy与服务代理或入口控制联系起来。当筛选掉这一功能时，只有18%的用户在生产或评估情况下使用了Envoy。 超过一半（55%）的为Ingress使用Envoy的受访者在生产中有服务网格。另有26%的人正在积极测试服务网格，9%的人计划在未来12个月内开始。其中大部分都倾向于Istio，以及基于项目技术的解决方案，例如F5 Networks的Aspen Mesh和Tetrate。 另一个调查则显示，并非所有的服务网格采用都将来自CNCF社区（那里充斥着供应商和大公司）。NGINX在2020年6月调查了近500人，调查结果显示，16%使用NGINX入口控制器（NIC），其中19