Envoy

Istio 是一个开源的服务网格，可为分布式微服务架构提供所需的基础运行和管理要素。随着各组织越来越多地采用云平台，开发者必须使用微服务设计架构以实现可移植性，而运维人员必须管理包含混合云部署和多云部署的大型分布式应用。Istio 采用一种一致的方式来保护、连接和监控微服务，降低了管理微服务部署的复杂性。 从架构设计上来看，Istio 服务网格在逻辑上分为控制平面和数据平面两部分。其中，控制平面 Pilot 负责管理和配置代理来路由流量，并配置 Mixer 以实施策略和收集遥测数据；数据平面由一组以 Sidecar 方式部署的智能代理（Envoy）组成，这些代理可以调节和控制微服务及 Mixer 之间所有的网络通信。 作为代理，Envoy 非常适合服务网格的场景，但要发挥 Envoy 的最大价值，就需要使它很好地与底层基础设施或组件紧密配合。Envoy 构成了服务网格的数据平面，Istio 提供的支撑组件则是创建了控制平面。 一方面，我们在 Envoy 中看到，可以使用静态配置文件或使用一组发现服务来配置一组服务代理，以便在运行时发现监听器、端点和集群。Istio 在 Pilot 中实现了这些 Envoy 代理的 xDS API。 另一方面，Envoy 的服务发现依赖于某种服务注册表来发现服务端点。Istio Pilot 实现了这个 API，但也将 Envoy

Istio 1.6.3 发布了。Istio 是一个由谷歌、IBM 与 Lyft 共同开发的开源项目，旨在提供一种统一化的微服务连接、安全保障、管理与监控方式。具体来说，Istio 是一个开源服务网格平台，它确保微服务在处理故障时以指定的方式相互连接。 更新内容 修复了监视资源被删除后，操作员无法重新创建的问题 修复了Istio因消息崩溃的问题： proto.Message is *client.QuotaSpecBinding, not *client.QuotaSpecBinding 添加了对 k8s.v1.cni.cncf.io/networks 注释的支持 更新了 SidecarInjectionSpec 以从 .Values.global 读取 imagePullSecret 更新了水平分割以跳过解析主机名的网关 修复了 istioctl experimental metrics ，仅将错误响应代码标记为 erros 更新了 istioctl analyze 以对输出格式进行排序 更新了网关以使用 proxyMetadata 更新了 Prometheus Sidecar 以使用 proxyMetadata 启用 gateway.runAsRoot 时从 PodSecurityContext 中删除了无效的配置 升级更新 从已有版本升级，运行： istioctl

Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖 Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh，来自陌陌和百度的 Service Mesh 生产实践。 本文根据5月7日晚，美国 Service Mesh 服务商 Tetrate 创始工程师高洪涛的主题分享《Apache SkyWalking 在 Service Mesh 中的可观察性应用》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。 前言 本次演讲为大家分享的是 Apache SkyWalking 对 Service Mesh 可观测性方面的应用实践，共分为三个部分： 第一部分是 Apache SkyWalking 的相关背景； 第二部分是 Service Mesh 场景下 SkyWalking 所面临的挑战； 最后是针对 Service Mesh 场景方案的演化； SkyWalking 的历史沿革及其特点 SkyWalking 项目的建设目的是为了解决在微服务环境下

作者 | 声东 阿里云售后技术专家 **<关注阿里巴巴云原生公众号，回复 排查 即可下载电子书> ** 《深入浅出 Kubernetes》一书共汇集 12 篇技术文章，帮助你一次搞懂 6 个核心原理，吃透基础理论，一次学会 6 个典型问题的华丽操作！ Istio is the future！基本上，我相信对云原生技术趋势有些微判断的同学，都会有这个觉悟。其背后的逻辑其实是比较简单的：当容器集群，特别是 Kubernetes 成为事实上的标准之后，应用必然会不断的复杂化，服务治理肯定会成为强需求。 **Istio 的现状是，聊的人很多，用的人其实很少。**所以导致我们能看到的文章，讲道理的很多，讲实际踩坑经验的极少。阿里云售后团队作为一线踩坑团队，分享问题排查经验，我们责无旁贷。这篇文章，我就跟大家聊一个简单 Istio 问题的排查过程，权当抛砖。 二分之一活的微服务 问题是这样的，用户在自己的测试集群里安装了 Istio，并依照官方文档部署 bookinfo 应用来上手 Istio。部署之后，用户执行 kubectl get pods 命令，发现所有的 Pod 都只有二分之一个容器是 READY 的。 # kubectl get pods NAME READY STATUS RESTARTS AGE details-v1-68868454f5-94hzd 1/2 Running 0

