Deploying the Application

What we need to do next is deploy our demo application. But, this time, since we already saw that we are going to extend our chaos experiments into networking and that we are going to use Istio for that, our application will be slightly more complex. We will need to add a couple of Istio resources to it.

You might already be proficient with Istio. If you’re not, then you might not find sufficient information about what we are going to create here. I will not go into details about Virtual Services, Gateways, and other Istio resources. If that is not your strong point, I strongly recommend that you check out the Canary Deployments in Kubernetes with Istio And Friends course in Udemy. Even though it is not focused on everything there is to know about Istio, it does, in an indirect way, provide insights into the most important concepts and constructs.

Besides Istio-specific resources, we will also need to deploy one additional application, but I will explain that later. For now, let’s start by deploying the app in the same way as we did before.

Pulling the latest version of the repository#

First, we’re going to go to the go-demo-8 directory, and we are going to pull the latest version of the repository. That’ll make sure that you have any changes that I might have made since the last time you cloned it.

Creating a namespace#

Then we’re going to create the go-demo-8 Namespace where our application will be running.

Enabling Istio injection#

Now comes the new part. We’re going to label that Namespace with istio-injection=enabled. That will give a signal to Istio that it should add a proxy container to every single Pod running in that Namespace.

Then, we are going to deploy our application, just as we did before, and without any changes. The only difference is that this time, there will be no nginx Ingress resource. Soon, we’re going to start using Istio gateway for that. So let’s take a quick look at what we have in the k8s/health/app directory.

Applying the definition to the cluster#

The output is too big to be presented in a lesson. If you take a closer look, you’ll notice that those are the same definitions we used in the previous section, so commenting on them would only introduce unnecessary delay. Instead, we’ll just apply those definitions and wait until the go-demo-8 Deployment rolls out.

Now we have our application running in the same way as before. The only difference is that it is without the Ingress resource.

Inspecting the pods#

Let’s take a quick look at the Pods we just created.

The output is as follows.

NAME             READY STATUS  RESTARTS AGE
go-demo-8-...    2/2   Running 2        113s
go-demo-8-...    2/2   Running 1        98s
go-demo-8-db-... 2/2   Running 0        113s

We can see that this time, all the Pods have two containers. One of those containers is ours, and the additional one was injected by Istio. That is the proxy sidecar running in every single Pod. However, sidecar containers are not enough by themselves, and we still need to create a few Istio resources.

Inspecting the istio.yaml and applying the definition#

Next, we’ll take a look at a few additional resources we’ll need for the applications to be managed by Istio, or, to be more precise, for networking of those applications to be managed by Istio.

The output is as follows.

---

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: go-demo-8
spec:
  hosts:
  - go-demo-8
  http:
  - route:
    - destination:
        host: go-demo-8
        subset: primary
        port:
          number: 80

---

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: go-demo-8
spec:
  host: go-demo-8
  subsets:
  - name: primary
    labels:
      release: primary

We have a Virtual Service called go-demo-8 that will allow internal traffic to our application. We can see that we have the host set to go-demo-8 (the name of the Service associated with the app). The destination is also set to the same host, and the subset is set to primary. Typically, we would have primary (and secondary) subsets if we’d use Canary Deployments. But, in this case, we are not going to do that. If you’re curious about canaries, please check out the Canary Deployments in Kubernetes with Istio And Friends course in Udemy. In any case, we are going to define only the primary subset as being the only one since we won’t have canary deployments this time. Finally, the port is set to 80. That is the port through which network requests will be coming to this Virtual Service.

Then we have the DestinationRule resource, which is pretty straightforward. It is called go-demo-8, the host is also go-demo-8. It points to the primary subset, which will forward all the requests to go-demo-8 Pods that have the label release set to primary.

Let’s apply that definition before we see what else we might need.

Exploring the repeater.yaml and applying the definitions#

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.

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.

Let’s apply the definitions of this new application and wait until it rolls out.

Now we should be ready.

We have our go-demo-8 application, and we have the associated database. Those two are the same as before with the addition of Istio resources, and we have a new app called repeater.

Sending a request to confirm#

The only thing left is to double-check whether all that works. We’re going to do that by sending a request to the repeater.

We sent a request with the “fake” domain, just as we did a few times before. The major difference is that, this time, the request was sent with the Host header set to repeater.acme.com, and that there is the addr=http://go-demo-8 parameter in the address.

When we sent a request to the repeater, it forwarded it to the value of the query parameter addr, which, in turn, is set to go-demo-8. So, it just forwards requests wherever we specify. We can see that’s true since we sent a request to the repeater but got the familiar response from go-demo-8 saying Version: 0.0.1.

In the next lesson, we will be installing the Chaos Toolkit Istio plugin and discovering more about it.