4.3. 配置无服务器应用程序
4.3.1. 覆盖 Knative Serving 系统部署配置
您可以通过修改 KnativeServing
自定义资源(CR)中的 deployments
spec 来覆盖某些特定部署的默认配置。
4.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
相关的字段除外。
4.3.2. EmptyDir 卷
emptyDir
卷是创建 pod 时创建的空卷,用来提供临时工作磁盘空间。当为其创建 pod 被删除时,emptyDir
卷会被删除。
4.3.2.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 ...
4.3.3. Serving 的持久性卷声明
有些无服务器应用程序需要持久性数据存储。要做到这一点,您可以为 Knative 服务配置持久性卷声明 (PVC) 。
4.3.3.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 容器用户的用户权限。
4.3.3.2. 其他资源
4.3.4. init 容器
Init 容器是 pod 中应用程序容器之前运行的专用容器。它们通常用于为应用程序实施初始化逻辑,其中可能包括运行设置脚本或下载所需的配置。您可以通过修改 KnativeServing
自定义资源 (CR) 来启用 init 容器用于 Knative 服务。
Init 容器可能会导致应用程序的启动时间较长,应该谨慎地用于无服务器应用程序,这应该经常被扩展或缩减。
4.3.4.1. 启用 init 容器
先决条件
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
- 有集群管理员权限。
流程
通过在
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 ...
4.3.5. 将镜像标签解析到摘要
如果 Knative Serving 控制器可以访问容器 registry,Knative Serving 会在创建服务的修订时将镜像标签解析为摘要。这被称为 tag-to-digest 解析,有助于为部署提供一致性。
4.3.5.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
配置映射,并将配置映射作为卷挂载到控制器。
4.3.5.1.1. 使用 secret 配置 tag-to-digest 解析
如果 controller-custom-certs
spec 使用 Secret
类型,secret 将被挂载为 secret 卷。Knative 组件直接使用 secret,假设 secret 具有所需的证书。
先决条件
- 在 OpenShift Container Platform 上具有集群管理员权限。
- 您已在集群中安装了 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
4.3.6. 配置 TLS 身份验证
您可以使用 传输层安全 (TLS) 加密 Knative 流量并进行身份验证。
TLS 是 Knative Kafka 唯一支持的流量加密方法。红帽建议将 SASL 和 TLS 同时用于 Knative Kafka 资源。
如果要使用 Red Hat OpenShift Service Mesh 集成启用内部 TLS,您必须使用 mTLS 启用 Service Mesh,而不是按照以下流程所述的内部加密。 请参阅在使用带有 mTLS 的 Service Mesh 时启用 Knative Serving 指标的文档。
4.3.6.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
4.3.7. 限制网络策略
4.3.7.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: []
4.3.7.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