本文为翻译文章，点击查看原文。 Sidecar代理模式是一个重要的概念，它允许Istio为服务网格中运行的服务提供路由、度量、安全和其他功能。在这篇文章中，我将解释为Istio提供支持的关键技术，同时还将向您展示一种构建简单的HTTP流量嗅探sidecar代理的方法。 引言 服务网格的实现通常依赖于sidecar代理，这些代理使得服务网格能够控制、观察和加密保护应用程序。sidecar代理是反向代

本文转载自赵化冰的博客。 在Istio架构中，Pilot组件负责维护网格中的标准服务模型，该标准服务模型独立于各种底层平台，Pilot通过适配器和各底层平台对接，以使用底层平台中的服务数据填充此标准模型。 例如Pilot中的Kubernetes适配器通过Kubernetes API Server到Kubernetes中的Service以及对应的Pod实例，将该数据被翻译为标准模型提供给Pilot使

引子 这几天拜读了灵雀云出品的一篇文章：《从“鸿沟理论”看云原生》，其中有两段关于 Istio 的陈述，我深感赞同： 在 Control Plane，Istio 是最具光环的明星级项目。它正在引领 Service Mesh 创造出一个全新的市场，不过从传播周期看现在还没有跨过技术鸿沟，处于 Early adopters 阶段。 在开源领域，并不存在对Istio有实质性威胁的竞品。可能在经历了 Ku

作者: 钟华，腾讯云容器团队高级工程师，热衷于容器、微服务、service mesh、istio、devops 等领域技术 今天我们分析下 istio-sidecar-injector 组件: image-20190319105935249 查看高清原图 用户空间的Pod要想加入mesh, 首先需要注入sidecar 容器, istio 提供了2种方式实现注入: 自动注入: 利用 Kubernet

背景 对于服务的可见性，在 Istio 设计之初，是没有特别考虑的，或者说，Istio 一开始的假定，就是建立在如下这个前提下的： Istio中的每个服务都可以访问Mesh中的任意服务 即在服务发现/请求转发这个层面，对服务访问的可见性不做任何限制，而通过安全机制来解决服务间调用权限的问题，如RBAC的使用。在这个思想的指导下，Pilot组件是需要将全量的服务信息（服务注册信息和服务治理信息）下发

下面这段是发布说明，来自 Istio 官方博客 https://istio.io/zh/blog/2019/announcing-1.1/，译者宋净超。 Istio 于北京时间今日凌晨4点，太平洋时间下午1点 Istio 1.1 发布。 自从去年 7 月份 1.0 发布以来，为了帮助人们将 Istio 投入生产我们做了很多工作。我们不出所料得发布了很多补丁（到目前为止已经发布了 6 个补丁！），但

本文为翻译文章，点击查看原文。 这篇文章是使用Istio打造微服务的第二部分，如果没有看第一篇的话，请先看第一部分内容，因为这篇博客是以第一篇博客为基础进行进一步深入的。 在第一篇文章中，我们建立了一个Kubernetes集群，并且在上面部署了 Istio 和示例微服务应用程序“Sentiment Analysis”，用来展示Istio的功能。 使用Istio后，我们可以把应用层中的重试、超时、断

本文为翻译文章，点击查看原文。 Istio提供了非常易用的安全解决方案，包括服务间身份验证mTLS，服务间访问控制RBAC，以及终端用户身份验证JWT等，本文主要介绍如何使用服务间访问控制，同时涉及双向TLS。 Istio版本 1.1.0 在的github.com/hb-go/micro-mesh中有结合示例的RBAC配置实践可以参考 要实现RBAC主要理解以下几个类型的yaml配置，以及之间的关

本文为翻译文章，点击查看原文。 编者案 Idit Levine 作为 solo.io 创始人兼首席执行官，在本系列博客中介绍了她们的产品 Gloo。这篇博客是系列中的其中一篇，这一篇的主要内容是，如果要基于 Envoy 构建一个控制平面的话，我们需要考虑哪些问题；要用什么样的解决方案来应对这些问题。作者在本文章阐述了 Envoy 的工作原理、为什么要选择 Envoy 以及在构建一个控制平面过程中要

背景 由于容器化和微服务的大力发展，Kubernetes基本已经统一了容器管理方案，当我们使用Kubernetes来进行容器化管理的时候，全面监控Kubernetes也就成了我们第一个需要探索的问题。我们需要监控kubernetes的ingress、service、deployment、pod……等等服务，以达到随时掌握Kubernetes集群的内部状况。 此文章也是Prometheus监控系列的

