{"componentChunkName":"component---src-pages-markdown-remark-fields-slug-js","path":"/engineering/istio-installation-and-service-configuration/","result":{"data":{"markdownRemark":{"id":"ff673742-abcd-5886-b3fa-acb74541fbd9","excerpt":"An infrastructure layer that allows you to manage communication between the microservices of your application is a service mesh. As more developers work with…","html":"

An infrastructure layer that allows you to manage communication between the microservices of your application is a service mesh. As more developers work with microservices, by consolidating common management and administrative tasks in a distributed setup, service meshes have developed to make the job easier and more effective.

\n

To know more about Istio, you can read this article on Istio service mesh to understand the basic terminology, In this tutorial, will explain how to install and configure Istio. Let's get started.

\n

Installing Istio

\n

Get the latest Istio release:

\n
curl -L https://istio.io/downloadIstio | sh -
\n

Extract the archive and export the bin directory in the environment path.

\n

This will also install istioctl, a command-line tool to manage Istio service mesh.

\n

Configuration Profiles

\n

Istio provides various built-in configuration profiles, a set of pre-defined configs related to data and control plane. We can customize the configs according to our needs.

\n

For testing locally or trying it ou, you can use a demo profile. For dev and other environments, we will be using the default configuration profile.

\n
istioctl install --set profile=demo
\n

Customizing configs

\n

Run:

\n
istioctl profile dump default
\n

to see the various configurations. We can change those flag using istioctl commands and --set flag.

\n

For development purpose, we can enabled/changes following flags:

\n
istioctl install --set addonComponents.kiali.enabled=true \\ \n--set components.telemetry.enabled=true \\ \n--set components.citadel.enabled=true \\ \n--set values.global.proxy.privileged=true \\ \n--set addonComponents.tracing.enabled=true \\ \n--set values.pilot.traceSampling=100.0 \\ \n--set values.global.proxy.tracer=datadog
\n

The path value of --set flag is the YAML path, which you can see in the profile dump command.

\n
\n

While changing any config, make sure to pass all the previous flags with the new ones. For example, if first time, you enabled istioctl install --set addonComponents.kiali.enabled=true and now let’s say, you want to enable citadel, then you have to pass both flags like this: istioctl install --set addonComponents.kiali.enabled=true --set components.telemetry.enabled=true.\nFailing to add any previously enabled variable will revert the config to its default values.\nOne way to store the dump in a file and do istioctl apply or use helm charts for Istio.

\n
\n

Sidecar injection

\n

For Istio to work properly, a sidecar Envoy proxy needs to be enabled for the services. By default, the Istio control plane will not enable any sidecar to any services. To enable sidecar, we have to add labels at the namespace level.

\n
kubectl label namespace dsl-test istio-injection=enabled
\n

You need to have this label even if you do not want to add a sidecar to all your services.

\n

You need to restart the pods.

\n

For services, which do not require sidecar, we need to add the following annotation in the deployment template:

\n
# Pod Annotations \npodAnnotations: \n\tsidecar.istio.io/inject: "false"
\n

Configuring Services

\n

For demonstration, we will take two demo services demo-1 and demo-2, and configure both services with Istio, and will try to call demo-2 service from demo-1. Make sure there is an env variable in demo-1, which we will configure with demo-2 internal DNS url. The programming language for the two services does not matter here.

\n

A service configuration requires a VirtualService, DestinationRule, PeerAuthentication, and optionally a Gateway configuration.

\n

Gateway

\n
apiVersion: networking.istio.io/v1alpha3 \nkind: Gateway \nmetadata: \n\tname: demo-1\nspec: \n\tselector: \n\t\tistio: ingressgateway \n\tservers: \n\t- port: \n\t\tnumber: 80 \n\t\tname: http \n\t\tprotocol: HTTP \n\t- hosts: \n\t\t- "demo-1.example.com"
\n

Gateway is used when we want to access the services from the public network.

\n

Here we are using the default gateway provided by the Istio. We can also create multiple gateways and assign the proper name here.

\n

The above gateway configuration enables both HTTP and HTTPS communication. In the case of HTTPS, we have to supply the secret containing the CA certs and key.

\n
spec:\n\tservers: \n\t- port: \n\t\tnumber: 443\n\t\tname: http \n\t\tprotocol: HTTP\n\t  tls: \n\t\tmode: SIMPLE \n\t\tcredentialName: div4-dev-certs\n\t  hosts: \n\t\t- "demo-1.example.com"
\n

We can apply the same gateway for demo-2. We just have to update the hosts and metadata name. Since we will demo-2 internally from demo-1, there is no need for an external gateway for demo-2 here.

\n

VirtualServices

\n
---\napiVersion: networking.istio.io/v1alpha3\nkind: VirtualService\nmetadata:\n  name: demo-1\nspec:\n  hosts:\n  - "demo-1.test.svc.cluster.local"\n  - "demo-1.example.com"\n  gateways:\n    - demo-1\n  http:\n  - route:\n    - destination:\n        host: demo-1.test.svc.cluster.local\n        port:\n          number: 80
\n

spec.hosts: Specifies the URL which the caller of the service will use. Here, dsl-es.pbdp.svc.cluster.local will be used by the services calling internally. The endpoint demo-1.example.com will be exposed publicly, and it should match the spec.servers.hosts value in Gateway config.

\n

spec.gateways: In order for the gateways configured above to reach the service, we need to define the gateway metadata name here.

\n

http.route.destination.host: This value should be the actual service FQDN.

\n

DestinationRule

\n

After the virtualservice decides the destination hosts, DestinationRule defines the configuration on the actual service. DestinationRule is optional and is needed only in case we want to override the default behavior.

\n
---\napiVersion: networking.istio.io/v1alpha3\nkind: DestinationRule\nmetadata:\n  name: demo-1\nspec:\n  host: "demo-1.test.svc.cluster.local"\n  trafficPolicy:\n    loadBalancer:\n      simple: ROUND_ROBIN\n    tls:\n      mode: ISTIO_MUTUAL
\n

spec.host: specifies service FQDN

\n

spec.trafficPolicy: Specifies policy on the traffic. Here we can specify load balancing algorithms, TLS mode, circuit breaking policies.

\n

spec.trafficPolicy.tls.mode: ISTIO_MUTUAL mode is a TLS mode where we will use the certificates generated by the Istio.

\n

A configuration like circuit breakers, outlier detection comes under the Destination Rule.

\n

PeerAuthentication

\n

This configuration defines how the other services will connect.

\n
---\napiVersion: security.istio.io/v1beta1\nkind: PeerAuthentication\nmetadata:\n  name: demo-1\nspec:\n  selector:\n    matchLabels:\n      app: demo-1\n  mtls:\n    mode: STRICT
\n

spec.selector.matchLabels.app: Specify the deployment label on which this configuration will be applied.

\n

spec.mtls.mode: TLS mode. STRICT being the connection will always be mutual tls.

\n

PeerAuthentication can be applied to a whole namespace. This is useful when all the services in the namespace are part of the mesh.

\n
\n

Apply the same configuration for virutalservice, destination, and peerauthentication by replacing demo-1 with demo-2 assuming both services are in the same namespace.

\n
\n
kubectl apply -f <file>.yaml -n test
\n

Access the objects:

\n
kubectl get virtualservices -n pbdp\nkubectl get gateways -n pbdp\nkubectl get destinationrule -n pbdp\nkubectl get peerauthentication -n pbdp
\n

Now update the env for demo-2 with demo-2.test.svc.cluster.local in demo-1 service.

\n","headings":[{"value":"Installing Istio","depth":2},{"value":"Configuration Profiles","depth":3},{"value":"Customizing configs","depth":3},{"value":"Sidecar injection","depth":3},{"value":"Configuring Services","depth":2},{"value":"Gateway","depth":3},{"value":"VirtualServices","depth":3},{"value":"DestinationRule","depth":3},{"value":"PeerAuthentication","depth":3}],"fields":{"slug":"/engineering/istio-installation-and-service-configuration/"},"frontmatter":{"metatitle":null,"metadescription":null,"description":"This article will provide a step by step process on how to install and configure services using Istio.","title":"How to Install and Configure Istio","canonical":null,"date":"January 22, 2021","updated_date":null,"tags":["Istio","Service Mesh"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/452f4d9f7cb358e3d6224ed3aba3d5d6/03979/Istio.png","srcSet":"/static/452f4d9f7cb358e3d6224ed3aba3d5d6/f5f11/Istio.png 200w,\n/static/452f4d9f7cb358e3d6224ed3aba3d5d6/6d133/Istio.png 400w,\n/static/452f4d9f7cb358e3d6224ed3aba3d5d6/03979/Istio.png 800w,\n/static/452f4d9f7cb358e3d6224ed3aba3d5d6/0d359/Istio.png 900w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Piyush Kumar","github":"kpiyush17","bio":"Software Engineer","avatar":null}}}},"pageContext":{"id":"ff673742-abcd-5886-b3fa-acb74541fbd9","fields__slug":"/engineering/istio-installation-and-service-configuration/","__params":{"fields__slug":"engineering"}}},"staticQueryHashes":["1171199041","1384082988","1711371485","1753898100","2100481360","229320306","23180105","528864852"]}