4.3. 配置无服务器应用程序

4.3.1. 覆盖 Knative Serving 系统部署配置

您可以通过修改 KnativeServing 自定义资源(CR)中的 deployments spec 来覆盖某些特定部署的默认配置。

4.3.1.1. 覆盖系统部署配置

目前,支持覆盖 resources, replicas, labels, annotations, 和 nodeSelector 项的默认配置设置,以及探测的 readinessliveness 字段的默认设置。

在以下示例中,KnativeServing CR 会覆盖 Webhook 部署,以便:

  • net-kourier-controllerreadiness 探测超时设置为 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
您可以使用 readinessliveness 探测覆盖来覆盖在 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 支持

流程

  1. 要启用 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 是否使用写入访问权限。
  2. 要声明 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

    1
    卷挂载规格。
    2
    持久性卷声明规格。
    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。

流程

  1. 创建 secret:

    示例命令

    $ oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate>

  2. 配置 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。

流程

  1. 在 spec 中创建一个包含 internal-encryption: "true" 字段的 Knative 服务:

    ...
    spec:
      config:
        network:
          internal-encryption: "true"
    ...
  2. 重启 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。

流程

  1. knative.openshift.io/system-namespace=true 标签添加到需要访问应用程序的每个 Knative 系统命名空间:

    1. 标记 knative-serving 命名空间:

      $ oc label namespace knative-serving knative.openshift.io/system-namespace=true
    2. 标记 knative-serving-ingress 命名空间:

      $ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true
    3. 标记 knative-eventing 命名空间:

      $ oc label namespace knative-eventing knative.openshift.io/system-namespace=true
    4. 标记 knative-kafka 命名空间:

      $ oc label namespace knative-kafka knative.openshift.io/system-namespace=true
  2. 在应用程序命名空间中创建一个 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

    1
    为您的网络策略提供名称。
    2
    应用程序所在的命名空间。