在生产环境运行Istio(一)


Istio是什么?Istio是服务网格技术,在网络上添加一层抽象层。它截获Kubernetes集群里的所有或者部分流量,并在之上执行一系列操作。支持哪些操作呢?比如,搭建智能路由或实现断路器方案,进行“金丝雀部署”等。另外,Istio还可以限制外部交互并且控制集群和外部网络的所有路由。而且,Istio支持配置策略规则来控制不同微服务之间的交互。最终,我们可以生成完整的网络交互图,并且得到对于应用来说完全透明的指标集。

官方文档里有Istio的详细介绍。本文介绍Istio上微服务交互背后的基本原理,展示Istio的确是解决各种问题的相当强大的工具。本文尝试回答Istio初学者经常会问的各种问题,帮助大家更有效率地使用Istio。

在介绍安装之前,先介绍一些核心观点,总体看一下Istio的组件和组件间交互的原理。

工作原理

Istio由两大组件组成——控制面板和数据面板。控制面板包含基础组件,确保和其他组件之间的正确交互。在当前的1.0版本里,控制面板有三个组件:Pilot,Mixer和Citadel。这里不讨论Citadel,因为在生成证书来进行服务间的双向TLS通信时才需要它。我们先了解一下Pilot和Mixer的设计和目标。
review.png

Pilot是主要的控制组件,它负责分发集群内的所有信息——服务,它们的端点以及路由规则(比如,金丝雀发布规则或者断流器规则)。

Mixer是可选的控制面板组件,它负责收集指标、日志以及其他网络交互的信息。它还监控是否符合策略规则以及是否符合速率限制。

数据面板的组件使用sidecar代理容器来实现。默认使用强大的代理服务器Envoy。为了确保Istio对于应用来说是彻底透明的,这里使用了自动注入系统。最新的实现支持Kubernetes 1.9或更新版本(mutational admission webhook)。对于Kubernetes 1.7,1.8版本,可以是用Initializer。

Sidecar容器通过GRPC协议连接Pilot,优化集群内变更的pushdown模型。Envoy从1.6版本就开始使用GRPC;Istio则从0.8版本开始使用,它是pilot-agent——Envoy之上GO的封装,用来配置启动参数。

Pilot和Mixer是纯粹的无状态组件,所有的状态都保存在应用程序的内存里。它们的配置由Kubernetes的Custom Resource定义,存储在etcd里。Istio-agent得到Pilot的地址,并打开GRPC连接。

正如我所说,Istio在对应用完全透明的前提下实现了所有功能。让我们一起看看是怎么实现的。算法原理如下:
  1. 我们部署服务的一个新版本。
  2. 取决于sidecar容器的注入类型,在配置阶段添加istio-init容器和istio-agent容器(Envoy),或者手动插入到Kubernetes实体的Pod描述里。
  3. istio-init容器是一些脚本,为Pod设置iptables规则。有两种方式配置流量重定向到istio-agent容器里:使用直接的iptables规则或者TPROXY。撰写本文时,默认使用的是重定向规则。在istio-init里,可以配置截获哪些流量并发送给istio-agent。比如,为了截获所有入站和出站流量,用户需要将参数-i-b设置为*。用户也可以指定截获特定端口的流量。为了避免截获特定子网的流量,可以使用-x参数。
  4. 在init运行后,会启动容器,包括pilot-agent(Envoy)。它通过GRPC连接上已经部署的Pilot,得到集群内所有已有服务以及路由策略的信息。根据接收到的数据,它配置集群,将这些流量直接映射到Kubernetes集群里的应用程序端口。重要的地方是:Envoy动态配置监听器(IP,端口对)开始监听。因此,当请求进入Pod,并且使用iptables规则重定向到sidecar时,Envoy已经准备好处理这些连接,并且知道将这些代理流量转发到哪里去。这一步里,信息发送给Mixer,下文会详细介绍。


最终,我们得到Envoy代理服务器的所有网络,可以从一点(Pilot)完成配置。最终,所有inbound和outbound请求都会通过Envoy。更为重要的是,只截获TCP流量。这意味着仍旧是使用UDP上的kube-dns来解析Kubernetes服务IP,这点没有变化。然后,在resolver之后,outbound请求被envoy截获并处理,它决定请求发送到哪个端点(或者不发送,当访问策略禁止或者触发了断流算法时)。

现在我们已经熟悉了Pilot,接下来研究Mixer是怎么工作的,以及为什么我们需要Mixer。Mixer的官方文档在这里

Mixer有两个组件:istio-telemetry,isito-policy(0.8版本之前使用单个组件istio-mixer)。它们都是Mixer。Istio telemetry接收sidecar容器的GPRC,并且汇报服务交互和参数信息。Istio-policy接收到检查请求,确保满足Policy规则。这些策略检查在客户端(sidecar里)缓存一段时间。报告检查是批量发送的。这里介绍怎么配置以及需要设置哪些参数。

Mixer应该是高可用组件,提供telemetry数据的不间断收集和处理。整个系统是一个多层缓存器。最初,数据缓存在容器的sidecar里,然后在Mixer,最终发送到Mixer后台。因此,如果任意系统组件发生故障,buffer会增长,之后当系统恢复时,会flush。Mixer后台是发送telemetry数据的端点:statsd,newrelic等等。编写自定义后台很简单,之后我会给大家介绍。
mixer.png

总结一下,使用istio-telemetry的工作流如下:
  1. 服务1发送请求给服务2
  2. 在已有的服务1里,请求重定向到sidecar
  3. Sidecar Envoy监控到给服务2的请求,并准备所需信息
  4. 然后它使用Report请求发送给istio-telemetry。
  5. Istio-telemetry决定是否将Report发送给后台,这里也负责发送请求以及请求内容。


