The DevOps Toolkit Catalogue/

...

/

Defining Knative Applications as Code

Defining Knative Applications as Code

Learn how to define the Knative applications as code.

We'll cover the following...

Viewing definitions

Executing commands like kn service create is great because it’s simple. But it’s the wrong approach to deploying any type of application, Knative included. Maintaining a system created through ad hoc commands is a nightmare. The initial benefits from that approach are often overshadowed by the cost that comes later.

So we’ll move on with the assumption that you want to have a YAML file that defines your application. It could be some other format but, given that almost everything is YAML in the Kubernetes world, we’ll assume that’s what you need.

So, let’s take a look at how we’d define our application. We’ve already prepared a sample definition devops-toolkit.yaml to use.

Press + to interact
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: devops-toolkit
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "0"
        autoscaling.knative.dev/maxScale: "3"
    spec:
      containerConcurrency: 100
      containers:
      - image: vfarcic/devops-toolkit-series
        ports:
        - containerPort: 80
        resources:
          limits:
            memory: 256Mi
            cpu: 100m

That definition could be shorter. If we want to accomplish the same result as what we had with the kn service create command, we don’t need the annotations and the resources section. But we wanted to show that we can be more precise. That’s one of the big advantages of Knative. It can be as simple or as complicated as we need it to be. But we don’t have time to go into details of everything we might (or might not) want to do. Instead, we’re trying to gain just enough knowledge to decide whether Knative is worth exploring in more detail and potentially adopting it as a way to define, deploy, and manage some (if not all) of our applications.

The annotations tell Knative that we want to scale to 0 replicas if there's no traffic and that there should never be more than three replicas. For example, we could choose never to scale below 2 replicas and go way above 3. That would give us scalability and high availability without making our applications serverless, without scaling down to zero replicas.

The containerConcurrency field is set to 100, meaning that, in a simplified form, there should be one replica for every hundred concurrent requests while never going above the maxScale value.

The image, ports, and resources fields should be self-explanatory since those are the same ones we would typically use in, let’s say, a Deployment.

There are also some limitations we might need to be aware of. The most important one is that we can ...