istio-project

The project centers around the implementation of Istio to enhance the advantages of a microservices architecture.

Setup EKS Cluster

Install Istio

Install istiod

Installation of Istiod consist of combination of pilot, citadel and gallery. Ensure to update meshconfig in the istiod.yaml to allow easy installation of cert-manager so as to be able to resolve http01 challenge from lets encrypt

Confirm if Istiod pod is running

Now that Istio is deployed properly we can start managing traffic in the cluster using the istio control plane.

We need to ensure istio inject sidecars to all pods which enhance and control communication betweeen micro services. This injection allows Istio to provide features such as traffic management, security, observability, and policy enforcement consistently across all microservices in the cluster

Ensuring istio is deployed in all pod in a namespace, in order for istio to manage traffic, each service must have an istio sidecar

We have two deployments to simulate canary with each one having label version "v1" and "v2" respectively and label "app:first-app", which is used by service as the label selector and this will randomly route traffic between v1 and v2

To handle managing and shifting traffic, we make use of some istio custom resources

DestinationRule:

Lets you define how you want to route your traffic using subsets and specifying appropriate labels and the service

Virtualservice:

Lets you define how you want to route traffic to different versions using http or https

The screenshot above just show all traffic will go the v1 version. Lets run the app-01 folder to deploy the application and explore how the traffic is covered. To test, we used a client inside kubernetes which also has a sidecar

Lets exec into the client and use curl to hit our first app service in the staging namespace. From the screenshot, we can see that we are only connecting the v1 application.

Now lets edit the virtual service to ensure traffic goes to v1 and v2 equally

Same with if we want all traffic to move to v2 only

Istio Ingress Gateway:

We will expose application running in Kubernetes to the internet using istio ingress gateway. Install using helm

Now let's deploy another application to the production namespace making use of DNS name to access it. We will have to work on virtualservice, gateway respectively and lastly, cert-manager to secure application with TLS certificate

In case you do not have a domain to test with, you can use the host header format in the screenshot below

We can update our domain name (if you own one) with the load balancer in Route53 records

Cert-Manager

We will install cert-manager and use letsencrypt to automatically obtain TLS certificates and secure our API

To automatically obtain TLS certificate from Letsencrypt we need to creat a cluster issuer. Ensure you specify the ingress class to use solve http01 challenge

When you create these certificate, the cert-manager will obtain a certificate from letsencrypt and store it in kubernetes secret. The certificate is valid for 90 days and the cert-manager will automatically renew and update the secret

Ensure the certificate is deployed in istio-ingress namespace where you have the gateway pod

Now to secure the API, we need to update the gateway file with port 443 and use https protocol and also specify the secret name that was created by the certificate resource

Now let's apply the gateway file and confirm if the certificate has been issued

Now lets deploy prometheus and grafana for monitoring and visualization.

To monitor istio, let's create a pod monitor and use istio sidecar labels. To create a podmonitor prometheus object we need a named pod http-envoy-prom and also select the pods based on the label such as ìstio:monitor. Based on this two we can start monitoring istio service mesh

Now lets monitor ingress gateway also

In this case, we have a port but the name is missing so we cannot use podmonitor since we need a named port, instead we can create a service and a service monitor to target this port.

Lets define a kubernetes service that only uses prometheus port 15090 and give it a name metrics. Now lets create a servicemonitor and use the endpoint and the metrics port name

Now we can create a servicemonitor and use the endpoint and metrics port name, this is a useful workaround when we dont have a port name and not able to add to it but still want to monitor the application with prometheus.

Now lets connect to grafana

Use Istio workload dashboard

Lets Deploy Kiali to visualize the service topology inside Kubernetes