[译] 在Kubernetes生产环境中运行Istio

本文翻译自 https://www.tigera.io/blog/running-istio-on-kubernetes-in-production-part-i/，作者 Alexander Lukyanchenko，发表于2019年5月。

什么是Istio？ Istio是一种服务网格（service mesh）技术，它为网络添加了一个抽象层。它拦截K8S集群中的全部或部分流量，并对其进行处理。它支持哪些操作呢？ 例如，设置智能路由（smart routing）或实现断路器（circuit breaker）或金丝雀部署（Canary deployment）。此外，Istio还可以限制外部交互，并控制群集和外部网络之间的所有路由。此外，它支持设置策略规则以控制不同微服务之间的交互。最后，我们可生成一个完整的网络交互图，采用统一度量，并对应用程序完全透明。

Istion的详细介绍可以访问其官方文档https://istio.io/docs/concepts/。本文中，我会介绍基于Istio的微服务之间交互的基本原理，你将会看到Istio是一个非常强大的能解决很多问题的工具。我还会尝试着回答一些初学者经常问到的问题。我相信这些能帮助你高效地使用Istio。

在安装Istio之前，我想介绍一些基本概念、主要组件和组件之间交互的基本原理。

1. 运行原理

Istio包括两个主要组件：控制平面和数据平面。控制平面包括若干基础组件，用于控制其它组件之间能正确地交互。在当前1.0版本中，控制平面有三个主要组件：Pilot、Mixer和Citadel。文中不会介绍Citadel，它主要用于产生服务间通信所使用的TLS证书。我们现在来看下Polit和Mixer组件的用途和设计。

Pilot是主要的控制组件，它分发集群中的有关信息，包括服务、端点和路由规则等。Mixer是一个可选控制平面组件，用于收集性能数据、日志和其它有关网络交互的信息。它还负责监视策略规则（policy rule）的合法性。

数据平面使用边车代理容器（sidecar proxy container）实现，默认使用Envoy。为了确保Istio对应用完全透明，还实现了自动插入机制。最新的实现支持K8S 1.9和更新版本。对于老K8S版本，可以使用初始化器（Initializer）。

边车容器通过GRPC协议连接到Pilot，该协议优化了对集群变化的推送实现机制。从Envoy 1.6版本就开始使用GPRC了。Istio从0.8版本起就实现了一个 pilot-agent，它是一个用Go语言实现的Envoy的封装，用于配置启动参数。

Pilot和Mixer是完全无状态组件，所有状态都保存在内存中。它们的配置保存在K8S CRD 中。Istio-agent获取Pilot地址，然后打开GPRC流。

如上述介绍的，Istio实现了一种对应用完全透明的机制。过程如下：

  1. 部署一个服务的新版本。
  2. 根据不同的边车容器插入方式，在配置阶段，一个istio-init容器和istio-agent容器（envoy）被自动或手动插入服务pod。
  3. Istio-init容器是一个脚本，用于设置pod的iptables规则。有两种方式可配置将网络流量导入istio-agent容器：使用redirect iptables规则或TPROXY。本文写作时默认采用redirect iptables规则。在istio-init中，可配置哪些网络流量会被截取并发送到istio-agent。比如，为了截取所有进出的流量，你需要添加参数 –i和-b 到*。你可以配置只截取特定端口的流量。要避免截取特定子网的流量，可以使用-x标志。
  4. Istio-init容器执行完毕后，包括pilot-agent和业务容器在内的所有容器都会被启动。Pilot-agent通过GRPC连接到Pilot，获取集群的有关信息。根据所收到的数据，它进行相关配置，其中，envoy会动态配置监听器，并开始监听。因此，当请求进入pod后，它会被redirect iptables规则导给边车容器，envoy处理这些流量并进行转发。本步中，会有数据被发给Mixer，下文会进行介绍。

到此为止，我们了解了envoy代理所组成的完整网络，它能被从一个中心点（Pilot）上进行配置。现在，所有进出的请求都会经过Envoy。而且，只有TCP流量会被截取。这意味着K8S服务的DNS请求不会受到影响。当出去的流量被截取后，Envoy会处理它，并决定发往哪里。

