问题描述
我目前正在评估 Knative Serving 作为将我的应用程序部署到 Kubernetes 的替代方案。我想知道是否有可能扩展 Knative 功能以向我的应用程序开发人员提供更多功能，例如，我希望他们定义其他自定义基础架构，如云数据库，或者让他们配置 Istio 功能，如授权策略，仅使用服务 yaml 清单，无需部署其他 Kubernetes yaml。归根结底，我只想将 Knative 服务作为我的应用合同，别无其他。
可以这样做吗？有没有关于如何操作的文档？
解决方法
我想知道是否可以扩展 Knative 功能以提供更多功能
您如何看待使用设置功能的用户？没有机制允许资源的 spec 中的自定义属性不分叉我们的控制器。
您可以让用户在 Knative 服务的 spec.template.metadata 上设置标签和注释，并让网络钩子改变最终创建的 pod。
我没有对 Istio 发表评论的专业知识，但如果您需要创建额外的资源来设置身份验证策略，您可以编写一个控制器来监视 knative 的 istio 网络插件创建的虚拟服务/网关。如果身份验证策略修改了虚拟服务，那么您可能会遇到垃圾处理，因为控制器可能会协调您的更改。这是我们需要探索的一个领域，K8s 是否具有帮助协调控制器/网络钩子的设施。
请随意创建更具体的问题
,很高兴听到您发现 Knative 很有用！ Knative 旨在补充而不是取代 Kubernetes，因此我将向您指出一些可与 Knative 配合使用的有用 Kubernetes 模式（而不是建议您分叉或扩展 Knative 控制器以添加数据库部署等功能）。
对于云数据库等功能，我会研究“操作员”模式。如果您与云提供商合作，Crossplane 提供了一组自定义资源以允许开发人员使用自定义 kubernetes 对象管理云资源。例如，这里是用于配置 RDS 数据库的 AWS RDSInstance type。
特别是对于 Istio authorization policy，您可以简单地预先配置一组固定的身份验证策略，然后使用工作负载标签来选择哪些应该应用于特定工作负载。 （注意，我不是 Istio 用户，所以这是基于阅读他们的文档，而不是实际经验。）如果您需要更动态的东西（例如，一个注释来指示哪些主体可以调用该服务），您我可能想编写一个控制器来观察集群中的 Knative 服务和/或部署，并动态创建适当的 Istio AuthorizationPolicies。
听起来您已经在使用 OAM，因此将其构建到您的应用程序定义中可能更有意义； Knative Serving 最好被认为是“更好的部署版本”，而不是“完整的应用程序模型”。