Istio

在软件研发过程中，“测试环境”是部署最频繁、也是开发者使用最频繁的一种运行环境，稳定而易用的测试环境能够极大提高开发者的工作效率和幸福感。为更好的将阿里巴巴在测试环境管理方面的实践和经验跟广大开发者分享，《云效说码》策划了《阿里巴巴Kubernetes测试环境开源工具箱》系列直播视频，由阿里巴巴技术专家林帆（金戟）和郑云龙（砧木） 来为大家讲述。 本系列分享共有三节内容，本文整理自砧木的第二次分享《单人开发场景下的测试环境实践》。 【以下为分享实录，有删节】 《阿里巴巴测试环境管理概述》要点回顾 在正式开始本次分享之前，我们首先回顾一下上一次分享中我的同事金戟分享的要点。在测试环境管理中，我们主要遇到两个问题，第一个是本地与集群双向互通的问题，在阿里巴巴集团内部主要通过基于CNI(Conteinre Network Interface)机制改造Kubernetes的IP逻辑实现的“扁平化的内网IP”这个方法来解决，这种方式更适合大型集团企业。第二个问题是多人协作开发时，路由的可访问性控制问题，在阿里巴巴内部我们是通过“项目环境”与“隔离域”实现的。 程序员小黑的困扰：测试环境不稳定导致集成效率低下 本次分享，我们将把视角从阿里巴巴集团内部转向外部开发者，特别是广大开发者所在的中小团队，聊聊他们如何解决前文中提到的“本地与集群双向互通”的问题。 我们先来思考一个问题：在本地开发的时候

前言：Kubernetes-1.15.5集成Istio-1.5.2，小米开源的Istio管理工具 一、下载项目本地解压 二、创建命名空间kubectl create namespace naftis（名称可以自定义，但是对应的yaml文件中对应的命名空间对应也要改动），分别执行kubectl apply -n naftis -f mysql.yaml｜naftis.yaml，查看服务启动状态 三、将UI端口暴露外网访问、pod名称查找服务中的命名、对外端口可以自己指定 kubectl -n naftis port-forward pod/naftis-ui-9d66dbc74-hbq4m 8080:80 四、浏览器访问 http://127.0.0.1:8080/ ；账号密码：admin/admin 来源： oschina 链接： https://my.oschina.net/wubiaowpBlogShare/blog/4262444

Istio-proxy的report主要是将envoy采集到的连接attributes的信息上报给控制面的mixer，它的入口在request_handler_impl.cc文件中，这里需要打开enable_mixer_report开关，提取出report_data中的attribute信息,调用SendReport发送出去。 SendReport的实现在client_context_base.cc中,跳转到client_impl中。 client_impl.cc跳转到report_batch中。 report_batch.cc中会在batch_compresser中添加attributes作为向mixer发起的请求report,这里的Add是一个bool，判断是否所有的上次请求所用的attributes都在本次的report的请求中。 attribute_compressor.cc中定义了Add的方法，利用CompressByDict更新压缩过的attributes &pb，如果在这一步压缩的变量全部都在，那么compressbydict的返回值是true，会更新pb。如果有的attributes的变量不存在，那么返回值为false，不更新pb，回到上一张图。 Compress是否成功在下图的函数中判断，这里用到的是delta_update，在delta_update.cc中

前言 微服务架构提供了更好的灵活性、可伸缩性以及服务复用的能力，但，微服务也有特殊的安全需求，Istio Security尝试提供全面的安全解决方案。为了提供灵活的服务访问控制，需要双向 TLS 和细粒度的访问策略。Istio 提供两种类型的身份验证：传输身份验证和来源身份验证。通过配置不同级别的认证策略，可以快速控制不同的安全访问粒度。 典型的使用场景： 1.在未启用双向TLS的安装好 Istio 的 Kubernetes 集群中，需要快速启用全网格双向TLS； 2.网格内某些服务之间需要使用双向TLS，可以将这些服务放入同一命名空间并在命名空间启用双向TLS； 3.当单个服务需要启用TLS时，可以在配置策略中通过spec字段指定； 认证策略是对服务收到的请求生效的，要在双向 TLS 中指定客户端认证策略，需要在DetinationRule 中设置 TLSSettings，每个认证策略需要和目的地规则共同生效。下面通过实例来演示在不同存储范围内配置传输身份认证策略的过程，来源身份验证通过spec中的origins字段指定。 环境准备：装好istio的集群，禁用全局双向TLS；Httpbin应用镜像和sleep应用镜像 1.创建命名空间、部署应用 创建3个命名空间：foo、bar、legacy，foo和bar中部署带sidecar的httpbin应用和sleep应用