2. Mixer组件

下面我们会介绍Mixer的原理及用途。官方文档在https://istio.io/docs/concepts/policies-and-telemetry/overview/。Mixer有两个组件：istio-telemetry和istio-policy（0.8版本之前，只有一个组件istio-mixer）。istio-telemetry通过GRPC从边车容器收取有关服务交互的计量信息，istio-policy收取并处理策略校验请求，并超检查策略规则的合法性。这些策略会在边车容器中被缓存一段时间。Mixer是一个高可用组件，采用多级缓存。一开始数据被缓存在边车容器中，然后在mixer侧，最后被发到所谓的mixer后端。结果，如果有某个组件故障，缓存会一直增长；如果组件重启，则缓存会被刷新。Mixer后端是一些发送计量数据的端点，比如statsd和newrelic之类。写这种后端也很容器，后文会做介绍。

总结一下，istio-telemetry的工作流如下：

  1. 服务1给服务2发一个请求。
  2. 在服务1中，请求会被边车容器截取。它监控发给服务2的请求，会准备一些信息，封装成报告请求（Report reques）发给istio-telemetry。
  3. istio-telemetry决定是否向其后端发送这些请求。

3. 使用Pilot和Envoy搭建Istio系统

我们来看看如何使用Pilot和Envoy组件搭建Istio系统。首先来看下Pilot所用到的配置：

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

我们把Istio所有组件都放到istio-sytem命名空间中。最小配置只需要Pilot。我们使用如下的配置。我们会手动进行边车容器插入。

初始容器配置：

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

　　

边车容器配置：

- 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

一个完整的安装还需要创建服务账户、集群角色、集群角色绑定和CRD。更多信息请阅读https://github.com/istio/istio/tree/release-1.0/install/kubernetes/helm/istio/charts/pilot/templates。安装好以后，边车容器会被注入服务pod，Envoy会被启动起来，从Pilot接受数据并开始处理请求。

这里关键的一点是，所有控制平面组件都是无状态的，因此很容器水平扩展。所有数据都以CRD被保存在etcd中。

而且，还可以将Istio安装在集群之外，并用于多个K8S集群。更多信息可阅读https://istio.io/docs/setup/kubernetes/multicluster-install/。在多集群部署中，需要考虑以下限制：

  • CIDR Pod和服务CIDR必须是集群间唯一，而且不能重叠。
  • 所有CIDR Pod都能在集群内被访问。
  • 所有K8S API 服务器都能被互访。

感谢您的阅读，欢迎关注我的微信公众号：

原文地址：https://www.cnblogs.com/sammyliu/p/12308226.html

时间： 2024-11-09 23:18:35

[译] 在Kubernetes生产环境中运行Istio的相关文章

OpenCV程序在生产环境中运行

1.安装OpenCV(3.0),需要注意的是OpenCV的提取路径要和VS中项目的OpenCV路径保持一致: 2.设置环境变量,在path变量后追加:C:\OpenCV的提取路径\build\x64[对应自己的系统版本]\vc12\bin: 3.也是很重要的一步:如果系统中没有:MSVCR120D.dll和MSVCP120D.dll这两个dll,一定要将这两个dll拷贝到:C:\windows\system32文件夹下: (ps:在安装过vs的系统中的system32文件夹下可以找到这俩文件)

Kubernetes 在生产环境中常用架构

Kubernetes 在生产环境中常用架构 首先,我们来梳理下Kubernetes生产架构,其设计适用于绝大多数环境.如下图所示 在该架构中,我们可以将其分为四层,如下: Client层:即Kubernetes集群外部用户.客户端等: 服务访问层:即由Traefik ingress实现服务发现.负载均衡和路由规则定义等: 业务应用层:即基于Kubernetes平台构建和运行企业业务应用,如CI/CD持续集成.微服务项目.监控告警和日志管理.私有镜像仓库等服务: 基础设施层:即由Kubernete

.NET跨平台之旅：在生产环境中上线第一个运行于Linux上的ASP.NET Core站点

