Using Serverless Strategy with Gloo and Knative (GKE Only)

Judging by the name of this section, you might be wondering why we start with serverless deployments. We’re starting with serverless simply because that’s what we used in the previous chapter. So, we’ll start with what we have right now, at least for those who are running Jenkins X in GKE.

Another question you might be asking is why we cover serverless with Knative given that we already discussed it in the previous chapter. The answer to that question lies in completeness. Serverless deployments are one of the essential options we have when choosing the strategy, and this chapter would not be complete without it. If you did go through the previous chapter, consider this one a refresher with the potential to learn something new. If nothing else, you’ll get a better understanding of the flow of events with Knative and to see a few diagrams. In any case, the rest of the strategies will build on top of this one. On the other hand, you might be impatient and bored with repetition. If that’s the case, feel free to skip this section altogether.

⚠️ At the time of this writing (September 2019), serverless deployments with Knative work out-of-the-box only in GKE (issue 4668). That does not mean that Knative does not work in other Kubernetes flavors, but rather that the Jenkins X installation of Knative works only in GKE. I encourage you to set up Knative yourself and follow along in your Kubernetes flavor. If you cannot run Knative, I still suggest you stick around even if you cannot run the examples. I’ll do my best to be brief and make the examples clear even for those not running them.

Instead of discussing the pros and cons first, we’ll start each strategy with an example. We’ll observe the results and, comment on their advantages and disadvantages as well as the scenarios when they might be a good fit. In that spirit, let’s create a serverless deployment and see what we get.

Checking the ksvc.yaml file

Let’s go into the project directory and take a quick look at the definition that makes the application serverless.

We won’t go into details on Knative specification. It was briefly explained in the Using Jenkins X To Define And Run Serverless Deployments chapter and details can be found in the official docs. What matters in the context of the current discussion is that the YAML you see in front of you defined a serverless deployment using Knative.

Inspecting jx-progressive activities

By now, if you created a new cluster, the application we imported should be up-and-running. But, to be on the safe side, we’ll confirm that by taking a quick look at the jx-progressive activities.

⚠️ There’s no need to inspect the activities to confirm whether the build is finished if you are reusing the cluster from the previous chapter. The application we deployed previously should still be running.

Once you confirm that the build is finished press ctrl+c to stop watching the activities.

Inspecting environment-jx-rocks-staging activities

As you probably already know, the activity of an application does not wait until the release is promoted to the staging environment. So, we’ll confirm that the build initiated by changes to the environment-jx-rocks-staging repository is finished as well.

Just as before, feel free to press ctrl+c once you confirm that the build was finished.

Checking the Pods

Finally, the last verification we’ll do is to confirm that the Pods are running.

The output is as follows:

In your case, jx-progressive deployment might not be there. That means it’s been a while since you used the application and Knative made the decision to scale it to zero replicas. We’ll go through a scaling-to-zero example later. For now, imagine that you do have that Pod running.

Observations gathered from the Pods

At first look, everything looks ...