Next, we’re going to take a look at a new application. We’re going to deploy something I call repeater. Why we’re introducing a new (third) application, besides the API and the DB. For us to do chaos to networking, we will need an additional app so that we can, for example, do some damage to the networking of the API and see how that new application connected to it works.

The repeater is a very simple application. All it does is forward requests coming into it to the specified address. So, for example, if we send a request to the repeater, and we specify that we would like it to forward that request to go-demo-8, that’s where it will go. It is intentionally very simple because the objective is to see how multiple applications collaborate together through networking and what happens when we do some damage to the network.

So let’s take a look at the definition.

1

cat k8s/network/repeater/*

I will not present the output nor comment (much) on it. You can see it on your screen, and you should be able to deduce what each of the resources does. The Deployment contains the definition of the repeater application. HorizontalPodAutoscaler will make sure that the app scales up and down depending on memory and CPU usage, as well as that there are never less than two replicas. The VirtualService, the DestinationRule, and the Gateway are Istio resources that will handle incoming and outgoing traffic. Finally, we have a “standard” Kubernetes Service, and you hopefully already know what it does.