问题标签 [knative]

我的目标： 实现一个每周运行一次的 cron 作业，我打算在 Knative 上实现这个拓扑以节省计算资源：

PingSource -> knative 服务

PingSource 将每周一次向 knative 服务发出一个虚拟事件，以调出 1 个 knative 服务 pod。knative service pod 会获取大量数据，然后进行处理。

我的担心： 如果我设置enable-scale-to-zero为 true，Knative pod 自动缩放器可能会关闭 knative 服务 pod，即使该 pod 尚未完成其工作。

到目前为止，我探索了：

• scale-to-zero-grace-periodwhich 可以配置为告诉自动缩放器在最后一个流量结束后应该等待多长时间才能关闭 pod 。但我不认为这种方法是微妙的。我更喜欢有点类似于 readinessProbe 或 livenessProbe。在发送终止信号之前，自动缩放器应该发送一个探测来了解 pod 是否正在处理某些东西。

• 此外，根据 knative 的文档，有两种类型的事件接收器：可调用和可寻址。Addressable 和 Callable 都返回响应或确认。knative 自动缩放器是否会将 pod 视为处理请求，直到 pod 返回响应/确认？所以只要 pod 没有响应，它就不会被自动缩放器移除。

最近我正在尝试 Knative 示例https://github.com/meteatamel/knative-tutorial/blob/master/docs/image-processing-pipeline.md，我使用默认代理（MTChannelBasedBroker）和触发器创建了 knative 触发器，我还在同一个命名空间中安装了 Google Cloud Pub/Sub Channel。我不确定是什么导致了这个错误。

我想使用 Knative Sequence 链接几个 ksvcs 但失败了。可以触发第一步 ksvc，但不能触发其余步骤。

在我的 ksvc(Node.js) 中，我使用了 CloudEvent js-sdk。我假设我需要在收到新的 CloudEvent 后返回它。所以这是我的代码：

我是 devops 世界的新手，对 Kubernetes 有疑问。我的用例如下。
我的组织目前使用 Kubernetes 容器编排平台将其所有微服务托管在 Docker 容器中。

我希望我的微服务容器如何使用 Kubernetes 进行扩展和自动化：

我在 Amazon S3 存储桶中存储了 100 多个 AI 模型。当 user1 向具有特定模型名称的容器发出请求时，应从 S3 中获取相应的模型并将其加载到容器内存中，然后 user1 应开始推理。同样，如果来自 user2 的另一个请求具有另一个模型名称，则新容器应该分拆 并且 user2 应该开始推理。对于 n 个模型请求，n 个容器应该分拆并为每个会话提供服务。容器应该根据不同的请求自动扩展。

由于上述逻辑类似于 AWS Lambda 函数的工作原理，因此我向我们的 devops 团队推荐了相同的逻辑。“他们告知他们不能将 AWS Lambda 用于单个微服务，因为它是无服务器的，而所有其他微服务都是在 Kubernetes 中运行的非无服务器”

我的问题是，相同的概念可以用 Kubernetes 实现吗？如果是这样，请建议一种方法或文档。

提前致谢。

我目前正在评估 Knative Serving 作为将我的应用程序部署到 Kubernetes 的替代方案。我想知道是否有可能扩展 Knative 功能以为我的应用程序开发人员提供更多功能，例如，我希望他们定义其他自定义基础架构，如云数据库，或者让他们配置 Istio 功能，如授权策略，仅使用服务 yaml 清单，无需部署其他 Kubernetes yaml。归根结底，我只想将 Knative Service 作为我的应用程序合同，而不是其他任何东西。

是否有可能做到这一点？有没有关于如何做的文件？

我正在研究将通道实现从内存更改为 Kafka 的好处。我知道 inmemorychannel 不是持久的，而 Kafkachannel 是。

所以我假设 Kafkachannel 会像这样工作：

1. 当一个 channelPod（kafka-ch-dispatcher Pod）在通过 Kafkachannel 注册的事件交付到 sink 之前宕机时，宕机前注册的事件会保留在 Kafkatopic 中。
2. 当 kafka-ch-dispatcher 恢复时，Kafkatopic 中任何未投递到 sink 的事件都会被发送到 sink。

