Istio Service Mesh, the Step-by-Step Guide, Part 2: Tutorial

Welcome back! If you missed Part 1, you can check it out here. 

Getting Started With Istio

Installing Istio on the Minikube Platform

The best way to test Istio locally on Istio Kubernetes is through Istio Minikube. Microservices with Kubernetes service mesh and Docker should be used. To install Istio on Minikube, you would have to enable the following plugins at startup.

Minikube start setup—extra-config-device-controller-lokalcube.setup.rg

Minikube startup setup—extra-config- clustersign.

• After running Minikube, enable Docker on Minikube’s VM. This will help you in compiling and running commands on the Docker platform. Send a call function for the service mesh by specifying the token, delimiter, and Minikube Docker image.

 

@FOR /f “tokens=* //[The star sign reflects that all tokens will be loaded at the run time]

 

 

delimiter=^K” %[CallName] IN ([DockerSource]) DO @call %[CallName] //[At the callname, the new window will be opened with delimiter K and all the tokens].

 

• Next, install Istio and all its core components through Minikube to enter the plugin and add-on commands after entering the YAML code.

kubectl apply -f install/kubernetes/istio.yaml 

Istio’s Core Components

• Envoy
  • Envoy is an open source extension and service proxy provider, built for cloud-extensive meshes. The Istio mesh creates an extendible proxy system through Envoy.
• Mixer
  • The mixer is a part of the service mesh that helps in enforcing safety protocols, allowing access controls and implementing usage policies and works independently from the mesh.
• Pilot
  • Pilot provides all the services for the Istio Envoy sidecars and allows for a more coherent traffic management system with high-level routing.

On checking the configuration files inside the istio.yaml deployments, you’ll find some pods and services which can be activated using the kubectl command on the Minikube command central.

Building Sample Applications

Before configuring any traffic rules with Istio, sample applications have to be created to communicate with each other. There are two services available: caller-service and callme-service.

Both of them expose an endpoint ping which lists the application’s name and version. The following is the implementation of the endpoint GET /callme/ping.

 

@RestController

 

 

@RequestMapping(“/callme”)

 

 

public class CallmeController {

 

private static final Logger LOGGER = LoggerFactory.getLogger(CallmeController.class);

 

@Autowired

 

BuildProperties buildProperties;

 

@GetMapping(“/ping”)

 

public String ping() {

 

LOGGER.info(“Ping: name={}, version={}”, buildProperties.getName(), buildProperties.getVersion());

 

return buildProperties.getName() + “:” + buildProperties.getVersion();

 

}

 

}

 

Below is the code that calls the GET /callme/ping endpoint using Spring RestTemplate. This output will be exposed inside the Minikube node under Port 8091.

 

@RestController

 

@RequestMapping(“/caller”)

 

 

