Istio可观测性

分类：istio作者：编程之家用户

Istio可观测性

Istio的可观测性包括metrics，日志，分布式链路跟踪以及可视化展示。下面主要介绍如何在istio中部署基于Prometheus的metrics监控，基于jaeger的链路跟踪和基于kiali的可视化界面。

目录

Prometheus

配置说明

在istio网格中，每个组件都会暴露一个提供metrics的endpoint。Prometheus可以从这些endpoints上抓取metrics(通过Prometheus配置文件来设置scraping，端口以及TLS等)。

为了采集整个网格的metrics，需要配置Prometheus scraping组件：

  1. 控制面(istiod deployment)
  2. ingress和egress网关
  3. Envoy sidecar
  4. 用户应用(如果该应用也可以暴露Prometheus metrics的话)

为了简化metrics的配置，istio提供了如下两种操作模式：

Option 1:合并metrics

为了简化配置，istio可以通过prometheus.io annotations来控制所有scraping。这使Istio的scraping可以使用标准配置(例如Helm stable/prometheus charts提供的配置)来做到开箱即用。

该选项默认是启用的，但可以在安装期间通过传入--set meshConfig.enablePrometheusMerge=false来禁用该功能。当启用时，会在所有的控制面pod上添加prometheus.io annotations来配置scraping。如果已经存在这些annotations，则会被覆盖。通过该选项，Envoy sidecar会将istio的metrics和应用的metrics进行合并，合并后的metrics暴露地址为：/stats/prometheus:15020.

通过kubect describe pod命令可以查看pod的annotation，需要注意的是控制面和数据暴露的端口是不同的。数据面暴露的端口为15020，如下：

      prometheus.io/path: /stats/prometheus
      prometheus.io/port: 15020
      prometheus.io/scrape: true

但istiod的端口为15014，ingress-gateway和egress-gateway的端口为15090。总体来说与官方端口描述一致。

该选项会以明文方式暴露所有的metrics。

下面特性可能并不适用于所有场景：

  • 在抓取metrcis时启用TLS
  • 应用暴露的metrics与istio的metrics的名称相同。例如，应用暴露了一个名为istio_requests_total的metric，可能是因为应用本身也运行了Envoy
  • 部署的Prometheus没有基于标准的prometheus.io annotation抓取metrics。

如果有必要，则可以在pod上添加prometheus.istio.io/merge-metrics: "false" annotation来禁用metrics合并功能。

Option 2:自定义抓取metrics配置

内置的demo profile会安装Prometheus，并包含了所有必要的scraping配置。可以在使用istioctl部署istio时传入参数--set values.prometheus.enabled=true来部署Prometheus。

但内置的Prometheus缺少高级自定义配置功能，如认证的持久化等，导致其不大合适在生产环境中使用。为了使用已经存在的Prometheus，需要在Prometheus配置中添加scraping配置prometheus/configmap.yaml。

该配置会添加抓取控制面以及所有Envoy sidecar的metrcis的功能。此外，还配置了一个job，用来抓取添加了prometheus.io annotation的所有数据面pod的应用metrics。

TLS设置

控制面，网关和Envoy sidecar的metrics都以明文方式暴露。然而，应用metrics会遵循istio对负载的配置。例如如果启用了Strict mTLS，那么Prometheus需要使用istio证书来配置scrape

对于自建的Prometheus，参考为没有sidecar的应用程序提供证书和密钥一文来为Prometheus提供证书，并添加TLS scraping配置。

总结

istio的metrics分为两类：istio自身的metrics和应用产生的metrics，前者以明文方式暴露，后者遵循对应负载的配置，即，如果负载启用了TLS，则Prometheus也需要配置TLS才能获取应用的metrics。

istio的metrics主要通过kubernetes_sd_config服务发现进行采集。其中prometheus.io/path和prometheus.io/port annotation分别对应metrics meta_kubernetes_pod_annotation_prometheus_io_scrape和meta_kubernetes_pod_annotation_prometheus_io_path 。简单配置如下：

