Serving
Knative Serving 和配置服务入门
摘要
第 1 章 Knative Serving 入门
1.1. 无服务器应用程序
无服务器应用程序已创建并部署为 Kubernetes 服务,由路由和配置定义,并包含在 YAML 文件中。要使用 OpenShift Serverless 部署无服务器应用程序,您必须创建一个 Knative Service
对象。
Knative Service
对象 YAML 文件示例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: hello 1 namespace: default 2 spec: template: spec: containers: - image: docker.io/openshift/hello-openshift 3 env: - name: RESPONSE 4 value: "Hello Serverless!"
使用以下任一方法创建一个无服务器应用程序:
从 OpenShift Container Platform web 控制台创建 Knative 服务。
对于 OpenShift Container Platform,请参阅使用 Developer 视角创建应用程序。
-
使用 Knative (
kn
) CLI 创建 Knative 服务。 -
使用
oc
CLI 创建并应用 KnativeService
对象作为 YAML 文件。
1.1.1. 使用 Knative CLI 创建无服务器应用程序
通过使用 Knative (kn
) CLI 创建无服务器应用程序,通过直接修改 YAML 文件来提供更精简且直观的用户界面。您可以使用 kn service create
命令创建基本无服务器应用程序。
先决条件
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
-
已安装 Knative (
kn
) CLI。 - 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
流程
创建 Knative 服务:
$ kn service create <service-name> --image <image> --tag <tag-value>
其中:
-
--image
是应用的镜像的 URI。 --tag
是一个可选标志,可用于向利用服务创建的初始修订版本添加标签。示例命令
$ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
输出示例
Creating service 'event-display' in namespace 'default': 0.271s The Route is still working to reflect the latest desired specification. 0.580s Configuration "event-display" is waiting for a Revision to become ready. 3.857s ... 3.861s Ingress has not yet been reconciled. 4.270s Ready to serve. Service 'event-display' created with latest revision 'event-display-bxshg-1' and URL: http://event-display-default.apps-crc.testing
-
1.1.2. 使用 YAML 创建无服务器应用程序
使用 YAML 文件创建 Knative 资源使用声明性 API,它允许您以声明性的方式描述应用程序,并以可重复的方式描述应用程序。要使用 YAML 创建无服务器应用程序,您必须创建一个 YAML 文件来定义 Knative Service
对象,然后使用 oc apply
来应用它。
创建服务并部署应用程序后,Knative 会为应用程序的这个版本创建一个不可变的修订版本。Knative 还将执行网络操作,为您的应用程序创建路由、入口、服务和负载平衡器,并根据流量自动扩展或缩减 pod。
先决条件
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
- 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
-
安装 OpenShift CLI (
oc
) 。
流程
创建包含以下示例代码的 YAML 文件:
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: event-delivery namespace: default spec: template: spec: containers: - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest env: - name: RESPONSE value: "Hello Serverless!"
导航到包含 YAML 文件的目录,并通过应用 YAML 文件来部署应用程序:
$ oc apply -f <filename>
如果您不想在 OpenShift Container Platform web 控制台中切换到 Developer 视角,或使用 Knative (kn
) CLI 或 YAML 文件,您可以使用 OpenShift Container Platform Web 控制台的 Administator 视角创建 Knative 组件。
1.1.3. 使用管理员视角创建无服务器应用程序
无服务器应用程序已创建并部署为 Kubernetes 服务,由路由和配置定义,并包含在 YAML 文件中。要使用 OpenShift Serverless 部署无服务器应用程序,您必须创建一个 Knative Service
对象。
Knative Service
对象 YAML 文件示例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: hello 1 namespace: default 2 spec: template: spec: containers: - image: docker.io/openshift/hello-openshift 3 env: - name: RESPONSE 4 value: "Hello Serverless!"
创建服务并部署应用程序后,Knative 会为应用程序的这个版本创建一个不可变的修订版本。Knative 还将执行网络操作,为您的应用程序创建路由、入口、服务和负载平衡器,并根据流量自动扩展或缩减 pod。
先决条件
要使用 管理员 视角创建无服务器应用程序,请确定您已完成了以下步骤。
- 安装了 OpenShift Serverless Operator 和 Knative Serving。
- 您已登录到 Web 控制台,且处于 Administrator 视角。
流程
- 进入 Serverless → Serving 页面。
- 在 Create 列表中,选择 Service。
- 手动输入 YAML 或 JSON 定义,或者将文件拖放到编辑器中。
- 点 Create。
1.1.4. 使用离线模式创建服务
您可以在离线模式下执行 kn service
命令,以便集群中不会发生任何更改,而是在本地机器上创建服务描述符文件。创建描述符文件后,您可以在向集群传播更改前修改该文件。
Knative CLI 的离线模式只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
先决条件
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
-
已安装 Knative (
kn
) CLI。
流程
在离线模式下,创建一个本地 Knative 服务描述符文件:
$ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest \ --target ./ \ --namespace test
输出示例
Service 'event-display' created in namespace 'test'.
--target ./
标志启用脱机模式,并将./
指定为用于存储新目录树的目录。如果您没有指定现有目录,但使用文件名,如
--target my-service.yaml
,则不会创建目录树。相反,当前目录中只创建服务描述符my-service.yaml
文件。文件名可以具有
.yaml
、.yml
或.json
扩展名。选择.json
以 JSON 格式创建服务描述符文件。namespace test
选项将新服务放在test
命名空间中。如果不使用
--namespace
,且您登录到 OpenShift Container Platform 集群,则会在当前命名空间中创建描述符文件。否则,描述符文件会在default
命名空间中创建。
检查创建的目录结构:
$ tree ./
输出示例
./ └── test └── ksvc └── event-display.yaml 2 directories, 1 file
-
使用
--target
指定的当前./
目录包含新的test/
目录,它在指定的命名空间后命名。 -
test/
目录包含ksvc
,它在资源类型后命名。 -
ksvc
目录包含描述符文件event-display.yaml
,它根据指定的服务名称命名。
-
使用
检查生成的服务描述符文件:
$ cat test/ksvc/event-display.yaml
输出示例
apiVersion: serving.knative.dev/v1 kind: Service metadata: creationTimestamp: null name: event-display namespace: test spec: template: metadata: annotations: client.knative.dev/user-image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest creationTimestamp: null spec: containers: - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest name: "" resources: {} status: {}
列出新服务的信息:
$ kn service describe event-display --target ./ --namespace test
输出示例
Name: event-display Namespace: test Age: URL: Revisions: Conditions: OK TYPE AGE REASON
--target ./
选项指定包含命名空间子目录的目录结构的根目录。另外,您可以使用
--target
选项直接指定 YAML 或 JSON 文件名。可接受的文件扩展包括.yaml
、.yml
和.json
。--namespace
选项指定命名空间,与kn
通信包含所需服务描述符文件的子目录。如果不使用
--namespace
,并且您登录到 OpenShift Container Platform 集群,kn
会在以当前命名空间命名的子目录中搜索该服务。否则,kn
在default/
子目录中搜索。
使用服务描述符文件在集群中创建服务:
$ kn service create -f test/ksvc/event-display.yaml
输出示例
Creating service 'event-display' in namespace 'test': 0.058s The Route is still working to reflect the latest desired specification. 0.098s ... 0.168s Configuration "event-display" is waiting for a Revision to become ready. 23.377s ... 23.419s Ingress has not yet been reconciled. 23.534s Waiting for load balancer to be ready 23.723s Ready to serve. Service 'event-display' created to latest revision 'event-display-00001' is available at URL: http://event-display-test.apps.example.com
1.1.5. 其他资源
1.2. 验证无服务器应用程序的部署
要验证您的无服务器应用程序是否已成功部署,您必须获取 Knative 创建的应用程序的 URL,然后向该 URL 发送请求并检查其输出。OpenShift Serverless 支持 HTTP 和 HTTPS URL,但 oc get ksvc
的输出始终使用 http://
格式打印 URL。
1.2.1. 验证无服务器应用程序的部署
要验证您的无服务器应用程序是否已成功部署,您必须获取 Knative 创建的应用程序的 URL,然后向该 URL 发送请求并检查其输出。OpenShift Serverless 支持 HTTP 和 HTTPS URL,但 oc get ksvc
的输出始终使用 http://
格式打印 URL。
先决条件
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
-
已安装
oc
CLI。 - 您已创建了 Knative 服务。
先决条件
-
安装 OpenShift CLI (
oc
) 。
流程
查找应用程序 URL:
$ oc get ksvc <service_name>
输出示例
NAME URL LATESTCREATED LATESTREADY READY REASON event-delivery http://event-delivery-default.example.com event-delivery-4wsd2 event-delivery-4wsd2 True
向集群发出请求并观察其输出。
HTTP 请求示例
$ curl http://event-delivery-default.example.com
HTTPS 请求示例
$ curl https://event-delivery-default.example.com
输出示例
Hello Serverless!
可选。如果您在证书链中收到与自签名证书相关的错误,可以在 curl 命令中添加
--insecure
标志来忽略以下错误:$ curl https://event-delivery-default.example.com --insecure
输出示例
Hello Serverless!
重要在生产部署中不能使用自签名证书。这个方法仅用于测试目的。
可选。如果 OpenShift Container Platform 集群配置有证书颁发机构 (CA) 签名但尚未为您的系统配置全局证书,您可以使用
curl
命令指定此证书。证书的路径可使用--cacert
标志传递给 curl 命令:$ curl https://event-delivery-default.example.com --cacert <file>
输出示例
Hello Serverless!
第 2 章 自动缩放
2.1. 自动缩放
Knative Serving 为应用程序提供自动扩展功能(或 autoscaling),以满足传入的需求。例如,如果应用程序没有流量,并且启用了缩减到零,Knative Serving 将应用程序缩减为零个副本。如果缩减到零,则应用程序会缩减到为集群中的应用程序配置的最小副本数。如果应用流量增加,也可以向上扩展副本来满足需求。
Knative 服务的自动扩展设置可以是集群管理员配置的全局设置(或用于 AWS 和 OpenShift Dedicated 的专用管理员),或为单个服务配置每个修订设置。
您可以使用 OpenShift Container Platform Web 控制台修改服务的每个修订设置,方法是修改服务的 YAML 文件,或使用 Knative (kn
) CLI 修改服务。
您为服务设置的任何限制或目标均是针对应用程序的单个实例来衡量。例如,将 target
注解设置为 50
可将自动扩展器配置为缩放应用程序,以便每个修订一次处理 50 个请求。
2.2. 扩展范围
缩放范围决定了可在任意给定时间为应用程序服务的最小和最大副本数。您可以为应用设置规模绑定,以帮助防止冷启动和控制计算成本。
2.2.1. 最小扩展范围
为应用程序提供服务的最小副本数量由 min-scale
注解决定。如果没有启用缩减为零,则 min-scale
值默认为 1
。
如果满足以下条件,min-scale
值默认为 0
个副本:
-
不设置
min-scale
注解 - 启用扩展到零
-
使用类
KPA
带有 min-scale
注解的 service spec 示例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/min-scale: "0" ...
2.2.1.1. 使用 Knative CLI 设置 min-scale 注解
使用 Knative (kn
) CLI 设置 min-scale
注解,比直接修改 YAML 文件提供了一个更加精简且直观的用户界面。您可以使用带有 --scale-min
标志的 kn service
命令为服务创建或修改 min-scale
值。
先决条件
- 在集群中安装了 Knative Serving。
-
已安装 Knative (
kn
) CLI。
流程
使用
--scale-min
标志设置服务的最小副本数:$ kn service create <service_name> --image <image_uri> --scale-min <integer>
示例命令
$ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --scale-min 2
2.2.2. 最大扩展范围
可提供应用程序的副本数量由 max-scale
注解决定。如果没有设置 max-scale
注解,则创建的副本数没有上限。
带有 max-scale
注解的 service spec 示例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/max-scale: "10" ...
2.2.2.1. 使用 Knative CLI 设置 max-scale 注解
使用 Knative (kn
) CLI 设置 max-scale
注解,比直接修改 YAML 文件提供了一个更精简且直观的用户界面。您可以使用带有 --scale-max
标志的 kn service
命令为服务创建或修改 max-scale
值。
先决条件
- 在集群中安装了 Knative Serving。
-
已安装 Knative (
kn
) CLI。
流程
使用
--scale-max
标志设置服务的最大副本数:$ kn service create <service_name> --image <image_uri> --scale-max <integer>
示例命令
$ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --scale-max 10
2.3. 并发
并发请求数决定了应用程序的每个副本可在任意给定时间处理的并发请求数。并发可以配置为软限制或硬限制 :
- 软限制是目标请求限制,而不是严格实施的绑定。例如,如果流量突发,可以超过软限制目标。
硬限制是严格实施的上限请求限制。如果并发达到硬限制,则请求将被缓冲,必须等到有足够的可用容量来执行请求。
重要只有在应用程序中明确用例时才建议使用硬限制配置。指定较少的硬限制可能会对应用程序的吞吐量和延迟造成负面影响,并可能导致冷启动。
添加软目标和硬限制意味着自动扩展以并发请求的软目标数为目标,但为请求的最大数量施加硬限制值。
如果硬限制值小于软限制值,则软限制值将降级,因为不需要将目标设定为多于实际处理的请求数。
2.3.1. 配置软并发目标
软限制是目标请求限制,而不是严格实施的绑定。例如,如果流量突发,可以超过软限制目标。您可以通过在 spec 中设置 autoscaling.knative.dev/target
注解,或者使用带有正确标记的 kn service
命令为 Knative 服务指定软并发目标。
流程
可选:在
Service
自定义资源的 spec 中为您的 Knative 服务设置autoscaling.knative.dev/target
注解:服务规格示例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/target: "200"
可选: 使用
kn service
命令指定--concurrency-target
标志:$ kn service create <service_name> --image <image_uri> --concurrency-target <integer>
创建服务的示例,并发目标为 50 请求
$ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-target 50
2.3.2. 配置硬并发限制
硬并发限制是严格强制执行上限的上限。如果并发达到硬限制,则请求将被缓冲,必须等到有足够的可用容量来执行请求。您可以通过修改 containerConcurrency
spec 或使用带有正确标记的 kn service
命令为 Knative 服务指定硬并发限制。
流程
可选:在
Service
自定义资源的 spec 中为您的 Knative 服务设置containerConcurrency
spec:服务规格示例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: template: spec: containerConcurrency: 50
默认值为
0
,这意味着允许同时访问服务的一个副本的请求数量没有限制。大于
0
的值指定允许一次传输到服务的一个副本的请求的确切数量。这个示例将启用 50 个请求的硬并发限制。可选: 使用
kn service
命令指定--concurrency-limit
标志:$ kn service create <service_name> --image <image_uri> --concurrency-limit <integer>
创建服务且并发限制为 50 个请求的命令示例
$ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-limit 50
2.3.3. 并发目标使用率
此值指定自动扩展实际的目标并发限制的百分比。这也称为指定运行副本的热性(hotness),允许自动扩展在达到定义的硬限制前进行扩展。
例如,如果 containerConcurrency
值设置为 10,并且 target-utilization-percentage
值设置为 70%,则自动扩展会在所有现有副本的平均并发请求数量达到 7 时创建一个新的副本。编号为 7 到 10 的请求仍然会被发送到现有的副本,但达到 containerConcurrency
值后会启动额外的副本。
使用 target-utilization-percentage 注解配置的服务示例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/target-utilization-percentage: "70" ...
2.4. Scale-to-zero
Knative Serving 为应用程序提供自动扩展功能(或 autoscaling),以满足传入的需求。
2.4.1. 启用 scale-to-zero
您可以使用 enable-scale-to-zero
spec,为集群中的应用程序全局启用或禁用 scale-to-zero。
先决条件
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
- 在 OpenShift Container Platform 上具有集群管理员权限,或在 Red Hat OpenShift Service on AWS 或 OpenShift Dedicated 上具有集群或专用管理员权限。
- 使用默认的 Knative Pod Autoscaler。如果使用 Kubernetes Horizontal Pod Autoscaler,则缩减为零功能将不可用。
流程
在
KnativeServing
自定义资源 (CR) 中修改enable-scale-to-zero
spec:KnativeServing CR 示例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: autoscaler: enable-scale-to-zero: "false" 1
- 1
enable-scale-to-zero
spec 可以是"true"
或"false"
。如果设置为 true,则会启用 scale-to-zero。如果设置为 false,应用程序将缩减至配置的最小扩展绑定。默认值为"true"
。
2.4.2. 配置 scale-to-zero 宽限期
Knative Serving 为应用程序提供自动缩放为零个 pod。您可以使用 scale-to-zero-grace-period
spec 定义上限,Knative 在删除应用程序的最后一个副本前等待 scale-to-zero machinery 原位。
先决条件
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
- 在 OpenShift Container Platform 上具有集群管理员权限,或在 Red Hat OpenShift Service on AWS 或 OpenShift Dedicated 上具有集群或专用管理员权限。
- 使用默认的 Knative Pod Autoscaler。如果使用 Kubernetes Horizontal Pod Autoscaler,则缩减为零功能将不可用。
流程
在
KnativeServing
自定义资源 (CR) 中修改scale-to-zero-grace-period
spec:KnativeServing CR 示例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: autoscaler: scale-to-zero-grace-period: "30s" 1
- 1
- 宽限期(以秒为单位)。默认值为 30 秒。
第 3 章 配置无服务器应用程序
3.1. 覆盖 Knative Serving 系统部署配置
您可以通过修改 KnativeServing
自定义资源(CR)中的 deployments
spec 来覆盖某些特定部署的默认配置。
您只能覆盖部署中默认定义的探测。
所有 Knative Serving 部署都会默认定义一个就绪度和存活度探测,但以下例外:
-
net-kourier-controller
和3scale-kourier-gateway
仅定义就绪度探测。 -
net-istio-controller
和net-istio-webhook
定义没有探测。
3.1.1. 覆盖系统部署配置
目前,支持覆盖 resources
, replicas
, labels
, annotations
, 和 nodeSelector
项的默认配置设置,以及探测的 readiness
和 liveness
字段的默认设置。
在以下示例中,KnativeServing
CR 会覆盖 Webhook
部署,以便:
-
net-kourier-controller
的readiness
探测超时设置为 10 秒。 - 部署指定了 CPU 和内存资源限制。
- 部署有 3 个副本。
-
添加
example-label: label
标签。 -
添加
example-annotation:
注解。 -
nodeSelector
字段被设置为选择带有disktype: hdd
标签的节点。
KnativeServing
CR 标签和注解设置覆盖部署本身和生成的 Pod 的部署标签和注解。
KnativeServing CR 示例
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
name: ks
namespace: knative-serving
spec:
high-availability:
replicas: 2
deployments:
- name: net-kourier-controller
readinessProbes: 1
- container: controller
timeoutSeconds: 10
- name: webhook
resources:
- container: webhook
requests:
cpu: 300m
memory: 60Mi
limits:
cpu: 1000m
memory: 1000Mi
replicas: 3
labels:
example-label: label
annotations:
example-annotation: annotation
nodeSelector:
disktype: hdd
- 1
- 您可以使用
readiness
和liveness
探测覆盖来覆盖在 Kubernetes API 中指定的一个部署中的一个容器探测的所有字段,与探测 handler:exec
,grpc
,httpGet
, 和tcpSocket
相关的字段除外。
3.2. 对 Serving 的多容器支持
您可以使用单个 Knative 服务部署多容器 pod。这个方法可用于将应用程序职责划分为较小的特殊部分。
对 Serving 的多容器支持只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
3.2.1. 配置多容器服务
默认启用多容器支持。您可以通过指定服务中的多个容器来创建多容器 pod。
流程
修改您的服务使其包含其他容器。只有一个容器可以处理请求,因此为一个容器指定一个
端口
。以下是有两个容器的示例配置:多容器配置
apiVersion: serving.knative.dev/v1 kind: Service ... spec: template: spec: containers: - name: first-container 1 image: gcr.io/knative-samples/helloworld-go ports: - containerPort: 8080 2 - name: second-container 3 image: gcr.io/knative-samples/helloworld-java
3.3. EmptyDir 卷
emptyDir
卷是创建 pod 时创建的空卷,用来提供临时工作磁盘空间。当为其创建 pod 被删除时,emptyDir
卷会被删除。
3.3.1. 配置 EmptyDir 扩展
kubernetes.podspec-volumes-emptydir
扩展控制 emptyDir
卷是否与 Knative Serving 搭配使用。要使用 emptyDir
卷启用,您必须修改 KnativeServing
自定义资源 (CR) 使其包含以下 YAML:
KnativeServing CR 示例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: features: kubernetes.podspec-volumes-emptydir: enabled ...
3.4. Serving 的持久性卷声明
有些无服务器应用程序需要持久性数据存储。要做到这一点,您可以为 Knative 服务配置持久性卷声明 (PVC) 。
3.4.1. 启用 PVC 支持
流程
要启用 Knative Serving 使用 PVC 并写入它们,请修改
KnativeServing
自定义资源 (CR) 使其包含以下 YAML:启用具有写入访问的 PVC
... spec: config: features: "kubernetes.podspec-persistent-volume-claim": enabled "kubernetes.podspec-persistent-volume-write": enabled ...
-
kubernetes.podspec-persistent-volume-claim
扩展控制持久性卷 (PV) 是否可以用于 Knative Serving。 -
kubernetes.podspec-persistent-volume-write
扩展控制 Knative Serving 是否使用写入访问权限。
-
要声明 PV,请修改您的服务使其包含 PV 配置。例如,您可能具有以下配置的持久性卷声明:
注意使用支持您请求的访问模式的存储类。例如,您可以使用
ReadWriteMany
访问模式的ocs-storagecluster-cephfs
类。PersistentVolumeClaim 配置
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: example-pv-claim namespace: my-ns spec: accessModes: - ReadWriteMany storageClassName: ocs-storagecluster-cephfs resources: requests: storage: 1Gi
在这种情况下,若要声明具有写访问权限的 PV,请修改服务,如下所示:
Knative 服务 PVC 配置
apiVersion: serving.knative.dev/v1 kind: Service metadata: namespace: my-ns ... spec: template: spec: containers: ... volumeMounts: 1 - mountPath: /data name: mydata readOnly: false volumes: - name: mydata persistentVolumeClaim: 2 claimName: example-pv-claim readOnly: false 3
注意要在 Knative 服务中成功使用持久性存储,您需要额外的配置,如 Knative 容器用户的用户权限。
3.4.2. OpenShift Container Platform 的其他资源
3.5. init 容器
Init 容器是 pod 中应用程序容器之前运行的专用容器。它们通常用于为应用程序实施初始化逻辑,其中可能包括运行设置脚本或下载所需的配置。您可以通过修改 KnativeServing
自定义资源 (CR) 来启用 init 容器用于 Knative 服务。
Init 容器可能会导致应用程序的启动时间较长,应该谨慎地用于无服务器应用程序,这应该经常被扩展或缩减。
3.5.1. 启用 init 容器
先决条件
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
- 在 OpenShift Container Platform 上具有集群管理员权限,或在 Red Hat OpenShift Service on AWS 或 OpenShift Dedicated 上具有集群或专用管理员权限。
流程
通过在
KnativeServing
CR 中添加kubernetes.podspec-init-containers
标记来启用 init 容器的使用:KnativeServing CR 示例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: features: kubernetes.podspec-init-containers: enabled ...
3.6. 将镜像标签解析到摘要
如果 Knative Serving 控制器可以访问容器 registry,Knative Serving 会在创建服务的修订时将镜像标签解析为摘要。这被称为 tag-to-digest 解析,有助于为部署提供一致性。
3.6.1. tag-to-digest 解析
要让控制器访问 OpenShift Container Platform 上的容器 registry,您必须创建一个 secret,然后配置控制器自定义证书。您可以通过修改 KnativeServing
自定义资源 (CR) 中的 controller-custom-certs
spec 来配置控制器自定义证书。secret 必须位于与 KnativeServing
CR 相同的命名空间中。
如果 KnativeServing
CR 中不包含 secret,此设置默认为使用公钥基础架构 (PKI) 。在使用 PKI 时,集群范围的证书会使用 config-service-sa
配置映射自动注入到 Knative Serving 控制器。OpenShift Serverless Operator 使用集群范围证书填充 config-service-sa
配置映射,并将配置映射作为卷挂载到控制器。
3.6.1.1. 使用 secret 配置 tag-to-digest 解析
如果 controller-custom-certs
spec 使用 Secret
类型,secret 将被挂载为 secret 卷。Knative 组件直接使用 secret,假设 secret 具有所需的证书。
先决条件
- 在 OpenShift Container Platform 上具有集群管理员权限,或在 Red Hat OpenShift Service on AWS 或 OpenShift Dedicated 上具有集群或专用管理员权限。
- 您已在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
流程
创建 secret:
示例命令
$ oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate>
配置
KnativeServing
自定义资源 (CR) 中的controller-custom-certs
规格以使用Secret
类型:KnativeServing CR 示例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: controller-custom-certs: name: custom-secret type: Secret
3.7. 配置 TLS 身份验证
您可以使用 传输层安全 (TLS) 加密 Knative 流量并进行身份验证。
TLS 是 Knative Kafka 唯一支持的流量加密方法。红帽建议将 SASL 和 TLS 用于 Apache Kafka 资源的 Knative 代理。
如果要使用 Red Hat OpenShift Service Mesh 集成启用内部 TLS,您必须使用 mTLS 启用 Service Mesh,而不是按照以下流程所述的内部加密。
对于 OpenShift Container Platform 和 Red Hat OpenShift Service on AWS,请参阅 在使用带有 mTLS 的 Service Mesh 时启用 Knative Serving 指标 的文档。
3.7.1. 为内部流量启用 TLS 身份验证
OpenShift Serverless 默认支持 TLS 边缘终止,以便最终用户的 HTTPS 流量加密。但是,OpenShift 路由后面的内部流量使用普通数据转发到应用。通过为内部流量启用 TLS,组件间发送的流量会进行加密,从而使此流量更加安全。
如果要使用 Red Hat OpenShift Service Mesh 集成启用内部 TLS,您必须使用 mTLS 启用 Service Mesh,而不是按照以下流程所述的内部加密。
内部 TLS 加密支持只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
先决条件
- 安装了 OpenShift Serverless Operator 和 Knative Serving。
-
已安装 OpenShift (
oc
) CLI。
流程
在 spec 中创建一个包含
internal-encryption: "true"
字段的 Knative 服务:... spec: config: network: internal-encryption: "true" ...
重启
knative-serving
命名空间中的 activator pod 来加载证书:$ oc delete pod -n knative-serving --selector app=activator
3.8. 限制网络策略
3.8.1. 具有限制性网络策略的集群
如果您使用多个用户可访问的集群,您的集群可能会使用网络策略来控制哪些 pod、服务和命名空间可以通过网络相互通信。如果您的集群使用限制性网络策略,Knative 系统 Pod 可能无法访问 Knative 应用程序。例如,如果您的命名空间具有以下网络策略(拒绝所有请求),Knative 系统 pod 无法访问您的 Knative 应用程序:
拒绝对命名空间的所有请求的 NetworkPolicy 对象示例
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default namespace: example-namespace spec: podSelector: ingress: []
3.8.2. 在具有限制性网络策略的集群中启用与 Knative 应用程序通信
要允许从 Knative 系统 pod 访问应用程序,您必须为每个 Knative 系统命名空间添加标签,然后在应用程序命名空间中创建一个 NetworkPolicy
对象,以便为具有此标签的其他命名空间访问命名空间。
拒绝对集群中非原生服务的请求的网络策略仍阻止访问这些服务。但是,通过允许从 Knative 系统命名空间访问 Knative 应用程序,您可以从集群中的所有命名空间中访问 Knative 应用程序。
如果您不想允许从集群中的所有命名空间中访问 Knative 应用程序,您可能需要为 Knative 服务使用 JSON Web Token 身份验证 。Knative 服务的 JSON Web 令牌身份验证需要 Service Mesh。
先决条件
-
安装 OpenShift CLI (
oc
) 。 - 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
流程
将
knative.openshift.io/system-namespace=true
标签添加到需要访问应用程序的每个 Knative 系统命名空间:标记
knative-serving
命名空间:$ oc label namespace knative-serving knative.openshift.io/system-namespace=true
标记
knative-serving-ingress
命名空间:$ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true
标记
knative-eventing
命名空间:$ oc label namespace knative-eventing knative.openshift.io/system-namespace=true
标记
knative-kafka
命名空间:$ oc label namespace knative-kafka knative.openshift.io/system-namespace=true
在应用程序命名空间中创建一个
NetworkPolicy
对象,允许从带有knative.openshift.io/system-namespace
标签的命名空间访问:NetworkPolicy
对象示例apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: <network_policy_name> 1 namespace: <namespace> 2 spec: ingress: - from: - namespaceSelector: matchLabels: knative.openshift.io/system-namespace: "true" podSelector: {} policyTypes: - Ingress
第 4 章 流量分割
4.1. 流量分割概述
在 Knative 应用程序中,可以通过创建流量分割来管理流量。流量分割被配置为由 Knative 服务管理的路由的一部分。
配置路由允许将请求发送到服务的不同修订版本。此路由由 Service
对象的 traffic
spec 决定。
traffic
规格声明由一个或多个修订版本组成,每个修订版本负责处理整个流量的一部分。路由到每个修订版本的流量百分比必须添加到 100%,由 Knative 验证确保。
traffic
规格中指定的修订版本可以是固定的、名为修订的修订版本,或者可以指向"latest"修订,该修订跟踪服务所有修订版本列表的头。"latest" 修订版本是一个浮动引用类型,它在创建了新修订版本时更新。每个修订版本都可以附加标签,为该修订版本创建一个额外访问 URL。
traffic
规格可通过以下方法修改:
-
直接编辑
Service
对象的 YAML。 -
使用 Knative (
kn
) CLI--traffic
标志。 - 使用 OpenShift Container Platform Web 控制台。
当您创建 Knative 服务时,它没有任何默认 traffic
spec 设置。
4.2. traffic 规格示例
以下示例显示了一个 traffic
规格,其中 100% 的流量路由到该服务的最新修订版本。在 status
下,您可以看到 latestRevision
解析为的最新修订版本的名称:
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: ... traffic: - latestRevision: true percent: 100 status: ... traffic: - percent: 100 revisionName: example-service
以下示例显示了一个 traffic
规格,其中 100% 的流量路由到当前标记为 current
修订版本,并且该修订版本的名称指定为 example-service
。标记为 latest
的修订版本会保持可用,即使没有流量路由到它:
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: ... traffic: - tag: current revisionName: example-service percent: 100 - tag: latest latestRevision: true percent: 0
以下示例演示了如何扩展 traffic
规格中的修订版本列表,以便在多个修订版本间分割流量。这个示例将 50% 的流量发送到标记为 current
修订版本,50% 的流量发送到标记为 candidate
的修订版本。标记为 latest
的修订版本会保持可用,即使没有流量路由到它:
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: ... traffic: - tag: current revisionName: example-service-1 percent: 50 - tag: candidate revisionName: example-service-2 percent: 50 - tag: latest latestRevision: true percent: 0
4.3. 使用 Knative CLI 进行流量分割
使用 Knative (kn
) CLI 创建流量分割功能,通过直接修改 YAML 文件,提供更精简且直观的用户界面。您可以使用 kn service update
命令在服务修订版本间分割流量。
4.3.1. 使用 Knative CLI 创建流量分割
先决条件
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
-
已安装 Knative (
kn
) CLI。 - 您已创建了 Knative 服务。
流程
使用带有标准
kn service update
命令的--traffic
标签指定服务修订版本以及您要路由到它的流量百分比:示例命令
$ kn service update <service_name> --traffic <revision>=<percentage>
其中:
-
<service_name>
是您要为其配置流量路由的 Knative 服务的名称。 -
<revision>
是您要配置为接收流量百分比的修订版本。您可以使用--tag
标志指定修订版本的名称,或指定分配给修订版本的标签。 -
<percentage>
是您要发送到指定修订版本的流量百分比。
-
可选:
--traffic
标志可在一个命令中多次指定。例如,如果您有一个标记为@latest
的修订版本以及名为stable
的修订版本,您可以指定您要分割到每个修订版本的流量百分比:示例命令
$ kn service update example-service --traffic @latest=20,stable=80
如果您有多个修订版本,且没有指定应分割到最后一个修订版本的流量百分比,
--traffic
标志可以自动计算此设置。例如,如果您有一个第三个版本名为example
,则使用以下命令:示例命令
$ kn service update example-service --traffic @latest=10,stable=60
剩余的 30% 的流量被分成
example
修订,即使未指定。
4.4. 用于流量分割的 CLI 标志
Knative (kn
) CLI 支持作为 kn service update
命令的一部分对服务的流量块进行流量操作。
4.4.1. Knative CLI 流量分割标志
下表显示流量分割标志、值格式和标志执行的操作汇总。Repetition 列表示在 kn service update
命令中是否允许重复标志的特定值。
标记 | 值 | 操作 | 重复 |
---|---|---|---|
|
|
为 | 是 |
|
|
为带有 | 是 |
|
|
为最新可用的修订版本提供 | 否 |
|
|
为 | 是 |
|
|
为最新可用的修订版本提供 | 否 |
|
|
从修订中删除 | 是 |
4.4.1.1. 多个标志和顺序优先级
所有流量相关标志均可使用单一 kn service update
命令指定。kn
定义这些标志的优先级。不考虑使用命令时指定的标志顺序。
通过 kn
评估标志时,标志的优先级如下:
-
--untag
:带有此标志的所有引用修订版本均将从流量块中移除。 -
--tag
:修订版本将按照流量块中的指定进行标记。 -
--traffic
:为引用的修订版本分配一部分流量分割。
您可以将标签添加到修订版本,然后根据您设置的标签来分割流量。
4.4.1.2. 修订版本的自定义 URL
使用 kn service update
命令为服务分配 --tag
标志,可为在更新服务时创建的修订版本创建一个自定义 URL。自定义 URL 遵循 https://<tag>-<service_name>-<namespace>.<domain>
或 http://<tag>-<service_name>-<namespace>.<domain>
。
--tag
和 --untag
标志使用以下语法:
- 需要一个值。
- 在服务的流量块中表示唯一标签。
- 在一个命令中可多次指定.
4.4.1.2.1. 示例:将标签分配给修订版本
以下示例将标签 latest
分配给名为 example-revision
的修订版本:
$ kn service update <service_name> --tag @latest=example-tag
4.4.1.2.2. 示例:从修订中删除标签
您可以使用 --untag
标志来删除自定义 URL。
如果修订版本删除了其标签,并分配了流量的 0%,则修订版本将完全从流量块中删除。
以下命令从名为 example-revision
的修订版本中删除所有标签:
$ kn service update <service_name> --untag example-tag
4.5. 在修订版本间分割流量
创建无服务器应用程序后,应用程序会在 OpenShift Container Platform Web 控制台中的 Developer 视角 的 Topology 视图中显示。应用程序修订版本由节点表示,Knative 服务由节点的四边形表示。
代码或服务配置中的任何新更改都会创建一个新修订版本,也就是给定时间点上代码的快照。对于服务,您可以根据需要通过分割服务修订版本并将其路由到不同的修订版本来管理服务间的流量。
4.5.1. 使用 OpenShift Container Platform Web 控制台管理修订版本之间的流量
先决条件
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
- 已登陆到 OpenShift Container Platform Web 控制台。
流程
要在 Topology 视图中的多个应用程序修订版本间分割流量:
- 点 Knative 服务在侧面面板中查看其概述信息。
点 Resources 选项卡,查看服务的 Revisions 和 Routes 列表。
图 4.1. 无服务器应用程序
- 点侧边面板顶部的由 S 图标代表的服务,查看服务详情概述。
-
点 YAML 选项卡,在 YAML 编辑器中修改服务配置,然后点 Save。例如,将
timeoutseconds
从 300 改为 301。这个配置更改会触发新修订版本。在 Topology 视图中会显示最新的修订,服务 Resources 选项卡现在会显示两个修订版本。 在 Resources 选项卡中,点 查看流量分布对话框:
- 在 Splits 字段中为两个修订版本添加流量百分比。
- 添加标签以便为这两个修订版本创建自定义 URL。
点 Save 查看两个节点,分别代表 Topology 视图中的两个修订版本。
图 4.2. 无服务器应用程序修订
4.6. 使用蓝绿策略重新路由流量
您可以使用蓝绿部署策略,安全地将流量从应用的生产版本重新路由到新版本。
4.6.1. 使用蓝绿部署策略路由和管理流量
先决条件
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
-
安装 OpenShift CLI (
oc
) 。
流程
- 创建并部署应用程序作为 Knative 服务。
通过查看以下命令的输出,查找部署服务时创建的第一个修订版本的名称:
$ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'
示例命令
$ oc get ksvc example-service -o=jsonpath='{.status.latestCreatedRevisionName}'
输出示例
$ example-service-00001
在服务
spec
中添加以下 YAML 以将入站流量发送到修订版本:... spec: traffic: - revisionName: <first_revision_name> percent: 100 # All traffic goes to this revision ...
验证您可以在 URL 输出中运行以下命令来查看您的应用程序:
$ oc get ksvc <service_name>
-
通过修改服务的
template
规格中至少有一个字段来部署应用程序的第二个修订版本。例如,您可以修改服务的image
或env
环境变量。您可以通过应用服务 YAML 文件重新部署服务,如果安装了 Knative (kn
) CLI,也可以使用kn service update
命令。 运行以下命令,查找您在重新部署服务时创建的第二个最新的修订版本的名称:
$ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'
此时,服务的第一个和第二个修订版本都已部署并运行。
更新您的现有服务,以便为第二个修订版本创建新的测试端点,同时仍然将所有其他流量发送到第一个修订版本:
使用测试端点更新的服务 spec 示例
... spec: traffic: - revisionName: <first_revision_name> percent: 100 # All traffic is still being routed to the first revision - revisionName: <second_revision_name> percent: 0 # No traffic is routed to the second revision tag: v2 # A named route ...
在通过重新应用 YAML 资源重新部署此服务后,应用的第二个修订现已被暂存。没有流量路由到主 URL 的第二个修订版本,Knative 会创建一个名为
v2
的新服务来测试新部署的修订版本。运行以下命令,获取第二个修订版本的新服务的 URL:
$ oc get ksvc <service_name> --output jsonpath="{.status.traffic[*].url}"
在将任何流量路由到之前,您可以使用此 URL 验证新版本的应用运行正常。
再次更新您的现有服务,以便 50% 的流量发送到第一个修订版本,50% 发送到第二个修订版本:
更新的服务 spec 在修订版本间分割流量 50/50 的示例
... spec: traffic: - revisionName: <first_revision_name> percent: 50 - revisionName: <second_revision_name> percent: 50 tag: v2 ...
当您准备好将所有流量路由到应用程序的新版本时,请再次更新该服务,将 100% 的流量发送到第二个修订版本:
更新的服务 spec 将所有流量发送到第二个修订版本的示例
... spec: traffic: - revisionName: <first_revision_name> percent: 0 - revisionName: <second_revision_name> percent: 100 tag: v2 ...
提示如果您不计划回滚修订版本,您可以删除第一个修订版本,而不是将其设置为流量的 0%。然后,不可路由的修订版本对象会被垃圾回收。
- 访问第一个修订版本的 URL,以验证没有更多流量发送到应用程序的旧版本。
第 5 章 External 和 Ingress 路由
5.1. 路由概述
Knative 利用 OpenShift Container Platform TLS 终止来为 Knative 服务提供路由。创建 Knative 服务时,会自动为该服务创建一个 OpenShift Container Platform 路由。此路由由 OpenShift Serverless Operator 管理。OpenShift Container Platform 路由通过与 OpenShift Container Platform 集群相同的域公开 Knative 服务。
您可以禁用 OpenShift Container Platform 路由的 Operator 控制,以便您可以配置 Knative 路由来直接使用 TLS 证书。
Knative 路由也可以与 OpenShift Container Platform 路由一起使用,以提供额外的精细路由功能,如流量分割。
5.1.1. OpenShift Container Platform 的其他资源
5.2. 自定义标签和注解
OpenShift Container Platform 路由支持使用自定义标签和注解,您可以通过修改 Knative 服务的元数据规格来配置这些标签和注解
。自定义标签和注解从服务传播到 Knative 路由,然后传播到 Knative ingress,最后传播到 OpenShift Container Platform 路由。
5.2.1. 为 OpenShift Container Platform 路由自定义标签和注解
先决条件
- 您必须已在 OpenShift Container Platform 集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
-
安装 OpenShift CLI (
oc
) 。
流程
创建包含您要传播到 OpenShift Container Platform 路由的标签或注解的 Knative 服务:
使用 YAML 创建服务:
使用 YAML 创建的服务示例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: <service_name> labels: <label_name>: <label_value> annotations: <annotation_name>: <annotation_value> ...
要使用 Knative (
kn
) CLI 创建服务,请输入:使用
kn
命令创建的服务示例$ kn service create <service_name> \ --image=<image> \ --annotation <annotation_name>=<annotation_value> \ --label <label_value>=<label_value>
通过检查以下命令的输出来验证 OpenShift Container Platform 路由是否已使用您添加的注解或标签创建:
验证命令示例
$ oc get routes.route.openshift.io \ -l serving.knative.openshift.io/ingressName=<service_name> \ 1 -l serving.knative.openshift.io/ingressNamespace=<service_namespace> \ 2 -n knative-serving-ingress -o yaml \ | grep -e "<label_name>: \"<label_value>\"" -e "<annotation_name>: <annotation_value>" 3
5.3. 为 Knative 服务配置路由
如果要将 Knative 服务配置为在 OpenShift Container Platform 上使用 TLS 证书,则必须禁用 OpenShift Serverless Operator 为服务自动创建路由,而是手动为服务创建路由。
完成以下步骤时,不会创建 knative-serving-ingress
命名空间中的默认 OpenShift Container Platform 路由。但是,应用程序的 Knative 路由仍然在此命名空间中创建。
5.3.1. 为 Knative 服务配置 OpenShift Container Platform 路由
先决条件
- OpenShift Serverless Operator 和 Knative Serving 组件必须安装在 OpenShift Container Platform 集群中。
-
安装 OpenShift CLI (
oc
) 。
流程
创建包含
service.knative.openshift.io/disableRoute=true
注解的 Knative 服务:重要service.knative.openshift.io/disableRoute=true
注解指示 OpenShift Serverless 不自动为您创建路由。但是,该服务仍然会显示 URL 并达到Ready
状态。除非使用与 URL 中主机名相同的主机名创建自己的路由,此 URL 才能在外部工作。创建 Knative
Service
资源:资源示例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: <service_name> annotations: serving.knative.openshift.io/disableRoute: "true" spec: template: spec: containers: - image: <image> ...
应用
Service
资源:$ oc apply -f <filename>
可选。使用
kn service create
命令创建 Knative 服务:kn
命令示例$ kn service create <service_name> \ --image=gcr.io/knative-samples/helloworld-go \ --annotation serving.knative.openshift.io/disableRoute=true
验证没有为服务创建 OpenShift Container Platform 路由:
示例命令
$ $ oc get routes.route.openshift.io \ -l serving.knative.openshift.io/ingressName=$KSERVICE_NAME \ -l serving.knative.openshift.io/ingressNamespace=$KSERVICE_NAMESPACE \ -n knative-serving-ingress
您将看到以下输出:
No resources found in knative-serving-ingress namespace.
在
knative-serving-ingress
命名空间中创建Route
资源:apiVersion: route.openshift.io/v1 kind: Route metadata: annotations: haproxy.router.openshift.io/timeout: 600s 1 name: <route_name> 2 namespace: knative-serving-ingress 3 spec: host: <service_host> 4 port: targetPort: http2 to: kind: Service name: kourier weight: 100 tls: insecureEdgeTerminationPolicy: Allow termination: edge 5 key: |- -----BEGIN PRIVATE KEY----- [...] -----END PRIVATE KEY----- certificate: |- -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- caCertificate: |- -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE---- wildcardPolicy: None
应用
Route
资源:$ oc apply -f <filename>
5.4. 全局 HTTPS 重定向
HTTPS 重定向为传入的 HTTP 请求提供重定向。这些重定向的 HTTP 请求会被加密。您可以通过为 KnativeServing
自定义资源 (CR) 配置 httpProtocol
spec,为集群中的所有服务启用 HTTPS 重定向。
5.4.1. HTTPS 重定向全局设置
启用 HTTPS 重定向的 KnativeServing
CR 示例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: network: httpProtocol: "redirected" ...
5.5. 外部路由的 URL 方案
用于增强安全性,外部路由的 URL 方案默认为 HTTPS。这个方案由 KnativeServing
自定义资源 (CR) spec 中的 default-external-scheme
键决定。
5.5.1. 为外部路由设置 URL 方案
默认规格
... spec: config: network: default-external-scheme: "https" ...
您可以通过修改 default-external-scheme
键来覆盖默认的 spec 以使用 HTTP:
HTTP 覆盖规格
... spec: config: network: default-external-scheme: "http" ...
5.6. 每个服务的 HTTPS 重定向
您可以通过配置 networking.knative.dev/http-option
注解来为服务启用或禁用 HTTPS 重定向。
5.6.1. 为服务重定向 HTTPS
以下示例演示了如何在 Knative Service
YAML 对象中使用此注解:
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example namespace: default annotations: networking.knative.dev/http-option: "redirected" spec: ...
5.7. 集群本地可用性
默认情况下,Knative 服务会发布到一个公共 IP 地址。被发布到一个公共 IP 地址意味着 Knative 服务是公共应用程序,并有一个公开访问的 URL。
可以从集群以外访问公开的 URL。但是,开发人员可能需要构建后端服务,这些服务只能从集群内部访问(称为 私有服务 )。开发人员可以使用 networking.knative.dev/visibility=cluster-local
标签标记集群中的各个服务,使其私有。
对于 OpenShift Serverless 1.15.0 及更新的版本,service.knative.dev/visibility
标签不再可用。您必须更新现有服务来改用 networking.knative.dev/visibility
标签。
5.7.1. 将集群可用性设置为集群本地
先决条件
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
- 您已创建了 Knative 服务。
流程
通过添加
networking.knative.dev/visibility=cluster-local
标签来设置服务的可见性:$ oc label ksvc <service_name> networking.knative.dev/visibility=cluster-local
验证
输入以下命令并查看输出结果,检查您的服务的 URL 是否现在格式为
http://<service_name>.<namespace>.svc.cluster.local
:$ oc get ksvc
输出示例
NAME URL LATESTCREATED LATESTREADY READY REASON hello http://hello.default.svc.cluster.local hello-tx2g7 hello-tx2g7 True
5.7.2. 为集群本地服务启用 TLS 身份验证
对于集群本地服务,使用 Kourier 本地网关 kourier-internal
。如果要针对 Kourier 本地网关使用 TLS 流量,则必须在本地网关中配置您自己的服务器证书。
先决条件
- 安装了 OpenShift Serverless Operator 和 Knative Serving。
- 有管理员权限。
-
已安装 OpenShift (
oc
) CLI。
流程
在
knative-serving-ingress
命名空间中部署服务器证书:$ export san="knative"
注意需要主题备用名称(SAN)验证,以便这些证书能够向
<app_name>.<namespace>.svc.cluster.local
提供请求。生成 root 密钥和证书:
$ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \ -subj '/O=Example/CN=Example' \ -keyout ca.key \ -out ca.crt
生成使用 SAN 验证的服务器密钥:
$ openssl req -out tls.csr -newkey rsa:2048 -nodes -keyout tls.key \ -subj "/CN=Example/O=Example" \ -addext "subjectAltName = DNS:$san"
创建服务器证书:
$ openssl x509 -req -extfile <(printf "subjectAltName=DNS:$san") \ -days 365 -in tls.csr \ -CA ca.crt -CAkey ca.key -CAcreateserial -out tls.crt
为 Kourier 本地网关配置 secret:
从前面的步骤创建的证书,在
knative-serving-ingress
命名空间中部署 secret:$ oc create -n knative-serving-ingress secret tls server-certs \ --key=tls.key \ --cert=tls.crt --dry-run=client -o yaml | oc apply -f -
更新
KnativeServing
自定义资源 (CR) spec,以使用 Kourier 网关创建的 secret:KnativeServing CR 示例
... spec: config: kourier: cluster-cert-secret: server-certs ...
Kourier 控制器在不重启该服务的情况下设置证书,因此您不需要重启 pod。
您可以通过端口 443
访问 Kourier 内部服务,方法是从客户端挂载并使用 ca.crt
。
5.8. Kourier 网关服务类型
Kourier 网关默认作为 ClusterIP
服务类型公开。此服务类型由 KnativeServing
自定义资源 (CR) 中的 service-type
ingress spec 决定。
默认规格
... spec: ingress: kourier: service-type: ClusterIP ...
5.8.1. 设置 Kourier 网关服务类型
您可以通过修改 service-type
spec 来覆盖默认服务类型来使用负载均衡器服务类型:
LoadBalancer 覆盖规格
... spec: ingress: kourier: service-type: LoadBalancer ...
5.9. 使用 HTTP2 和 gRPC
OpenShift Serverless 只支持不安全或边缘终端路由。不安全或边缘终端路由不支持 OpenShift Container Platform 中的 HTTP2。这些路由也不支持 gRPC,因为 gRPC 由 HTTP2 传输。如果您在应用程序中使用这些协议,则必须使用入口(ingress)网关直接调用应用程序。要做到这一点,您必须找到 ingress 网关的公共地址以及应用程序的特定主机。
5.9.1. 使用 HTTP2 和 gRPC 与无服务器应用程序交互
此方法适用于 OpenShift Container Platform 4.10 及更新的版本。有关旧版本,请参阅以下部分。
先决条件
- 在集群上安装 OpenShift Serverless Operator 和 Knative Serving。
-
安装 OpenShift CLI (
oc
) 。 - 创建 Knative 服务。
- 升级 OpenShift Container Platform 4.10 或更高版本。
- 在 OpenShift Ingress 控制器中启用 HTTP/2。
流程
将
serverless.openshift.io/default-enable-http2=true
注解添加到KnativeServing
自定义资源中:$ oc annotate knativeserving <your_knative_CR> -n knative-serving serverless.openshift.io/default-enable-http2=true
添加注解后,您可以验证 Kourier 服务的
appProtocol
值是否为h2c
:$ oc get svc -n knative-serving-ingress kourier -o jsonpath="{.spec.ports[0].appProtocol}"
输出示例
h2c
现在,您可以对外部流量使用 HTTP/2 协议的 gRPC 框架,例如:
import "google.golang.org/grpc" grpc.Dial( YOUR_URL, 1 grpc.WithTransportCredentials(insecure.NewCredentials())), 2 )
其他资源
5.9.2. 在 OpenShift Container Platform 4.9 及更高版本中使用 HTTP2 和 gRPC 与无服务器应用程序交互
此方法需要使用 LoadBalancer
服务类型公开 Kourier 网关。您可以通过在 KnativeServing
自定义资源定义 (CRD) 中添加以下 YAML 来配置:
... spec: ingress: kourier: service-type: LoadBalancer ...
先决条件
- 在集群上安装 OpenShift Serverless Operator 和 Knative Serving。
-
安装 OpenShift CLI (
oc
) 。 - 创建 Knative 服务。
流程
- 找到应用程序主机。请参阅验证无服务器应用程序部署中的相关内容。
查找 ingress 网关的公共地址:
$ oc -n knative-serving-ingress get svc kourier
输出示例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kourier LoadBalancer 172.30.51.103 a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com 80:31380/TCP,443:31390/TCP 67m
公共地址位于
EXTERNAL-IP
字段,在本例中是a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com
。手动在 HTTP 请求的主机标头中设置应用程序的主机,但将请求定向到 ingress 网关的公共地址。
$ curl -H "Host: hello-default.example.com" a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com
输出示例
Hello Serverless!
您还可以对入口网关发出直接 gRPC 请求:
import "google.golang.org/grpc" grpc.Dial( "a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com:80", grpc.WithAuthority("hello-default.example.com:80"), grpc.WithInsecure(), )
注意如上例所示,请确保将对应的端口(默认为 80)附加到两个主机中。
第 6 章 配置对 Knative 服务的访问
6.1. 为 Knative 服务配置 JSON Web 令牌身份验证
OpenShift Serverless 当前没有用户定义的授权功能。要为部署添加用户定义的授权,您必须将 OpenShift Serverless 与 Red Hat OpenShift Service Mesh 集成,然后为 Knative 服务配置 JSON Web Token (JWT) 身份验证和 sidecar 注入。
6.2. 在 Service Mesh 2.x 中使用 JSON Web 令牌身份验证
您可以使用 Service Mesh 2.x 和 OpenShift Serverless 在 Knative 服务中使用 JSON Web Token (JWT) 身份验证。要做到这一点,您必须在作为 ServiceMeshMemberRoll
对象成员的应用程序命名空间中创建身份验证请求和策略。您还必须为该服务启用 sidecar 注入。
6.2.1. 为 Service Mesh 2.x 和 OpenShift Serverless 配置 JSON Web 令牌身份验证
在启用了 Kourier 时,不支持在系统命名空间中向 pod 添加 sidecar 注入,如 knative-serving
和 knative-serving-ingress
。
对于 OpenShift Container Platform,如果您需要对这些命名空间中的 pod 进行 sidecar 注入,请参阅 OpenShift Serverless 文档中的 将 Service Mesh 与 OpenShift Serverless 原生集成。
先决条件
- 您已在集群中安装了 OpenShift Serverless Operator、Knative Serving 和 Red Hat OpenShift Service Mesh。
-
安装 OpenShift CLI (
oc
) 。 - 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
流程
在您的服务中添加
sidecar.istio.io/inject="true"
注解:服务示例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: <service_name> spec: template: metadata: annotations: sidecar.istio.io/inject: "true" 1 sidecar.istio.io/rewriteAppHTTPProbers: "true" 2 ...
应用
Service
资源:$ oc apply -f <filename>
在
ServiceMeshMemberRoll
对象的每个无服务器应用程序命名空间中创建一个RequestAuthentication
资源:apiVersion: security.istio.io/v1beta1 kind: RequestAuthentication metadata: name: jwt-example namespace: <namespace> spec: jwtRules: - issuer: testing@secure.istio.io jwksUri: https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/jwks.json
应用
RequestAuthentication
资源:$ oc apply -f <filename>
通过创建以下
AuthorizationPolicy
资源,允许从ServiceMeshMemberRoll
对象中的每个无服务器应用程序命名空间的系统 pod 访问RequestAuthenticaton
资源:apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: allowlist-by-paths namespace: <namespace> spec: action: ALLOW rules: - to: - operation: paths: - /metrics 1 - /healthz 2
应用
AuthorizationPolicy
资源:$ oc apply -f <filename>
对于作为
ServiceMeshMemberRoll
对象中成员的每个无服务器应用程序命名空间,请创建以下AuthorizationPolicy
资源:apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: require-jwt namespace: <namespace> spec: action: ALLOW rules: - from: - source: requestPrincipals: ["testing@secure.istio.io/testing@secure.istio.io"]
应用
AuthorizationPolicy
资源:$ oc apply -f <filename>
验证
如果您尝试使用
curl
请求来获取 Knative 服务 URL,则会被拒绝:示例命令
$ curl http://hello-example-1-default.apps.mycluster.example.com/
输出示例
RBAC: access denied
使用有效 JWT 验证请求。
获取有效的 JWT 令牌:
$ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -
使用
curl
请求标头中的有效令牌访问该服务:$ curl -H "Authorization: Bearer $TOKEN" http://hello-example-1-default.apps.example.com
现在允许请求:
输出示例
Hello OpenShift!
6.3. 在 Service Mesh 1.x 中使用 JSON Web 令牌身份验证
您可以使用 Service Mesh 1.x 和 OpenShift Serverless 在 Knative 服务中使用 JSON Web Token (JWT) 身份验证。要做到这一点,您必须在作为 ServiceMeshMemberRoll
对象的成员的应用程序命名空间中创建策略。您还必须为该服务启用 sidecar 注入。
6.3.1. 为 Service Mesh 1.x 和 OpenShift Serverless 配置 JSON Web 令牌身份验证
在启用了 Kourier 时,不支持在系统命名空间中向 pod 添加 sidecar 注入,如 knative-serving
和 knative-serving-ingress
。
对于 OpenShift Container Platform,如果您需要对这些命名空间中的 pod 进行 sidecar 注入,请参阅 OpenShift Serverless 文档中的 将 Service Mesh 与 OpenShift Serverless 原生集成。
先决条件
- 您已在集群中安装了 OpenShift Serverless Operator、Knative Serving 和 Red Hat OpenShift Service Mesh。
-
安装 OpenShift CLI (
oc
) 。 - 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
流程
在您的服务中添加
sidecar.istio.io/inject="true"
注解:服务示例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: <service_name> spec: template: metadata: annotations: sidecar.istio.io/inject: "true" 1 sidecar.istio.io/rewriteAppHTTPProbers: "true" 2 ...
应用
Service
资源:$ oc apply -f <filename>
在作为
ServiceMeshMemberRoll
对象的成员的无服务器应用程序命名空间中创建策略,该策略只允许具有有效 JSON Web Tokens(JWT)的请求:重要路径
/metrics
和/healthz
必须包含在excludePaths
中,因为它们是从knative-serving
命名空间中的系统 pod 访问的。apiVersion: authentication.istio.io/v1alpha1 kind: Policy metadata: name: default namespace: <namespace> spec: origins: - jwt: issuer: testing@secure.istio.io jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/jwks.json" triggerRules: - excludedPaths: - prefix: /metrics 1 - prefix: /healthz 2 principalBinding: USE_ORIGIN
应用
Policy
资源:$ oc apply -f <filename>
验证
如果您尝试使用
curl
请求来获取 Knative 服务 URL,则会被拒绝:$ curl http://hello-example-default.apps.mycluster.example.com/
输出示例
Origin authentication failed.
使用有效 JWT 验证请求。
获取有效的 JWT 令牌:
$ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -
使用
curl
请求标头中的有效令牌访问该服务:$ curl http://hello-example-default.apps.mycluster.example.com/ -H "Authorization: Bearer $TOKEN"
现在允许请求:
输出示例
Hello OpenShift!
第 7 章 为 Serving 配置 kube-rbac-proxy
kube-rbac-proxy
组件为 Knative Serving 提供内部身份验证和授权功能。
7.1. 为 Serving 配置 kube-rbac-proxy 资源
您可以使用 OpenShift Serverless Operator CR 全局覆盖 kube-rbac-proxy
容器的资源分配。
You can also override resource allocation for a specific deployment.
以下配置设置 Knative Serving kube-rbac-proxy
最小值和最大 CPU 和内存分配:
KnativeServing CR 示例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: config: deployment: "kube-rbac-proxy-cpu-request": "10m" 1 "kube-rbac-proxy-memory-request": "20Mi" 2 "kube-rbac-proxy-cpu-limit": "100m" 3 "kube-rbac-proxy-memory-limit": "100Mi" 4
第 8 章 为 Knative 服务配置自定义域
8.1. 为 Knative 服务配置自定义域
Knative 服务会自动根据集群配置分配默认域名。例如,<service_name>-<namespace>.example.com
。您可以通过将您自己的自定义域名映射到 Knative 服务来自定义 Knative 服务域。
您可以通过为服务创建 DomainMapping
资源来完成此操作。您还可以创建多个 DomainMapping
资源,将多个域和子域映射到单个服务。
8.2. 自定义域映射
您可以通过将您自己的自定义域名映射到 Knative 服务来自定义 Knative 服务域。要将自定义域名映射到自定义资源(CR),您必须创建一个映射到可寻址目标 CR 的 DomainMapping
CR,如 Knative 服务或 Knative 路由。
8.2.1. 创建自定义域映射
您可以通过将您自己的自定义域名映射到 Knative 服务来自定义 Knative 服务域。要将自定义域名映射到自定义资源(CR),您必须创建一个映射到可寻址目标 CR 的 DomainMapping
CR,如 Knative 服务或 Knative 路由。
先决条件
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
-
安装 OpenShift CLI (
oc
) 。 - 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
您已创建了 Knative 服务,并控制要映射到该服务的自定义域。
注意您的自定义域必须指向 OpenShift Container Platform 集群的 IP 地址。
流程
在与您要映射的目标 CR 相同的命名空间中创建一个包含
DomainMapping
CR 的 YAML 文件:apiVersion: serving.knative.dev/v1alpha1 kind: DomainMapping metadata: name: <domain_name> 1 namespace: <namespace> 2 spec: ref: name: <target_name> 3 kind: <target_type> 4 apiVersion: serving.knative.dev/v1
服务域映射示例
apiVersion: serving.knative.dev/v1alpha1 kind: DomainMapping metadata: name: example.com namespace: default spec: ref: name: example-service kind: Service apiVersion: serving.knative.dev/v1
路由域映射示例
apiVersion: serving.knative.dev/v1alpha1 kind: DomainMapping metadata: name: example.com namespace: default spec: ref: name: example-route kind: Route apiVersion: serving.knative.dev/v1
将
DomainMapping
CR 应用为 YAML 文件:$ oc apply -f <filename>
8.3. 使用 Knative CLI 的 Knative 服务自定义域
您可以通过将您自己的自定义域名映射到 Knative 服务来自定义 Knative 服务域。您可以使用 Knative (kn
) CLI 创建映射到可寻址目标 CR 的 DomainMapping
自定义资源 (CR) ,如 Knative 服务或 Knative 路由。
8.3.1. 使用 Knative CLI 创建自定义域映射
先决条件
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
您已创建了 Knative 服务或路由,并控制要映射到该 CR 的自定义域。
注意您的自定义域必须指向 OpenShift Container Platform 集群的 DNS。
-
已安装 Knative (
kn
) CLI。 - 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
流程
将域映射到当前命名空间中的 CR:
$ kn domain create <domain_mapping_name> --ref <target_name>
示例命令
$ kn domain create example.com --ref example-service
--ref
标志为域映射指定一个可寻址的目标 CR。如果使用
--ref
标志时没有提供前缀,则会假定目标为当前命名空间中的 Knative 服务。将域映射到指定命名空间中的 Knative 服务:
$ kn domain create <domain_mapping_name> --ref <ksvc:service_name:service_namespace>
示例命令
$ kn domain create example.com --ref ksvc:example-service:example-namespace
将域映射到 Knative 路由:
$ kn domain create <domain_mapping_name> --ref <kroute:route_name>
示例命令
$ kn domain create example.com --ref kroute:example-route
8.4. 使用 Developer 视角的域映射
您可以通过将您自己的自定义域名映射到 Knative 服务来自定义 Knative 服务域。您可以使用 OpenShift Container Platform Web 控制台的 Developer 视角将 DomainMapping
自定义资源 (CR) 映射到 Knative 服务。
8.4.1. 使用 Developer 视角将自定义域映射到服务
先决条件
- 已登陆到 web 控制台。
- 处于 Developer 视角。
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。这必须由集群管理员完成。
- 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
您已创建了 Knative 服务,并控制要映射到该服务的自定义域。
注意您的自定义域必须指向 OpenShift Container Platform 集群的 IP 地址。
流程
- 导航到 Topology 页面。
-
右键单击要映射到某个域的服务,然后选择包含服务名称的 Edit 选项。例如,如果该服务命名为
example-service
,请选择 Edit example-service 选项。 在 Advanced options 部分中,点 Show advanced Routing options。
- 如果要映射到该服务的域映射 CR 已存在,您可以在域映射列表中选择。
-
如果要创建新域映射 CR,在框中输入域名,然后选择 Create 选项。例如,如果您在
example.com 中
键入,则 Create 选项为 Create "example.com"。
- 单击 Save,将更改保存到您的服务。
验证
- 导航到 Topology 页面。
- 单击您创建的服务。
- 在服务信息窗口的 Resources 选项卡中,您可以看到您映射到域映射中列出的服务的域。
8.5. 使用 Administrator 视角的域映射
如果您不想在 OpenShift Container Platform web 控制台中切换到 Developer 视角,或使用 Knative (kn
) CLI 或 YAML 文件,您可以使用 OpenShift Container Platform Web 控制台的 Administator 视角。
8.5.1. 使用 Administrator 视角将自定义域映射到服务
Knative 服务会自动根据集群配置分配默认域名。例如,<service_name>-<namespace>.example.com
。您可以通过将您自己的自定义域名映射到 Knative 服务来自定义 Knative 服务域。
您可以通过为服务创建 DomainMapping
资源来完成此操作。您还可以创建多个 DomainMapping
资源,将多个域和子域映射到单个服务。
如果您在 OpenShift Container Platform (或集群或 OpenShift Dedicated 或 Red Hat OpenShift Service on AWS)上具有集群管理员权限,您可以使用 web 控制台中的 Administrator 视角创建 DomainMapping
自定义资源(CR)。
先决条件
- 已登陆到 web 控制台。
- 您处于 Administrator 视角。
- 已安装 OpenShift Serverless Operator。
- 已安装 Knative Serving。
- 您已创建了一个项目,或者具有适当的角色和权限访问项目,以创建应用程序和其他工作负载。
您已创建了 Knative 服务,并控制要映射到该服务的自定义域。
注意您的自定义域必须指向集群的 IP 地址。
流程
- 导航到 CustomResourceDefinitions,并使用搜索框查找 DomainMapping 自定义资源定义 (CRD) 。
- 点 DomainMapping CRD,然后导航到 Instances 选项卡。
- 单击 Create DomainMapping。
修改
DomainMapping
CR 的 YAML,使其为您的实例包含以下信息:apiVersion: serving.knative.dev/v1alpha1 kind: DomainMapping metadata: name: <domain_name> 1 namespace: <namespace> 2 spec: ref: name: <target_name> 3 kind: <target_type> 4 apiVersion: serving.knative.dev/v1
到 Knative 服务的域映射示例
apiVersion: serving.knative.dev/v1alpha1 kind: DomainMapping metadata: name: custom-ksvc-domain.example.com namespace: default spec: ref: name: example-service kind: Service apiVersion: serving.knative.dev/v1
验证
使用
curl
请求访问自定义域。例如:示例命令
$ curl custom-ksvc-domain.example.com
输出示例
Hello OpenShift!
8.6. 使用 TLS 证书保护映射的服务
8.6.1. 使用 TLS 证书保护带有自定义域的服务
为 Knative 服务配置了自定义域后,您可以使用 TLS 证书来保护映射的服务。要做到这一点,您必须创建一个 Kubernetes TLS secret,然后更新 DomainMapping
CR 以使用您创建的 TLS secret。
如果您将 net-istio
用于 Ingress,并使用 security.dataPlane.mtls: true
通过 SMCP 启用 mTLS,Service Mesh 为 *.local
主机部署 DestinationRule
,这代表不允许对 OpenShift Serverless 使用 DomainMapping
。
要临时解决这个问题,部署 PeerAuthentication
来启用 mTLS,而不是使用 security.dataPlane.mtls: true
。
先决条件
-
为 Knative 服务配置了自定义域,并有一个正常工作的
DomainMapping
CR。 - 您有来自证书授权机构供应商或自签名证书的 TLS 证书。
-
您已从证书授权中心(CA)提供商或自签名证书获取
cert
和key
文件。 -
安装 OpenShift CLI (
oc
) 。
流程
创建 Kubernetes TLS secret:
$ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>
将
networking.internal.knative.dev/certificate-uid: <id>'
标签添加到 Kubernetes TLS secret 中:$ oc label secret <tls_secret_name> networking.internal.knative.dev/certificate-uid="<id>"
如果使用第三方 secret 供应商(如 cert-manager),您可以配置 secret manager 来自动标记 Kubernetes TLS secret。cert-manager 用户可以使用提供的 secret 模板自动生成带有正确标签的 secret。在本例中,secret 过滤仅基于键,但这个值可以存储有用的信息,如 secret 包含的证书 ID。
注意Red Hat OpenShift 的 cert-manager Operator 只是一个技术预览功能。如需更多信息,请参阅 为 Red Hat OpenShift 安装 cert-manager Operator 文档。
更新
DomainMapping
CR,以使用您创建的 TLS secret:apiVersion: serving.knative.dev/v1alpha1 kind: DomainMapping metadata: name: <domain_name> namespace: <namespace> spec: ref: name: <service_name> kind: Service apiVersion: serving.knative.dev/v1 # TLS block specifies the secret to be used tls: secretName: <tls_secret_name>
验证
验证
DomainMapping
CR 状态是否为True
,输出中的URL
列显示了使用 schemehttps
的映射域:$ oc get domainmapping <domain_name>
输出示例
NAME URL READY REASON example.com https://example.com True
可选: 如果服务公开,请运行以下命令验证该服务是否可用:
$ curl https://<domain_name>
如果证书是自签名的,请通过在
curl
命令中添加-k
标志来跳过验证。
8.6.2. 使用 secret 过滤改进 net-kourier 内存用量
默认情况下,Kubernetes client-go
库的 informers 实施会获取特定类型的所有资源。当有很多资源可用时可能会导致大量开销。这可能会导致因为内存泄露的问题导致 Knative net-kourier
ingress 控制器在大型集群中失败。但是,Knative net-kourier
ingress 控制器提供了一个过滤机制,它可让控制器只获取 Knative 相关的 secret。您可以通过将环境变量设置为 KnativeServing
自定义资源 (CR) 来启用此机制。
如果启用 secret 过滤,则所有 secret 都需要使用 networking.internal.knative.dev/certificate-uid: "<id>"
。否则,Knative Serving 不会检测到它们,这会导致失败。您必须标记新的和现有的 secret。
先决条件
- 在 OpenShift Container Platform 上具有集群管理员权限,或在 Red Hat OpenShift Service on AWS 或 OpenShift Dedicated 上具有集群或专用管理员权限。
- 您创建或具有创建应用程序和其他工作负载的角色和权限的项目。
- 安装 OpenShift Serverless Operator 和 Knative Serving。
-
安装 OpenShift CLI (
oc
) 。
流程
对于
KnativeServing
CR 中的net-kourier-controller
,将ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID
变量设置为true
:KnativeServing CR 示例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: deployments: - env: - container: controller envVars: - name: ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID value: 'true' name: net-kourier-controller
第 9 章 为 Knative 服务配置高可用性
9.1. Knative 服务的高可用性
高可用性 (HA) 是 Kubernetes API 的标准功能,有助于确保在出现中断时 API 保持正常运行。在 HA 部署中,如果活跃控制器崩溃或被删除,另一个控制器就可以使用。此控制器会接管处理由现在不可用的控制器提供服务的 API。
OpenShift Serverless 中的 HA 可通过领导选举机制获得,该机制会在安装 Knative Serving 和 Eventing control plane 后默认启用。在使用领导选举 HA 模式时,控制器实例在需要前应该已在集群内调度并运行。这些控制器实例争用共享资源,即领导选举锁定。在任何给定时间可以访问领导选举机制锁定资源的控制器实例被称为领导 (leader) 。
9.2. Knative 服务的高可用性
默认情况下,Knative Serving activator
, autoscaler
, autoscaler-hpa
, controller
, webhook
, kourier-control
, 和 kourier-gateway
组件支持高可用性(HA)功能,它们默认被配置为有两个副本。您可以通过修改 KnativeServing
自定义资源 (CR) 中的 spec.high-availability.replicas
值来更改这些组件的副本数。
9.2.1. 为 Knative Serving 配置高可用性副本
要为有资格的部署资源指定三个最小副本,请将自定义资源中的 spec.high-availability.replicas
的值设置为 3
。
先决条件
- 在 OpenShift Container Platform 上具有集群管理员权限,或在 Red Hat OpenShift Service on AWS 或 OpenShift Dedicated 上具有集群或专用管理员权限。
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
流程
- 在 OpenShift Container Platform web 控制台的 Administrator 视角中,进入 OperatorHub → Installed Operators。
-
选择
knative-serving
命名空间。 - 点 OpenShift Serverless Operator 的 Provided APIs 列表中的 Knative Serving 来进入 Knative Serving 选项卡。
点 knative-serving,然后使用 knative-serving 页面中的 YAML 选项卡。
修改
KnativeServing
CR 中的副本数量:YAML 示例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: high-availability: replicas: 3