Istio 成为 CNCF 项目的毕业生。这一历史性的时刻代表着 Istio 在云原生领域的成长和成熟，标志着最广泛部署的服务网格迎来了一个令人兴奋的新篇章。Kubernetes 是 第一个获得毕业资格的项目，时间是 2018 年。今天，自它作为一个孵化项目进入 CNCF 不到一年的时间，Istio 就毕业了，成为 CNCF 历史上最快的一个。 Tetrate 是由 Istio 创始团队的成员创立

要想部署istio，我门需要kubernetes组件。控制平面默认部署在istio-system名称空间内，包含，istiod,ingress-gateway,egress-gateway,addons(kiali.prometheus,grafanajacger)。而数据平面的自动注入只会在部署应用之后部署在应用的名称空间内，以Sidecar 运行，并且是需要打上一个label才能被启用。 而e

流量治理 在istio1.5后的版本，istiod充当控制平面，并且将配置分发到所有的sidecar代理和网关，能够支持网格的应用实现只能话的负载均衡机制。 而envoy通过简单的二次开发后在istio中称为istio-proxy，被用于围绕某个pod，以sidecar的模式允许在某个应用的pod中。除此之外envoy还负责ingress和egress，分别是入向和出向网关。 在k8s中，一旦is

6.故障注入 istiO支持两种故障注入，分别是延迟故障和中断故障 延迟故障：超时，重新发送请求 abort中断故障：重试 故障注入仍然在http层进行定义 中断故障 fault: abort: # 中断故障 percentage: value: 20 # 在多大的比例流量上注入 httpStatus: 567 # 故障响应码 延迟故障 fault: delay: percentage: valu

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 大家好，我是张晋涛。 就在昨天 Istio 正式成为 CNCF 毕业项目了 ！ 这是 Istio 发展过程中的一个重要的里程碑。 这篇文章我将快速回顾下 Istio 的发展历程以及它的一些主要特性。Istio 大概是我除了 Kubernetes 和 Docker 外写的相关内容

本文是 Istio 管理 Java 微服务的案例教程，使用的所有工具和软件全部基于开源方案，替换了 redhat-developer-demos/istio-tutorial 中的 minishift 环境，使用 kubernetes-vagrant-centos-cluster 替代，沿用了原有的微服务示例，使用 Zipkin 做分布式追踪而不是 Jaeger。 本文中的代码和 YAML 文件见

北京时间 2018 年 6 月 1 日（儿童节）上午 9: 30 Istio 0.8.0 LTS（长期支持版本）发布。该版本除了常见的一堆错误修复和性能改进之外，还包含以下更新和新功能。 Istio 0.8 发布 网络 改进了流量管理模型。我们终于准备好了推出新的流量管理配置模型。该模型增加了许多新功能并解决了先前模型的可用性问题。istioctl 中内置了一个转换工具来帮助您迁移旧模型。试用新的

本文为翻译文章，点击查看原文。 AspenMesh提供一种Istio的分布式架构支持，这意味着即使与上游Istio项目无关，我们也需要能够测试和修复Bug。为此我们已开发构建了我们自己的打包和测试基础架构方案。如果你对Istio的CI（持续集成）也感兴趣，请参考我们已经投入使用，可能有用但还没有提交给Circle CI或GKE的组件。 这篇文章描述的是我们如何制作一个新的Minikube-in-a

儿童节期间，拖拉了一个多月的 Istio 0.8 正式发布了，这可能是 Istio 1.0 之前的最后一个 LTS 版本，意义重大。 新版本中，原来的 Kubernetes 安装文件 install/kubernetes/istio.yaml，变成了 install/kubernetes/istio-demo.yaml，是的，你没看错，这个 LTS 的安装文件名字叫 demo。查看了一下文档，大概

本文为翻译文章，点击查看原文。 到目前为止，Istio提供了一个简单的API来进行流量管理，该API包括了四种资源：RouteRule、DestinationPolicy、EgressRule和Ingress（直接使用了Kubernets的Ingress资源）。借助此API，用户可以轻松管理Istio服务网格中的流量。该API允许用户将请求路由到特定版本的服务，为弹性测试注入延迟和失败，添加超时和

