Service Mesh
Configuration affecting the service mesh as a whole.
AuthenticationPolicy
AuthenticationPolicy defines authentication policy. It can be set for different scopes (mesh, service …), and the most narrow scope with non-INHERIT value will be used. Mesh policy cannot be INHERIT.
Name | Description |
---|---|
NONE | Do not encrypt Envoy to Envoy traffic. |
MUTUAL_TLS | Envoy to Envoy traffic is wrapped into mutual TLS connections. |
INHERIT | Use the policy defined by the parent scope. Should not be used for mesh policy. |
ConfigSource
ConfigSource describes information about a configuration store inside a mesh. A single control plane instance can interact with one or more data sources.
LocalityLoadBalancerSetting
Locality-weighted load balancing allows administrators to control the distribution of traffic to endpoints based on the localities of where the traffic originates and where it will terminate. These localities are specified using arbitrary labels that designate a hierarchy of localities in {region}/{zone}/{sub-zone} form. For additional detail refer to Locality Weight The following example shows how to setup locality weights mesh-wide.
Given a mesh with workloads and their service deployed to “us-west/zone1/” and “us-west/zone2/”. This example specifies that when traffic accessing a service originates from workloads in “us-west/zone1/”, 80% of the traffic will be sent to endpoints in “us-west/zone1/”, i.e the same zone, and the remaining 20% will go to endpoints in “us-west/zone2/”. This setup is intended to favor routing traffic to endpoints in the same locality. A similar setting is specified for traffic originating in “us-west/zone2/”.
distribute:
- from: us-west/zone1/*
to:
"us-west/zone1/*": 80
"us-west/zone2/*": 20
- from: us-west/zone2/*
to:
"us-west/zone1/*": 20
"us-west/zone2/*": 80
If the goal of the operator is not to distribute load across zones and regions but rather to restrict the regionality of failover to meet other operational requirements an operator can set a ‘failover’ policy instead of a ‘distribute’ policy.
The following example sets up a locality failover policy for regions. Assume a service resides in zones within us-east, us-west & eu-west this example specifies that when endpoints within us-east become unhealthy traffic should failover to endpoints in any zone or sub-zone within eu-west and similarly us-west should failover to us-east.
failover:
- from: us-east
to: eu-west
- from: us-west
to: us-east
Locality load balancing settings.
LocalityLoadBalancerSetting.Distribute
Describes how traffic originating in the ‘from’ zone or sub-zone is distributed over a set of ‘to’ zones. Syntax for specifying a zone is {region}/{zone}/{sub-zone} and terminal wildcards are allowed on any segment of the specification. Examples: * - matches all localities us-west/* - all zones and sub-zones within the us-west region us-west/zone-1/* - all sub-zones within us-west/zone-1
LocalityLoadBalancerSetting.Failover
Specify the traffic failover policy across regions. Since zone and sub-zone failover is supported by default this only needs to be specified for regions when the operator needs to constrain traffic failover so that the default behavior of failing over to any endpoint globally does not apply. This is useful when failing over traffic across regions would not improve service health or may need to be restricted for other reasons like regulatory controls.
MeshConfig
MeshConfig defines mesh-wide variables shared by all Envoy instances in the Istio service mesh.
NOTE: This configuration type should be used for the low-level global configuration, such as component addresses and port numbers. It should not be used for the features of the mesh that can be scoped by service or by namespace. Some of the fields in the mesh config are going to be deprecated and replaced with several individual configuration types (for example, tracing configuration).
MeshConfig.AccessLogEncoding
Name | Description |
---|---|
TEXT | |
JSON |
MeshConfig.H2UpgradePolicy
Default Policy for upgrading http1.1 connections to http2.
Name | Description |
---|---|
DO_NOT_UPGRADE | Do not upgrade connections to http2. |
UPGRADE | Upgrade the connections to http2. |
MeshConfig.IngressControllerMode
Name | Description |
---|---|
OFF | Disables Istio ingress controller. |
DEFAULT | Istio ingress controller will act on ingress resources that do not contain any annotation or whose annotations match the value specified in the ingress_class parameter described earlier. Use this mode if Istio ingress controller will be the default ingress controller for the entireKubernetes cluster. |
STRICT | Istio ingress controller will only act on ingress resources whose annotations match the value specified in the ingress_class parameter described earlier. Use this mode if Istio ingress controller will be a secondary ingress controller (e.g., in addition to a cloud-provided ingress controller). |
MeshConfig.OutboundTrafficPolicy
MeshConfig.OutboundTrafficPolicy.Mode
Name | Description |
---|---|
REGISTRY_ONLY | outbound traffic will be restricted to services defined in the service registry as well as those defined through ServiceEntries |
ALLOW_ANY | outbound traffic to unknown destinations will be allowed, in case there are no services or ServiceEntries for the destination port |
MeshNetworks
MeshNetworks (config map) provides information about the set of networks inside a mesh and how to route to endpoints in each network. For example
MeshNetworks(file/config map):
networks:
network1:
- endpoints:
- fromRegistry: registry1 #must match secret name in Kubernetes
- fromCidr: 192.168.100.0/22 #a VM network for example
gateways:
- registryServiceName: istio-ingressgateway.istio-system.svc.cluster.local
port: 15443
locality: us-east-1a
- address: 192.168.100.1
port: 15443
locality: us-east-1a
Network
Network provides information about the endpoints in a routable L3 network. A single routable L3 network can have one or more service registries. Note that the network has no relation to the locality of the endpoint. The endpoint locality will be obtained from the service registry.
Network.IstioNetworkGateway
The gateway associated with this network. Traffic from remote networks will arrive at the specified gateway:port. All incoming traffic must use mTLS.
Network.NetworkEndpoints
NetworkEndpoints describes how the network associated with an endpoint should be inferred. An endpoint will be assigned to a network based on the following rules:
Implicitly: If the registry explicitly provides information about the network to which the endpoint belongs to. In some cases, its possible to indicate the network associated with the endpoint by adding the
ISTIO_META_NETWORK
environment variable to the sidecar.Explicitly:
a. By matching the registry name with one of the “fromRegistry” in the mesh config. A “from_registry” can only be assigned to a single network.
b. By matching the IP against one of the CIDR ranges in a mesh config network. The CIDR ranges must not overlap and be assigned to a single network.
(2) will override (1) if both are present.
ProxyConfig
ProxyConfig defines variables for individual Envoy instances.
ProxyConfig.InboundInterceptionMode
The mode used to redirect inbound traffic to Envoy. This setting has no effect on outbound traffic: iptables REDIRECT is always used for outbound connections.
Name | Description |
---|---|
REDIRECT | The REDIRECT mode uses iptables REDIRECT to NAT and redirect to Envoy. This mode loses source IP addresses during redirection. |
TPROXY | The TPROXY mode uses iptables TPROXY to redirect to Envoy. This mode preserves both the source and destination IP addresses and ports, so that they can be used for advanced filtering and manipulation. This mode also configures the sidecar to run with the CAPNETADMIN capability, which is required to use TPROXY. |
RemoteService
SDS
SDS defines secret discovery service(SDS) configuration to be used by the proxy. For workload, its values are set in sidecar injector(passed as arguments to istio-proxy container). For pilot/mixer, it’s passed as arguments to istio-proxy container in pilot/mixer deployment yaml files directly.
Tracing
Tracing defines configuration for the tracing performed by Envoy instances.
Tracing.Datadog
Datadog defines configuration for a Datadog tracer.
Tracing.Lightstep
Defines configuration for a LightStep tracer.
Tracing.Stackdriver
Stackdriver defines configuration for a Stackdriver tracer. See Opencensus trace config for details.
Tracing.Zipkin
Zipkin defines configuration for a Zipkin tracer.