2016年7月10日,我们在生产环境中上线了第一个运行于Linux上的ASP.NET Core站点,这是一个简单的提供后端服务的ASP.NET Core Web API站点. 项目是在Windows上用V2015开发的,以self-contained应用部署方式发布到Linux服务器.Linux服务器用的是Ubuntu 14.04,站点通过supervisor以服务方式运行,部署在2台阿里云服务器上,用了1台阿里云内网负载均衡. 虽然是很简单的站点,虽然是很小的一步,但是进入生产环境就意味着对性

Dubbo Mesh 在闲鱼生产环境中的落地实践

本文作者至简曾在 2018 QCon 上海站以<Service Mesh 的本质.价值和应用探索>为题做了一次分享,其中谈到了 Dubbo Mesh 的整体发展思路是"借力开源.反哺开源",也讲到了 Service Mesh 在阿里巴巴的发路径将经历以下三大阶段: 撬动做透价值***实现技术换代Dubbo Mesh 在闲鱼生产环境的落地,分享的是以多语言为撬动点的阶段性总结. 文章首发于「QCon」,阿里巴巴中间件授权转载. 闲鱼场景的特点闲鱼采用的编程语言是 Dart,思

生产环境中CentOS7部署NET Core应用程序

NET Core应用程序部署至生产环境中(CentOS7) 阅读目录 环境说明 准备你的ASP.NET Core应用程序 安装CentOS7 安装.NET Core SDK for CentOS7. 部署ASP.NET Core应用程序 配置Nginx 配置守护服务(Supervisor) 这段时间在使用Rabbit RPC重构公司的一套系统(微信相关),而最近相关检验(逻辑测试.压力测试)已经完成,接近部署至线上生产环境从而捣鼓了ASP.NET Core应用程序在CentOS上的部署方案,今天

理解Docker（6）：若干企业生产环境中的容器网络方案

本系列文章将介绍 Docker的相关知识: (1)Docker 安装及基本用法 (2)Docker 镜像 (3)Docker 容器的隔离性 - 使用 Linux namespace 隔离容器的运行环境 (4)Docker 容器的隔离性 - 使用 cgroups 限制容器使用的资源 (5)Docker 网络 (6)若干企业生产环境中的容器网络方案 Docker 在早期只有单机上的网络解决方案,在 1.19 版本引入了原生的 overlay 网络解决方案,但是它的性能损耗较大,可能无法适应一些生产环

生产环境中tomcat的配置

生产环境中要以daemon方式运行tomcat 通常在开发环境中,我们使用$CATALINA_HOME/bin/startup.sh来启动tomcat, 使用$CATALINA_HOME/bin/shutdown.sh来关闭tomcat. 而在生产环境中,我们要配置tomcat使其以daemon方式运行,这是因为: 以daemon运行不受终端影响,不会因为退出终端而停止运行 可以让tomcat以普通用户身份运行,可以让tomcat随linux启动而启动 如何将tomcat配置成守护进程 将tom

.NET跨平台之旅：生产环境中第2个跑在Linux上的ASP.NET Core站点

今天我们在生产环境中上线了第2个跑在Linux上的ASP.NET Core站点.这是一个简单的Web API站点,通过命令行的方式调用安装在Linux服务器上的程序完成操作.之前用的是nodejs,现在换成了ASP.NET Core,主要代码如下: var psi = new ProcessStartInfo(command, arguments) { RedirectStandardOutput = true, RedirectStandardInput = true, CreateNoWin

JDK 9 发布仅数月，为何在生产环境中却频遭嫌弃？

千呼万唤始出来,在经历了整整一年的跳票之后,Java 9 终于在 9 月 21 日拨开云雾,露出真正的面目.对众多 Java 程序员来说,这一天无疑是一个重大的日子,首先 Java 开发者们再也不用羡慕别的自带 REPL 的语言了,不用为了试个 Java 功能而开个 Groovy shell:其次最主要的莫过于 Jigsaw 项目下颠覆性的 Java 模块化了,有了它,自己定制/裁剪 JDK 变得更直接. 其中,整个 Java 的核心内容非 JDK 莫属,其包括了 Java 运行环境(Java