前言 本系列文章将详细介绍Istio中Mixer Cache的工作原理，为了避免空谈，将引入广大程序员同学喜闻乐见的源码分析环节，并结合Mixer的接口API，详细展现Mixer Cache的各种细节。 预警：Mixer Cache系列文章除了本文讲述概念比较简单外，其它文章会包含大量复杂和繁琐的细节，包括设计／实现／API等，适合追求深度的同学。 阅读本系列文章前，请确保对Service Mes

本文为翻译文章，点击查看原文。 把单体应用拆分为微服务之后，会得到不少好处，例如稳定性的提高、持续运行时间的增长以及更好的故障隔离等。然而把大应用拆分为小服务的过程中，也会引入一个风险就是——可能的受攻击面积变大了。从前单体应用中通过函数调用完成的通信，现在都要通过网络完成。提高安全性从而避免这个问题带来的安全影响，是微服务之路上必须要着重考虑的问题。 Aspen Mesh 的基础是一个开源软件：

Istio 为网格中的微服务提供了较为完善的安全加固功能，在不影响代码的前提下，可以从多个角度提供安全支撑，官方文档做了较为详细的介绍，但是也比较破碎，这里尝试做个简介兼索引，实现过程还是要根据官方文档进行。 Istio 的安全功能主要分为三个部分的实现： 双向 TLS 支持。 基于黑白名单的访问控制。 基于角色的访问控制。 JWT 认证支持。 首先回顾一下 Istio 网格中的服务通信过程： 利

本文转载自敖小剑的博客 经过前面基本概念和实现原理的介绍，大家对mixer check cache应该有了基本的了解，下面我们开始展开源代码来细细研读。 Check Cache的主要流程 Check Cache的调用入口 对mixer cache的调用在代码 proxy/src/istio/mixerclient/client_impl.cc中的方法Check()中，此处跳过quota cache

本文为翻译文章，点击查看原文。 Istio已经成为一种流行且可靠的服务网格管理平台，使用它可以更轻松地部署、操作和扩展跨云部署的微服务。作为保证这些服务网格的一种方式，Twistlock已经与Istio集成，以丰富平台的连接机器学习功能。 Twistlock通过使用Twistlock数据来隔离受损服务并提供合规策略来执行安全配置，以及Istio运行的其他堆栈。 随着云原生成为构建和运行现代的基于W

本文为翻译文章，点击查看原文。 如何确保微服务之间网络通信的可靠性、安全性和可管理性？ 使用服务网格吧！ 在过去一年中，Istio服务网格技术引发关注度和吸引力的持续提升，这是一件非常有趣的事情。 事实上，在我写这篇文章时，Istio仅为0.8版本，但对于最近两届KubeCon/CloudNativeCon活动而言，它一直是热门话题，仅在丹麦的活动中就有超过十几个不同的活动议题。 那么它为什么会这

vistio全局级别可视化视图 本文为翻译文章，点击查看原文。 Vistio GitHub地址：https://github.com/nmnellis/vistio Vizceral是Netflix发布的一个开源项目，用于近乎实时地监控应用程序和集群之间的网络流量。Vistio是使用Vizceral对Istio和网格监控的改进。它利用Istio Mixer生成的指标，然后将其输入Prometheu

本文转载自nino’s blog。 本篇总结pilot的xDS常用接口，顺便浏览了部分pilot实现，下篇总结下istio的流量管理和服务发现的实现。简单来说istio做为管理面，集合了配置中心和服务中心两个功能，并把配置发现和服务发现以一组统一的xDS接口提供出来，数据面的envoy通过xDS获取需要的信息来做服务间通信和服务治理。 api v1 reference Istio中部署pilot的

多租户是一个在各种环境和各种应用中都得到了广泛应用的概念，但是不同环境中，为每租户提供的具体实现和功能性都是有差异的。Kubernetes 多租户工作组致力于在 Kubernetes 中定义多租户用例和功能。然而根据他们的工作进展来看，恶意容器和负载对于其他租户的 Pod 和内核资源的访问无法做到完全控制，因此只有“软性多租户”支持是可行的。 软性多租户 文中提到的“软性多租户”的定义指的是单一

本文为翻译文章，点击查看原文。 更新 感谢 Laurent Demailly 的评论，这里有一些更新。这篇文章已经得到了更新： 现在有一个 Cert-Manager 官方 Helm chart Istio Ingress 也支持基于 HTTP/2 的 GRPC Istio Istio 是管理微服务世界中数据流的一种新方式。事实上，这对我来说更是如此。人们不停的谈论微服务与单体应用，说微服务更好开发