Knative Serverless架构

1、什么是 Knative？

Knative（读音为 kay-nay-tiv）是由Google捐献给CNCF组织的一个开源社区项目，他整合Kubernetes和Istio，提供无服务器架构应用架构，只需简单开发，可更轻松地部署即可实现业务功能，无需关心运行资源和管理，具有高可用和高扩展，提高开发人员的生产率和降低运营成本。

2、Knative 包含哪些组件？

Knative 主要由 3 个组件构成：

• 构建(Knative Build)：一种灵活地将源代码构建到容器中的方法。
• 服务(Knative Serving)：通过请求驱动模型实现容器的快速部署和自动扩展，以根据需要为工作负载提供服务。
• 事件(Knative Event) ： 用于使用和发起事件以触发应用的基础架构。应用可能由多种源触发，例如触动应用的事件、来自多个提供商的云服务、Saas系统，消息中间建，流服务，以及数据存储服务。

 1）Knative Serving

        Knative Serving 资源包含：服务、路由、配置和版本修订：

• 服务：service.serving.knative.dev 资源自动管理工作负载的整个生命周期。 它控制其他对象的创建，以确保您的应用程序具有路由、配置和服务的每次更新的新修订。 服务可以定义为始终将流量路由到最新版本或固定版本。
• 路由：route.serving.knative.dev 资源将网络端点映射到一个或多个修订版。 您可以通过多种方式管理流量，包括部分流量和命名路线。
• 配置：configuration.serving.knative.dev 资源维护部署所需的状态。 它在代码和配置之间提供了清晰的分离，并遵循十二因素应用程序方法。 修改配置会创建一个新的修订版。
• 版本修订：revision.serving.knative.dev 资源是对工作负载所做的每次修改的代码和配置的时间点快照。 修订是不可变的对象，只要有用就可以保留。 Knative Serving Revisions 可以根据传入流量自动放大和缩小。

 Knative Serving架构

Knative Serving需要：custom resource (CR), add a networking layer to the CR, and configure DNS.

    HTTP Request Flows：

 2）Knative Event

Knative Event 是一组 API，可让您在应用程序中使用事件驱动的架构。可以使用这些 API 创建组件，将事件从事件生产者路由到事件消费者（称为接收器）以接收事件。 还可以将接收器配置为通过发送响应事件来响应 HTTP 请求。

Knative Eventing 使用标准的 HTTP POST 请求在事件生产者和接收器之间发送和接收事件。 这些事件符合 CloudEvents 规范，允许以任何编程语言创建、解析、发送和接收事件。Knative Eventing 组件松散耦合，可以相互独立开发和部署。 任何生产者都可以在有活动的事件消费者正在侦听这些事件之前生成事件。 在创建事件的生产者之前，任何事件消费者都可以表达对一类事件的兴趣。

Knative Eventing典型案例：

• 事件生产者
• 事件消费者

Knative Eventing 支持支持多种事件源

kn source list

Knative Sources

Name	Status	Maintainer	Description
APIServerSource	Stable	Knative	Brings Kubernetes API server events into Knative. The APIServerSource fires a new event each time a Kubernetes resource is created, updated or deleted.
Apache CouchDB	Alpha	Knative	Brings Apache CouchDB messages into Knative.
Apache Kafka	Stable	Knative	Brings Apache Kafka messages into Knative. The KafkaSource reads events from an Apache Kafka Cluster, and passes these events to a sink so that they can be consumed. See the Kafka Source example for more details.
ContainerSource	Stable	Knative	The ContainerSource instantiates container image(s) that can generate events until the ContainerSource is deleted. This may be used, for example, to poll an FTP server for new files or generate events at a set time interval. Given a spec.template with at least a container image specified, the ContainerSource keeps a Pod running with the specified image(s). K_SINK (destination address) and KE_CE_OVERRIDES (JSON CloudEvents attributes) environment variables are injected into the running image(s). It is used by multiple other Sources as underlying infrastructure. Refer to the Container Source example for more details.
GitHub	Beta	Knative	Registers for events of the specified types on the specified GitHub organization or repository, and brings those events into Knative. The GitHubSource fires a new event for selected GitHub event types. See the GitHub Source example for more details.
GitLab	Beta	Knative	Registers for events of the specified types on the specified GitLab repository, and brings those events into Knative. The GitLabSource creates a webhooks for specified event types, listens for incoming events, and passes them to a consumer. See the GitLab Source example for more details.
KogitoSource	Alpha	Knative	An implementation of the Kogito Runtime custom resource managed by the Kogito Operator.
PingSource	Stable	Knative	Produces events with a fixed payload on a specified Cron schedule. See the Ping Source example for more details.
RabbitMQ	Stable	Knative	Brings RabbitMQ messages into Knative.
RedisSource	Alpha	Knative	Brings Redis Stream into Knative.
SinkBinding	Stable	Knative	The SinkBinding can be used to author new event sources using any of the familiar compute abstractions that Kubernetes makes available (e.g. Deployment, Job, DaemonSet, StatefulSet), or Knative abstractions (e.g. Service, Configuration). SinkBinding provides a framework for injecting K_SINK (destination address) and K_CE_OVERRIDES (JSON cloudevents attributes) environment variables into any Kubernetes resource which has a spec.template that looks like a Pod (aka PodSpecable). See the SinkBinding example for more details.

