Istio introduction on the Kubernetes
Istio is a service mesh that allows service mesh to extend on various platforms.
This allows service mesh to extend outside the standard service mesh we use on the Kubernetes. Istio introduces Virtualservice as an abstraction over existing services. It is intentionally mentioned so that it is not confused with the Kubernetes service.
Istio uses an envoy proxy as a sidecar container to implement service mesh.
Istio
Istio has many features. In this article, the focus will be on the service mesh and traffic management. To enable this Istio introduces the next concepts:
- Virtualservice
- Destination rules
- Ingress gateway
- Egress gateway
Virtualservice
Virtual services and destination rules are the key building blocks of Istio’s traffic routing functionality.
They let you define how traffic is routed to the services within the service mesh.
Virtual service lets you manage traffic based on the following parameters:
- Host
- The specific version of the service itself
- Different parameters like Header value
Also, it is possible to:
- Handle incoming traffic to the cluster via Ingress gateway (Instead of ingress controller)
- Handle traffic only inside the Kubernetes cluster
Destination rules
You can think of virtual services as how you route your traffic to a given destination, and then you use destination rules to configure what happens to traffic for that destination.
You use destination rules to specify named service subsets, such as grouping all a given service’s instances by version. You can then use these service subsets in the routing rules of virtual services to control the traffic to different instances of your services.
Ingress gateway
Ingress gateway exposes service mesh to the outside world. On the Kubernetes, it acts as an ingress controller since it uses an Ingress gateway from the Kubernetes.
Egress gateway
The Egress gateway is an outgoing point of the service mesh. It can be used to enforce policy for outgoing connections.
Example setup
Deploying istio
Istio already gives an example of a book review web. It consists of different microservices as a part of their tutorial.
We will assume the Kubernetes cluster is clear and ready to use. In this article, K3s is used. There are many articles about k3s on the qdnqn.
First, we need to install Istio and all add-ons.
helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update
kubectl create namespace istio-system
helm install istio-base istio/base -n istio-system
helm install istio istio/istio -n istio-system
helm install istio-ingress istio/gateway -n istio-ingress
After this Istio service mesh is ready to be configured.
Deploying services
You can follow the tutorial directly on the link:
Istio will inject a sidecar container in all namespaces labeled as below.
kubectl label namespace default istio-injection=enabled
To deploy the book info application apply resources from the official Istio repository.
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.21/samples/bookinfo/platform/kube/bookinfo.yaml
Configuring VirtualService
Using the example given in the book info we can configure VirtualService in the next way:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: bookinfo-gateway
namespace: default
spec:
# The selector matches the ingress gateway pod labels.
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "istio.k3s.local"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo
namespace: default
spec:
hosts:
- "istio.k3s.local"
gateways:
- bookinfo-gateway
http:
- match:
- uri:
exact: /productpage
- uri:
prefix: /static
- uri:
exact: /login
- uri:
exact: /logout
- uri:
prefix: /api/v1/products
route:
- destination:
host: productpage
port:
number: 9080
We need to point istio.k3s.local
to the local IP of the local machine. Afterwards accessing the http://istio.k3s.local/
will resolve the book review front page.
How does Kubernetes service coexist with VirtualService?
As seen in the picture, both the Kubernetes service and VirtualService can coexist.
Traffic still can flow using service FQDN to get to the pod. On the other hand, the virtual channel is open for the mesh traffic. Traffic designated to the VirtualService will leave through the sidecar container and hit the sidecar container where VirtualService points.
That is valid fact if we assume the next scenario:
- Service 1:
service1.ns1.svc.cluster.local
- Service 2:
service2.ns2.svc.cluster.local
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: KubernetesInternalMeshVirtualService
namespace: default
spec:
hosts:
- "service2.ns2.svc.cluster.local"
- "service2.ns2"
http:
- route:
- destination:
host: service2.ns2
port:
number: 8080
VirtualService uses Kubernetes FQDN to solve endpoints but traffic is flowing through the mesh now. Now when the container from Pod 1 tries to reach service2.ns2
it will go through the mesh instead of the Kubernetes service.
What happens is that Istio will control the traffic, apply all rules, and policies, if defined on the VirtualService, then route the traffic to the Pod 2 via sidecar containers.
This way mesh will resolve internal Kubernetes services FQDN and route the traffic via mesh.
To confirm this behavior one can implement some delay on the VirtualService and send a request from Pod 1 to Pod 2.
What is the point of the service mesh?
Mesh also can be extended to be:
- Multi cluster aware
- Bare-metal/VM aware
So that requests can go out of the cluster and vice versa. This way we can create a logical group of services under one umbrella. It makes sense to create a service mesh when services are dispersed over various clusters and virtual machines.
Another great benefit is that you have complete control over the network with policies implemented on the VirtualService.
Istio ingress and egress concepts allows full control of in-and-out control of the traffic entering or leaving the mesh.
It is a fully featured product for service mesh with all the tools you need to manage networking on a scale. It is only intended to be used with Kubernetes as the main platform where support for the bare-metal/virtual machines is given as an option.
Do you need a reliable freelancer to take your project back on track?
I am ready to deliver!