public class CallerController {

 

private static final Logger LOGGER = LoggerFactory.getLogger(CallerController.class);

 

@Autowired

 

BuildProperties buildProperties;

 

@Autowired

 

RestTemplate restTemplate;

 

@GetMapping(“/ping”)

 

public String ping() {

 

LOGGER.info(“Ping: name={}, version={}”, buildProperties.getName(), buildProperties.getVersion());

 

String response = restTemplate.getForObject(“http://callme-service:8091/callme/ping”, String.class);

 

LOGGER.info(“Calling: response={}”, response);

 

return buildProperties.getName() + “:” + buildProperties.getVersion() + “. Calling… ” + response;

 

}

 

}

 

Working on Sample Applications

All sample applications have to be started on a Docker container. Below is the Dockerfile that is responsible for building images using the critical caller-service application.

 

FROM openjdk:8-jre-alpine

 

 

ENV APP_FILE caller-service-1.0.0-SNAPSHOT.jar

 

 

ENV APP_HOME /usr/app

 

 

EXPOSE 8090

 

 

COPY target/$APP_FILE $APP_HOME/

 

 

WORKDIR $APP_HOME

 

 

ENTRYPOINT [“sh”, “-c”]

 

 

CMD [“exec java -jar $APP_FILE”]

 

The callme-service has a similar Docker file. Now let’s move on to building Docker images.

 

docker build -t piomin/callme-service:1.0 .

 

 

docker build -t piomin/caller-service:1.0.

 

 

docker build -t piomin/callme-service:2.0.

 

Deploying Sample Applications on Minikube

Begin by deploying the callme-service in two versions: 1.0 and 2.0. The application caller-service is just calling the callme-service.

You can route traffic between two versions of the callme-service in various proportions using the Istio route rule. Also, Minikube does not support Ingress, and it’s best to use the Kubernetes Service Mesh. Set the type to NodePort if the objective is to extend it beyond the Minikube service.

 

apiVersion: v1

 

 

kind: Service

 

 

metadata:

 

 

name: callme-service

 

 

labels:

 

 

app: callme-service

 

 

spec:

 

 

type: NodePort

 

 

ports:

 

 

– port: 8091

 

 

name: http

 

 

selector:

 

 

app: callme-service

 

 

apiVersion: extensions/v1beta1

 

 

kind: Deployment

 

 

metadata:

 

 

name: callme-service

 

 

spec:

 

 

replicas: 1

 

 

template:

 

 

metadata:

 

 

labels:

 

 

app: callme-service

 

 

version: v1

 

 

spec:

 

 

containers:

 

 

– name: callme-service

 

 

image: piomin/callme-service:1.0

 

 

imagePullPolicy: IfNotPresent

 

 

ports:

 

 

– containerPort: 8091

 

Next, it’s time to implement some Istio properties. The command below prints a new version of the deployment definition with any Istio configuration.

istioctl kube-inject -f deployment.yaml 

To apply this configuration to Kubernetes, type in the command below.

kubectl apply -f deployment-with-istio.yaml 

All YAML configuration files are committed together and can be found in the root directory of every application’s module. 

Setting Up Istio Routing Rules

Istio works on a domain-specific language (DSL) that allows you to configure efficient rules that control how requests are routed within the service mesh.

The following code splits traffic in proportions 20:80 between the versions while also adding a 5-second delay in 10% of the requests, and returns an HTTP 500 error code for 10% of the requests.

 

 

apiVersion: config.istio.io/v1alpha2

 

 

kind: RouteRule

 

 

metadata:

 

 

name: callme-service

 

 

spec:

 

 

destination:

 

 

name: callme-service

 

 

route:

 

 

– labels:

 

 

version: v1

 

 

weight: 20

 

 

– labels:

 

 

version: v2

 

 

weight: 80

 

 

httpFault:

 

 

delay:

 

 

per cent: 10

 

 

fixedDelay: 5s

 

 

abort:

 

 

per cent: 10

 

 

httpStatus: 500

 

Applying Further Rules

Use the following command to apply a new route rule to Kubernetes.

kubectl apply -f routerule.yaml 

Programmers can now easily verify that rule by typing the command istioctl get routerule.

If a case arrives where an Istio Ingress controller is required, a Kubernetes Ingress resource for the application can be annotated with kubernetes.io/ingress.class: “istio”. Here is one such example using the case study of the books in a library/store:

 

cat \<\<EOF “` kubectl create -f –

 

 

apiVersion: extensions/v1beta1

 

 

kind: Ingress

 

 

metadata:

 

 

name: bookinfo

 

 

annotations:

 

 

kubernetes.io/ingress.class: “istio.”

 

 

spec:

 

 

rules:

 

 

– http:

 

 

paths:

 

 

– path: /productpage

 

 

backend:

 

 

serviceName: productpage

 

 

servicePort: 9080

 

 

– path: /login

 

 

backend:

 

 

serviceName: productpage

 

 

servicePort: 9080

 

 

– path: /logout

 

 

backend:

 

 

serviceName: productpage

 

 

servicePort: 9080

 

The new application can be accessed using the code:

 

export BOOKINFO\_URL=$(kubectl get po -l istio=ingress -o jsonpath={.items[0].status.hostIP}):$(kubectl get svc istio-ingress -o jsonpath={.spec.ports[0].nodePort})

 

Testing Solutions

Before jumping up to the testing phase, it’s useful to deploy Zipkin on Minikube. Istio provides the deployment definition file zipkin.yaml that can be found inside the directory ${ISTIO_HOME}/install/kubernetes/addons.

kubectl apply -f zipkin.yaml 

The API provided by the application caller-service can be viewed under the port as mentioned in the source code.

If you do feel like testing the service, open up a web browser and call the URL generated with the address and caller ping. The name and version of the service will be printed as well as the name and version of the callme-service invoked by the caller-service.

 

 

 

 

for Future

Reference: https://dzone.com/articles/istio-service-mesh-the-step-by-step-guide-part-2-t