概述¶

本页为管理员提供了有关如何在现有 Kubernetes 集群上管理 Knative 的指南。Knative 管理员会安装和配置服务和事件组件，或两者都安装，以及默认或首选插件。

管理员可以使用 Knative 为开发人员提供一种简单的与集群交互和部署应用程序的体验。在此模型中，开发人员主要与 Knative 资源（如 Services、Brokers 和 Triggers）进行交互。由于 Knative 可以与核心 Kubernetes 对象互操作，开发人员还可以根据需要使用现有的 Kubernetes 工具，如 Pod、Services、Networking、Identity 和 Storage。希望进一步简化部署体验的开发人员可以使用 Knative Functions 编程模型来定义函数。下图显示了在此模型中管理员和开发人员的角色。

---
config:
  theme: redux
  layout: dagre
  look: classic
---
flowchart LR
 subgraph Knative["**Knative**&nbsp;&nbsp;"]
    direction LR
        Serving["Serving"]
        Eventing["Eventing"]
  end
 subgraph Plugins["**Plugins**&nbsp;&nbsp;"]
    direction LR
        net-istio["Istio"]
        net-contour["Contour"]
        net-gateway-api["Gateway API"]
        event-kafka["Kafka"]
        event-rabbitmq["RabbitMQ"]
        event-nats["NATS"]
  end
    Dev(["**Developers**"]) --> dev-acts["Develops and manages"]
    dev-acts --> Serving & Eventing
    Admin(["**Administrators**"]) --> admin-acts["Installs and configures"]
    admin-acts --> Knative & Plugins
    Serving --> net-impl["Controls"]
    net-impl --> net-istio & net-contour & net-gateway-api
    Eventing --> event-impl["Controls"]
    event-impl --> event-kafka & event-rabbitmq & event-nats
    dev-acts@{ shape: text}
    admin-acts@{ shape: text}
    net-impl@{ shape: text}
    event-impl@{ shape: text}
    style Serving fill:#D5D5D5,color:#000000
    style Eventing fill:#F0DBDB,color:#000000
    style net-istio fill:#D5D5D5,color:#000000
    style net-contour fill:#D5D5D5,color:#000000
    style net-gateway-api fill:#D5D5D5,color:#000000
    style event-kafka fill:#F0DBDB
    style event-rabbitmq fill:#F0DBDB
    style event-nats fill:#F0DBDB
    style Dev fill:#EFB769,color:#000000
    style dev-acts fill:transparent
    style Admin fill:#94C6C1,color:#000000
    style admin-acts fill:transparent
    style Knative text-align: left
    style Plugins text-align: left
    style net-impl fill:transparent
    style event-impl fill:transparent

作为集群管理员，您的职责包括管理 Kubernetes 环境、安装集群范围的组件，以及使开发人员能够在集群上部署应用程序。Knative 旨在简化开发人员任务，同时与现有的管理工具和流程保持一致。

Knative 包括一个插件系统，用于与集群中的现有基础架构集成，使 Knative 资源（如 Routes 和 Brokers）可以使用多个底层供应商之一来实现。例如，Knative 事件应用程序可以向 Broker 发送事件，该 Broker 根据接收到的事件触发一个函数。在测试集群中，传递可能使用内存选项，而在暂存或生产环境中，可能会使用云提供的 Kafka 服务。

集群管理员特别关注的是，Knative 支持资源 YAML 文件中定义的参数的可自定义*默认值*。这些配置减少了开发人员需要考虑的环境配置任务量。

安装决策¶

有关先决条件和安装步骤，请参阅安装路线图。您的第一个安装决策是使用基于 YAML 的安装还是使用 Knative Operator。Knative Operator 是一个自定义控制器，它扩展了 Kubernetes API 来安装 Knative 组件。如果您现在只是需要熟悉 Knative，可以安装快速入门。

您安装 Knative 的方法不是永久性的，您可以根据情况使用不同的方法安装集群。虽然在单个集群上切换安装方法是可行的，但建议在新集群上执行新安装，因为这是经过更充分测试且官方支持的方法。

升级¶

管理员通常负责执行集群基础架构、应用程序和服务的升级。Knative 的设计和测试均支持在升级和回滚期间持续运行，允许您

在服务流量的同时升级或回滚 Knative 组件，而无需维护窗口。
降级一个 Knative 版本。降级工作的前提是，自上次升级以来，没有应用程序使用了新功能。