大家都知道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的无穷魅力。今天，将向大家介绍如何用Istio实现流量熔断。 熔断机制是创建弹性微服务应用程序的重要模式。熔断可以帮助您自由控制故障影响的范围、网络延迟的峰值以及抵御其他一些来自外部的恶意攻击等场景。 在接下来的任务中，idou老师将通过配置一个熔断器来详细介绍如何在Istio中实现熔断，以及背后的原理。 首先，我们需要添加一个应用程序来模拟访问网络中的通信。接着我们按照前面Istio实践中所要求的将Sidecar注入进应用中，然后启动应用。 步骤一 为了演示Istio的熔断功能，我们需要创建熔断器，并在熔断器中设置一个目标规则，如下所示： 在本步骤中，我们可以理解为Istio的熔断功能主要是通过在链接池中加入上述三个参数： MaxConnections定义了到目标主机的 HTTP1/TCP 最大连接数； http1MaxPendingRequests定义了针对一个目标的 HTTP 请求的最大排队数量； maxRequestsPerConnection定义了对某一后端的请求中，一个连接内能够发出的最大请求数量。如果将这一参数设置为 1 则会禁止 keep alive 特性。 在上述yaml文件中，我们为了方便进行实践，所以都设置成了1，当然大家也可以根据自己的需求自己设定阈值。 步骤二

使用Prometheus进行监控是Istio提供的监控能力之一。Istio提供丰富的监控能力，为网格中的服务收集遥测数据。Mixer是负责提供策略控制和遥测收集的Istio组件。 Istio通过Mixer实现流量监控的基本流程如下图：每个pod内有一个service和proxy，Envoy容器实现proxy功能，对流入和流出pod的流量进行管理、认证和控制。Mixer则主要负责访问控制和遥测信息收集。当某个服务被请求时，首先会请求istio-policy服务，来判定是否具备访问资格，若具备资格则放行，反之则请求不会被下发到服务。这一切的访问信息，都会被记录在Envoy中，之后会上报给Mixer作为原始数据，并生成具体的监测指标。 Figure 1 mixer拓扑 Mixer配合一系列后端基础设施，为运维提供丰富而深入的控制和监测，并且不额外增加服务开发人员负担。后端提供用于构建服务的支持功能，访问控制系统，遥测捕获系统，配额执行系统，计费系统等。Mixer开放了Istio服务与不同的基础设施后端的交互能力，隔离用户程序和各个基础设施后端的实现细节。Istio通过丰富组件的边界交互，减少系统复杂性，消除服务代码中的策略逻辑并将控制权交给运维。 Mixer处理不同基础设施后端的是通过使用通用插件模型实现的。每个插件都被称为 Adapter，Mixer通过它们可对接到不同的基础设施后端

在Istio中，双向TLS是传输身份验证的完整堆栈解决方案，它为每个服务提供可跨集群的强大身份、保护服务到服务通信和最终用户到服务通信，以及提供密钥管理系统。本文阐述如何在不中断通信的情况下，把现存Istio服务的流量从明文升级为双向TLS。 使用场景 在部署了Istio的集群中，使用人员刚开始可能更关注功能性，服务之间的通信配置的都是明文传输，当功能逐渐完善，开始关注安全性，部署有sidecar的服务需要使用双向TLS进行安全传输，但服务不能中断，这时，一个可取的方式就是进行双向TLS的迁移。 下面通过实例演示如何进行双向TLS的迁移。 环境准备 • 已经部署好Istio的集群，没有启用双向TLS • 创建三个命名空间，分别是 foo、bar 以及 legacy • 在 foo、bar 中分别部署注入 Istio sidecar 的 httpbin 以及 sleep 应用，在legacy中部署未注入sidecar的sleep应用 检查部署情况 可以看到，从任意一个命名空间选一个sleep应用，发送http请求到httpbin.foo，都能请求成功。这个时候，使用的是明文传输。 检查系统中的认证策略和目标规则： 可以看到，系统中在foo、bar 以及 legacy命名空间下没有认证策略和目标规则。 下面开始通过配置服务端和客户端来升级传输过程： 1. 配置服务器

istio的授权功能，也称为基于角色的访问控制（RBAC），它为istio服务网格中的服务提供命名空间级别、服务级别和方法级别的访问控制。基于角色的访问控制具有简单易用、灵活和高性能等特性。本文介绍如何在服务网格中为服务进行授权控制。 ·前置条件· •安装istio的k8s集群，启用认证功能、双向TLS认证 •部署bookinfo示例应用 下面基于bookinfo应用实例具体介绍如何启用授权并配置访问控制策略： 1. 创建service accout，启用访问控制 我们在service account的基础上启用访问控制，为了给不同的微服务授予不同的访问权限，需要建立不同的service account，在本例中： 创建Service account: bookinfo-productpage，并用它部署 productpage； 创建 Service account：bookinfo-reviews，并用它部署 reviews（其中包含 reviews-v2 和 reviews-v3 两个版本）。 清理所有现存RBAC规则： 此时，用浏览器打开bookinfo的productpage页面，会看到： 2. 启用Istio授权 使用 RbacConfig 对象启用 Istio Authorization： 此时，bookinfo的productpage页面，会看到： 3.