【2021年4月版】Kubernetes 指南 第五集:无服务器

Kubernetes 导航

在本系列中,我们简要介绍了构成Kubernetes集群的各种组件和技术。

    • 【2021年4月版】Kubernetes ナビ その1: ディストリいろいろ

 

    • 【2021年4月版】Kubernetes ナビ その2: ネットワーク・サービス関連

 

    • 【2021年4月版】Kubernetes ナビ その3: ストレージ関連

 

    • 【2021年4月版】Kubernetes ナビ その4: コンテナ関連

 

    【2021年4月版】Kubernetes ナビ その5: Serverless

这次是第五个。

各种可用于 Kubernetes 的无服务器框架有很多选择。

我們將介紹能夠在k8s上部署的Serverless框架。

Knative – Knative

原本是由Google公司开发的框架,现在已经开放源代码。基于Istio,并支持HTTP服务。

    • 公式サイト: https://knative.dev/

リポジトリ: https://github.com/knative

受到支持的事件来源

以下是官方网站上发布的代表性事件组件。

NameAPI VersionMaintainerDescriptionAPIServerSourcev1KnativeBrings Kubernetes API server events into Knative. The APIServerSource fires a new event each time a Kubernetes resource is created, updated or deleted.AWS SQSv1alpha1KnativeBrings AWS Simple Queue Service messages into Knative. The AwsSqsSource fires a new event each time an event is published on an AWS SQS topic.Apache Camelv1alpha1KnativeEnables use of Apache Camel components for pushing events into Knative. A CamelSource is an event source that can represent any existing Apache Camel component, that provides a consumer side, and enables publishing events to an addressable endpoint. Each Camel endpoint has the form of a URI where the scheme is the ID of the component to use. CamelSource requires Camel-K to be installed into the current namespace. See the CamelSource example.Apache CouchDBv1alpha1KnativeBrings Apache CouchDB messages into Knative.Apache Kafkav1beta1KnativeBrings 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.Container Sourcev1KnativeThe ContainerSource will instantiate 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, ContainerSource will keep 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.GitHubv1alpha1KnativeRegisters 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.GitLabv1alpha1KnativeRegisters 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.HeartbeatsN/AKnativeUses an in-memory timer to produce events at the specified interval.PingSourcev1beta2KnativeProduces events with a fixed payload on a specified Cron schedule. See the Ping Source example for more details.RabbitMQActivedevelopmentNoneSinkBindingv1KnativeThe 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.WebSocketN/AKnativeOpens a WebSocket to the specified source and packages each received message as a Knative event.Auto Container SourceProof of ConceptNoneAutoContainerSource is a controller that allows the Source CRDs without needing a controller. It notices CRDs with a specific label and starts controlling resources of that type. It utilizes Container Source as underlying infrastructure.Amazon CloudWatchSupportedTriggerMeshCollects metrics from Amazon CloudWatch.Amazon CloudWatch LogsSupportedTriggerMeshSubscribes to log events from an Amazon CloudWatch Logs stream.Amazon CodeCommitSupportedTriggerMeshRegisters for events emitted by an Amazon CodeCommit source code repository.Amazon Cognito IdentitySupportedTriggerMeshRegisters for events from Amazon Cognito identity pools.Amazon Cognito UserSupportedTriggerMeshRegisters for events from Amazon Cognito user pools.Amazon DynamoDBSupportedTriggerMeshReads records from an Amazon DynamoDB stream.Amazon KinesisSupportedTriggerMeshReads records from an Amazon Kinesis stream.Amazon SNSSupportedTriggerMeshSubscribes to messages from an Amazon SNS topic.Amazon SQSSupportedTriggerMeshConsumes messages from an Amazon SQS queue.BitBucketProof of ConceptNoneRegisters for events of the specified types on the specified BitBucket organization/repository. Brings those events into Knative.CloudAuditLogsSourcev1GoogleRegisters for events of the specified types on the specified Google Cloud Audit Logs. Brings those events into Knative. Refer to the CloudAuditLogsSource example for more details.CloudPubSubSourcev1GoogleBrings Cloud Pub/Sub messages into Knative. The CloudPubSubSource fires a new event each time a message is published on a Google Cloud Platform PubSub topic. See the CloudPubSubSource example for more details.CloudSchedulerSourcev1GoogleCreate, update, and delete Google Cloud Scheduler Jobs. When those jobs are triggered, receive the event inside Knative. See the CloudSchedulerSource example for further details.CloudStorageSourcev1GoogleRegisters for events of the specified types on the specified Google Cloud Storage bucket and optional object prefix. Brings those events into Knative. See the CloudStorageSource example.DockerHubSourcev1alpha1NoneRetrieves events from Docker Hub Webhooks and transforms them into CloudEvents for consumption in Knative.FTP / SFTPProof of conceptNoneWatches for files being uploaded into a FTP/SFTP and generates events for those.HeartbeatProof of ConceptNoneUses an in-memory timer to produce events as the specified interval. Uses AutoContainerSource for underlying infrastructure.KonnekActive DevelopmentNoneRetrieves events from cloud platforms (like AWS and GCP) and transforms them into CloudEvents for consumption in Knative.K8sProof of ConceptNoneBrings Kubernetes cluster events into Knative. Uses AutoContainerSource for underlying infrastructure.RedisSourcev1alpha1NoneBrings Redis Stream into Knative.Slackv1alpha1TriggerMeshSubscribes to events from Slack.VMwareActive DevelopmentNoneBrings vSphere events into Knative.Zendeskv1alpha1TriggerMeshSubscribes to events from Zendesk.

