Istio 的配置分析

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

Istio 的配置分析

目录

Analyzer 的消息格式

istioctl analyze 命令提供了如下消息格式：

<level> [<code>] (<affected-resource>) <message-details>

字段可以展开为：

<resource-kind> <resource-name>.<resource-namespace>

例如：

Error [IST0101] (VirtualService httpbin.default) Referenced gateway not found: "httpbin-gateway-bogus"

<message-details>字段包含关于解决问题的详细信息。当对于集群范围的资源(如namespace)时，会忽略namespace前缀。

ConflictingMeshGatewayVirtualServiceHosts

Message Name ConflictingMeshGatewayVirtualServiceHosts
Message Code IST0109
Description Conflicting hosts on VirtualServices associated with mesh gateway
Level Error

当Istio检测到virtual service资源之间存在重叠导致的冲突时，会出现该消息。例如，定义了多个使用相同的主机名的virtual service，并将其附加到网格网关上，这样就会产生上述错误。注意，Istio支持合并附加到ingress网关的virtual services。

问题解决

可以使用如下动作来解决该问题：

  • 将多个冲突的virtual service合并为一个
  • 将附加到一个网格网关的多个virtual service的主机名配置为唯一的
  • 通过exportTo字段将资源指定到某个指定的命名空间中

举例

例如，team1命名空间中的 productpage virtual service 与team2命名空间中的custom virtual service因为同时设置了如下条件导致了冲突：

  • 都附加到了默认的mesh网关上(没有指定用户网关)
  • 定义了相同的host productpage.default.svc.cluster.local 
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: productpage
  namespace: team-1
spec:
  hosts:
  - productpage.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: productpage
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: custom
  namespace: team-2
spec:
  hosts:
  - productpage.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: productpage.team-2.svc.cluster.local
---

可以通过设置exportTo字段来解决该问题，这样，virtual service的范围就限制于其所在的命名空间。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: productpage
  namespace: team-1
spec:
  exportTo:
  - "." #当前命名空间
  hosts:
  - productpage.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: productpage
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: custom
  namespace: team-2
spec:
  exportTo:
  - "." #当前命名空间
  hosts:
  - productpage.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: productpage.team-2.svc.cluster.local
---

ConflictingSidecarWorkloadSelectors

Message Name ConflictingSidecarWorkloadSelectors
Message Code IST0110
Description A Sidecar resource selects the same workloads as another Sidecar resource
Level Error

当一个命名空间中的多个sidecar选择相同的负载实例时会出现该消息，可能导致不可预知的行为。更多信息参见Sidecar资源。

为了解决该问题，需要一个命名空间中的Sidecar负载选择器(workloadSelector)选择的负载实例不会出现重叠。

GatewayPortNotOnWorkload

Message Name GatewayPortNotOnWorkload
Message Code IST0104
Description Unhandled gateway port
Level Warning

当一个网关(通常是istio-ingressgateway)提供的端口并不在网关选择的kubernetes service负载上时会出现该消息。

例如，Istio的配置包含如下值：

# Gateway with bogus port

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: httpbin-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
  - port:
      number: 8004
      name: http2
      protocol: HTTP
    hosts:
    - "*"

在上面例子中会出现GatewayPortNotOnWorkload消息，因为一个默认的IngressGateway仅会打开端口 80,443,31400,和15443，并不包括8004。使用istioctl analyze分析的结果如下：

# istioctl analyze
Warn [IST0104] (Gateway httpbin-gateway.default) The gateway refers to a port that is not exposed on the workload (pod selector istio=ingressgateway; port 8004)
Info [IST0118] (Service mutatepodimages.default) Port name  (port: 443,targetPort: 8443) doesn't follow the naming convention of Istio port.
Error: Analyzers found issues when analyzing namespace: default.

为了解决该问题，可以修改网关的配置，使用一个有效的负载端口，并重新部署即可。

InternalError

Message Name InternalError
Message Code IST0001
Description There was an internal error in the toolchain. This is almost always a bug in the implementation.
Level Error

