Istio

下周六，深圳，阔别已久的线下技术沙龙要和你见面啦！ 现场有Rancher Labs研发经理demo刚刚发布的Rancher 2.3中的Istio、Windows容器、集群模板等功能及使用，还有k3s首次线下workshop，由Rancher Labs资深架构师带你一起玩转k3s！还有长城证券的运维负责人分享数字化浪潮下传统金融IT的转型。 访问链接 即可了解详情及报名啦! 诸如容器、Kubernetes等云原生架构和技术的成熟推动了服务网格架构的极速增长以及广泛采用。尽管云原生环境可以为企业带来一系列好处，但是其复杂性也对负责开发维护这类系统的人员，如软件开发人员、网络运维人员、基础架构工程师以及CIO、CTO等带来了重大挑战。 服务网格框架能够为跨不同云原生环境的应用程序整合一致的服务和网络管理能力，它还极大地加快了DevOps实践的进程，正缘于此，服务网格近年来可谓是发展迅猛。云原生普及的加快，要求拥有云原生应用程序的工程团队必须熟悉服务网格功能，以判断该技术将来是否能为企业提供价值。 什么是服务网格？ 服务网格可以连接、保护、控制以及监控在编排平台上的服务。“服务网格”这一术语本身用于分布式应用程序中服务之间的一组搭接网络连接，也适用于管理该组连接服务的一系列工具。如果你有两个通过网络连接进行交互的微服务，那就意味着你有了一个服务网格。下图是一个十分简单的示例

I have multiple public and private applications running in my kubernetes cluster. I want to separate out traffic for each type by running multiple istio-gateway deployments. Is there any straight methods to implement it with istio. For both type of application I am using custom CA and importing certificates as secret manually. Do I need to anything cert manager part to achieve my use case The cert-manager is not required to achieve this configuration. To install custom istio-ingress-gateway (for you private domain) next to the default one (for public domain), you can take as an example '

敖小剑，蚂蚁金服高级技术专家，十七年软件开发经验，微服务专家，Service Mesh 布道师，ServiceMesher 社区联合创始人。 本文内容整理自 8 月 11 日 Service Mesher Meetup 广州站主题演讲，完整的分享 PPT 获取方式见文章底部。 前言 标题“Service Mesh发展趋势(续)”中的“续”是指在今年5月底，我在 CloudNative Meetup上做了一个“ Service Mesh发展趋势：云原生中流砥柱 ”的演讲，当时主要讲了三块内容：Service Mesh 产品动态、发展趋势、与云原生的关系。后来有同学反应希望部分感兴趣的内容能讲的更深一些，所以今天将继续“Service Mesh 发展趋势”这个话题。 今天给大家分享的内容有部分是上次演讲内容的深度展开，如社区关心的 Mixer v2 以及最近看到的一些业界新的技术方向，如 web assembly 技术，还有产品形态上的创新，如 google traffic director 对 Service Mesh 的虚拟机形态的创新支持。 在 Service Mesh 出道四年之际，也希望和大家一起带着问题来对 Service Mesh 未来的发展进行一些深度思考。 在正式开始分享之前，让我们先轻松一下，下面是最近流行的梗，各种灵魂拷问： 我们今天的分享内容，将效仿上面的方式

