istio

摸索:Istio 路由规则 Alpha v3

Istio 近期的版本中出现了一个新的 API 组:networking.istio.io/v1alpha3,应该会替代现有的config.istio.io/v1alpha2 API。新的 API 不管是结构上还是功能上、以及命名上,都有很大差异。这里使用一些简单例子,体验一下 Alpha 3 带来的变化。

注意:正常情况下 istioctl 和 kubectl 都可以用来操作这些对象,但是 kubectl 缺乏验证功能,因此调试阶段使用 istioctl 会更方便一些。

Redhat 提供 Istio 在线交互式教学

Redhat 新近为用户提供了 Istio 的交互式学习工具,基于 Openshift 和最新的 Istio 0.6,试用了一下,主要有三个方面让我非常满意:

  1. 无需注册即可使用。
  2. 不受国内网络限制。
  3. 精心调校的示例应用和相关规则。

以上优点让这一工具的运行非常流畅,能够完整、直观并快速的为用户提供一个对于 Istio 的第一印象。下面用著名的老大难问题——断路器的课程,来看看这一教学工具的好处。

首先进入系列教程的首页。页面上排布了一系列的 Service Mesh 相关教程,分别是一个直通教程,外加八个 Workshop 环节,这里我们用第七个,也就是断路器的 Workshop 来看看这一教程的使用过程。

启动服务

进入首页之后,点击醒目的红色按钮,进入场景。会看到三栏式的页面:

istio 0.5.0 新特性:流量镜像

在类似 Dark launch 的测试、发布过程中,流量复制是个非常有用的功能,istio 0.5.0 的更新,带来了一个新的路由相关特性:流量镜像。

这一场景中,我们会将正常的流量进行复制,将复制出来的流量分发给待上线的应用(V2),使用实际流量对新版本应用进行测试;而现有客户端则仅会感知到单一版本(V1)的存在。

下面做个小实验来进行验证。

条件

基于 Kubernetes 运行的 Istio 0.5.0 版本部署。

部署

源码见后。

nginx:stabel-alpine镜像,生成v1v2两个版本的 Deployment,以及一个target服务:

在 Azure 上运行 Istio 的注意事项

Tags: 
  • ACS Engine: v0.12.4
  • Istio: v0.5.0
  • Kubernetes: v1.8.7

在 Istio 注入之后,生成的 Init 容器中会有 RunAs 的 SecurityContext,而 ACS Engine 的缺省 admission 包含了SecurityContextDeny,会拒绝这一选项,造成 Istio Workload 无法运行,

解决方法很简单,只要在定义文件中修改 api server 配置:

Istio 尾行记

Istio 一直没有什么像样的更新,Conduit 也迟迟不出来怼,眼看 2017 就要过去,安装试用也不新鲜了,补一篇 Istio 的笔记,算做个收尾了。

Istio 最大的亮点之一,就是使用 Pilot 将集群控制语言翻译成为 Envoy 配置,利用 Sidecar 的方式对服务通信进行控制,下面就是对这一过程的跟踪尝试。

kubectl apply -f install/kubernetes/istio.yaml

cat istio.yaml| grep ^kind

会看到,这里生成了相当多的内容,除去 Deployment、Service 和 ConfigMap 老几样之外,还有当前集群必须的 RBAC 几要素:Service Account、ClusterRole 以及 ClusterRoleBinding。然后就是 Kubernetes 世界里强力扩展的标志:各种 CRD(CustomResourceDefinition) 了。

Istio 尾行记

Istio 一直没有什么像样的更新,Conduit 也迟迟不出来怼,眼看 2017 就要过去,安装试用也不新鲜了,补一篇 Istio 的笔记,算做个收尾了。

Istio 最大的亮点之一,就是使用 Pilot 将集群控制语言翻译成为 Envoy 配置,利用 Sidecar 的方式对服务通信进行控制,下面就是对这一过程的跟踪尝试。

kubectl apply -f install/kubernetes/istio.yaml

cat istio.yaml| grep ^kind