背景 由于容器化和微服务的大力发展，Kubernetes基本已经统一了容器管理方案，当我们使用Kubernetes来进行容器化管理的时候，全面监控Kubernetes也就成了我们第一个需要探索的问题。我们需要监控kubernetes的ingress、service、deployment、pod……等等服务，以达到随时掌握Kubernetes集群的内部状况。 此文章是Prometheus监控系列的第

背景 由于容器化和微服务的大力发展，Kubernetes基本已经统一了容器管理方案，当我们使用Kubernetes来进行容器化管理的时候，全面监控Kubernetes也就成了我们第一个需要探索的问题。我们需要监控kubernetes的ingress、service、deployment、pod……等等服务，以达到随时掌握Kubernetes集群的内部状况。 此文章是Prometheus监控系列的第

本文为翻译文章，点击查看原文。 在微服务领域，各个服务需要在网络上执行大量的调用。而网络是很脆弱的，如果某个服务繁忙或者无法响应请求，将有可能引发集群的大规模级联故障，从而造成整个系统不可用，通常把这种现象称为 服务雪崩效应。为了使服务有一定的冗余，以便在系统故障期间能够保持服务能力，我们可以使用熔断机制。 什么是熔断？ 熔断（Circuit Breaking）这一概念来源于电子工程中的断路器（C

本文为翻译文章，点击查看原文。 编者按 如果说Spring Cloud是以SpingBoot为核心和基础的微服务架构，那么MicroProfile则是将传统JavaEE轻量化以适应微服务时代的一个体系。作者Emily Jiang，开源项目eclipse/microprofile的contributor之一，在本文中探讨了如何结合MicroProfile与流行的服务网格Istio安全地部署微服务，比

本文为翻译文章，点击查看原文。 “服务网格”是一个热点话题。似乎去年每一个与容器相关的大会都包含了一个“服务网格”议题，世界各地有影响力的业内人士都在谈论这项革命性的技术带来的好处。 然而，截至2019年初，服务网格技术仍不成熟。主要的实现产品Istio还没有准备好进行广泛的企业级部署，只有少数成功的案例运行在生产环境中。也存在其他的服务网格产品，但并没有得到业界专家所说的广泛关注。 我们如何协调

作者: 钟华，腾讯云容器产品中心高级工程师，热衷于容器、微服务、service mesh、istio、devops 等领域技术。 今天我们来解析istio控制面组件Galley。Galley Pod是一个单容器单进程组件, 没有sidecar, 结构独立，职责明确。 查看高清原图 前不久istio 1.1 版本正式发布, 其中istio的配置管理机制有较大的改进, 以下是1.1 release n

本文为翻译文章，点击查看原文。 原文发表于2019年3月27日。 在 re:Invent 2018，AWS宣布了AWS App Mesh 的公开预览版，App Mesh是一个服务网格，可以轻松监视和控制跨应用的通信。今天，我很高兴地宣布App Mesh 已经可以为用户提供使用了（GA）。 新的架构模式 许多客户正在对现有应用进行现代化改造，以求更快更灵活地进行创新。微服务等架构模式使团队能够独立测

本文为翻译文章，点击查看原文。 这是探索为 Envoy 代理构建控制平面系列文章的第3部分。 在本系列博客中，我们将关注以下领域: 采用一种机制来动态更新 Envoy 的路由、服务发现和其他配置 确定控制平面由哪些组件组成，包括支持存储、服务发现 api、安全组件等 建立最适合您的使用场景和组织架构的特定于域的配置对象和 api（本博客） 考虑如何最好地使您的控制平面可插在您需要它的地方 部署各种

Istio 服务网格架构的概述，通常都是从对数据面和控制面的叙述开始的。 来自 Istio 的官方文档。 Istio 服务网格逻辑上分为数据平面和控制平面。 数据平面由一组以 sidecar 方式部署的智能代理（Envoy）组成。这些代理和 Mixer（一个通用的策略和遥测中心）合作，对所有微服务之间的之间所有的网络通信进行控制。 控制平面负责管理和配置代理来路由流量。此外控制平面配置 Mixer

本文为翻译文章，点击查看原文。 持续部署（Continuous delivery）符合企业软件实践，它是完善持续集成（continuous integration）原则的自然演化。 但持续部署案例却非常罕见，其中原因可能是需要复杂的管理以及担心部署失败而影响系统的可用性。 Flagger是一个开源的Kubernetes operator，旨在解决上述复杂性。它使用Istio切换流量并通过Prome