🥇Knative — a platform as a service based on k8s with serverless support

Kubernetes has undoubtedly become the dominant platform for container deployment. It allows for management of virtually everything using its APIs and custom controllers that extend its API through custom resources.

However, users still need to make detailed decisions about how to deploy, configure, manage, and scale applications. Questions of application scaling, security, and traffic routing are left to the user's discretion. This distinguishes Kubernetes from traditional Platform as a Service (PaaS) offerings like Cloud Foundry and Heroku.

These platforms feature a simplified user interface aimed at application developers, who often focus on configuring individual applications. Routing, deployment, and metrics are transparently managed by the underlying PaaS system.

The workflow of ‘source code to delivery’ is handled by PaaS through the creation of a custom container image, its deployment, the setup of a new route, and a DNS subdomain for incoming traffic. All of this is triggered on command. git push.

In Kubernetes, only the basic building blocks are intentionally provided for such platforms, giving the community the opportunity to do this work themselves. As Kelsey Hightower said,:

Kubernetes is a platform for building platforms. The best starting point, but not the finish line.

As a result, we see a flurry of Kubernetes builds and hosting solutions attempting to create PaaS for Kubernetes, such as OpenShift and Rancher. Against the backdrop of a growing Kube-PaaS market, Knative entered the ring, created in July 2018 by Google and Pivotal.

Knative emerged from a collaboration between Google and Pivotal, with some assistance from other companies like IBM, RedHat, and Solo.im. It offers similar PaaS capabilities for Kubernetes with top-notch support for serverless application deployment. Unlike Kubernetes builds, Knative is installed as an extension on any compatible Kubernetes cluster and is configured through custom resources.

What is Knative?

Knative is described as "A Kubernetes-based platform for deploying and managing workloads using modern serverless computing." By declaring itself such a platform, Knative automatically scales containers proportionally to simultaneous HTTP requests. Unused services ultimately scale down to zero, providing on-demand scaling in a serverless computing style.

Knative consists of a set of controllers that are installed in any Kubernetes cluster and provide the following capabilities:

building containerized applications from source code (provided by the Build),
component) providing incoming traffic access to applications (provided by the),
Serving providing incoming traffic access to applications (provided by the),
component) delivery and automatic scaling of applications on demand (also provided by the).

Eventing component). The key component is Serving, which provides delivery, automatic scaling, and traffic management for managed applications. After installing Knative, full access to the Kubernetes API remains, allowing users to manage applications in a conventional

manner and also serves for debugging Knative services, working with the same API primitives that these services use (modules, services, etc.).

Serving also automates blue-green traffic routing, ensuring traffic splitting between new and old versions of an application when a user deploys an updated version of the application. Knative relies on the installation of a compatible ingress controller. At the time of writing, supported and Gloo API GatewayIstio Service Mesh

. It will configure the available ingress for routing traffic to applications managed by Knative. Istio Service Mesh may become a significant dependency for Knative users wanting to try it without installing the Istio control panel, as Knative relies solely on the gateway.

For this reason, most users prefer Gloo as a gateway for Knative, providing a similar set of features to Istio (when considering usage solely with Knative), while utilizing significantly fewer resources and offering lower operational costs.

Let's check Knative in action on the setup. I will use a freshly installed cluster running on GKE:

kubectl get namespace
NAME          STATUS   AGE
default       Active   21h
kube-public   Active   21h
kube-system   Active   21h

Let's start installing Knative and Gloo. This can be done in any order:

# ставим Knative-Serving
kubectl apply -f 
 https://github.com/knative/serving/releases/download/v0.8.0/serving-core.yaml
namespace/knative-serving created
# ...
# ставим Gloo
kubectl apply -f 
  https://github.com/solo-io/gloo/releases/download/v0.18.22/gloo-knative.yaml
namespace/gloo-system created
# ...

We check that all Pods are in ‘Running’ status:

kubectl get pod -n knative-serving
NAME                              READY   STATUS    RESTARTS   AGE
activator-5dd55958cc-fkp7r        1/1     Running   0          7m32s
autoscaler-fd66459b7-7d5s2        1/1     Running   0          7m31s
autoscaler-hpa-85b5667df4-mdjch   1/1     Running   0          7m32s
controller-85c8bb7ffd-nj9cs       1/1     Running   0          7m29s
webhook-5bd79b5c8b-7czrm          1/1     Running   0          7m29s
kubectl get pod -n gloo-system
NAME                                      READY   STATUS    RESTARTS   AGE
discovery-69548c8475-fvh7q                1/1     Running   0          44s
gloo-5b6954d7c7-7rfk9                     1/1     Running   0          45s
ingress-6c46cdf6f6-jwj7m                  1/1     Running   0          44s
knative-external-proxy-7dd7665869-x9xkg   1/1     Running   0          44s
knative-internal-proxy-7775476875-9xvdg   1/1     Running   0          44s

Gloo is ready for routing, let's create a scalable Knative service (we'll call it kservice) and direct traffic to it.

Knative services provide an easier way to deploy applications in Kubernetes compared to the traditional Deployment+Service+Ingress model. We'll work with an example like this:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
 name: helloworld-go
 namespace: default
spec:
 template:
   spec:
     containers:
       - image: gcr.io/knative-samples/helloworld-go
         env:
           - name: TARGET
             Value: Knative user

I copied this into a file and then applied it to my Kubernetes cluster like this:

kubectl apply -f ksvc.yaml -n default

We can view the resources created by Knative in the cluster after deploying our ‘helloworld-go’ kservice:

kubectl get pod -n default
NAME                                              READY   STATUS    RESTARTS   AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8   2/2     Running   0          68s

The Pod with our image ‘helloworld-go’ starts up upon deploying the kservice. If there is no traffic, the number of pods will scale down to zero. Conversely, if the number of concurrent requests exceeds a configurable threshold, the number of pods will increase.

kubectl get ingresses.networking.internal.knative.dev -n default
NAME            READY   REASON
helloworld-go   True

Knative configures its ingress using a specific ‘ingress’ resource in the Knative internal API. Gloo takes this API as its configuration to provide PaaS-like features, including blue-green deployment model, automatic TLS application, timeouts, and other advanced routing features.

After a while, we notice that our pods have disappeared (as there was no incoming traffic):

kubectl get pod -n default

No resources found.
kubectl get deployment -n default
NAME                             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
helloworld-go-fjp75-deployment   0         0         0            0           9m46s

Finally, let's try to reach them. Getting the URL for the Knative Proxy can easily be done with glooctl:

glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80

Without having it installed, glooctl you can peek at the address and port in kube service:

kubectl get svc -n gloo-system knative-external-proxy
NAME                     TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                      AGE
knative-external-proxy   LoadBalancer   10.16.11.157   35.190.151.188   80:32168/TCP,443:30729/TCP   77m

Let's run some data through cURL:

curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!

Knative provides almost-PaaS for developers on top of out-of-the-box Kubernetes, using the high-performance, fully-featured Gloo API gateway. This note only slightly touched upon the extensive capabilities of Knative available for customization, as well as additional features. The same goes for Gloo!

Although Knative is still a young project, its team releases new versions every six weeks, and advanced features such as automatic TLS deployment and control panel auto-scaling are being implemented. There’s a high chance that as a result of collaboration among several cloud companies, as well as being the basis for Google's new Cloud Run offering, Knative may become a primary option for serverless computing and PaaS in Kubernetes. Stay tuned!

From the SouthBridge editorial team
We value readers' opinions, so we ask you to participate in a brief survey regarding future articles on Knative, Kubernetes, and serverless computing:

Only registered users can participate in the survey. Please log in, please.