会看到,这里生成了相当多的内容,除去 Deployment、Service 和 ConfigMap 老几样之外,还有当前集群必须的 RBAC 几要素:Service Account、ClusterRole 以及 ClusterRoleBinding。然后就是 Kubernetes 世界里强力扩展的标志:各种 CRD(CustomResourceDefinition) 了。

Mixer 的 SPOF 迷思

SPOF: Single Point of Failure

Istio 的意思:

  1. Mixer 很稳定

  2. 你们说的延迟不是我说的延迟

Mixer 出现在请求路径上,很自然的会引发一个疑问:他对系统可用性和延迟会产生什么样的影响?我们经常被提问的一句话就是:“这不是一个单点失败的案例么?”

本文中我们会深入挖掘和阐述 Mixer 的设计原则,这些设计原则让 Mixer 能够提高系统可用性,并降低平均请求延时。

Istio 的 Mixer 对系统可用性和延迟有两个主要的好处:

  • 提高 SLO:Mixer 把 Proxy 和服务从基础设施后端的故障中隔离出来,提供了高级、高效的 Mesh 可用性保障。Mesh 作为一个整体来说,在同基础设施后端的交互中,有了 Mixer 的帮助,会有更低的故障率。

试译:Mixer 的适配器模型

Istio 0.2 引入了新的 Mixer 适配器模型,从而具有了更大的灵活性去接入各种基础设施后端。本文尝试讲述这一模型及其工作机制。

为什么是适配器模型?

各种基础设施都提供了用于支持服务构建的功能,例如访问控制、遥测、配额、计费等等。传统服务会直接和这些后端系统打交道,和后端紧密耦合,并集成其中的个性化语义以及用法。

Mixer 服务构成了基础设施和 Istio 之间的抽象层。Istio 组件和运行于 Service Mesh 中的服务,借助 Mixer 的能力就能在不直接访问后端接口的情况下和这些后端进行交互。

Mixer 除了作为应用和基础设施之间的隔离层之外,操作者还可以借助 Mixer 的中介模型,注入或者操作应用和后端之间的策略,例如哪些数据需要报告给哪些后端、哪些后端提供认证等。

每种后端都有各自不同的接口和操作方式,因此 Mixer 需要有代码来支持这种差异,我们称这些内容为适配器

非缺省域名下 Istio 的使用

Kubernetes 缺省的域名为 cluster.local,好死不死的,istio 的缺省安装也沿用了这一设定, 并且文档中并没有明确指出这一假设。Istio 中使用了大量的 FQDN 进行服务的甄别,域名不一致这样 的问题可以说是后患无穷。经过 101 号 issue 的讨论,得知 proxy 和 pilot 组件提供了域名的设置功能, 大致用法如下:

Pilot

kubectl edit deploy istio-pilot -n istio-system 或者编辑官方的 istio.yaml,查找 docker.io/istio/pilot:0.2.9 的容器,并在 args 一节中加入如下的两行:

Istio 的频率限制

本来这个应该是作为第三天“零散功能点”介绍的,结果目标规则部分遇到一个 bug 一直没得到修正,就拖 着了——然后后来发现自己这个想法挺无知的——零散的功能点非常多,非常大,而且文档非常弱,很难搞,只好 逐个介绍了。

简介

调用频率限制这个功能其实也是比较常见的东西了。这里就不多做介绍了。下面简单粗暴的介绍一下测试要完 成的目标。

测试中我们将使用两个服务,服务叫 workload,客户端叫 sleep,workload 服务正常返回群众喜闻乐见 的 “Hello World”,而 sleep 仅用来做 Shell 方便测试。

测试过程将为 workload 建立规则:

  • 对于任意访问,十秒钟之内仅能访问两次;
  • 对于来自 sleep 的访问,十秒钟之内仅能访问一次

下面所有内容都在 default 命名空间进行

建立测试环境

编辑 workload.yaml 以及 sleep.yaml 之后, 我们使用如下命令运行(这两部分源码,只有些乌七八糟的标签和命名有点问题,其他很普通。 见最后页)

页面