为了验证这个假设，我在确认向 Kafkatopic 注册的事件尚未交付后，杀死了 kafka-ch-dispatcher Pod。正如预期的那样，Kafkatopic 仍然有事件。然而，在等待之后，该事件从未交付到接收器。

我的假设错了吗？

还是确认方法不对？（有没有很好的方法来验证 Kafkachannel 持久性？）

我使用的频道和订阅如下。我在 knativetorial 命名空间中运行它们。

我是 Knative 的新手。我已经安装了用于集群支持的 minikube 和 knative 所需的所有工具。在参考此创建服务时：https://knative.dev/docs/serving/getting-started-knative-app/

我得到以下输出：

1. 按预期创建服务命令输出）：

kn service create helloworld-go --image gcr.io/knative-samples/helloworld-go --env TARGET="Go Sample v1"

在命名空间“默认”中创建服务“helloworld-go”：

0.047s 配置仍在工作以反映最新的所需规范。0.407s 路线仍在努力反映最新的所需规范。0.522s 配置“helloworld-go”正在等待修订准备就绪。12.683s ... 12.882s Ingress 尚未协调。15.143s 准备发球。

创建到最新版本 'helloworld-go-yvtlp-1' 的服务 'helloworld-go' 可在以下 URL 获得：http: //helloworld-go.default.mydomain.com

2. 这是我的服务：

kn service describe helloworld-go

名称：helloworld-go 命名空间：默认年龄：18 岁 URL： http ://helloworld-go.default.mydomain.com

修订：100% @latest (helloworld-go-yvtlp-1) [1] (18s) 图片：gcr.io/knative-samples/helloworld-go（固定到 5ea96b）

条件：OK TYPE AGE REASON ++ Ready 3s ++ ConfigurationsReady 5s ++ RoutesReady 3s

3. 但是当我试图卷曲时，它给了我错误：

curl http://helloworld-go.default.mydomain.com -v

• 无法解析主机：helloworld-go.default.mydomain.com
• 关闭连接 0 curl：（6）无法解析主机：helloworld-go.default.mydomain.com

有人可以帮忙吗？

我无法为 Knative 服务启用 Istio 授权以进行服务通信。

采取的步骤：

1. 安装 Istio 并使用 STRICT 模式启用 mTLS
2. 安装了 Knative 并启用了 mTLS PERMISSIVE [https://knative.dev/docs/serving/istio-authorization/]，因为请求可能由激活器基于 TargetBurstCapacity 转发。
3. 创建了两个命名空间 serving-test1 & serving-test2
4. 启用 istio sidecar 注入并在 serving-test1 和 serving-test2 中部署 Hello 服务 ** 忽略代码中使用的 IP，因为我尝试使用内部负载均衡器 IP。

期待：

1. 访问服务测试 2 中的服务时，服务测试 1 中的服务应该拒绝 RBAC 访问
2. 反之亦然#1

实际结果：

1. serving-test1 中的服务能够与 serving-test2 中的服务通信，反之亦然。

我也尝试使用 host="*.local" 和 tls mode=ISTIO_MUTUAL 添加目标规则，但没有运气。任何帮助表示赞赏。

下面完成安装和测试脚本。

在启用 AutoTLS 的 Knative文档中，它说我需要将其添加到configmap中的data块中：config-certmanager

我能想到的唯一解决方案是使用null_resource带有kubectl patch命令的资源。但是，这样做会给我以下错误：Error running command 'kubectl patch configmap config-certmanager -n knative-serving --type merge --patch '{"data":{"issuerRef":"kind:ClusterIssuer"}}'': exit status 1. Output: Error from server: Invalid JSON Patch

我试图将命令分成两部分。我还尝试对两行使用一个null_resource（kind: ClusterIssuer和name: letsencrypt-issuer

我的代码：

我究竟做错了什么？

我正在评估 knative 是否对我的项目有意义。我正在尝试创建一个连接到第三方 API 的服务。我想知道从 knative 的角度来看，存储需要定期更新的第三方 API 令牌的最佳策略是什么。

• 秘密是要走的路吗？我已经尝试过了，但我认为无法从 pod 修改秘密，对吧？
• 对于这个用例，传统的 k8 部署是否更有意义？
• 从 knative 服务存储数据的正确方法是什么？