0%

gRPC services 定义

dapr 支持在各组件之间使用 gRPC 的方式通信。这些 gRPC 的 services 定义存放在 dapr/dapr 目录下。dapr/dapr/proto 下各目录的定义如下:

packages description
common common protos that are imported by multiple packages
internals internal gRPC and protobuf definitions which is used for Dapr internal
runtime Dapr and App Callback services and its associated protobuf messages
operator Dapr Operator gRPC service
placement Dapr Placement service
sentry Dapr Sentry for CA service

本例的目的在于分析事件在不同 app 间的传递原理,所以将主要参考上述 runtime 部分的实现。

阅读全文 »

概述

在使用 Kubebuilder 开发 Kubernetes Operator 的时候,通过在本地直接运行 Operator 进行功能调试往往更为方便、效率。

一般情况下开发者仅需要执行 make run 即可在本地运行 Operator。但是当 Operator 启用了 webhook 服务时,就需要对配置内容进行一些调整,才能使 Operator 在本地正常运行。

本文记录了如何在本地调试基于 controller-runtime 实现的启用 webhook 的 Operator。

阅读全文 »

Kubernetes-based Event Driven Autoscaling - HTTP Add-On

The KEDA HTTP Add On allows Kubernetes users to automatically scale their HTTP servers up and down (including to/from zero) based on incoming HTTP traffic. Please see our use cases document to learn more about how and why you would use this project.

阅读全文 »

概述

当我们将容器的日志收集到消息服务器之后,我们该如何处理这些日志?部署一个专用的日志处理工作负载可能会耗费多余的成本,而当日志体量骤增、骤降时亦难以评估日志处理工作负载的待机数量。本文提供了一种基于 Serverless 的日志处理思路,可以在降低该任务链路成本的同时提高其灵活性。

我们的大体设计是使用 Kafka 服务器作为日志的接收器,之后以输入 Kafka 服务器的日志作为事件,驱动 Serverless 工作负载对日志进行处理。据此的大致步骤为:

  1. 搭建 Kafka 服务器作为 Kubernetes 集群的日志接收器
  2. 部署 OpenFunction 为日志处理工作负载提供 Serverless 能力
  3. 编写日志处理函数,抓取特定的日志生成告警消息
  4. 配置 Notification Manager 将告警发送至 Slack

在这个场景中,我们会利用到 OpenFunction 带来的 Serverless 能力。

OpenFunction 是 KubeSphere 社区开源的一个 FaaS(Serverless)项目,旨在让用户专注于他们的业务逻辑,而不必关心底层运行环境和基础设施。该项目当前具备以下关键能力:

  • 支持通过 dockerfile 或 buildpacks 方式构建 OCI 镜像
  • 支持使用 Knative Serving 或 OpenFunctionAsync ( KEDA + Dapr ) 作为 runtime 运行 Serverless 工作负载
  • 自带事件驱动框架
阅读全文 »

概述

本文对比了几种主流的FaaS(Serverless)框架(平台)中的从事件到函数的工作方式,同时根据对比分析的结果,探讨FaaS(Serverless)框架(平台)在处理事件源调用与函数内容处理方面的设计优化。

函数框架中,函数的工作方式主要分为以下几个部分:

  1. 函数的触发器、输入和输出
  2. 函数服务的监听地址、监听协议、监听端口
  3. 框架内函数的编写规范

以下将根据上述三点内容对比Azure Function、AWS Lambda、Google Cloud Functions、Fission、OpenWhisk、Kubeless这几种框架(平台)的实现方式。

阅读全文 »

概述

本例中使用Kubesphere v3.1.0环境(Kubernetes v1.20.4 + Calico v3.16.3),网关设备为Kourier。

在Kubernetes上部署应用负载并提供服务后,访问流量将经过网关设备、负载均衡最后到达后端设备。

在这个过程中Kourier将作为网关设备解析流量的目的地址,根据域名分发到负载均衡器即Service上。

Kube-proxy(本例中为ipvs模式)将负责Service、Endpoint部分的流量处理。

Calico(本例中为IPIP模式)将负责后端设备即pod间流量的传输。

阅读全文 »