极有可能是因为Istio的内部错误造成的。可以参见Istio的issue页面来了解会提交问题。

IstioProxyImageMismatch

Message Name IstioProxyImageMismatch
Message Code IST0105
Description The image of the Istio proxy running on the pod does not match the image defined in the injection configuration.
Level Warning

当一个Pod出现如下条件时会发生该问题：

  • 启用sidecar自动注入(默认是启用的，除非在安装时禁用)
  • pod运行在一个启用sidecar注入的命名空间中(给命名空间打上标签istio-injection=enabled)
  • 运行在sidecar中的代理版本与自动注入的版本不匹配

该问题通常会发生在更新Istio的控制面之后，在升级Istio后，所有带Istio sidecar运行的负载必须重启来注入新版本的sidecar。

为了解决该问题，可以通过滚动策略来重新部署应用的sidecar。对于kubernetes的deployment：

  1. 如果使用kubernetes 1.15或更高版本，可以运行 kubectl rollout restart <my-deployment>来触发滚动
  2. 或者，可以修改deployment的template字段来强制触发滚动。这通常是通过在模板的pod定义中添加诸如force-redeploy = <current-timestamp>之类的标签来触发deployment滚动的。

JwtFailureDueToInvalidServicePortPrefix

Message Name JwtFailureDueToInvalidServicePortPrefix
Message Code IST0119
Description Authentication policy with JWT targets Service with invalid port specification.
Level Warning

当一个认证策略使用JWT认证时，而目标kubernetes service配置不正确时会出现该消息。正确的kubernetes service要求port使用http|http2|https作为前缀来命名(参见Protocol Selection)，并且协议为TCP。默认的协议为TCP。

举例

当集群中存在如下策略时：

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: secure-httpbin
  namespace: default
spec:
  targets:
    - name: httpbin
  origins:
    - jwt:
        issuer: "testing@secure.istio.io"
        jwksUri: "https://raw.githubusercontent.com/istio/istio-1.4/security/tools/jwt/samples/jwks.json"

target的service配置如下:

apiVersion: v1
kind: Service
metadata:
  name: httpbin
  namespace: default
  labels:
    app: httpbin
spec:
  ports:
  - name: svc-8080
    port: 8080
    targetPort: 80
    protocol: TCP
  selector:
    app: httpbin

在上面例子中，port svc-8080并没有遵守语法: name: <http|https|http2>[-<suffix>]。将会接收到如下消息：

Warn [IST0119] (Policy secure-httpbin.default) Authentication policy with JWT targets Service with invalid port specification (port: 8080,name: svc-8080,protocol: TCP,targetPort: 80).

JWT认证仅支持http，https或http2，修改Service 端口名，使其遵守 <http|https|http2>[-<suffix>]即可。

MisplacedAnnotation

Message Name MisplacedAnnotation
Message Code IST0107
Description An Istio annotation is applied to the wrong kind of resource.
Level Warning

当Istio的annotation附加到一个无效的资源或错误的位置上时会出现该消息。例如，如果创建一个deployment，然后将annotation附加到该deployment，而不是pods上时就会出现该错误提示。

将annotation放到正确的位置即可修改该问题。

MTLSPolicyConflict

Message Name MTLSPolicyConflict
Message Code IST0113
Description A DestinationRule and Policy are in conflict with regards to mTLS.
Level Error

当一个destination rule资源和一个策略资源因为mutual TLS冲突时会出现该消息。当两个资源选择的TLS模式不匹配时就会出现这种情况。该冲突意味着，匹配到destination rule的流量将会被拒绝。

该消息已经被废弃，仅在使用alpha认证策略的服务网格中使用。(了解该问题仍然可以避免配置错误)

哪些destination rules和策略与服务相关

