当前位置:网站首页>How to reduce the resource consumption of istio agent through sidecar custom resource

How to reduce the resource consumption of istio agent through sidecar custom resource

2020-11-08 23:46:00 control

stay Istio In the system , The main components of the data plane are istio proxy(envoy), About istio proxy, There are two issues that we are more concerned about :

  • Request delay
  • resource consumption

It's easy to understand the request delay , After all, our business is mesh in , There's an extra layer of agency .

Today we mainly talk about Istio Agent resource consumption and how to use the new Sidecar Custom resources to reduce consumption .

Sidecar Custom resources

And VirtualService and DestinationRule These common resources are different ,Sidecar Resources are not known to all .

Sidecar It describes sidecar Agent configuration , It coordinates inbound and outbound communication with the workload instances to which it is connected . By default ,Istio You will use the necessary configuration to reach each workload instance in the grid for all sidecar Agent programming , And accept traffic on all ports related to the workload . Sidecar Configuration provides the ability to fine tune the port set , The protocol that the agent will accept when forwarding traffic to or from the workload . Besides , When forwarding outbound traffic from a workload instance , You can limit the set of services that the proxy can access .

Each namespace can only have one Sidecar To configure , Without any workload selectors , The payload specifies all Pod The default value of . For namespace scoped sidecar, It is recommended to use the default name . If there are more than one in a given namespace that does not use selectors Sidecar To configure , Then the behavior of the system is uncertain . If two or more Sidecar Configure to select the same workload instance , Then the behavior of the system is uncertain .
By default ,MeshConfig In the root namespace Sidecar The configuration will be applied to all without Sidecar Configured namespace . This global default is Sidecar The configuration should not have any workload selectors .

Now let's go through some official examples to better understand .

The following example declares the global default in the root namespace Sidecar To configure default, This configuration configures... In all the namespace sidecar, To allow only traffic to be sent to other workloads in the same namespace as well as istio-system Services in the namespace .

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: default
  namespace: istio-config
spec:
  egress:
  - hosts:
    - "./*"
    - "istio-system/*"

The following example is in prod-us1 Name space Sidecar To configure , This configuration will override the global defaults defined above , And configure... In the namespace sidecar, To allow access to prod-us1,prod-apis and istio-system Services in the namespace .

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: default
  namespace: prod-us1
spec:
  egress:
  - hosts:
    - "prod-us1/*"
    - "prod-apis/*"
    - "istio-system/*"

The following example is in prod-us1 All tags in the namespace app: ratings Of pod Statement Sidecar To configure , these pod Belong to rating.prod-us1 service . Workload on port 9080 Accept inbound on HTTP signal communication . then , Forward communication to listening Unix Additional workload instances for domain sockets . Stand in the direction of , except istio-system Out of the namespace ,sidecar Only the proxy is bound to the port 9080 Of prod-us1 Of the service in the namespace HTTP signal communication .

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: ratings
  namespace: prod-us1
spec:
  workloadSelector:
    labels:
      app: ratings
  ingress:
  - port:
      number: 9080
      protocol: HTTP
      name: somename
    defaultEndpoint: unix:///var/run/someuds.sock
  egress:
  - port:
      number: 9080
      protocol: HTTP
      name: egresshttp
    hosts:
    - "prod-us1/*"
  - hosts:
    - "istio-system/*"

Sidecar The description includes the following 4 part :

  • workloadSelector -- Used to select that this... Should be applied to it Sidecar Configuration specific Pod/VM Conditions for groups . If omitted , be Sidecar The configuration will be applied to all workload instances in the same namespace .
  • ingress -- ingress Specifies the inbound traffic of the workload instance Sidecar Configuration of . If omitted ,Istio Will be based on information about the workload obtained from the business process platform ( for example , Public ports , Service etc. ) Automatic configuration sidecar. If specified , Then only if the workload instance is associated with the service , To configure the inbound port .
  • egress -- egress Specifies the... Used to handle outbound traffic from connected workload instances to other services in the grid Sidecar Configuration of . If not specified , From the namespace scope or global default Sidecar Inherit detected system defaults .
  • outboundTrafficPolicy -- Configuration of outbound traffic policy . If your application uses one or more unknown external services , Set the policy to ALLOW_ANY Will lead to sidecar The application routes all its requests to unknown destinations . If not specified , From the namespace scope or global default Sidecar Inherit detected system defaults .

Why should I use Sidecar Custom resources ?

Without using this custom resource ,Pilot The same configuration is automatically sent to the agent , It contains information about each workload instance in the grid .

So use Sidecar What are the benefits of custom resources ?

  • Security .Istio Operations can limit the set of services that can be accessed from a particular namespace or workload , So you can make sure that these workloads won't be able to access anything outside their scope .
  • performance . By default , All in the cluster Envoy Agent through xDS from Pilot Receive the same configuration , This configuration contains all the Pod. This configuration can be very large , Especially in large clusters , And in most cases , A simple workload can only communicate with a few . Changing this configuration to include only a set of necessary services may affect Istio The amount of memory used by agents has a big impact .

Let's take a look at the test data , Let's compare .

The two dashboards above show basically the same memory consumption metrics , But the first dashboard is each sidecar, And the second dashboard is all of the Istio Total memory usage of the agent .

When the cluster is idle , When configuring namespace isolation ,Envoy The memory consumed by the agent is reduced by about 40%. When the cluster is under load , The percentage difference will narrow a little bit , Still more than 30%. And it's just a contract with 150 individual Pod Of 10 Node cluster , Outbound traffic is limited to the namespace ! In a production cluster ,Pod The numbers can easily reach hundreds or even thousands , And these limits can be further tightened to the workload level . therefore , With the right settings , You can easily save about 40-50% Of sidecar Agent memory consumption .

版权声明
本文为[control]所创,转载请带上原文链接,感谢