Are you worried about building, deploying, and managing applications on Kubernetes? Or you want it to go serverless? Whatever may be the reason, Knative is the next big choice for Kubernetes apps.
Kubernetes is 6 years old but is a popular choice for serverless Kubernetes and is supported by all the cloud-provider.
Serverless fundamentally changes the way the developer builds applications.
It’s not about building functions, but much more than building the snippets of code in the cloud. DevSamurai Vietnam will show you all about Knative and its products.
1) The a whole stack like messaging, data warehouse, AI, storage, data processing, etc, that allows the developers to focus on what matters that decides the core of business values, and not have to be concerned with the complexities of the infrastructure that runs that code.
2) Serverless is not the absence of servers. The application runs on servers but the underline technology makes sure that developers are not concern about the infrastructure while they code for their projects.
If an application needs additional containers you can arrange it regardless of the underlying platform.
3) Event-driven enables the wiring of the systems together. A complex system that tangles most of the popular tools and sites are widely used. Event-driven coding enables the source and consumer of events to interact on a single platform.
4) By adapting your code to the serverless you can change your servers may be a third-party data center or a different cloud. You work on a single or multi-cloud platform. Working on traditional development methods, testing methods, or using canary development all the ways can be followed on serverless technology.
Knative:
It is an open-source project that is a serverless add-on for the Google Kubernetes Engine. Three major components “Build”, “Serve”, and “Events” are primitives or building blocks of Knative and works on serverless and provide tools to work with Kubernetes, and work naturally.
The developer has code and hosted, and put that code into the container, like Kubernetes or docker. How the docker builds, and create an image using Traverse or Jenkins make that container built for you. Once the cloud is created push that to a cloud registry like docker hub or private registry. To have it on Kubernetes we need to have a manifest file EML depending on the complexity of projects.
1. Build:
Source code management, complex or custom builds, templates like could factory-build packs. Using Knative build you can all these in the cluster itself. It’s easy, developers can deploy all these steps into the single manifest.
Build makes the iterative development faster and agile.
Orchestrate from code to server.
2. Serve:
It comes with Istio. Istio comes with traffic management, intelligent routing, automatic scaling, scale to zero. In serverless applications, you need to scale up to 1000 pods and bring them to zero, if no one is accessing that service. Let’s look at how to serve works.
1) Service: it’s a microservice or a simple code. It points and manages two different things:
- Route: It manages all the traffic. Using Istio traffic management traffic, 10% traffic to the new version and 90% to the new version. This helps to do a staged rollout while doing API testing. Config:
- Revisions: It stores the revisions made to service, and these revisions are managed using config.
It gives us, snapshots, intelligent routing, scaling. Build and serve solve problems on CI/CD pipelines while working on Kubernetes.
3. Events:
You need to create events and triggers that respond to the platform itself. Eg: An algorithm to detect the weather. You want to trigger that algorithm and actions. Eventing allows you to set up triggers. Hook into CI/CD pipeline. Any time you have a new push to master, 10% of the traffic will be pushed to the new version. Creating a pipeline with eventing is also an option.
Let’s look into Knative Eventing, as it’s one of the important aspects for Knative to work.
Knative event acts as an Event Intermediatery, between the wired producers and consumer or both. The produces can be from the application or the third-party tool. One of the advantages of having Knative is,
1) Fully-decoupling of Producers and consumers with no point-to-point communication. No need to upgrade and downgrade services as they are fully decoupled.
2) Having true separation of concern leads to high scalability.
3) It extends organically, the decoupled architecture makes it easy to add/remove the existing application. In the Microservices pattern, the spider web of point-to-point interactions impacts significant changes in upstream and downstream events.
Knative uses the cloud events format, producers are any Knative sources can be from applications and directly creates the custom events to intermediates. Knative acts as an intermediary. Knative also has a vibrant community as sources that act as the sources like Github source, Knative svc, Kafka sources, etc.
Products of Knative:
The native community has product offerings as commercial productions.
1) Gardener: Used to create an extra layer for serverless in Gardener’s vanilla Kubernetes clusters.
2) Google Cloud Run for Anthos: Extends serverless functionality in Google Kubernetes Engine.
3) Google Cloud Run: Fully-managed Knative-based serverless platform at no clusters.
4) IBM cloud code engine: A fully-managed serverless platform for containerized workloads.
5) Managed Knative for IBM Cloud Kubernetes Service: Delays and manages Knative based services on Kubernetes cluster.
6) Red Hat Openshift Serverless: Runs single multi-load serverless platform.
7) Pivotal Function Service (PFS): Based on riff open source projects, it works for containers on Kubernetes.
8) TriggerMesh Cloud: Tekton and Knative for cloud-native platforms.
TakeAway:
Knative has made the Kubernetes cluster go serverless. Working on serverless architecture, the developer’s concentration on products than on underlying infrastructure. Knatives primitive blocks “ Build”, Serve”, and Events together allow to work more on Kebertenes clusters directly. Kubernetes events collaborate various Knative sources to consumers that are needed for complex systems.
Various development and operational benefits are using Knative, but working on serverless is your decision that depends on the user cases and your desire to invest in the needed technology and skills.