那个维护者是Knative的事件源,它是官方支持的。果然支持的事件源很多呢。

2. 科大

CNCF的Event-driven Auto-Scaling项目。在KEDA中,将事件源称为“Scaler” 。将整个系统拟人化为Meterix的感觉很不错。

    • 公式サイト: https://keda.sh/

リポジトリ: https://github.com/kedacore/keda

支持的放大器

这是在官方网站上发布的 Scalers。

NameAvailabilityMaintainterDescriptionActiveMQ Artemisv1.5+CommunityScale applications based on ActiveMQ Artemis queuesApache Kafkav1.0+MicrosoftScale applications based on an Apache Kafka topic or other services that support Kafka protocol.AWS CloudWatchv1.0+CommunityScale applications based on AWS CloudWatch.AWS Kinesis Streamv1.1+CommunityScale applications based on AWS Kinesis Stream.AWS SQS Queuev1.0+CommunityScale applications based on AWS SQS Queue.Azure Blob Storagev1.1+CommunityScale applications based on the count of blobs in a given Azure Blob Storage container. Notioce:As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.Azure Event Hubsv1.0+CommunityScale applications based on Azure Event Hubs. Notice:As of now, the Event Hub scaler only supports reading checkpoints from Blob Storage, as well as scaling only Event Hub applications written in C#, Java, Python or created with Azure Functions.Azure Log Analyticsv2.0+CommunityScale applications based on Azure Log Analytics query resultAzure Monitorv1.3+CommunityScale applications based on Azure Monitor metrics.Azure Service Busv1.0+MicrosoftScale applications based on Azure Service Bus Queues or Topics.Azure Storage Queuev1.0+MicrosoftScale applications based on Azure Storage Queues.CPUv2.0+CommunityScale applications based on cpu metrics.Cronv1.5+CommunityScale applications based on a cron schedule.Externalv1.0+MicrosoftScale applications based on an external scaler.External Pushv2.0+MicrosoftScale applications based on an external push scaler.Google Cloud Platform‎ Pub/Subv1.0+CommunityScale applications based on Google Cloud Platform‎ Pub/Sub.Huawei Cloudeyev1.1+CommunityScale applications based on a Huawei Cloudeye.IBM MQv2.0+CommunityScale applications based on IBM MQ QueueInfluxDBv2.1+CommunityScale applications based on InfluxDB queriesLiiklus Topicv1.0+CommunityScale applications based on Liiklus Topic.Memoryv2.0+CommunityScale applications based on memory metrics. Notice: This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.This scaler only applies to ScaledObject, not to Scaling Jobs.Metrics APIv2.0+CommunityScale applications based on a metric provided by an APIMongoDBv2.1+CommunityScale applications based on MongoDB queries.MSSQLv2.2+MicrosoftScale applications based on Microsoft SQL Server (MSSQL) query results.MySQLv1.2+CommunityScale applications based on MySQL query result.NATS Streamingv1.0+CommunityScale applications based on NATS Streaming.OpenStack Swiftv2.1+CommunityScale applications based on the count of objects in a given OpenStack Swift container.PostgreSQLv1.2+CommunityScale applications based on a PostgreSQL query.Prometheusv1.0+CommunityScale applications based on Prometheus.RabbitMQ Queue Latestv1.0+MicrosoftScale applications based on RabbitMQ Queue.Redis Listsv1.0+CommunityScale applications based on Redis Lists.Redis Lists (supports Redis Cluster)v2.1+CommunityRedis Lists scaler with support for Redis Cluster topologyRedis Streamsv1.5+CommunityScale applications based on Redis Streams.Redis Streams (supports Redis Cluster)v2.1+CommunityRedis Streams scaler with support for Redis Cluster topology

