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