保护 Knative¶

Knative 资源是命名空间化的。Knative 遵循 Kubernetes 的基于命名空间的隔离模型，该模型允许您通过将开发团队和资源分配到命名空间来管理它们。您还可以授予开发人员访问其命名空间在其他服务中相关的其他资源（如可观察性、日志、指标、跟踪和仪表板）的权限。

命名空间还可以隔离工具（如日志、指标、跟踪、CI/CD 集成和仪表板）的边界。此隔离的程度取决于强制执行策略以及团队对命名空间边界遵守的一致性。

您可以使用标准的 Kubernetes 机制来优化和强制执行涉及命名空间的隔离，包括

配置¶

Knative 配置通过以下方法执行

编辑 YAML 清单并使用 kubectl 工具应用

直接修改资源定义，包括标签、注解和字段值。您可以使用 Kubernetes 功能（如 OPA 和 Kyverno）来强制特定值应用于资源类型，或使用插件安装中的 ConfigMap 来设置集群级别的默认值。
使用 ConfigMaps

将配置数据存储和管理为键值对。ConfigMaps 通常用于调整平台范围的行为。大多数 Knative ConfigMaps 位于 knative-serving 和 knative-eventing 命名空间中。它们的设置适用于所有命名空间中所有相关的 Knative 组件。

有关重要的用法信息和最佳实践，请参阅使用 ConfigMaps。
使用 Knative Operator

某些平台范围的设置可以使用 Knative Operator 进行声明式管理，该 Operator 使用 kn Knative CLI 插件安装。您可以管理 Operator 而不使用 kn CLI。kn CLI 仅管理 Operator 安装。

有关更多信息，请参阅使用 Operator 配置 Knative 和CLI 工具。

Knative 使用 Kubernetes YAML 清单来定义和配置系统组件。这些清单包括核心资源、自定义资源定义 (CRD) 和可扩展性功能。与 Kubernetes 一样，这些配置资源是声明式的，可以使用 kubectl CLI 工具或持续交付工具进行管理。

以下各节概述了当前管理员感兴趣的配置资源。您可以使用 kubectl 编辑这些配置；Knative 会将具有这些名称的空 ConfigMap 安装到集群中。

服务配置¶

配置	ConfigMap	描述
默认配置	`config-defaults`	默认资源值，例如性能、硬件和存储设置。
部署资源	`config-deployment`	支持 Knative 服务的 Kubernetes 部署资源。
域名	`config-domain`	配置和发布域名。
垃圾回收	`config-gc`	禁用和启用收集，并设置保留时间值。
入口网关	`config-istio`	对于新集群，您可以配置自己的网关和底层服务。
Istio 授权	NA	授予对已部署 Knative 服务的授权。
修订版本的发布时长	`config-network`	调整发布时长以适应更长的请求队列。
安全 - 证书	`config-certmanager`	描述如何管理自动证书预配。
安全 - 加密	`config-network`	提供有关加密外部域名、本地集群和系统内部的程序的链接。

事件配置¶

配置	ConfigMap	描述
Broker 默认值	`config-br-defaults`	指定您自己的 Broker 类和通道，或使用默认的 `MTChannelBasedBroker` Broker 类和通道默认值的 ConfigMap。
Broker 功能 (Kafka)	`config-kafka-features`	配置 Broker 与 Apache Kafka 集群交互的选项。
通道默认值	`default-ch-webhook`	要用于通道的默认配置和标签。
通道默认值 (Kafka)	`kafka-channel`	定义 KafkaChannel 实例的创建方式。需要安装 KafkaChannel 自定义资源定义 (CRD)。
事件源默认值	`config-ping-defaults`	配置 PingSource 默认资源以及它生成的 CloudEvents 的最大数据大小。
KEDA Kafka 资源自动伸缩	`config-kafka-features`	配置 KEDA 如何伸缩 KafkaSource、触发器或订阅。注意：此功能为 Alpha 预发布版本。
Sugar Controller	`config-sugar`	配置 Sugar Controller，它响应标签配置来生成或控制事件资源。另请参阅Knative 事件 Sugar Controller。

通用配置¶

配置	ConfigMap	描述
高可用性	NA	配置以确保 API 在发生中断时保持运行。
从 Webhook 中排除命名空间	NA	为了在升级期间处理性能问题。