这个适应的Scaler相当厚实。
微软给了意外的合作呢。。。

3. 无服务

这是Bitnami提供的无服务器框架。与上述项目相比,尽管规模较小,但它提供了类似于AWS Lambda的开源版本,包括WEB UI等功能。

    • 公式サイト: https://kubeless.io/

リポジトリ: https://github.com/kubeless

支持的事件触发方式 de

目前支持的事件触发器如下所示。

    • HTTP Trigger

 

    • CronJob Trigger

 

    • PubSub Triggers

 

    Kafka Trigger

这样正直没问题吧,不是吗…

4. 分裂

这也是fission的特点之一吗?组件包含了构建工具等等,所以用事件驱动编写的代码可以轻松部署,可能会很方便使用。

    • 公式サイト: https://fission.io/

リポジトリ: https://github.com/fission/fission

受支持的事件触发器

以下是支持的事件触发器列表。

    • HTTP

 

    • NATS Streaming

 

    • Kafka

 

    • AWS SQS (KEDA based)

 

    • AWS Kinesis (KEDA based)

 

    • NATS Streaming (KEDA based)

 

    Timer Triggers

下一个版本?计划中似乎会集成KEDA…看看会有怎样的组合…

5. 开放式策动

这是Apache旗下的Serverless项目。它不仅适用于k8s,还可以使用docker-compose、mesos、ansible和Vagrant进行部署。

    • 公式サイト: https://openwhisk.apache.org/

リポジトリ: https://github.com/apache?q=openwhisk

只需要一种选择的话,对应的语言(环境)很多。

    • nodejs

 

    • Docker

 

    • Python

 

    • go

 

    • Swift

 

    • PHP

 

    • Java

 

    Ruby

而相应的组件是

    • alarm

 

    • cloudant

 

    • kafka

 

    • pushnotification

 

    • rss

 

    jira

有诸如此类的事物。

定义对这些事物的”触发器”、”规则”和”动作”,并将其部署到目标环境中,就像Apache一样,影响广泛…

6. 开放函数即服务

这个 Serverless 框架似乎以简洁为卖点?它不仅支持 K8s,还支持 OpenShift。

    • 公式サイト: https://www.openfaas.com/

リポジトリ: https://github.com/openfaas

将来可能会考虑分享行动等方面。似乎希望进一步发展Serverless,创建类似IFTTT的基于社区的事件/行动中心。这个项目仍处于初期阶段。

The Chinese paraphrasing for “番外 Tekton” could be “番外修真” .

这是一个仅从Knative中分离出构建组件的CI/CD项目。

    • 公式サイト: https://tekton.dev/

リポジトリ: https://github.com/tektoncd

因为有非常易懂的解释,所以请详细查看以下页面。

进行 CI/CD 需要一定的设备,因此对于 CI/CD 本身的维护成本也不容忽视。提供这些设备的整合也是非常感激的。

雜感/無服務器改變的範式

由于过去使用Serveless框架进行开发,因此我对”Serveless”的概念和机制有所了解,但它只是AWS或GCP服务菜单中的一个选项,其中包含lambda和Functions,我认为如果不使用主要的云服务提供商,就与我无关…

但是,当k8s实现了真正的Serverless,以及Event-Driven + MicroService体系结构可以在任何基础设施上运行时,情况就不同了。

如果使用k3s或k0s,甚至在我的Raspberry Pi上也可以运行Serverless。实际上,我甚至认为Event-Driven + MicroService更适合于物联网边缘技术。

边缘也成为Serverless的一部分,服务器端也成为Serverless,这导致了从以往基于Web、应用程序和客户端为主的”Pull”模型到主要采用推送模型的模式的彻底范式转变。

KEDA的SQL触发器简直太烦人了。

所以今天就到这里吧。

参考来源页面

广告
将在 10 秒后关闭
bannerAds