Third-Party Sources

Name	Status	Maintainer	Description
Amazon CloudWatch	Stable	TriggerMesh	Collects metrics from Amazon CloudWatch. (installation) (example)
Amazon CloudWatch Logs	Stable	TriggerMesh	Subscribes to log events from an Amazon CloudWatch Logs stream. (installation) (example)
AWS CodeCommit	Stable	TriggerMesh	Registers for events emitted by an AWS CodeCommit source code repository. (installation) (example)
Amazon Cognito Identity	Stable	TriggerMesh	Registers for events from Amazon Cognito identity pools. (installation) (example)
Amazon Cognito User	Stable	TriggerMesh	Registers for events from Amazon Cognito user pools. (installation) (example)
Amazon DynamoDB	Stable	TriggerMesh	Reads records from an Amazon DynamoDB stream. (installation) (example)
Amazon Kinesis	Stable	TriggerMesh	Reads records from an Amazon Kinesis stream. (installation) (example
Amazon S3	Stable	TriggerMesh	Subscribes to event notifications from an Amazon S3 bucket. (installation) (example)
Amazon SNS	Stable	TriggerMesh	Subscribes to messages from an Amazon SNS topic. (installation) (example)
Amazon SQS	Stable	TriggerMesh	Consumes messages from an Amazon SQS queue. (installation) (example)
Apache Camel	Stable	Apache Software Foundation	Enables use of Apache Camel components for pushing events into Knative. Camel sources are now provided via Kamelets as part of the Apache Camel K project.
Azure Activity Logs	Stable	TriggerMesh	Capture activity logs from Azure Activity Logs. (installation) (example)
Azure Blob Storage	Stable	TriggerMesh	Subscribes to events from an Azure Blob Storage account. (installation) (example)
Azure Event Grid	Stable	TriggerMesh	Retrieves events from Azure Event Grid. (installation) (example)
Azure Event Hubs	Stable	TriggerMesh	Consumes events from Azure Event Hubs. (installation) (example)
Azure IoT Hub	Stable	TriggerMesh	Consumes event from Azure IoT Hub. (installation) (example)
Azure Queue Storage	Stable	TriggerMesh	Retrieves messages from Azure Queue Storage. (installation) (example)
Azure Service Bus Queues	Stable	TriggerMesh	Consumes messages from an Azure Service Bus queue. (installation) (example)
Azure Service Bus Topics	Stable	TriggerMesh	Subscribes to messages from an Azure Service Bus topic. (installation) (example)
Debezium	Alpha	Debezium	Consume database changes as CloudEvents in Knative. (knative configuration)
Direktiv	Alpha	Direktiv	Receive events from Direktiv.
DockerHubSource	Alpha	None	Retrieves events from Docker Hub Webhooks and transforms them into CloudEvents for consumption in Knative.
Google Cloud Audit Logs	Stable	TriggerMesh	Captures audit logs from Google Cloud Audit Logs. (installation) (example)
Google Cloud Billing	Stable	TriggerMesh	Captures budget notifications from Google Cloud Billing. (installation) (example)
Google Cloud Pub/Sub	Stable	TriggerMesh	Subscribes to messages from a Google Cloud Pub/Sub topic. (installation) (example)
Google Cloud Source Repositories	Stable	TriggerMesh	Consumes events from Google Cloud Source Repositories. (installation) (example)
Google Cloud Storage	Stable	TriggerMesh	Captures change notifications from a Google Cloud Storage bucket. (installation) (example)
HTTP Poller	Stable	TriggerMesh	Periodically pulls events from an HTTP/S URL. (installation) (example)
Oracle Cloud Infrastructure	Stable	TriggerMesh	Retrieves metrics from Oracle Cloud Infrastructure. (installation) (example)
Salesforce	Stable	TriggerMesh	Consumes events from a Salesforce channel. (installation) (example)
Slack	Stable	TriggerMesh	Subscribes to events from Slack. (installation) (example)
Twilio	Supported	TriggerMesh	Receive events from Twilio. (installation) (example)
VMware	Alpha	VMware	Brings vSphere events into Knative.
Webhook	Stable	TriggerMesh	Ingest events from a webhook using HTTP. (installation) (example)
Zendesk	Stable	TriggerMesh	Subscribes to events from Zendesk. (installation) (example)

Knative Eventing Brokers方式：

Broker是 Kubernetes 自定义资源，它们定义用于收集事件池的事件网格。 代理为事件入口提供一个可发现的端点，并使用触发器进行事件传递。 事件生产者可以通过 POST 事件将事件发送给代理。

 Event delivery:

Event delivery是依赖于配置的 Broker 类的实现细节。 使用 Brokers 和 Triggers 从事件生产者和事件消费者那里抽象出事件路由的细节。

3、Knative 的优势是什么？

• Knative 无需配置和管理服务器：开发人员可以专注于代码，不必担心设置复杂的基础架构，运维及容量等问题。
• 按需付费：利用 Knative 无服务器架构，可以轻松将代码部署到Kubernets容器平台。借助 Knative，可以将代码打包为容器镜像并交给系统，以此来创建相应的服务，仅在需要时才会运行，根据预设置值，自动启动和停止实例，从而达到充分利用资源，而不浪费资源。只需为所需的云计算时间付费，而不用全程运行和管理自己的服务器，因此可大大降低运维成本。
• Knative 组件：Knative 支持第三方Add-On组件，如：GitHub，通过GitHub事件流出发自动CI/CD流水线部署。

4、Knative 部署

1)、系统资源需求（至少需要）：