为了有效解决mutual TLS的冲突，需要同时了解destination rule和策略是如何影响到一个服务的流量的。考虑一个my-namespace命名空间中的名为my-service的服务。为了确定应用到my-service上的是哪个策略对象，按顺序匹配以下资源：

  1. my-namespace命名空间中的策略资源包含一个target，指定了my-service
  2. my-namespace命名空间中的一个名为default的策略资源不包含一个target，意味着该策略适用于整个命名空间。
  3. 名为default的网格策略资源

为了确定哪个destination rule应用到到达my-service的流量，首先要知道流量来自哪个命名空间。本例中，假设命名空间为other-namespace。destination rule按照如下方式进行匹配：

  1. other-namespace命名空间中的destination rule会指定一个host来匹配 my-service.my-namespace.svc.cluster.local(可能会通过完整匹配或通配符匹配)。注意exportTo字段，该字段控制了配置资源的可见性，当目标资源与源服务在相同的命名空间时会被忽略(相同命名空间下的服务总是可见的)。

  2. my-namespace命名空间中的destination rule会指定一个host来匹配 my-service.my-namespace.svc.cluster.local(可能会通过完整匹配或通配符匹配)。注意为了进行匹配，exportTo字段必须将该资源指定为公共的(即，值为*或不指定)。

  3. 根命名空间(默认为istio-system)中的destination rule会匹配 my-service.my-namespace.svc.cluster.local。MeshConfig 资源中的rootNamespace属性会控制根命名空间。注意为了进行匹配，exportTo字段必须将该资源指定为公共的(即，值为*或不指定)。对rootNamespace的描述如下

    The namespace to treat as the administrative root namespace for Istio configuration. When processing a leaf namespace Istio will search for declarations in that namespace first and if none are found it will search in the root namespace. Any matching declaration found in the root namespace is processed as if it were declared in the leaf namespace.

最后，注意在遵循这些规则时，Istio不会应用任何继承概念，它将使用符合指定条件的第一个资源。

问题解决

查看如下输出：

Error [IST0113] (DestinationRule default-rule.istio-system) A DestinationRule
and Policy are in conflict with regards to mTLS for host
myhost.my-namespace.svc.cluster.local:8080. The DestinationRule
"istio-system/default-rule" specifies that mTLS must be true but the Policy
object "my-namespace/my-policy" specifies Plaintext.

可以看出两个资源是冲突的：

  • 策略资源my-namespace/my-policy使用Plaintext来支持mutual TLS模式
  • destination rule资源istio-system/default-rule,指定发送到host myhost.my-namespace.svc.cluster.local:8080的流量需要启用mutual TLS

可以使用下面的方式之一来修复该问题：

  • 修改策略资源my-namespace/my-policy来启用mutual TLS作为认证模式。
  • 修改destination rule istio-system/default-rule，通过移除ISTIO_MUTUAL来禁用mutual TLS。注意default-rule位于istio-system命名空间，即默认的根命名空间中，意味着该destination rule会影响到网格中过的所有其他服务。
  • 在与服务相同的命名空间(my-namespace)中添加一个新的destination rule，该destination rule不指定流量策略mutual TLS。由于该规则位于与服务相同的命名空间中，它不会覆盖全局destination rule istio-system/default-rule.

MultipleSidecarsWithoutWorkloadSelectors

Message Name MultipleSidecarsWithoutWorkloadSelectors
Message Code IST0111
Description More than one sidecar resource in a namespace has no workload selector
Level Error

当一个命名空间中的多个sidecar资源没有定义任何负载选择器时会出现该消息，导致不可预知的行为。更多参见Sidecar。

一个命名空间仅允许一个sidecar资源不指定负载选择器。

NamespaceNotInjected

Message Name NamespaceNotInjected
Message Code IST0102
Description A namespace is not enabled for Istio injection.
Level Warning

当一个命名空间没有annotation(如sidecar.istio.io/inject.)指明该命名空间是否需要自动注入sidecar时会出现该提示。错误信息如下：

Warn [IST0102] (Namespace default) The namespace is not enabled for Istio
injection. Run 'kubectl label namespace default istio-injection=enabled' to
enable it,or 'kubectl label namespace default istio-injection=disabled' to
explicitly mark it as not needing injection Error: Analyzer found issues.