Naftis( https://github.com/xiaomi/naftis ) 是一个基于 web 的 Istio dashboard，通过任务模板的方式来帮助用户更方便地执行 Istio 任务。 用户可以在 Naftis 中定义自己的任务模板，并填充变量来构造单个或多个构造任务实例，从而完成各种服务治理功能。 代码结构 . ├── bin # 存放编译好的 Go 二进制文件 ├── config # 存放配置文件 │ ├── in-cluster.toml # 在 Kubernetes 集群中启动的配置 │ └── in-local.toml # 本地启动的配置 ├── install # Helm Charts │ └── helm │ ├── mysql │ └── naftis ├── src # 源码 │ ├── api # 后端 Go API 服务源码 │ │ ├── bootstrap # 启动 Go API 服务相关参数包 │ │ ├── executor # task 队列执行器 │ │ ├── handler # HTTP handlers │ │ ├── log # 基于 zap 封装的 log 包 │ │ ├── middleware # HTTP 中间件 │ │ ├── model # 全局通用 model │ │ ├── router # HTTP

流量治理是一个非常宽泛的话题，例如： 动态修改服务间访问的负载均衡策略，比如根据某个请求特征做会话保持； 同一个服务有两个版本在线，将一部分流量切到某个版本上； 对服务进行保护，例如限制并发连接数、限制请求数、隔离故障服务实例等； 动态修改服务中的内容，或者模拟一个服务运行故障等。 在Istio中实现这些服务治理功能时无须修改任何应用的代码。较之微服务的SDK方式，Istio以一种更轻便、透明的方式向用户提供了这些功能。用户可以用自己喜欢的任意语言和框架进行开发，专注于自己的业务，完全不用嵌入任何治理逻辑。只要应用运行在Istio的基础设施上，就可以使用这些治理能力。 一句话总结Istio流量治理的目标：以基础设施的方式提供给用户非侵入的流量治理能力，用户只需关注自己的业务逻辑开发，无须关注服务访问管理。 Istio流量治理的概要流程如图1所示： 图1 Istio流量治理的概要流程 在控制面会经过如下流程： （1）管理员通过命令行或者API创建流量规则； （2）Pilot将流量规则转换为Envoy的标准格式； （3）Pilot将规则下发给Envoy。 在数据面会经过如下流程： （1）Envoy拦截Pod上本地容器的Inbound流量和Outbound流量； （2）在流量经过Envoy时执行对应的流量规则，对流量进行治理。 负载均衡

I need to setup mutual tls communication from kubernetes pod to external service. My system is running with istio system. I found reference about this. https://istio.io/docs/reference/config/networking/v1alpha3/destination-rule/#TLSSettings apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: external-mtls spec: host: *.external.com trafficPolicy: tls: mode: MUTUAL clientCertificate: /etc/certs/myclientcert.pem privateKey: /etc/certs/client_private_key.pem caCertificates: /etc/certs/rootcacerts.pem According to this document, All I need to do is set mode MUTUAL (not

Helm 是目前 Istio 官方推荐的安装方式，除去安装之外，还可以利用对输入值的一些调整，完成对 Istio 的部分配置工作。官方提供了 Istio 的 Helm 部署方式，侧重于快速启动，而这一组文章将会采用由上至下的顺序，基于 Istio 1.0.2 版本的 Helm Chart 做一系列的讲解。 Istio 的 Helm Chart 分为两个大分支：istio 和 istio-remote，后者为多集群部署方式，这里暂不涉及，后面的内容围绕 istio 展开。 总体结构 Istio Chart 是一个总分结构，其分级结构和设计结构是一致的，这里做一个简单的说明。 Chart.yaml Chart 的基础信息，这里看到 1.0.2 的 Release 中， version 的值还是 1.0.1；要求的 Tiller 版本要大于等于 2.7.2-0 。 values-*.yaml 这里提供了一组 values 文件，提供 Istio 在各种场景下的关键配置范本。对 Istio 的定制可以从 values.yaml 的改写开始，完成后可以使用 helm template 命令来生成最终的部署文件供 kubectl 使用。 values.yaml 文件的一些细节可以参考官方文档。 values-istio-auth-galley.yaml ：启用控制面 mTLS；缺省打开网格内的

2019年10月9日，业界领先的容器管理软件提供商Rancher Labs（以下简称Rancher）正式发布Rancher 2.3 GA版本。这一版本是Rancher Labs迄今为止最重要的版本更新。Rancher 2.3是业界首个GA支持Windows容器的Kubernetes管理平台，并正式集成了Istio，还引入了创新的“集群模板”功能以增强企业集群的安全性。这些新功能无疑将极大助力企业充分利用Kubernetes变革性的力量，并为企业生产中落地Kubernetes提供更加便捷的途径，从而进一步实现了Rancher一直以来“Run Kubernetes Everywhere”的理念和战略。 “Gartner预测，到2022年，将有超过75%的全球性组织会在生产中运行容器化工作负载，”Rancher Labs联合创始人及CEO梁胜说道，“Rancher 2.3通过将Kubernetes的优势引入Windows应用程序中，并为企业提供对在任何地方（数据中心、云、边缘场景等）运行的容器的全局控制和可见性，扩展了我们的市场领导地位。” 首个GA支持Windows容器的Kubernetes管理平台 现如今，有70%的本地工作负载都运行在Windows Server操作系统中，因此对Windows容器的支持，一直是近年Kubernetes生态中最为需求的技术之一。 “今年3月

Service Mesh 发展趋势：云原生中流砥柱 前言 本文内容整理自5月25日在 Kubernetes & Cloud Native Meetup 上海站发表的主题演讲，主要介绍了 ServiceMesh 最新的产品动态，分析其发展趋势和未来走向；结合蚂蚁金服的上云实践，阐述在云原生背景下 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