이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 3. Architecture
3.1. Knative Serving architecture
Knative Serving on OpenShift Container Platform enables developers to write cloud-native applications using serverless architecture. Serverless is a cloud computing model where application developers don’t need to provision servers or manage scaling for their applications. These routine tasks are abstracted away by the platform, allowing developers to push code to production much faster than in traditional models.
Knative Serving supports deploying and managing cloud-native applications by providing a set of objects as Kubernetes Custom Resource Definitions (CRDs) that define and control the behavior of serverless workloads on an OpenShift Container Platform cluster. For more information about CRDs, see Extending the Kubernetes API with Custom Resource Definitions.
Developers use these CRDs to create custom resource (CR) instances that can be used as building blocks to address complex use cases. For example:
- Rapidly deploying serverless containers.
- Automatically scaling pods.
For more information about CRs, see Managing resources from Custom Resource Definitions.
3.1.1. Knative Serving CRDs
- Service
-
The
service.serving.knative.devCRD automatically manages the life cycle of your workload to ensure that the application is deployed and reachable through the network. It creates a Route, a Configuration, and a new Revision for each change to a user created Service, or custom resource. Most developer interactions in Knative are carried out by modifying Services. - Revision
-
The
revision.serving.knative.devCRD is a point-in-time snapshot of the code and configuration for each modification made to the workload. Revisions are immutable objects and can be retained for as long as necessary. - Route
-
The
route.serving.knative.devCRD maps a network endpoint to one or more Revisions. You can manage the traffic in several ways, including fractional traffic and named routes. - Configuration
-
The
configuration.serving.knative.devCRD maintains the desired state for your deployment. It provides a clean separation between code and configuration. Modifying a configuration creates a new Revision.
3.2. Knative Eventing architecture
Knative Eventing on OpenShift Container Platform enables developers to use an event-driven architecture with serverless applications. An event-driven architecture is based on the concept of decoupled relationships between event producers that create events, and event sinks, or consumers, that receive them.
Knative Eventing uses standard HTTP POST requests to send and receive events between event producers and consumers. These events conform to the CloudEvents specifications, which enables creating, parsing, sending, and receiving events in any programming language.
You can propagate an event from an event source to multiple event sinks by using:
The Channel and Broker implementations manage delivery of events to event sinks, by using Subscriptions and Triggers. Events are buffered if the destination sink is unavailable. Knative Eventing supports the following scenarios:
- Publish an event without creating a consumer
- You can send events to a Broker as an HTTP POST, and use a SinkBinding to decouple the destination configuration from your application that is producing events.
- Consume an event without creating a publisher
- You can use a Trigger to consume events from a Broker based on event attributes. Your application will receive events as an HTTP POST.
3.2.1. Event sinks
To enable delivery to multiple types of sinks, Knative Eventing defines the following generic interfaces that can be implemented by multiple Kubernetes resources:
- Addressable objects
-
Able to receive and acknowledge an Event delivered over HTTP to an address defined in the Event’s
status.address.urlfield. The Kubernetes Service object also satisfies the addressable interface. - Callable objects
- Able to receive an Event delivered over HTTP and transform it, returning 0 or 1 new Events in the HTTP response payload. These returned Events may be further processed in the same way that Events from an external event source are processed.