可以通过给命名空间打标签来解决该问题，明确声明是否需要启用sidecar自动注入：

$ kubectl label namespace <namespace-name> istio-injection=enabled

强烈建议明确指定sidecar注入行为。忘记注释命名空间是导致错误的常见原因。

SchemaValidationError

Message Name SchemaValidationError
Message Code IST0106
Description The resource has a schema validation error.
Level Error

当Istio的配置没有通过模式验证时会出现该错误。如：

Error [IST0106] (VirtualService ratings-bogus-weight-default.default) Schema validation error: percentage 888 is not in range 0..100

Istio配置为：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings-bogus-weight-default
  namespace: default
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
      weight: 999
    - destination:
        host: ratings
        subset: v2
      weight: 888

本例中可以看到weight元素为一个无效的值。可以通过消息的details字段来检查哪个元素或值没有符合模式要求，然后进行修正。

VirtualServiceDestinationPortSelectorRequired

Message Name VirtualServiceDestinationPortSelectorRequired
Message Code IST0112
Description A VirtualService routes to a service with more than one port exposed,but does not specify which to use.
Level Error

当一个virtual service路由到暴露多个port的服务，且没有指定使用哪个端口时会出现该错误。这种模糊性可能导致不确定的行为。

可以在virtual service Destination中增加port字段来解决该问题。

UnknownAnnotation

Message Name UnknownAnnotation
Message Code IST0108
Description An Istio annotation is not recognized for any kind of resource
Level Warning

当将格式为*.istio.io的无法识别的注释附加到名称空间时，会出现此消息。Istio仅能识别特定的annotation名称。

ReferencedResourceNotFound

Message Name ReferencedResourceNotFound
Message Code IST0101
Description A resource being referenced does not exist.
Level Error

当Istio资源相关的资源不存在时会出现该错误。当Istio尝试查找引用的资源但无法找到时，将导致错误。错误信息如：

Error [IST0101] (VirtualService httpbin.default) Referenced gateway not found: "httpbin-gateway-bogus"

本例中，VirtualService引用了一个不存在的网关。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: httpbin-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http2
      protocol: HTTP2
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - "*"
  gateways:
  - httpbin-gateway-bogus #  Should have been "httpbin-gateway"
  http:
  - route:
    - destination:
        host: httpbin-gateway

为了解决该问题，查看detaild错误消息中的资源类型，然后修正Istio配置即可。

PortNameIsNotUnderNamingConvention

Message Name PortNameIsNotUnderNamingConvention
Message Code IST0118
Description Port name is not under naming convention. Protocol detection is applied to the port.
Level Info

当端口不遵守Istio服务端口命名规范或端口未命名时会出现该错误。错误信息如：

Info [IST0118] (Service httpbin.default) Port name foo-http (port: 80,targetPort: 80) doesn't follow the naming convention of Istio port.

对应的Service为：

apiVersion: v1
kind: Service
metadata:
  name: httpbin
  labels:
    app: httpbin
spec:
  ports:
  - name: foo-http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin

可以通过将port foo-http按照语法name: <protocol>[-<suffix>]修改即可。

问题解决

  • 如果知道服务端口的协议，使用 <protocol>[-<suffix>] 格式重命名即可
  • 如果不知道服务端口的协议，则需要从Prometheus请求metrics来获取
    • 执行请求istio_requests_total
    • 如果有输出，可以在metrics的request_protocol字段中看到使用的协议
    • 如果没有输出，则可以保留端口不变。

PodMissingProxy

Message Name PodMissingProxy
Message Code IST0103
Description A pod is missing the Istio proxy.
Level Warning

当没有sidecar或sidecar不正常时会出现该错误。

通常是因为启用了自动注入，但后续没有重启pod导致sidecar不存在。

可以使用如下命令修复：

$ kubectl rollout restart deployment

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 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