- job_name: 'kubernetes-pods'

        kubernetes_sd_configs:
        - role: pod

        relabel_configs:
        - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
          action: keep
          regex: true
        - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
          action: replace
          target_label: __metrics_path__
          regex: (.+)
        - source_labels: [__address__,__meta_kubernetes_pod_annotation_prometheus_io_port]
          action: replace
          regex: ([^:]+)(?::\d+)?;(\d+)
          replacement: $1:$2
          target_label: __address__
        - action: labelmap
          regex: __meta_kubernetes_pod_label_(.+)
        - source_labels: [__meta_kubernetes_namespace]
          action: replace
          target_label: kubernetes_namespace
        - source_labels: [__meta_kubernetes_pod_name]
          action: replace
          target_label: kubernetes_pod_name

更多配置可以参见官方提供的配置。

Jaeger

概述

分布式跟踪使用户可以通过分布在多个服务中的网格跟踪请求。通过这种方式可以了解请求延迟，并通过可视化实现序列化和并行。

Istio利用Envoy的分布式跟踪特性提供开箱即用的跟踪集成。特别地，istio提供了选项来安装不同的跟踪后端，以及配置代理来发送这些后端自动发送跟踪span。查看Zipkin,Jaeger和Lightstep来了解istio如何与这些跟踪系统共同工作。

跟踪上下文的传递

虽然istio代理可以自动发送span，但它们需要一些提示来将整个跟踪联系在一起。应用需要传递合适的HTTP首部，这样当代理发送span信息时，这些span可以正确地关联到单个跟踪中。

为了实现上述目的，应用需要在传入请求中收集并传递如下首部到任何传出请求中：

  • x-request-id
  • x-b3-traceid
  • x-b3-spanid
  • x-b3-parentspanid
  • x-b3-sampled
  • x-b3-flags
  • x-ot-span-context

此外，基于OpenCensus (如Stackdriver)的跟踪集成需要传递下面首部：

  • x-cloud-trace-context
  • traceparent
  • grpc-trace-bin

如果查看istio的productpage例子的Python源码，可以看到应用会使用OpenTracing库从HTTP请求中抽取需要的首部：

def getForwardHeaders(request):
    headers = {}

    # x-b3-*** headers can be populated using the opentracing span
    span = get_current_span()
    carrier = {}
    tracer.inject(
        span_context=span.context,format=Format.HTTP_HEADERS,carrier=carrier)

    headers.update(carrier)

    # ...

    incoming_headers = ['x-request-id','x-datadog-trace-id','x-datadog-parent-id','x-datadog-sampled']

    # ...

    for ihdr in incoming_headers:
        val = request.headers.get(ihdr)
        if val is not None:
            headers[ihdr] = val

    return headers

reviews应用会使用requestHeaders做类似的事情：

