The software described in this documentation is either no longer supported or is in extended support.
Oracle recommends that you upgrade to a current supported release.
Istio automatically populates its service registry with all services you create in the service mesh, so it knows all possible service endpoints. By default, the Envoy proxy sidecars manage traffic by sending requests to each service instance in turn in a round-robin fashion. You can configure the management of this traffic to suit your own application requirements using the Istio traffic management APIs. The APIs are accessed using Kubernetes custom resource definitions (CRDs), which you set up and deploy using YAML files.
The Istio API traffic management features available are:
Virtual services: Configure request routing to services within the service mesh. Each virtual service can contain a series of routing rules, that are evaluated in order.
Destination rules: Configures the destination of routing rules within a virtual service. Destination rules are evaluated and actioned after the virtual service routing rules. For example, routing traffic to a particular version of a service.
Gateways: Configure inbound and outbound traffic for services in the mesh. Gateways are configured as standalone Envoy proxies, running at the edge of the mesh. An ingress and an egress gateway are deployed automatically when you install the Istio module.
Service entries: Configure services outside the service mesh in the Istio service registry. Allows you to manage the traffic to services as if they are in the service mesh. Services in the mesh are automatically added to the service registry, and service entries allow you to bring in outside services.
Sidecars: Configure sidecar proxies to set the ports, protocols and services to which a microservice can connect.
These Istio traffic management APIs are well documented in the upstream documentation at:
https://istio.io/docs/concepts/traffic-management/
Istio enables network communication between services to be abstracted from the services themselves and to instead be handled by proxies. Istio uses a sidecar design, which means that communication proxies run in their own containers alongside every service container.
To enable the use of a service mesh in your Kubernetes applications, you need to enable automatic proxy sidecar injection. This injects proxy sidecar containers into pods you create.
To put automatic sidecar injection into effect, the namespace to
be used by an application must be labeled with
istio-injection=enabled. For example, to enable
automatic sidecar injection for the default
namespace:
$kubectl label namespace default istio-injection=enablednamespace/default labeled $kubectl get namespace -L istio-injectionNAME STATUS AGE ISTIO-INJECTION default Active 29h enabled istio-system Active 29h kube-node-lease Active 29h kube-public Active 29h kube-system Active 29h
Any applications deployed into the default namespace have automatic sidecar injection enabled and the sidecar runs alongside the pod. For example, create a simple NGINX deployment:
$ kubectl create deployment --image nginx hello-world
deployment.apps/hello-world created
Show the details of the pod to see that an
istio-proxy container is also deployed with the
application:
$kubectl get podsNAME READY STATUS RESTARTS AGE hello-world-5fcdb6bc85-wph7h 2/2 Running 0 7m40s $kubectl describe pods hello-world-5fcdb6bc85-wph7h... Normal Started 13s kubelet, worker1.example.com Started container nginx Normal Started 12s kubelet, worker1.example.com Started container istio-proxy