Sidecar describes the configuration of the sidecar proxy that mediates
inbound and outbound communication to the workload it is attached to. By
default, Istio will program all sidecar proxies in the mesh with the
necessary configuration required to reach every workload in the mesh, as
well as accept traffic on all the ports associated with the
workload. The Sidecar resource provides a way to fine tune the set of
ports, protocols that the proxy will accept when forwarding traffic to
and from the workload. In addition, it is possible to restrict the set
of services that the proxy can reach when forwarding outbound traffic
from the workload.
Services and configuration in a mesh are organized into one or more namespaces (e.g., a Kubernetes namespace or a CF org/space). A Sidecar resource in a namespace will apply to one or more workloads in the same namespace, selected using the workloadSelector. In the absence of a workloadSelector, it will apply to all workloads in the same namespace. When determining the Sidecar resource to be applied to a workload, preference will be given to the resource with a workloadSelector that selects this workload, over a Sidecar resource without any workloadSelector.
NOTE: Each namespace can have only one Sidecar resource without any workload selector. The behavior of the system is undefined if more than one selector-less Sidecar resources exist in a given namespace. The behavior of the system is undefined if two or more Sidecar resources with a workload selector select the same workload.
The example below declares a Sidecar resource in the prod-us1 namespace that configures the sidecars in the namespace to allow egress traffic to public services in the prod-us1, prod-apis, and the istio-system namespaces.
apiVersion: networking.istio.io/v1alpha3 kind: Sidecar metadata: name: default namespace: prod-us1 spec: egress: - hosts: - "prod-us1/*" - "prod-apis/*" - "istio-system/*"
The example below declares a Sidecar resource in the prod-us1 namespace that accepts inbound HTTP traffic on port 9080 and forwards it to the attached workload listening on a Unix domain socket. In the egress direction, in addition to the istio-system namespace, the sidecar proxies only HTTP traffic bound for port 9080 for services in the prod-us1 namespace.
apiVersion: networking.istio.io/v1alpha3 kind: Sidecar metadata: name: default namespace: prod-us1 spec: ingress: - port: number: 9080 protocol: HTTP name: somename defaultEndpoint: unix:///var/run/someuds.sock egress: - hosts: - "istio-system/*" - port: number: 9080 protocol: HTTP name: egresshttp hosts: - "prod-us1/*"
If the workload is deployed without IP tables based traffic capture, the
Sidecar resource is the only way to configure the ports on the proxy
attached to the workload. The following example declares a Sidecar
resource in the prod-us1 namespace for all pods with labels “app:
productpage” belonging to the productpage.prod-us1 service. Assuming
that these pods are deployed without IPtable rules (i.e. the Istio init
container) and the proxy metadata
ISTIO_META_INTERCEPTION_MODE is set to
NONE, the specification below allows such pods to receive HTTP traffic
on port 9080 and forward it to the application listening on
127.0.0.1:8080. It also allows the application to communicate with a
backing MySQL database on 127.0.0.1:3306, that then gets proxied to the
externally hosted MySQL service at mysql.foo.com:3306.
apiVersion: networking.istio.io/v1alpha3 kind: Sidecar metadata: name: no-ip-tables namespace: prod-us1 spec: workloadSelector: labels: app: productpage ingress: - port: number: 9080 # binds to 0.0.0.0:9080 protocol: HTTP name: somename defaultEndpoint: 127.0.0.1:8080 captureMode: NONE # not needed if metadata is set for entire proxy egress: - port: number: 3306 protocol: MYSQL name: egressmysql captureMode: NONE # not needed if metadata is set for entire proxy bind: 127.0.0.1 hosts: - "*/mysql.foo.com"
And the associated service entry for routing to mysql.foo.com:3306
apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: external-svc-mysql namespace: ns1 spec: hosts: - mysql.foo.com ports: - number: 3306 name: mysql protocol: MYSQL location: MESH_EXTERNAL resolution: DNS
It is also possible to mix and match traffic capture modes in a single
proxy. For example, consider a setup where internal services are on the
192.168.0.0/16 subnet. So, IP tables are setup on the VM to capture all
outbound traffic on 192.168.0.0/16 subnet. Assume that the VM has an
additional network interface on 172.16.0.0/16 subnet for inbound
traffic. The following Sidecar configuration allows the VM to expose a
listener on 172.16.1.32:80 (the VM’s IP) for traffic arriving from the
172.16.0.0/16 subnet. Note that in this scenario, the
ISTIO_META_INTERCEPTION_MODE metadata on the proxy in the VM should
contain “REDIRECT” or “TPROXY” as its value, implying that IP tables
based traffic capture is active.
apiVersion: networking.istio.io/v1alpha3 kind: Sidecar metadata: name: partial-ip-tables namespace: prod-us1 spec: workloadSelector: labels: app: productpage ingress: - bind: 172.16.1.32 port: number: 80 # binds to 172.16.1.32:80 protocol: HTTP name: somename defaultEndpoint: 127.0.0.1:8080 captureMode: NONE egress: # use the system detected defaults # sets up configuration to handle outbound traffic to services # in 192.168.0.0/16 subnet, based on information provided by the # service registry - captureMode: IPTABLES hosts: - "*/*"
CaptureMode describes how traffic to a listener is expected to be captured. Applicable only when the listener is bound to an IP.
The default capture mode defined by the environment
Capture traffic using IPtables redirection
No traffic capture. When used in egress listener, the application is expected to explicitly communicate with the listener port/unix domain socket. When used in ingress listener, care needs to be taken to ensure that the listener port is not in use by other processes on the host.
IstioEgressListener specifies the properties of an outbound traffic listener on the sidecar proxy attached to a workload.
IstioIngressListener specifies the properties of an inbound traffic listener on the sidecar proxy attached to a workload.
WorkloadSelector specifies the criteria used to determine if the Gateway or Sidecar resource can be applied to a proxy. The matching criteria includes the metadata associated with a proxy, workload info such as labels attached to the pod/VM, or any other info that the proxy provides to Istio during the initial handshake. If multiple conditions are specified, all conditions need to match in order for the workload to be selected. Currently, only label based selection mechanism is supported.