@GET
@Path("/reviews/{productId}")
public Response bookReviewsById(@PathParam("productId") int productId,@Context HttpHeaders requestHeaders) {

  // ...

  if (ratings_enabled) {
    JsonObject ratingsResponse = getRatings(Integer.toString(productId),requestHeaders);

当在应用程序中执行下游调用时，需要包含这些首部。

使用Jaeger

本例将使用Bookinfo。

部署

  1. 使用如下方式快速部署一个用于演示的Jaeger。当然也可以参考Jaeger官方文件进行自定义部署。

    $ kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.7/samples/addons/jaeger.yaml

  2. 可以参考此处修改采样率

访问Jaeger

上面部署的Jaeger对应的k8s service名为tracing，查看该service，可以看到容器和service暴露的端口均为16686。

# oc describe svc tracing
Name:              tracing
Namespace:         istio-system
Labels:            app=jaeger
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app":"jaeger"},"name":"tracing","namespace":"istio-system"},"s...
Selector:          app=jaeger
Type:              ClusterIP
IP:                10.84.179.208
Port:              http-query  80/TCP
TargetPort:        16686/TCP
Endpoints:         10.80.2.226:16686
Session Affinity:  None
Events:            <none>

在openshift上创建一个route(ingress)，即可访问该Jaeger。

使用Boofinfo生成traces

  1. 在浏览器上多次访问http://$GATEWAY_URL/productpage来生成跟踪信息

    为了查看跟踪数据，需要服务发送请求。请求的数量取决于istio的采样率，采样率是在安装istio的时候设置的，默认为1%，即在看到第一个trace之前需要至少发送100个请求。使用如下命令向productpage发送100个请求：

    $ for i in $(seq 1 100); do curl -s -o /dev/null "http://$GATEWAY_URL/productpage"; done

  2. 在dashboard的左边，在Service下拉列表中选择productpage.default，并点击Find Traces，可以看到生成了两条span

  3. 点击最近时间内到/productpage的请求的细节

    此外还可以点击右上角的Alternate Views切换视图，可以更直观地看到请求的访问情况：

  4. trace由一组span构成，每个span对应一个Bookinfo服务，在执行到/productpage的请求或内部Istio组件(如istio-ingressgateway)时生成。

Kiali

本节展示如何可视化istio网格的方方面面。

本节将安装Kiali插件并使用基于Web的图形用户界面查看网格和Istio配置对象的服务图，最后，使用Kiali Developer API以consumable JSON的形式生成图形数据。

本任务并没有涵盖Kiali的所有特性，更多参见Kiali website。

本节将使用Boofinfo应用。

部署

Kiali依赖Prometheus，因此首先要部署Prometheus。使用如下命令快速部署一个用于演示的Prometheus：

$ kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.7/samples/addons/prometheus.yaml

使用如下方式快速部署一个用于演示的Kiali。如果要用于生产环境，建议参考quick start guide 和customizable installation methods。

$ kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.7/samples/addons/kiali.yaml

注：由于Kiali依赖Prometheus，因此需要将Kiali和Prometheus关联起来。修改上面kiali.yaml中的如下字段，然后部署即可：

    custom_metrics_url: http://prometheus.istio-system.svc.cluster.local:9090
    url: http://prometheus.istio-system.svc.cluster.local:9090

同样地，为名为kiali的k8s service创建一个route即可访问，端口为20001。

生成服务图

  1. 使用如下命令检查kiali的service

    $ kubectl -n istio-system get svc kiali

  2. 可以使用如下三种方式向网格发送流量

    • 通过浏览器访问http://$GATEWAY_URL/productpage

    • 使用如下curl命令

      $ curl http://$GATEWAY_URL/productpage

    • 使用watch持续访问

      $ watch -n 1 curl -o /dev/null -s -w %{http_code} $GATEWAY_URL/productpage

  3. 在Overview页面浏览网格概况，该页面展示了网格中所有命名空间下的服务。可以看到default命名空间下有流量(Bookinfo应用安装到的default命名空间下)

  4. 为了查看一个命名空间的图表，在Boofinfo所在的命名空间中查看bookinfo的图表如下，三角形表示service，方形表示app

  5. 可以在Display中选择不同的Edge来展示metrics的概况，如上图显示了Response Time。unknow是因为没有走istio的gateway，而使用了openshift的route

  6. 为了显示服务网格中的不同类型的图表，在Graph Type下拉框中可以选择如下图标类型：App,Versioned App,Workload,Service

    • App图表类型会将所有版本的app聚合为一个图表节点。下图可以看到，它使用一个reviews 节点来表示三个版本的reviews app

    • Versioned App图表类型使用一个node展示了不同版本的app，同时对特定app的不同版本进行分组。下图展示了reviews 组，其包含3个小的节点，三个节点表示三个版本的reviews app

    • Workload 图表类型使用节点展示了服务网格中的每个负载。该图形类型不要求使用app 和version标签，因此如果选择不在组件上使用这些标签时，就可以使用该图表类型。

    • Service 图表类型使用节点展示网格中的每个服务，但排除所有应用程序和工作负载

      image-20200902155441754

检查Istio配置

为了查看Istio配置的详细配置，可以在左边菜单栏中点击 Applications,Workloads和Services。下图展示了Bookinfo应用的信息

创建加权路由

可以使用Kiali加权路由向导来定义指定百分比的请求流量来路由到两个或更多负载。

  1. 将bookinfo图表切换为Versioned app graph

    • 确保在Display下拉框中选择了Requests percentage来查看路由到每个负载的流量百分比

    • 确保在Display下拉框中选择了Service Nodes来显示service节点

  2. 通过点击reviews服务(三角形)关注bookinfo图表中的reviews服务

  3. 在右上角的下拉框中选择Show Details进入ratings的service设置

  4. 在Action下拉框中，选择Create Weighted Routing来访问加权路由向导

  5. 通过拖动滑块来调整到负载的流量百分比。将reviews-v1设置为30%，reviews-v2设置为0%，将reviews-v3设置为70%。

  6. 点击Create创建该路由。对应会在istio中创建用于流量划分的一个VirtualService和一个DestinationRule：

    apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  labels:
    kiali_wizard: weighted_routing
  name: reviews
  namespace: default
spec:
  hosts:
  - reviews.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: reviews.default.svc.cluster.local
        subset: v1
      weight: 30
    - destination:
        host: reviews.default.svc.cluster.local
        subset: v2
      weight: 0
    - destination:
        host: reviews.default.svc.cluster.local
        subset: v3
      weight: 70

    kind: DestinationRule
metadata:
  labels:
    kiali_wizard: weighted_routing
  name: reviews
  namespace: default
spec:
  host: reviews.default.svc.cluster.local
  subsets:
  - labels:
      version: v1
    name: v1
  - labels:
      version: v2
    name: v2
  - labels:
      version: v3
    name: v3

  7. 点击左边导航栏的Graph按钮返回到bookinfo图表

  8. 向bookinfo应用发送请求。例如使用如下命令每秒发送一个请求：

    $ watch -n 1 curl -o /dev/null -s -w %{http_code} $GATEWAY_URL/productpage

  9. 一段时间后，可以看到流量百分比会体现为新的流量路由，即v1版本接收到30%的流量，v2版本没有流量，v3版本接收到70%的流量

验证Istio配置

Kiali可以验证Istio的资源来确保它们遵循正确的约定和语义。根据配置错误的严重性，可以将Istio资源配置中检测到的任何问题标记为错误或警告。

下面将尝试对服务端口名称进行无效性修改来查看Kiali如何报告错误：

  1. 将details服务的端口名称从http修改为foo

    # kubectl patch service details -n default --type json -p '[{"op":"replace","path":"/spec/ports/0/name","value":"foo"}]'

  2. 点击左侧导航栏的Services 转到服务列表

  3. 选择bookinfo所在的命名空间

  4. 注意在details一行中显示的错误图标

  5. 点击Name一栏对应的details来查看详细信息

  6. 将端口名称切换回http，可以看到bookinfo又变的正常了

    # kubectl patch service details -n default --type json -p '[{"op":"replace","value":"http"}]'

查看和修改Istio的配置YAML

Kiali提供了一个YAML编辑器，可以用于查看和修改Istio的配置资源。YAML编辑器也提供了校验配置的功能。

  1. 创建一条Bookinfo的destination rules

    $ kubectl apply -f samples/bookinfo/networking/destination-rule-all.yaml

  2. 点击导航栏左边的Istio Config转到istio的配置列表

  3. 选择bookinfo所在的命名空间

  4. 注意在右上角有提示配置的错误和告警信息

  5. 将鼠标悬停在details行Configuration 列中的错误图标上，可以查看其他消息。

  6. 单击Name列中的details链接，导航到details的destination rule视图。

  7. 可以看到有校验未通过的错误提示

  8. 点击YAML查看Istio的destination rule规则，Kiali用颜色高亮除了未通过有效性校验的行

  9. 将鼠标悬停在红色图标上可以查看工具提示消息，该消息提示触发错误的验证检查。

  10. 删除创建的bookinfo的destination rule，进行环境恢复

    $ kubectl delete -f samples/bookinfo/networking/destination-rule-all.yaml

在官方文档中，上述YAML中是存在黄色的告警图标，但实际部署时并没有出现。

关于Kiali Developer API

为了生成表示图表和其他指标，健康，以及配置信息的JSON文件，可以参考Kiali Developer API。例如，可以通过访问$KIALI_URL/api/namespaces/graph?namespaces=default&graphType=app来获取使用app 图表类型的JSON表示格式。

Kiali Developer API建立在Prometheus查询之上，并取决于标准的Istio metric配置，它还会执行kubernetes API调用来获取服务的其他详细信息。为了更好地使用Kiali，请在自己的应用组件中使用metadata labels app和version。

请注意，Kiali Developer API可能在不同版本间发送变更，且不保证向后兼容。

其他特性

Kiali还有其他丰富的特性，如与Jaeger跟踪的集成。

更多细节和特性，参见Kiali官方文档。

卸载

$ kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.7/samples/addons/kiali.yaml

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。

相关推荐

idou老师教你学istio 21：基于角色的访问控制
istio的授权功能，也称为基于角色的访问控制（RBAC），它为istio服务网格中的服务提供命名空间级别、服务级别和方法级别的访问控制。基于角色的访问控制具有简单易用、灵活和高性能等特性。本文介绍如何在服务网格中为服务进行授权控制。·前置条件·•安装istio的k8s集群，启用认证功能、
Kubernetes删除资源后持续terminating状态
Errorfromserver(Forbidden):errorwhencreating"oot/istio.yaml":configmaps"istio-galley-configuration"isforbidden:unabletocreatenewcontentinnamespaceistio-systembecauseitisbeingterminatedErrorfromserver(Forbid
第三章 Istio基本介绍
3.1Istio的核心组件及其功能Istio总体分两部分：控制面和数据面。数据面（sidecar）：sidecar通过注入的方式和业务容器共存于一个pod,会劫持业务容器的流量，并接受控制面组件的控制，同时会向控制面输出日志、跟踪以及监控数据。控制面：Istio的核心，管理Istio的所有功能。
idou老师教你学Istio 15：Istio实现双向TLS的迁移
在Istio中，双向TLS是传输身份验证的完整堆栈解决方案，它为每个服务提供可跨集群的强大身份、保护服务到服务通信和最终用户到服务通信，以及提供密钥管理系统。本文阐述如何在不中断通信的情况下，把现存Istio服务的流量从明文升级为双向TLS。使用场景 在部署了Istio的集群中，使用人员
idou老师教你学Istio11 : 如何用Istio实现流量熔断
在之前的最佳实践中，已经带大家通过一系列的实践任务领略了Istio的无穷魅力。今天，将向大家介绍如何用Istio实现流量熔断。熔断机制是创建弹性微服务应用程序的重要模式。熔断可以帮助您自由控制故障影响的范围、网络延迟的峰值以及抵御其他一些来自外部的恶意***等场景。在接下来
Istio流量管理实践之(3): 基于Istio实现流量对比分析
流量镜像流量镜像，也称为影子流量，流量镜像提供一种尽可能低的风险为生产带来变化的强大功能。镜像会将实时流量的副本发送到镜像服务。镜像流量发生在主服务的关键请求路径之外。在非生产或者测试环境中，尝试访问一个服务所有可能的测试用例组合是个非常不现实的任务。在某些情况下
idou老师教你学Istio 19 : Istio 流量治理功能原理与实战
一、负载均衡算法原理与实战负载均衡算法（loadbalancingalgorithm）,定义了几种基本的流量分发方式，在Istio中一共有4种标准负载均衡算法。•Round_Robin：轮询算法，顾名思义请求将会依次发给每一个实例，来共同分担所有的请求。•Random：随机算法，将所有的请求随机分发给健康的实例•
Istio调用链埋点原理剖析—是否真的“零修改”分享实录上
本文整理自华为CloudBU技术专家在K8S技术社上关于Istio调用链的分享。前言大家好，我是idouba，来自华为CloudBU，当前在做Istio服务网格在华为云容器服务的产品化工作。今天跟大家分享的主题是Istio调用链相关内容。通过剖析Istio的架构机制与Istio中调用链的工作原理来解答一个大
idou老师教你学istio1：如何为服务提供安全防护能力
今天，我们就来谈谈Istio主打功能---保护服务。那么，便引出3个问题：Istio凭什么保护服务？Istio具体如何保护服务？如何告诉Istio发挥保护能力？Istio凭什么保护服务？将单体应用程序分解为一个个服务，为大型软件系统的开发和维护带来了诸多好处，比如更好的灵活性、可伸缩性和可复用性
istio-opentracing链路追踪方案
istio-opentracing链路追踪方案istio-opentracing链路追踪主要是由sidecar(envoy)支持的，istio只是在上层进行配置的修改。envoy链路追踪envoy主要用三个功能来支撑系统范围内的跟踪生成RequestID:envoy会在需要的时候生成UUID，并操作名为[x-request-id]的HTTPHeader。应用可
idou老师教你学Istio 07: 如何用istio实现请求超时管理
在前面的文章中，大家都已经熟悉了Istio的故障注入和流量迁移。这两个方面的功能都是Istio流量治理的一部分。今天将继续带大家了解Istio的另一项功能，关于请求超时的管理。首先我们可以通过一个简单的Bookinfo的微服务应用程序来动手实践一下Istio是如何实现请求超时的管理。看过ido
Istio调用链埋点原理剖析—是否真的“零修改”分享实录下
调用链原理和场景正如ServiceMesh的诞生是为了解决大规模分布式服务访问的治理问题，调用链的出现也是为了对应于大规模的复杂的分布式系统运行中碰到的故障定位定界问题。大量的服务调用、跨进程、跨服务器，可能还会跨多个物理机房。无论是服务自身问题还是网络环境的问题导致调用
idou老师教你学Istio 15：Istio实现双向TLS的迁移
在Istio中，双向TLS是传输身份验证的完整堆栈解决方案，它为每个服务提供可跨集群的强大身份、保护服务到服务通信和最终用户到服务通信，以及提供密钥管理系统。本文阐述如何在不中断通信的情况下，把现存Istio服务的流量从明文升级为双向TLS。使用场景在部署了Istio的集群中，使用人员刚
idou老师教你学Istio 09: 如何用Istio实现K8S Ingress流量管理
前言在Istio的世界里，如果想把外部的请求流量引入网格，你需要认识并会学会配置IstioIngressGateway什么是IngressGateway由于KubernetesIngressAPI只能支持最基本的HTTP路由，使用KubernetesIngress资源来配置外部流量的方式不能满足需求。因此Istiov1alpha3routingAPI引
Service Mesh服务网格新生代——Istio|前沿
Istio是什么?使用云平台可以为组织提供丰富的好处。然而，不可否认的是，采用云可能会给DevOps团队带来压力。开发人员必须使用微服务已满足应用的可移植性，同时运营商管理了极其庞大的混合和多云部署。Istio允许您连接、保护、控制和观测服务。在较高的层次上，Istio有助于降低这些
idou老师教你学Istio 14：如何用K8S对Istio Service进行流量健康检查
Istio利用k8s的探针对service进行流量健康检查，有两种探针可供选择，分别是liveness和readiness:liveness探针用来侦测什么时候需要重启容器。比如说当liveness探针捕获到程序运行时出现的一个死锁，这种情况下重启容器可以让程序更容易可用。readiness探针用来使容器准备好接收流量。
idou老师教你学Istio 16：如何用 Istio 实现微服务间的访问控制
摘要使用Istio可以很方便地实现微服务间的访问控制。本文演示了使用Denier适配器实现拒绝访问，和Listchecker适配器实现黑白名单两种方法。使用场景有时需要对微服务间的相互访问进行控制，比如使满足某些条件（比如版本）的微服务能够（或不能）调用特定的微服务。访问控制属于策略
容器云未来：Kubernetes、Istio 和 Knative
导读目前以Kubernetes为基础构建的容器生态逐渐完善，这其中Kubernetes、Istio、Knative三个独立项目被越来越多的人提及，并且已经开始尝试大规模落地实践，它们恰好构成了容器云的未来拼图。今天与大家一起分享下，这三个项目究竟解决了什么问题，为什么它们能够一鸣惊人。随着微服务理念
深度解析Istio系列之Istio-proxy初始化篇
注：以下讲述的按理环境场景是基于Kubernetes环境基础上部署的Istio环境。涉及到Envoy概念介绍请参考深度解析Istio系列之流量控制篇。本文重点针对Envoy初始化场景进行拆解。Istio-proxy（Envoy）作为Istio数据平面的重要组件，基于sidecar方式与业务应用混合部署到同一pod，为应用提
Istio概念原理&&为什么要使用 Istio？&&架构图
使用云平台可以为组织提供丰富的好处。然而，不可否认的是，采用云可能会给DevOps团队带来压力。开发人员必须使用微服务以满足应用的可移植性，同时运营商管理了极其庞大的混合和多云部署。Istio允许您连接、保护、控制和观测服务。在较高的层次上，Istio有助于降低这些部署的复杂性，
pythonJavaScriptjavaHTMLPHPreactjsC#AndroidCSSNode.jssqlrpython-3.xMysqLjQueryc++pandasFlutterangularIOSdjangolinuxswifttypescript路由器JSON路由器设置无线路由器h3c华三华三路由器设置华三路由器电脑软件教程arraysdocker软件图文教程Cvue.jslaravelspring-boot