• one node ：6 CPUs, 6 GB of memory, and 30 GB of disk storage.
• multiple nodes（>=3 node）： 2 CPUs, 4 GB of memory, and 20 GB of disk storage.
• Kubernetes v1.24 or newer.

2)、 部署Knative Operator

最新版本：Knative Operator 1.5

kubectl create -f https://github.com/knative/operator/releases/download/knative-v1.5.1/operator-post-install.yaml

稳定版本：Knative Operator 1.2

kubectl apply -f https://github.com/knative/operator/releases/download/knative-v1.10.2/operator.yaml

3）、确认 Knative Operator

kubectl config set-context --current --namespace=default

shows a Ready status:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
knative-operator   1/1     1            1           19h

4）、检查日志信息

kubectl logs -f deploy/knative-operator

5）

定义custom resource文件：

apiVersion: v1
kind: Namespace
metadata:
  name: knative-serving
---
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving

Apply the YAML file：

kubectl apply -f <filename>.yaml

• To configure Knative Serving to use Kourier, add spec.ingress.kourier and spec.config.network to your Serving CR YAML file as follows

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  # ...
  ingress:
    kourier:
      enabled: true
  config:
    network:
      ingress-class: "kourier.ingress.networking.knative.dev"

Apply the YAML file for your Serving CR：

kubectl apply -f <filename>.yaml

Fetch the External IP or CNAME：

kubectl --namespace knative-serving get service kourier

Knative Serving deployment：

kubectl get deployment -n knative-serving
NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
activator              1/1     1            1           18s
autoscaler             1/1     1            1           18s
autoscaler-hpa         1/1     1            1           14s
controller             1/1     1            1           18s
domain-mapping         1/1     1            1           12s
domainmapping-webhook  1/1     1            1           12s
webhook                1/1     1            1           17s

Check the status of Knative Serving Custom Resource:

kubectl get KnativeServing knative-serving -n knative-serving

• Configure DNS

kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.10.2/serving-default-domain.yaml

configure DNS for Knative：

# Here knative.example.com is the domain suffix for your cluster
*.knative.example.com == A 35.233.41.212

# Here knative.example.com is the domain suffix for your cluster
*.knative.example.com == CNAME a317a278525d111e89f272a164fd35fb-1510370581.eu-central-1.elb.amazonaws.com

add spec.config.domain into your existing Serving CR：

# Replace knative.example.com with your domain suffix
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ...
  config:
    domain:
      "knative.example.com": ""
  ...

6）安装Istio

installed Istio under a namespace other than the default istio-system:

istioctl install -y

kubectl apply -f https://github.com/knative/net-istio/releases/download/knative-v1.10.1/net-istio.yaml

Enable sidecar injection on knative-serving system namespace:

kubectl label namespace knative-serving istio-injection=enabled

Set PeerAuthentication to PERMISSIVE on knative-serving system namespace:

---
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "knative-serving"
spec:
  mtls:
    mode: PERMISSIVE

kubectl apply -f <filename>.yaml

Configuring 部署:

kubectl edit configmap config-istio -n knative-serving

Replace the local-gateway.knative-serving.knative-local-gateway field with the custom service.

custom-local-gateway.istio-system.svc.cluster.local

Replace the label selector with the label of your service:

istio: knative-local-gateway

For the service mentioned earlier, it should be updated to:

custom: custom-local-gateway

确认 Istio installation:

istioctl verify-install

7）Knative Event

apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  # ceph github gitlab kafka rabbitmq redis
  source:
    ceph:
       enabled: true

执行YAML:

kubectl apply -f <filename>.yaml

检查Knative Eventing deployment：

kubectl get deployment -n knative-eventing
NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
eventing-controller     1/1     1            1           43s
eventing-webhook        1/1     1            1           42s
imc-controller          1/1     1            1           39s
imc-dispatcher          1/1     1            1           38s
mt-broker-controller    1/1     1            1           36s
mt-broker-filter        1/1     1            1           37s
mt-broker-ingress       1/1     1            1           37s
pingsource-mt-adapter   0/0     0            0           43s
sugar-controller        1/1     1            1           36s

检查Knative Eventing Custom Resource：

kubectl get KnativeEventing knative-eventing -n knative-eventing
NAME               VERSION             READY   REASON
knative-eventing   <version number>    True

恭喜您，您已经实现Knative Serverless架构，下一步可以开发部署Function，实现业务功能啦！！！