现在看看如何搭建包含两大基础组件Pilot和sidecar envoy的Istio系统。如下是Pilot读取的基础配置(Mesh):
apiVersion: v1
kind: ConfigMap
metadata:
name: istio
namespace: istio-system
labels:
   app: istio
   service: istio
data:
mesh: |-
# disable tracing mechanism for now
   enableTracing: false
# do not specify mixer endpoints, so that sidecar containers do not send the information
#mixerCheckServer: istio-policy.istio-system:15004
#mixerReportServer: istio-telemetry.istio-system:15004
# interval for envoy to check Pilot
   rdsRefreshDelay: 5s
# default config for envoy sidecar
   defaultConfig:
  # like rdsRefreshDelay
       discoveryRefreshDelay: 5s
# path to envoy executable
       configPath: "/etc/istio/proxy"
       binaryPath: "/usr/local/bin/envoy"
# default name for sidecar container
       serviceCluster: istio-proxy
# time for envoy to wait before it shuts down all existing connections
       drainDuration: 45s
       parentShutdownDuration: 1m0s
# by default, REDIRECT rule for iptables is used. TPROXY can be used as well.
  #interceptionMode: REDIRECT
# port for sidecar container admin panel
       proxyAdminPort: 15000
# address for sending traces using zipkin protocol (not used as turned off in enableTracing option)
       zipkinAddress: tracing-collector.tracing:9411
# statsd address for envoy containers metrics
  # statsdUdpAddress: aggregator:8126
# turn off Mutual TLS
      controlPlaneAuthPolicy: NONE
# istio-pilot listen port to report service discovery information to sidecars
      discoveryAddress: istio-pilot.istio-system:15007

让我们将所有主要控制组件(控制面板)放到Kubernetes的istio-system命名空间里。

最小的配置仅仅要求Pilot的部署。我们使用如下配置。并且手动配置sidecar容器的注入。

Init容器配置:
initContainers:
- name: istio-init
   args:
   - -p
   - "15001"
   - -u
   - "1337"
   - -m
   - REDIRECT
   - -i
   - '*'
   - -b
   - '*'
   - -d
   - ""
   image: istio/proxy_init:1.0.0
   imagePullPolicy: IfNotPresent
   resources:
      limits:
        memory: 128Mi
   securityContext:
      capabilities:
          add:
          - NET_ADMIN

sidecar配置:
- name: istio-proxy
     command:
     - "bash"
     - "-c"
     - |
       exec /usr/local/bin/pilot-agent proxy sidecar \
       --configPath \
       /etc/istio/proxy \
       --binaryPath \
       /usr/local/bin/envoy \
       --serviceCluster \
       service-name \
       --drainDuration \
       45s \
       --parentShutdownDuration \
       1m0s \
       --discoveryAddress \
       istio-pilot.istio-system:15007 \
       --discoveryRefreshDelay \
       1s \
       --connectTimeout \
       10s \
       --proxyAdminPort \
       "15000" \
       --controlPlaneAuthPolicy \
       NONE
     env:
     - name: POD_NAME
       valueFrom:
         fieldRef:
           fieldPath: metadata.name
     - name: POD_NAMESPACE
       valueFrom:
         fieldRef:
           fieldPath: metadata.namespace
     - name: INSTANCE_IP
       valueFrom:
         fieldRef:
           fieldPath: status.podIP
     - name: ISTIO_META_POD_NAME
       valueFrom:
         fieldRef:
           fieldPath: metadata.name
     - name: ISTIO_META_INTERCEPTION_MODE
       value: REDIRECT
     image: istio/proxyv2:1.0.0
     imagePullPolicy: IfNotPresent
     resources:
       requests:
         cpu: 100m
         memory: 128Mi
       limits:
         memory: 2048Mi
     securityContext:
       privileged: false
       readOnlyRootFilesystem: true
       runAsUser: 1337
     volumeMounts:
     - mountPath: /etc/istio/proxy
       name: istio-envoy

为了成功部署,需要为Pilot创建ServiceAccount,ClusterRole,ClusterRoleBinding,CRD;更多详细信息在这里。之后,带有注入的sidecar和Envoy的服务就启动了,会从Pilot获取所有数据并且处理请求。

最重要的一点是所有控制面板组件都是无状态的应用程序,都可以轻松地水平扩展。所有数据都以Kubernetes资源的自定义描述存储在etcd里。

此外,也可以在集群外运行Istio(实验用途),并且在几个Kubernetes集群之间监控并共享服务发现。更多的相关信息在这里。在多集群安装里,要考虑到如下限制:
  1. CIDR Pod和Service CIDR必须在所有集群里都是唯一的,不能重叠。
  2. 集群间的任意Pod CIDR必须能够访问所有CIDR Pod。
  3. 所有Kubernetes API server都必须能够相互访问。


本文让你开始了解Istio。但是,后续文章会接着讨论现有的问题。我们会讨论外部流量路由的特性,探讨最常见的sidecar debug和Profile的方法。最终,我们会创建跟踪系统并且仔细介绍它和Envoy是如何交互的。

原文链接:Running Istio on kubernetes in production. Part I.(翻译:崔婧雯 )
===========================
译者介绍
崔婧雯,现就职于IBM,高级软件工程师,负责IBM WebSphere业务流程管理软件的系统测试工作。曾就职于VMware从事桌面虚拟化产品的质量保证工作。对虚拟化,中间件技术,业务流程管理有浓厚的兴趣。

0 个评论

要回复文章请先登录注册