课程概要 如今微服务已成为构建现代云应用的主导模式，它围绕着特定的业务功能，将单个组件分解为独立的服务。但随之而来产生另外的问题：越来越多的系统被拆解成了很多个细胞一样的微服务，如何对微服务进行管理，这成为许多工程师头疼的挑战。 相信很多成熟企业都拥有复杂的研发环境：上百条产品线、上千位开发人员、数千个服务。 服务部署在多个地域的多个机房，各种服务运行环境很多。开发语言繁多，例如京东智联云以Go、C++、Java、Node.js为主，少量的Python和PHP，随着业务线不同使用的技术框架不同。调用协议有rest，有非rest的HTTP等，还有自定义TCP协议的…… 如何统一管理？服务治理应运而生。通过服务治理来解决分布式服务和微服务在整体的开发和运行时出现的运维问题，处理服务之间的关系，提供一系列数据依据和工具。 4月21日，技术公开课《六周玩转云原生》第五讲《微服务架构下，服务治理体系的演进历程》由京东云与AI事业部云产品研发部架构师张俊峰为大家详细讲解了服务治理、Spring Cloud微服务架构特点、Service Mesh以及京东智联云在微服务的探索。 以下是精华分享内容，咱们一起来看看： 六周玩转云原生 微服务架构下服务治理体系的演进历程 — 京东云与AI产品研发部架构师 张俊峰 — 1 服务治理演变史 服务治理是随着业务规模的不断扩大

1、概述 Mixer是Istio的核心组件，提供了遥测数据收集的功能，能够实时采集服务的请求状态等信息，以达到监控服务状态目的。 1.1 核心功能 •前置检查（Check）：某服务接收并响应外部请求前，先通过Envoy向Mixer（Policy组件）发送Check请求，做一些access检查，同时确认adaptor所需cache字段，供之后Report接口使用； •配额管理（Quota）：通过配额管理机制，处理多请求时发生的资源竞争； •遥测数据上报（Report）：该服务请求处理结束后，将请求相关的日志，监控等数据，通过Envoy上报给Mixer（telemetry） 1.2 示例图 2、代码分析 2.1 Report代码分析 本节主要介绍Report的详细流程（基于Istio release1.0.0版本，commit id为3a136c90）。Report是mixer server的一个接口，供Envoy通过grpc调用。首先，我们从mixer server的启动入口main函数看起： func main() { rootCmd := cmd.GetRootCmd(os.Args[1:], supportedTemplates(), supportedAdapters(), shared.Printf, shared.Fatalf) if err := rootCmd

我们知道每个pod内都会有一个Envoy容器，其具备对流入和流出pod的流量进行管理，认证，控制的能力。Mixer则主要负责访问控制和遥测信息收集。 如拓扑图所示，当某个服务被请求时，首先会请求istio-policy服务，来判定是否具备访问资格，若具备资格则放行反之则请求不会被下发到服务。这一切的访问信息，都会被记录在Envoy中，之后会上报给mixer作为原始数据。遥测数据的收集及其他功能完全是灵活可控的，你既可以配置新的收集指标和日志，也可以完全禁用这些功能。 1.Prometheus的应用和指标介绍 Prometheus是一款开源的监控和告警系统，2016年加入CNCF，以其灵活的检索语言，高效的数据存储方式以及多维度的数据模型使得越来越多的人使用。Istio自0.8开始就默认的将Prometheus包含在内，我们可以通过查询service或者pod看到普罗的运行状态和地址。点开Prometheus界面，UI十分简洁明了。 用户在Expression内输入想要查询数据的表达式，并且再输入的过程中，普罗还会在已有的指标中做出提示方便用户查找。我们输入一个简单的查询表达式istio_requests_total,点击Execute，在图形界面中，将鼠标放到图中的折线可以看到请求的详细信息。 详细信息中的每一项都可以作为选定参考指标的特性

大家都知道istio可以帮助我们实现灰度发布、流量监控、流量治理等功能。每一个功能都帮助我们在不同场景中实现不同的业务。那Istio是如何帮助我们实现监控和日志采集的呢？ 这里我们依然以Bookinfo应用程序作为贯穿此任务的示例程序。首先在集群中安装并部署Istio。 1 收集遥测数据 创建一个新的YAML文件，用来保存Istio将自动生成和收集的新度量标准和日志流的配置。如下图所示： 通过命令$ kubectl apply -f new_telemetry.yaml推送刚刚配置的YAML文件。然后去请求应用程序来生成流量，例如在本用例中就可以访问Bookinfo完成访问。 接下来我们就可以验证是否采集到了刚刚的请求数据。在Kubernetes环境中，通过执行以下命令为Prometheus设置端口转发： $ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=prometheus -o jsonpath='{.items[0].metadata.name}') 9090:9090 & 通过Prometheus UI查看新指标的值。执行对istio_double_request_count度量值的查询。Console选项卡中显示的表 包含类似于以下内容的条目：

