使用 Knative Operator 安装¶
Knative 提供了 Kubernetes Operator 来安装、配置和管理 Knative。您可以在集群上安装 Serving 组件、Eventing 组件或两者。
本主题描述了如何使用 manifests 和其他资源安装 Knative Operator 以及 Serving 和 Eventing 组件。要使用 CLI 安装 Operator 和组件，请参阅 Knative Operator CLI。
此安装需要满足以下先决条件
- CLI 工具已安装。
- 足够的硬件
一个节点至少需要 6 个 CPU、6 GB 内存和 30 GB 磁盘存储。
多个节点需要 2 个 CPU、4 GB 内存和 20 GB 磁盘存储。
- 现有 Kubernetes 正在运行受支持的版本。
有关其他 Knative 安装的信息，请参阅安装路线图。
安装 Knative Operator¶
在安装 Knative Serving 和 Eventing 组件之前，请首先从提供的 K8S Manifests 或通过 Helm 安装 Knative Operator。
安装 K8S Manifests（选项 1）¶
警告
Knative Operator 1.5 是最后一个同时支持 v1alpha1 和 v1beta1 CRD 的版本。如果您正在将现有 Operator 安装从 v1.2 或更早版本升级到 v1.3 或更高版本，请在安装当前版本之前运行以下命令将现有自定义资源升级到 v1beta1
kubectl create -f https://github.com/knative/operator/releases/download/knative-v1.5.1/operator-post-install.yaml
要安装最新的稳定 Operator 版本，请运行该命令
kubectl apply -f https://github.com/knative/operator/releases/download/knative-v1.20.0/operator.yaml
您可以在发布页面上找到有关 Knative Operator 发布版本的信息。
通过 Helm 安装（选项 2）¶
您可以使用我们的 helm chart 安装 Knative Operator
helm repo add knative-operator https://knative.github.io/operator
helm install knative-operator --create-namespace --namespace knative-operator knative-operator/knative-operator
要查看可用值，请运行
helm show values -n knative-operator knative-operator/knative-operator
验证 Knative Operator 安装¶
-
因为 Operator 安装到
knative-operator命名空间，请通过运行以下命令确保将当前命名空间设置为defaultkubectl config set-context --current --namespace=knative-operator -
通过运行以下命令检查 Operator 部署状态
kubectl get deployment knative-operator如果 Operator 安装正确，部署将显示
Ready状态NAME READY UP-TO-DATE AVAILABLE AGE knative-operator 1/1 1 1 19h
跟踪日志¶
要跟踪 Operator 的日志，请运行该命令
kubectl logs -f deploy/knative-operator
安装 Knative Serving¶
要安装 Knative Serving，您必须创建一个自定义资源 (CR)，向 CR 添加网络层，并配置 DNS。
创建 Knative Serving 自定义资源¶
要在 Operator 中为最新可用的 Knative Serving 创建自定义资源
-
将以下 YAML 复制到一个文件中
apiVersion: v1 kind: Namespace metadata: name: knative-serving --- apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving注意
当您不使用
spec.version字段指定版本时，Operator 默认为最新可用版本。 -
通过运行命令应用 YAML 文件
kubectl apply -f <filename>.yaml其中
<filename>是您在上一步中创建的文件的名称。
安装网络层¶
Knative Operator 可以使用不同的网络层选项配置 Knative Serving 组件。如果 Knative Serving CR 中未指定入口，Istio 是默认网络层。如果您选择使用默认的 Istio 网络层，则必须在集群上安装 Istio。因此，您可能会发现将 Kourier 配置为网络层更容易。
点击以下每个选项卡，查看如何使用不同的入口配置 Knative Serving
以下步骤安装 Kourier 并启用其 Knative 集成
-
要将 Knative Serving 配置为使用 Kourier，请将
spec.ingress.kourier和spec.config.network添加到 Serving CR YAML 文件中，如下所示apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: # ... ingress: kourier: enabled: true config: network: ingress-class: "kourier.ingress.networking.knative.dev" -
通过运行以下命令应用 Serving CR 的 YAML 文件
kubectl apply -f <filename>.yaml其中
<filename>是 Serving CR 文件的名称。 -
通过运行以下命令获取外部 IP 或 CNAME
kubectl --namespace knative-serving get service kourier保存此信息以供以后配置 DNS。
以下步骤安装 Istio 以启用其 Knative 集成
-
如果您在非默认的
istio-system命名空间下安装了 Istio-
将
spec.config.istio添加到您的 Serving CR YAML 文件中，如下所示apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: # ... config: istio: local-gateways: | - name: knative-local-gateway namespace: <local-gateway-namespace> service: knative-local-gateway.<istio-namespace>.svc.cluster.local其中
<local-gateway-namespace>是本地网关命名空间，与 Knative Serving 命名空间knative-serving相同。<istio-namespace>是安装 Istio 的命名空间。
-
通过运行以下命令应用 Serving CR 的 YAML 文件
kubectl apply -f <filename>.yaml其中
<filename>是 Serving CR 文件的名称。
-
-
通过运行以下命令获取外部 IP 或 CNAME
kubectl get svc istio-ingressgateway -n <istio-namespace>保存此信息以供以后配置 DNS。
以下步骤安装 Contour 并启用其 Knative 集成
-
安装正确配置的 Contour
kubectl apply --filename https://github.com/knative-extensions/net-contour/releases/download/knative-v1.20.0/contour.yaml -
要将 Knative Serving 配置为使用 Contour，请将
spec.ingress.contourspec.config.network添加到您的 Serving CR YAML 文件中，如下所示apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: # ... ingress: contour: enabled: true config: network: ingress-class: "contour.ingress.networking.knative.dev" -
通过运行以下命令应用 Serving CR 的 YAML 文件
kubectl apply -f <filename>.yaml其中
<filename>是 Serving CR 文件的名称。 -
通过运行以下命令获取外部 IP 或 CNAME
kubectl --namespace contour-external get service envoy保存此信息以供以后配置 DNS。
验证 Knative Serving 部署¶
-
监控 Knative 部署
kubectl get deployment -n knative-serving如果 Knative Serving 已成功部署，则 Knative Serving 的所有部署都将显示
READY状态。这是一个示例输出NAME READY UP-TO-DATE AVAILABLE AGE activator 1/1 1 1 18s autoscaler 1/1 1 1 18s autoscaler-hpa 1/1 1 1 14s controller 1/1 1 1 18s webhook 1/1 1 1 17s -
检查 Knative Serving 自定义资源的状态
kubectl get KnativeServing knative-serving -n knative-serving如果 Knative Serving 已成功安装，您应该会看到
NAME VERSION READY REASON knative-serving <version number> True
配置 DNS¶
您可以配置 DNS 以避免运行带有 host 头的 curl 命令。
以下选项卡展开以显示配置 DNS 的说明。按照您选择的 DNS 过程进行操作
Knative 提供了一个名为 default-domain 的 Kubernetes Job，用于配置 Knative Serving 使用 sslip.io 作为默认 DNS 后缀。
kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.20.0/serving-default-domain.yaml
警告
这仅在集群 LoadBalancer 服务暴露 IPv4 地址或主机名时才有效，因此它不适用于 IPv6 集群或像 minikube 这样的本地设置，除非正在运行 minikube tunnel。
在这些情况下，请参阅“真实 DNS”或“无 DNS”选项卡。
要为 Knative 配置 DNS，请从设置网络中获取外部 IP 或 CNAME，并使用您的 DNS 提供商进行配置，如下所示
-
如果网络层生成了外部 IP 地址，则为域配置通配符
A记录# Here knative.example.com is the domain suffix for your cluster *.knative.example.com == A 35.233.41.212 -
如果网络层生成了 CNAME，则为域配置 CNAME 记录
# Here knative.example.com is the domain suffix for your cluster *.knative.example.com == CNAME a317a278525d111e89f272a164fd35fb-1510370581.eu-central-1.elb.amazonaws.com -
一旦您的 DNS 提供商已配置，请将
spec.config.domain添加到您现有的 Serving CR 中，然后应用它# Replace knative.example.com with your domain suffix apiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: ... config: domain: "knative.example.com": "" ...
如果您使用 curl 访问示例应用程序或您自己的 Knative 应用程序，并且无法使用“Magic DNS (sslip.io)”或“真实 DNS”方法，则有一种临时方法。这对于那些希望在不更改其 DNS 配置的情况下评估 Knative 的用户（如“真实 DNS”方法所述），或者由于使用本地 minikube 或 IPv6 集群等原因而无法使用“Magic DNS”方法的用户非常有用。
要使用此方法使用 curl 访问您的应用程序
-
配置 Knative 使用集群外部可访问的域
kubectl patch configmap/config-domain \ --namespace knative-serving \ --type merge \ --patch '{"data":{"example.com":""}}' -
启动应用程序后，获取应用程序的 URL
输出应类似于kubectl get ksvcNAME URL LATESTCREATED LATESTREADY READY REASON helloworld-go http://helloworld-go.default.example.com helloworld-go-vqjlf helloworld-go-vqjlf True -
指示
curl连接到第 3 节中提到的网络层定义的外部 IP 或 CNAME，并使用-H "Host:"命令行选项指定 Knative 应用程序的主机名。例如，如果网络层将您的外部 IP 和端口定义为http://192.168.39.228:32198，并且您希望访问前面提到的helloworld-go应用程序，请使用在提供的curl -H "Host: helloworld-go.default.example.com" http://192.168.39.228:32198helloworld-go示例应用程序中，使用默认配置，输出为有关永久解决方案，请参阅“真实 DNS”方法。Hello Go Sample v1!
安装 Knative Eventing¶
要安装 Knative Eventing，您必须应用自定义资源 (CR)。您可以选择安装带有不同事件源的 Knative Eventing 组件。
创建 Knative Eventing 自定义资源¶
要在 Operator 中为最新可用的 Knative Eventing 创建自定义资源
-
将以下 YAML 复制到一个文件中
apiVersion: v1 kind: Namespace metadata: name: knative-eventing --- apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing注意
当您不使用
spec.version字段指定版本时，Operator 默认为最新可用版本。 -
通过运行命令应用 YAML 文件
kubectl apply -f <filename>.yaml
其中 <filename> 是您在上一步中创建的文件的名称。
安装特定版本的 Eventing¶
集群管理员可以使用 spec.version 字段安装特定版本的 Knative Eventing。例如，如果您想安装 Knative Eventing v1.7，您可以应用以下 KnativeEventing CR
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
version: "1.7"
您还可以运行以下命令进行等效更改
kn operator install --component eventing -v 1.7 -n knative-eventing
如果未指定 spec.version，Knative Operator 将安装最新可用的 Knative Eventing 版本。如果用户指定了无效或不可用的版本，Knative Operator 将不执行任何操作。Knative Operator 始终包含最新的 3 个次要版本。
如果 Knative Eventing 已由 Operator 管理，更新 KnativeEventing CR 中的 spec.version 字段可以升级或降级 Knative Eventing 版本，而无需修改 Operator。
请注意，Knative Operator 每次只允许升级或降级一个次要版本。例如，如果当前的 Knative Eventing 部署版本为 1.4，则必须先升级到 1.5，然后才能升级到 1.6。
安装自定义 Knative Eventing¶
Operator 提供了灵活性，您可以根据自己的要求安装自定义的 Knative Eventing。只要自定义 Knative Eventing 的 manifests 对 Operator 可访问，您就可以安装它们。
有两种模式可用于安装自定义 manifests：覆盖模式和追加模式。在覆盖模式下，在 .spec.manifests 下，您必须定义 Knative Eventing 安装所需的所有 manifests，因为 Operator 将不再安装任何默认 manifests。在追加模式下，在 .spec.additionalManifests 下，您只需定义您的自定义 manifests。自定义 manifests 在应用默认 manifests 之后安装。
覆盖模式¶
当您想自定义所有要安装的 Knative Eventing manifests 时，请使用覆盖模式。
例如，如果您只想安装自定义的 Knative Eventing，您可以创建并应用以下 Eventing CR
apiVersion: v1
kind: Namespace
metadata:
name: knative-eventing
---
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
version: $spec_version
manifests:
- URL: https://my-eventing/eventing.yaml
此示例安装版本为 $spec_version 的自定义 Knative Eventing，可在 https://my-eventing/eventing.yaml 处获取。
注意
您可以将自定义的 Knative Eventing 提供在一个或多个链接中，因为 spec.manifests 支持一个链接列表。URL 的顺序至关重要。将您想要首先应用的 manifest 放在最前面。
我们强烈建议您通过利用 spec.version 和 spec.manifests 来指定自定义 Knative Eventing 的版本和有效链接。请勿跳过任何一个字段。
追加模式¶
您可以使用追加模式将自定义 manifests 添加到默认 manifests 中。
例如，如果您只想自定义几个资源，但仍然想安装默认的 Knative Eventing，您可以创建并应用以下 Eventing CR
apiVersion: v1
kind: Namespace
metadata:
name: knative-eventing
---
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
version: $spec_version
additionalManifests:
- URL: https://my-eventing/eventing-custom.yaml
此示例安装默认的 Knative Eventing，并安装您在 https://my-eventing/eventing-custom.yaml 处可用的自定义资源。
Knative Operator 会安装 $spec_version 版本的 Knative Eventing 的默认 manifests，然后在此基础上安装您的自定义 manifests。
安装带有事件源的 Knative Eventing¶
Knative Operator 可以使用不同的事件源配置 Knative Eventing 组件。单击以下每个选项卡，了解如何使用不同的事件源配置 Knative Eventing
要将 Knative Eventing 配置为安装 Ceph 作为事件源
-
将
spec.source.ceph添加到您的 Eventing CR YAML 文件中，如下所示apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: # ... source: ceph: enabled: true -
通过运行命令应用 YAML 文件
kubectl apply -f <filename>.yaml其中
<filename>是您在上一步中创建的文件的名称。
要将 Knative Eventing 配置为安装 GitHub 作为事件源
-
将
spec.source.github添加到您的 Eventing CR YAML 文件中，如下所示apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: # ... source: github: enabled: true -
通过运行命令应用 YAML 文件
kubectl apply -f <filename>.yaml其中
<filename>是您在上一步中创建的文件的名称。
要将 Knative Eventing 配置为安装 GitLab 作为事件源
-
将
spec.source.gitlab添加到您的 Eventing CR YAML 文件中，如下所示apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: # ... source: gitlab: enabled: true -
通过运行命令应用 YAML 文件
kubectl apply -f <filename>.yaml其中
<filename>是您在上一步中创建的文件的名称。
要将 Knative Eventing 配置为安装 Kafka 作为事件源
-
将
spec.source.kafka添加到您的 Eventing CR YAML 文件中，如下所示apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: # ... source: kafka: enabled: true -
通过运行命令应用 YAML 文件
kubectl apply -f <filename>.yaml其中
<filename>是您在上一步中创建的文件的名称。
要将 Knative Eventing 配置为安装 RabbitMQ 作为事件源，
-
将
spec.source.rabbitmq添加到您的 Eventing CR YAML 文件中，如下所示apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: # ... source: rabbitmq: enabled: true -
通过运行命令应用 YAML 文件
kubectl apply -f <filename>.yaml其中
<filename>是您在上一步中创建的文件的名称。
要将 Knative Eventing 配置为安装 Redis 作为事件源
-
将
spec.source.redis添加到您的 Eventing CR YAML 文件中，如下所示apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: # ... source: redis: enabled: true -
通过运行命令应用 YAML 文件
kubectl apply -f <filename>.yaml其中
<filename>是您在上一步中创建的文件的名称。
验证 Knative Eventing 部署¶
-
监控 Knative 部署
kubectl get deployment -n knative-eventing如果 Knative Eventing 已成功部署，则 Knative Eventing 的所有部署都将显示
READY状态。这是一个示例输出NAME READY UP-TO-DATE AVAILABLE AGE eventing-controller 1/1 1 1 43s eventing-webhook 1/1 1 1 42s imc-controller 1/1 1 1 39s imc-dispatcher 1/1 1 1 38s mt-broker-controller 1/1 1 1 36s mt-broker-filter 1/1 1 1 37s mt-broker-ingress 1/1 1 1 37s pingsource-mt-adapter 0/0 0 0 43s sugar-controller 1/1 1 1 36s -
检查 Knative Eventing 自定义资源的状态
kubectl get KnativeEventing knative-eventing -n knative-eventing如果 Knative Eventing 已成功安装，您应该会看到
NAME VERSION READY REASON knative-eventing <version number> True
卸载 Knative¶
Knative Operator 会阻止不安全地删除 Knative 资源。即使 Knative Serving 和 Knative Eventing CR 已成功删除，Knative 中的所有 CRD 仍保留在集群中。所有依赖 Knative CRD 的资源仍然可以正常工作。
移除 Knative Serving 组件¶
要删除 Knative Serving CR，请运行该命令
kubectl delete KnativeServing knative-serving -n knative-serving
移除 Knative Eventing 组件¶
要删除 Knative Eventing CR，请运行该命令
kubectl delete KnativeEventing knative-eventing -n knative-eventing
移除 Knative Operator：¶
如果您使用发布页面安装了 Knative，请通过运行以下命令删除 Operator
kubectl delete -f https://github.com/knative/operator/releases/download/knative-v1.20.0/operator.yaml
如果您从源代码安装了 Knative，请在源代码的根目录中，使用以下命令卸载它
ko delete -f config/
支持的版本¶
下表描述了 Knative Operator 支持的 Serving 和 Eventing 版本
| 操作符 | 服务 | 事件 |
|---|---|---|
| v1.20 | v1.20.0 v1.19.0、v1.19.1、v1.19.2、v1.19.3、v1.19.4、v1.19.5、v1.19.6 和 v1.19.7 v1.18.0、v1.18.1 和 v1.18.2 v1.17.0、v1.17.1 和 v1.17.2 |
v1.20.0 v1.19.0、v1.19.1、v1.19.2、v1.19.3、v1.19.4、v1.19.5、v1.19.6、v1.19.7 和 v1.19.8 v1.18.0、v1.18.1、v1.18.2、v1.18.3 和 v1.18.4 v1.17.0、v1.17.1、v1.17.2、v1.17.3、v1.17.4、v1.17.5 和 v1.17.6 |