Istio: an overview and running Service Mesh in Kubernetes
Tags: kubernetes, aws, devops
Published: 2021-04-21 05:13:22

---
title: Istio: an overview and running Service Mesh in Kubernetes
published: true
date: 2021-04-11 04:53:49 UTC
tags: kubernetes,aws,devops
canonical_url: https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/
---

![](https://cdn-images-1.medium.com/max/1024/1*-hc5p49iJX0i7tU-6oKZNg.jpeg)

Istio is a Service Mesh solution that allows performing Service Discovery, Load Balancing, traffic control, canary rollouts and blue-green deployments, traffic monitoring between microservices.

We will use Istio in our AWS Elastic Kubernetes Service for traffic monitoring, as an API Gateway service, for traffic policies, and for various [deployment strategies](https://www.infoworld.com/article/3565750/4-deployment-strategies-for-resilient-microservices.html).

In this post, will speak about the Service Mesh concept in general, then will take an overview of Istio architecture and components, its installation process, and how to run a test application.

### Content

- [What is the Service Mesh](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/#Service_Mesh)?
- [Istio architecture](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/#Istio_architecture)
- [Control Plane](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/#Control_Plane)
- [Data Plane](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/#Data_Plane)
- [Istio network model](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/#Istio_network_model)
- [Running Istio in Kubernetes](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/#Running_Istio_in_Kubernetes)
- [Running test application](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/#Running_test_application)
- [Istio Ingress Gateway](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/#Istio_Ingress_Gateway)
- [Gateway](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/#Gateway)
- [VirtualService](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/#VirtualService)
- [Kiali — traffic observation](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/#Kiali_-_traffic_observation)
- [Sidecar — Envoy proxy](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/#Sidecar_-_Envoy_proxy)
- [Istio and iptables](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/#Istio_and_iptables)
- [Running Sidecar](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/#Running_Sidecar)
- [Useful links](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/#Useful_links)

### Service Mesh

Essentially, it’s a proxy-services manager. As a proxy service there can be systems like NGINX, HAProxy, or Envoy, working on the [Network OSI](https://rtfm.co.ua/what-is-model-osi/) Layer 7, that allows for dynamic traffic control and applications communication configuration.

Service mesh performs a new applications/services discovery, load-balancing, authentication, and traffic encryption.

For the traffic control in a service mesh for each application or in the case of Kubernetes for each pod, a proxy service called _sidecar_ is started alongside the application.

Together those sidecar containers are known as a _Data Plane_.

For their configuration and management, there is another process group called _Control Plane_. They are used for new applications discovery, encryption keys management, metrics collection and aggregation, and so on.

A service mesh can be displayed as such a scheme:

![](https://cdn-images-1.medium.com/max/800/0*mslilQvkYDR_fsFe.png)

Among many Service mesh solutions I’d mention the followings:

- [AWS App Mesh](https://aws.amazon.com/ru/app-mesh/)
- [Hashicop Consul](https://learn.hashicorp.com/tutorials/consul/service-mesh)
- [Linkerd](https://linkerd.io/)
- [Apache ServiceComb](https://servicecomb.apache.org/docs/introduction/)
- [Traefik Mesh](https://traefik.io/traefik-mesh/)
- [Istio](https://istio.io/)

Read more (all links in Rus):

- [Что такое Service Mesh?](https://habr.com/ru/company/otus/blog/506916/)
- [Service Mesh: что нужно знать каждому Software Engineer о самой хайповой технологии](https://habr.com/ru/company/flant/blog/478306/)
- [Что такое service mesh и почему он мне нужен [для облачного приложения с микросервисами]?](https://habr.com/ru/company/flant/blog/327536/)
- [Service mesh — это всё ещё сложно](https://habr.com/ru/company/flant/blog/533686/)

### Istio architecture

So, Istio as a service mesh consists of two main parts — the _Data plane_ and _Control plane_:

- **Data plane** (“a data layer”): contains a collection of proxy services represented as sidecar containers in each Kubernetes Pod, using an extended [Envoy](https://www.envoyproxy.io/) proxy server. Those sidecars links and controls traffic between applications, collects and sens metrics
- **Control plane** (“control layer”): manages and configures sidecars, aggregates monitoring metrics, TLS certificates management

Istio architecture can be represented as the following diagram:

![](https://cdn-images-1.medium.com/max/1000/0*fRjgCPJUHy_UJv1R.png)

Or another one:

![](https://cdn-images-1.medium.com/max/1024/0*8HJDyW-zQU5fcD0_.png)

#### Control Plane

Istio Control Plane inculdes for main componentes:

- _Pilot_: central controller responsible for communication with sidecars using [Envoy API](https://www.envoyproxy.io/docs/envoy/latest/api/api). It reads rules described in istio manifests and sends them to Envoy proxies to configure them. Also, it is used for the [service discovery](https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/), traffic control, routing, network resistance ability with timeouts and [circuit breaking](https://en.wikipedia.org/wiki/Circuit_breaker_design_pattern).
- _Citadel_: Identity and Access management — traffic encryption, users and services authentification, TLS keys management. See [Istio Security](https://istio.io/v1.4/docs/concepts/security/).
- _Galley_: configuration management — validates new configs and sends them over mesh
- _Mixer_: monitoring, metrics, logs, traffic control

Since the Istio version 1.9.1 they all, excluding Pilot, which is running in a dedicated Docker container, are built as a single binary file called `istiod`, plus additional Ingress and Egress Controllers.

#### Data Plane

Consist of sidecar containers running as additional processes which are running in Kubernetes via `kube-inject`, see the [Installing the Sidecar](https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/).

These containers and Envoy proxy instances allow to:

- Dynamic [service discovery](https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/)
- Load balancing
- TLS termination
- HTTP/2 and gRPC proxies
- [Circuit breakers](https://en.wikipedia.org/wiki/Circuit_breaker)
- Health checks
- [Deployment staged rollouts](https://www.infoworld.com/article/3565750/4-deployment-strategies-for-resilient-microservices.html)
- Rich metrics

Read more:

- [Architecture](https://istio.io/latest/docs/ops/deployment/architecture/)
- [Istio Architecture](https://www.istioworkshop.io/03-servicemesh-overview/istio-architecture/)

### Istio network model

Before going to run our Istio — let’s take a brief overview of the resources used to manage traffic.

During installation, Istio creates an Ingress Gateway service (and Egress Gateway, if this was set during the installation) — a new Kubernetes object described as [Kubernetes CRD](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) during Istio install.

In AWS with default settings, Ingress Gateway will create an AWS Classic LoadBalancer, as Ingress Gateway is represented as Kubernetes Ingress object with the LoadBalancer type.

“Behind” an Ingress Gateway is another resource is created — the [Gateway](https://istio.io/latest/docs/reference/config/networking/gateway/), which is also described as Kubernetes CRD during installation and used to describe hosts and ports used to send traffic with this Gateway.

Then, another resource is going to the scene — the VirtualService, which describes traffic routing sent over a Gateway and sends it to Kubernetes Services, as it’s described in the [Destination rules](https://istio.io/latest/docs/concepts/traffic-management/#destination-rules).

Ingress Gateway consists of two parts: a Kubernetes Pod with Envoy instance which controls traffic, and a Kubernetes Ingress, which accepts new connections.

In its turn Gateway and VirtualService configures Envoy proxy instance used as the Ingress Gateway controller.

So, in general, traffic flow is the following:

1. a packet is coming to an external Load Balancer and then sent to a Kubernetes WorkerNode TCP port
2. there the packet is sent to the Istio IngressGateway Service
3. and is redirected to the Istio IngressGateway Pod
4. an Envoy instance on this Pod is configured with Gateway and VirtualService
5. a Gateway describes ports, protocols, SSL certificates
6. VirtualService describes traffic routing to a Kubernetes Service of our application
7. Istio IngressGateway Pod sends this packet to the application’s Service
8. and the Service routes the packet to an application’s Pod

Read more:

- [Understanding Istio Ingress Gateway in Kubernetes](https://blog.jayway.com/2018/10/22/understanding-istio-ingress-gateway-in-kubernetes/)
- [Traffic Management](https://istio.io/latest/docs/concepts/traffic-management) и [Traffic Management](https://istio.io/latest/docs/reference/config/networking/)

### Running Istio in Kubernetes

Istio supports different [Deployment models](https://istio.io/latest/docs/ops/deployment/deployment-models/). In this current case, we are using one AWS Elastic Kubernetes Service cluster, and all pods are running in the same VPC network.

Also, there are different [Config Profiles](https://istio.io/latest/docs/setup/additional-setup/config-profiles/) which has pre-configured components set to be installed. Here, we can be interested in the _default_ — install `istiod` and `istio-ingressgateway`, _demo_ - similar, but also will install the `istio-egressgateway` service, and _preview_ - to investigate new abilities that are not yet included in the main Istion release.

You can install Istio in various ways: using the `istioctl` utility and by using manifest files, using Helm, or with Ansible.

Worth paying attention to the Mutual TLS (mTLS) — see the [Permissive mode](https://istio.io/latest/docs/concepts/security/#mutual-tls-authentication). In short: by default, Istion is installed in the Permissive mTLS mode, which allows existing applications to communicate using plaintext traffic. But all new connections via Envoy proxies will be made with TLS encryption.

For now, let’s install Istio manually with `istioctl`, and later on the Dev and Production clusters will install with Ansible and its [`helm`](https://docs.ansible.com/ansible/latest/collections/community/kubernetes/helm_module.html) module.

Read more:

- [Install with Istioctl](https://istio.io/latest/docs/setup/install/istioctl/)
- [Installation Guides](https://istio.io/latest/docs/setup/install/).

Download Istio:

```
$ curl -L [https://istio.io/downloadIstio](https://istio.io/downloadIstio) | sh -
$ cd istio-1.9.1/
```

[`istioctl`](https://istio.io/latest/docs/reference/commands/istioctl/) uses the `~/.kube/config` file or you can specify your own by using the `--kubeconfig` option, or set another context with `--context`.

The [`istioctl`](https://istio.io/latest/docs/reference/commands/istioctl/) file located in the `bin` directory - add it to the $PATH variable (Linux/macOS:

```
$ export PATH=$PWD/bin:$PATH
```

Check if it’s working:

```
$ istioctl version
no running Istio pods in “istio-system”
1.9.1
```

Generate a kubeconfig for the testing cluster, if need (if using Minicube, it will be generated automatically):

```
$ aws eks update-kubeconfig --name bttrm-eks-test-1–18 --alias iam-bttrm-eks-root-role-kubectl@bttrm-eks-test-1–18
Added new context iam-bttrm-eks-root-role-kubectl@bttrm-eks-test-1–18 to /home/setevoy/.kube/config
```

And install Istio with the _default _profile:

```
$ istioctl install — set profile=default -y
✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete
```

Check versions again:

```
$ istioctl version
client version: 1.9.1
control plane version: 1.9.1
data plane version: 1.9.1 (1 proxies)
```

And Istio pods:

```
$ kubectl -n istio-system get pod
NAME READY STATUS RESTARTS AGE
istio-ingressgateway-d45fb4b48-jsz9z 1/1 Running 0 64s
istiod-7475457497–6xskm 1/1 Running 0 77s
```

Now, let’s deploy a test application and will configure routing via Istio Ingress Gateway.

#### Running test application

We will not use the default Bookinfo from the [Istio Gettings Started](https://istio.io/latest/docs/setup/getting-started/#bookinfo) guide, instead let’s define our own Namespace, a Deployment with one pod with NGINX, and a Service — I’d like to emulate already existing applications that need to be migrated under Istio control.

Also, at this moment we will not configure automated sidecars injection — will go back to this later.

A manifest looks like the following:

```
---
apiVersion: v1
kind: Namespace
metadata:
  name: test-namespace
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deployment
  namespace: test-namespace
  labels:
    app: test
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
        version: v1
    spec:
      containers:
      - name: web
        image: nginx
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        readinessProbe:
          httpGet:
            path: /
            port: 80
      nodeSelector:
        role: common-workers
---
apiVersion: v1
kind: Service
metadata:
  name: test-svc
  namespace: test-namespace
spec:
  selector:
    app: test
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
```

It’s recommended to use the `version` label in applications, as later this will allow implementing canary and blue-green deployment, see the [How To Do Canary Deployments With Istio and Kubernetes](https://www.digitalocean.com/community/tutorials/how-to-do-canary-deployments-with-istio-and-kubernetes) и [Traffic Management](https://istio.io/latest/docs/concepts/traffic-management/).

Deploy it:

```
$ kubectl apply -f test-istio.yaml
namespace/test-namespace created
deployment.apps/test-deployment created
service/test-svc created
```

Check containers in the pod that we created:

```
$ kubectl -n tkk -n test-namespace get pod -o jsonpath={.items[*].spec.containers[*].name}
web
```

Okay, one pod as it was described in the Deployment above.

Using `kubectl port-forward` connect to the Service:

```
$ kubectl -n test-namespace port-forward services/test-svc 8080:80
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
```

And check if our application is working:

```
$ curl localhost:8080
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
…
```

Nice — here is everything working.

#### Istio Ingress Gateway

So, at this moment we have an Istio Ingress Gateway created during Istio installation, which is represented by an AWS Classic LoadBalancer:

![](https://cdn-images-1.medium.com/max/924/0*Nu5xolc3HsWGjteY.png)

But if try to access it right now, we will get an error as it has no idea where to route traffic to:

```
$ curl a6f***037.eu-west-3.elb.amazonaws.com
curl: (52) Empty reply from server
```

To configure it — need to add an Istio Gateway.

#### Gateway

The [Gateway](https://istio.io/latest/docs/reference/config/networking/gateway/) describes [Istio Ingress Gateway](https://istio.io/latest/docs/tasks/traffic-management/ingress/ingress-control/) config — which ports to use and which traffic to accept. Also, here you can perform SSL termination (but in this case, this is done by an AWS LoadBalancer).

Add a new resource to our `test-istio.yaml` - the Gateway:

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

In the `spec.selector.istio` we are specifying the Istio Ingress Gateway, for which this manifest will be applied to.

Pay attention, that our application is living in a dedicated namespace, so Gateway and VirtualService (see below) need to be created in the same Namespace.

Create the Gateway:

```
$ kubectl apply -f test-istio.yaml
namespace/test-namespace unchanged
deployment.apps/test-deployment unchanged
service/test-svc unchanged
gateway.networking.istio.io/test-gateway created
```

Check it:

```
$ kubectl -n test-namespace get gateways
NAME AGE
test-gateway 17s
```

#### VirtualService

Next, we are going to add a [VirtualService](https://istio.io/latest/docs/reference/config/networking/virtual-service/) where we will describe our “backend” where traffic will be sent.

As a “backend” here is just a common Kubernetes Service of our application — the _test-svc_:

```
$ kubectl -n test-namespace get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
test-svc NodePort 172.20.195.107 <none> 80:31581/TCP 15h
```

Describe a VirtualService in the same namespace where our application and where we’ve created the Gateway above:

```
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: test-virtualservice
  namespace: test-namespace
spec:
  hosts:
  - "*"
  gateways:
  - test-gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: test-svc
        port:
          number: 80
```

Create it:

```
$ kubectl apply -f test-istio.yaml
namespace/test-namespace unchanged
deployment.apps/test-deployment unchanged
service/test-svc unchanged
gateway.networking.istio.io/test-gateway unchanged
virtualservice.networking.istio.io/test-virtualservice created
```

Check:

```
$ kubectl -n test-namespace get virtualservice
NAME GATEWAYS HOSTS AGE
test-virtualservice [test-gateway] [*] 42s
```

And check again the URL of the LoadBalancer of the Istio Ingress Gateway:

```
$ curl a6f***037.eu-west-3.elb.amazonaws.com
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
…
```

And still, we are working without Envoy proxy aka sidecar in our application’s Pod:

```
$ kubectl -n tkk -n test-namespace get pod -o jsonpath={.items[*].spec.containers[*].name}
web
```

Will check a bit later why this is working.

### Kiali — traffic observation

Istio has a lot of addons: [Prometheus](https://prometheus.io/) for metrics collection and alerting, [Grafana](https://grafana.com/) for metrics visualization, [Jaeger](https://www.jaegertracing.io/) for requests tracing, and [Kiali](https://kiali.io/) to build a map of network and services. Read more at [Integrations](https://istio.io/latest/docs/ops/integrations/).

Install all addons:

```
$ kubectl apply -f samples/addons
```

And execute `istioctl dashboard kiali` - Kiali will be opened in a default browser:

![](https://cdn-images-1.medium.com/max/1024/0*y_ITCge-RzbvBTd3.png)

But, if navigate to the _Applications_, we will see that our application marked as “_Missing Sidecar_”:

![](https://cdn-images-1.medium.com/max/1024/0*2REy6QhctKVrWqQQ.png)

And no services map the _Graph_:

![](https://cdn-images-1.medium.com/max/1024/0*tsY0LN2VapIOvr0z.png)

### Sidecar — Envoy proxy

As we remember, our pod has no container with Envoy instance although the network is working, because at this moment Istio via iptables rules sends traffic directly to the container with NGINX. Read more at [Traffic flow from application container to sidecar proxy](https://istio.io/latest/blog/2019/data-plane-setup/#traffic-flow-from-application-container-to-sidecar-proxy).

Iptalbes rules are configured with an additional InitContainer  —  `istio-init` - when a pod is started, but at this moment they are default, configured with kube-proxy during our application deployment. Check the [Kubernetes: Service, load balancing, kube-proxy, and iptables](https://rtfm.co.ua/en/kubernetes-service-load-balancing-kube-proxy-and-iptables/) post for more details.

In the following post we will dive deeper into the Istio networking, and for now, let’s just add sidecars injection to our Namespace’s Pods and compare Iptables rules before and after.

#### Istio and iptables

Go to check Iptables rules before we will add a sidecar and istio-init.

Connect via SSH to a Kubernetes WorkerNode where your Pod is living and find NGINX Docker container:

```
[root@ip-10–22–35–66 ec2-user]# docker ps | grep nginx
22d64b132490 nginx “/docker-entrypoint.…” 3 minutes ago Up 3 minutes k8s_web_test-deployment-6864c5bf84-mk98r_test-namespace_8b88caf0–237a-4c94-ac71–186f8e701a7c_0
```

Find a PID of the process in this container:

```
[root@ip-10–22–35–66 ec2-user]# docker top k8s_web_test-deployment-6864c5bf84-mk98r_test-namespace_8b88caf0–237a-4c94-ac71–186f8e701a7c_0
UID PID PPID C STIME TTY TIME CMD
root 31548 31517 0 10:36 ? 00:00:00 nginx: master process nginx -g daemon off;
101 31591 31548 0 10:36 ? 00:00:00 nginx: worker process
```

Using the [`nsenter`](https://man7.org/linux/man-pages/man1/nsenter.1.html) utility check Ipables rules on the network-namespace of the process with PID 31548 - nothing unusual here, for now - all traffic is just sent directly to our container:

```
[root@ip-10–22–35–66 ec2-user]# nsenter -t 31548 -n iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
```

#### Running Sidecar

Documentation — [Installing the Sidecar](https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/).

To automatically inject Envoy proxy instances to pods in the _test-namespace_ namespace run the following:

```
$ kubectl label namespace test-namespace istio-injection=enabled
namespace/test-namespace labeled
```

Check the labels:

```
$ kubectl get namespace test-namespace — show-labels
NAME STATUS AGE LABELS
test-namespace Active 11m istio-injection=enabled
```

But sidecars will be added only for new pods in this namespace.

We can add them manually by using the [`kube-inject`](https://istio.io/latest/docs/reference/commands/istioctl/#istioctl-kube-inject), or just by recreating the pod:

```
$ kubectl -n test-namespace scale deployment test-deployment — replicas=0
deployment.apps/test-deployment scaled
kubectl -n test-namespace scale deployment test-deployment — replicas=1
deployment.apps/test-deployment scaled
```

Check containers in the Pod again:

```
$ kubectl -n test-namespace get pod -o jsonpath={.items[*].spec.containers[*].name}
web istio-proxy
```

Now we can see the `istio-proxy` container - this is pour sidecar container with Envoy.

Also, check initContainers of the Pod:

```
$ kubectl -n test-namespace get pod -o jsonpath={.items[*].spec.initContainers[*].name}
istio-init
```

And check Iptables rules again — find the container, its PID, and check the rules:

```
[root@ip-10–22–35–66 ec2-user]# nsenter -t 4194 -n iptables -t nat -L

Chain PREROUTING (policy ACCEPT)
target prot opt source destination
ISTIO_INBOUND tcp — anywhere anywhere

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ISTIO_OUTPUT tcp — anywhere anywhere

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination

Chain ISTIO_INBOUND (1 references)
target prot opt source destination
RETURN tcp — anywhere anywhere tcp dpt:15008
RETURN tcp — anywhere anywhere tcp dpt:ssh
RETURN tcp — anywhere anywhere tcp dpt:15090
RETURN tcp — anywhere anywhere tcp dpt:15021
RETURN tcp — anywhere anywhere tcp dpt:15020
ISTIO_IN_REDIRECT tcp — anywhere anywhere

Chain ISTIO_IN_REDIRECT (3 references)
target prot opt source destination
REDIRECT tcp — anywhere anywhere redir ports 15006

Chain ISTIO_OUTPUT (1 references)
target prot opt source destination
RETURN all — ip-127–0–0–6.eu-west-3.compute.internal anywhere
ISTIO_IN_REDIRECT all — anywhere !localhost owner UID match 1337
RETURN all — anywhere anywhere ! owner UID match 1337
RETURN all — anywhere anywhere owner UID match 1337
ISTIO_IN_REDIRECT all — anywhere !localhost owner GID match 1337
RETURN all — anywhere anywhere ! owner GID match 1337
RETURN all — anywhere anywhere owner GID match 1337
RETURN all — anywhere localhost
ISTIO_REDIRECT all — anywhere anywhere

Chain ISTIO_REDIRECT (1 references)
target prot opt source destination
REDIRECT tcp — anywhere anywhere redir ports 15001
```

Now we can see additional Iptables chains and rules created by Isio, which sends traffic to the Envoy sidecar container and then to the application’s container and back.

Go back to the Kiali dashboard and check the map:

![](https://cdn-images-1.medium.com/max/1024/0*4JBCCOorL-kphoH_.png)

And requests tracing:

![](https://cdn-images-1.medium.com/max/1024/0*i5i696TKHDMKSlkv.png)

Traces are also available via the Jaeger dashboard which can be accessed with `istioctl dashboard jaeger`:

![](https://cdn-images-1.medium.com/max/1024/0*XfsmoxnncQ1FxiTV.png)

Also, with `istioctl dashboard prometheus` you can open Prometheus and check available metrics, see more at [Querying Metrics from Prometheus](https://istio.io/latest/docs/tasks/observability/metrics/querying-metrics/):

![](https://cdn-images-1.medium.com/max/1024/0*LaXZ7765tgLJJsqt.png)

Actually, that’s all for now.

Later, we will integrate Istio with AWS Application LoadBalncer, deploy and configuration of an Isitio instance to the AWS Elastic Kubernetes Service with Ansible and Helm, Gateway, and VirtualServices configuration and debugging.

### Useful links

- [Learn Istio using Interactive Browser-Based Scenarios](https://www.katacoda.com/courses/istio) — basic course on Katacoda
- [Istio Service Mesh Workshop](https://www.istioworkshop.io/) — Istio overview
- [Service Mesh with Istio](https://www.eksworkshop.com/advanced/310_servicemesh_with_istio/) — one more workshop, from AWS EKS
- [How Istio Works Behind the Scenes on Kubernetes](https://betterprogramming.pub/how-istio-works-behind-the-scenes-on-kubernetes-aeb8003f2cb5) — architecture, components
- [Debugging Envoy and Istiod](https://istio.io/latest/docs/ops/diagnostic-tools/proxy-cmd/) — debugging Istio with istioctl
- [Starting with Istio](https://medium.com/ww-engineering/starting-with-istio-610421f5a815), see also [Istio, Part II](https://medium.com/ww-engineering/istio-part-ii-e219a2e771bb) и [Istio, Part III, why use it?](https://medium.com/ww-engineering/istio-iii-why-use-it-2ba2500cceda) — overview, architecture, network in Istio
- [North-South Traffic Management of Istio Gateways (with Answers from Service Mesh Experts)](https://www.alibabacloud.com/blog/north-south-traffic-management-of-istio-gateways-with-answers-from-service-mesh-experts_596658) — network in Istio
- [A Crash Course For Running Istio](https://medium.com/namely-labs/a-crash-course-for-running-istio-1c6125930715) — Istio, Envoy, iptables, components in Istio, very nice post
- [How to Make Istio Work with Your Apps](https://www.stackrox.com/post/2019/11/how-to-make-istio-work-with-your-apps/) — troubleshooting and proxy-status examples
- [Reducing Istio proxy resource consumption with outbound traffic restrictions](https://banzaicloud.com/blog/istio-sidecar/) — resources in Istio and sidecars tuning
- [Life of a Packet through Istio](https://www.infoq.com/presentations/life-packet-istio/) — seems to be not a bad networking overview in Istio, but I didn’t watch the video
- [Sidecar injection and transparent traffic hijacking process in Istio explained in detail](https://jimmysong.io/en/blog/sidecar-injection-iptables-and-traffic-routing/) — sidecars, iptables, and routing
- [An in-depth intro to Istio Ingress](https://banzaicloud.com/blog/backyards-ingress/) — Ingress, Gateway, and VirtualService, examples
- [Understanding Istio Ingress Gateway in Kubernetes](https://blog.jayway.com/2018/10/22/understanding-istio-ingress-gateway-in-kubernetes/) — the same as above
- [Istio Gateway](https://freecontent.manning.com/istio-gateway/) — the same as above
- [Getting started with Istio](https://rinormaloku.com/getting-started-istio/) and next parts — [Istio in Practice — Ingress Gateway](https://rinormaloku.com/istio-practice-gateways/), [Istio in Practice — Routing with VirtualService](https://rinormaloku.com/istio-practice-routing-virtualservices/)
- [4 Istio Gateway: getting traffic into your cluster](https://livebook.manning.com/book/istio-in-action/chapter-4/v-5/50) — again about Gateway and VirtualService

_Originally published at_ [_RTFM: Linux, DevOps и системное администрирование_](https://rtfm.co.ua/en/istio-an-overview-and-running-service-mesh-in-kubernetes/)_._

* * *