大家都知道istio可以帮助我们实现灰度发布、流量监控、流量治理等功能。每一个功能都帮助我们在不同场景中实现不同的业务。那Istio是如何帮助我们实现监控和日志采集的呢？ 这里我们依然以Bookinfo应用程序作为贯穿此任务的示例程序。首先在集群中安装并部署Istio。 1 收集遥测数据 创建一个新的YAML文件，用来保存Istio将自动生成和收集的新度量标准和日志流的配置。如下图所示： 通过命令$ kubectl apply -f new_telemetry.yaml推送刚刚配置的YAML文件。然后去请求应用程序来生成流量，例如在本用例中就可以访问Bookinfo完成访问。 接下来我们就可以验证是否采集到了刚刚的请求数据。在Kubernetes环境中，通过执行以下命令为Prometheus设置端口转发： $ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=prometheus -o jsonpath='{.items[0].metadata.name}') 9090:9090 & 通过Prometheus UI查看新指标的值。执行对istio_double_request_count度量值的查询。Console选项卡中显示的表 包含类似于以下内容的条目：

凡是产生连接关系，就必定带来安全问题，人类社会如此，服务网格世界，亦是如此。 今天，我们就来谈谈Istio第二主打功能 --- 保护服务。 那么，便引出3个问题： l Istio 凭什么保护服务？ l Istio 具体 如何保护服务？ l 如何告诉Istio发挥保护能力？ 1 Istio凭什么保护服务？ 将单体应用程序分解为一个个服务，为大型软件系统的开发和维护带来了诸多好处，比如更好的灵活性、可伸缩性和可复用性。但这也带来了一些安全问题： l 为了抵御中间人攻击，需要对流量进行加密 l 为了提供灵活的服务访问控制，需要 mTLS（双向的安全传输层协议）和细粒度的访问策略 l 要审计谁在什么时候做了什么，需要审计工具 Istio 尝试提供全面的安全解决方案来解决这3个问题。 如上图所示， Istio 安全的三大目标是： l 默认安全（Security by default）：应用程序代码和基础结构，无需更改。 l 深度防御（Defense in depth）：与现有安全系统集成，提供多层防御。 l 零信任网络（Zero-trust network）：在不受信任的网络上，构建安全解决方案。 为了实现这3个目标，Istio 安全功能提供了4大守护系统： l 强大的身份（Identity）系统 l 健壮的策略（Policy）系统 l 认证，授权和审计（AAA：Authentication