Kubernetes and cloud-native development
As great as it is that Kubernetes is dominating the cloud-native ecosystem, it’s not really the easiest platform to use when you’re coming from environments like CloudFoundry (CF). CF was specifically designed to hide all of the complexities of the infrastructure so that the developer could focus (as much as possible) just on their code/application. And that’s not really Kubernetes’ goal. It focuses more on making the administration of the infrastructure around your application (and the application itself) easier to manage, but that means people are forced to learn and understand a lot more of the technical details of what it takes to host their app.
Kubernetes was originally advertised as a platform to build other platforms, but it became “the platform” (to the detriment of the developer’s experience). Knative is attempting to change that by moving up the stack and trying to allow people to just focus on their application by having an opinionated view of how to leverage Kubernetes behind the scenes. Now, I won’t get into all of the benefits of Knative, for that you can see hereand here.
IBM Cloud Kubernetes Service and Knative
In this blog, I want to focus on a change to how IBM Cloud Kubernetes Service exposes Knative because there’s a recent change that will dramatically help people.
When IBM Cloud Kubernetes Service first announced support for Knative during IBM’s THINK conference in February 2019, installing the core Knative IBM Cloud Kubernetes Service add-on was already pretty simple. You could install it via the command line:
You could also do it via the web console by going to your cluster’s “add-on” tab and clicking a single button:
Both are obviously very easy to do and will complete in just a few seconds. That’s great!
However, while that would install Knative (and even Istio if not already installed), and you could then deploy your favorite Knative application, there was still something else that needed to be configured before it was truly useful—the network.
Extra steps to be able to call your app
In order to actually call your application, there were a couple of speed bumps that got in your way:
Knative would, by default, assign your application a domain name of “example.com.” You would need to modify the “config-domain” configMap in the knative-serving namespace to change this to something more meaningful to you.
The Istio ingress rules would not recognize your cluster’s real domain name and, therefore, would not route any incoming request to the Knative infrastructure.
In order to actually send requests to your application, you would have to manually set the HTTP “Host” header to your application’s full domain name and send the request to the IP address of your cluster. Meaning your curl command would need to look something like this:
While all of these things are possible for people to do/configure, it wasn’t obvious to someone new to this environment that they would need to do all of this, or how to do all of it, and (to be blunt) it’s just kind of annoying and hurts the simplified user experience we’re trying to achieve.
Streamlining the process
IBM Cloud Kubernetes Service has simplified all of this! Let’s start by showing you all of the steps you need to take to install Knative, install your application, and access it:
Yes, that’s it! One command to install and configure Knative. One command to deploy your application. And one command to invoke it.
The install of Knative will now automatically set the default domain name for Knative to match the domain name of your IBM Cloud Kubernetes Service cluster, which in this case is “test-532960.us-south.containers.appdomain.cloud.” It will also set up the Istio ingress to route all incoming requests targeted to that domain to Knative.
Installing the Knative application is just a vanilla “kubectl” command, nothing new there.
Calling the application no longer needs a custom HTTP “Host” header. Since IBM Cloud Kubernetes Service will automatically set up the proper wildcard DNS entries for your IKS cluster, you can just use it!
While this isn’t necessarily an earth-shattering change since the networking stuff could have been done before, sometimes it’s these little things that can really influence people’s first impressions of an environment, and I’ve seen people’s eyes glaze over having to do these steps just to get their first application deployed. So, I’m pretty excited that we can reduce the number of steps down to the bare minimum like this.
If you come across other annoyances, no matter how small, feel free to reach out to us so we can see what we can do to improve things even more!
New to Knative?
If you’re new to Knative, but know about Kubernetes, you might be wondering if I’m playing any tricks by putting a ton of configuration stuff into the application yaml file (app.yaml), well, I’m not. Here’s an app.yaml file you can use to test this out:
A bit more verbose than I’d like, but you’ll notice that there’s really only two bits of information in there: the application name (“helloworld”) and the container image to use (“duglin/helloworld”).
Also, if you’re new to IKS, you can use the following command to get your cluster’s domain name:
And look for the “Ingress Subdomain” line.
One last thing, don’t forget that you’ll need a Kubernetes cluster with at least 3 worker nodes to run Knative because it also installs Istio under the covers, and so you’ll need enough compute power for those bits of infrastructure.
Join the conversation