操作程序配置示例

引用映像流 (.spec.applicationImage)

要从映像流中部署映像，必须在 CR 中指定 .spec.applicationImage 字段。

spec:
  applicationImage: my-namespace/my-image-stream:1.0

上一个示例是从 my-namespace 项目中的 my-image-stream 映像流中查找 1.0 标记，并使用所引用的映像（例如 image-registry.openshift-image-registry.svc:5000/my-namespace/my-image-stream@sha256:*****）填充 CR .status.imageReference 字段。 该操作程序会监视指定的映像流，并部署指定标记中出现的新映像。

要引用映像流，.spec.applicationImage 字段必须采用 project_name/image_stream_name[:tag] 格式。 如果未指定 project_name 或 tag，那么该操作程序将使用 CR 名称空间和 latest 的缺省值。 例如，applicationImage: my-image-stream 配置与 applicationImage: my-namespace/my-image-stream:latest 配置相同。

如果无法找到与值匹配的任何映像流，那么操作程序会尝试先查找具有 project_name/image_stream_name 格式的映像流名称，然后回退到注册表查找。

仅当您在 Red Hat® OpenShift® 上运行时，此功能才可用。 如果映像流资源位于另一个名称空间，那么操作程序需要 ClusterRole 许可权。

配置服务帐户 (.spec.serviceAccount)

操作员可在部署 WebSphereLibertyApplication 自定义资源 (CR) 时创建 ServiceAccount 资源。 如果 .spec.serviceAccount.name 则操作员会创建一个与 CR 名称相同的服务账户（如 my-app ）。 此外，当检测到 CR 字段中的拉动秘密发生变化时，会动态更新该服务帐户。 .spec.pullSecret.

或者，操作员可以使用您提供的自定义 ServiceAccount 。 如果 .spec.serviceAccount.name 在 CR 中指定，则操作员在配置新 Pod 时会使用原服务账户，权限为 read only 。 在访问私人注册表后面的图像时，您有责任向服务帐户添加任何所需的图像提取机密。

默认情况下，操作员会验证所使用的服务账户是否引用了有效的拉取密钥。 如果使用的是自定义服务账户，可通过在 CR 中将 .spec.serviceAccount.skipPullSecretValidation 设置为 true 来禁用此检查。

您可以设置 .spec.serviceAccount.mountToken 以禁用将服务帐户令牌安装到应用程序 pod 中。 缺省情况下，将安装服务帐户令牌。 此配置适用于操作员创建的缺省服务帐户或您提供的定制服务帐户。

如果应用程序需要特定许可权，但仍希望操作员创建 ServiceAccount，那么您可以手动创建角色绑定以将角色绑定到该操作员创建的服务帐户。 要了解有关基于角色的访问控制 (RBAC) 的更多信息，请参阅 Kubernetes 文档。

添加或更改标签 (.metadata.labels)

缺省情况下，操作程序会将以下标签添加到为 WebSphereLibertyApplication CR 创建的所有资源中。

您可以添加新标签或覆盖现有标签（不包括 app.kubernetes.io/instance 标签）。 要设置标签，请在 CR 中指定这些标签，就像 .metadata.labels 字段中的键/值对一样。

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
  labels:
    my-label-key: my-label-value
spec:
  applicationImage: quay.io/my-repo/my-app:1.0

在初始部署 CR 后，仅当更新 spec 字段时才会应用对其标签所做的任何更改。

在 Red Hat OpenShift 中运行时，该平台上还提供了一些其他标准标签和注释。 在适用的情况下覆盖缺省值，并使用前面的指示信息从 Red Hat OpenShift 列表中添加缺省情况下未设置的任何标签。

添加注释 (.metadata.annotations)

要将新注释添加到为 WebSphere Liberty 操作程序创建的所有资源中，请在 CR 中指定这些注释，就像 .metadata.annotations 字段中的键/值对一样。 CR 中的注释将覆盖在资源上指定的任何注释，但在 Service 上使用 .spec.service.annotations 设置的注释除外。

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
  annotations:
    my-annotation-key: my-annotation-value
spec:
  applicationImage: quay.io/my-repo/my-app:1.0

在初始部署 CR 后，仅当更新 spec 字段时才会应用对其注释所做的任何更改。

在 Red Hat OpenShift 中运行时，该平台上还提供了一些其他标准注释。 在适用的情况下覆盖缺省值，并使用前面的指示信息从 Red Hat OpenShift 列表中添加缺省情况下未设置的任何标签。

设置应用程序容器的环境变量（.spec.env 或 .spec.envFrom）

要设置应用程序容器的环境变量，请在 CR 中指定 .spec.env 或 .spec.envFrom 字段。 这些环境变量可以直接来自键/值对、ConfigMap 或 Secret。 由 .spec.env 或 .spec.envFrom 字段设置的环境变量将覆盖在容器映像中指定的任何环境变量。

使用 .spec.envFrom 将 ConfigMap 或 Secret 中的所有数据定义为容器中的环境变量。 ConfigMap 或 Secret 资源中的键将成为容器中的环境变量名称。 以下 CR 会在 .spec.env 和 .spec.envFrom 字段中设置键/值对。

spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  env:
    - name: DB_NAME
      value: "database"
    - name: DB_PORT
      valueFrom:
        configMapKeyRef:
          name: db-config
          key: db-port
    - name: DB_USERNAME
      valueFrom:
        secretKeyRef:
          name: db-credential
          key: adminUsername
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-credential
          key: adminPassword
  envFrom:
    - configMapRef:
        name: env-configmap
    - secretRef:
        name: env-secrets

有关使用 .spec.envFrom.secretRef 的另一个示例，请参阅使用环境变量获取基本认证凭证。 有关覆盖控制台日志记录环境变量缺省值的示例，请参阅 覆盖控制台日志记录环境变量缺省值 (.spec.env)。

覆盖控制台日志记录环境变量缺省值 (.spec.env)

缺省情况下， WebSphere Liberty 操作程序设置与控制台日志记录相关的环境变量。 您可以使用您在 CR .spec.env 列表中拥有的值来覆盖控制台日志记录缺省值。

下表列出了控制台日志记录环境变量及其缺省值。

要覆盖控制台日志记录环境变量的缺省值，请在 CR .spec.env 列表中手动设置首选值。 有关可设置的值的信息，请参阅 Open Liberty 日志记录文档。

以下示例显示了用于设置控制台日志记录环境变量的非缺省值的 CR .spec.env 列表。

spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  env:
    - name: WLP_LOGGING_CONSOLE_FORMAT
      value: "DEV"
    - name: WLP_LOGGING_CONSOLE_SOURCE
      value: "messages,trace,accessLog"
    - name: WLP_LOGGING_CONSOLE_LOGLEVEL
      value: "error"

有关覆盖变量默认值的更多信息，请参阅 为应用程序容器设置环境变量（.spec.env 或 .spec.envFrom ）。 有关监视应用程序和分析应用程序日志的信息，请参阅使用 WebSphere Liberty 操作程序进行观察

配置静态副本以实现高可用性 (. spec.replicas )

要使用固定数量的副本运行应用程序的多个实例以实现高可用性，请使用 .spec.replicas 字段。 无论资源消耗情况如何， .spec.replicas 字段都会保持恒定的应用实例数量。 使用 .spec.autoscaling 字段配置自动缩放时，此配置将被忽略。

配置水平 Pod 自动扩展以实现高可用性 (. spec.autoscaling )

设置 pod 或容器的特权和许可权 (.spec.securityContext)

安全上下文可控制 pod 或应用程序容器的特权和许可权设置。 缺省情况下，该操作程序会为应用程序容器设置多个 .spec.securityContext 参数，如以下示例中所示。

spec:
  containers:
    - name: app
      securityContext:
        capabilities:
          drop:
            - ALL
        privileged: false
        runAsNonRoot: true
        readOnlyRootFilesystem: false
        allowPrivilegeEscalation: false
        seccompProfile:
          type: RuntimeDefault

要覆盖缺省值或设置更多参数，请更改 .spec.securityContext 参数，例如:

spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  securityContext:
    readOnlyRootFilesystem: true
    runAsUser: 1001
    seLinuxOptions:
      level: "s0:c123,c456"

WebSphere Liberty 操作符将 securityContext 字段设置为 RuntimeDefault seccomp 配置文件。 如果 Kubernetes 集群使用自定义安全上下文限制，则 seccompProfiles 必须设置为 runtime/default。

要在 Kubernetes 集群中使用自定义安全上下文限制，请添加以下部分。

seccompProfiles:
  - runtime/default

如果应用程序要求禁用 seccomp，则必须在安全上下文限制和 WebSphereLibertyApplication CR 中将 seccompProfile 设置为 unconfined

seccompProfiles:
  - unconfined

spec:
  securityContext:
    seccompProfile:
      type: Unconfined

有关更多信息，请参阅设置容器的安全上下文。

持久资源（.spec.statefulSet 和 .spec.volumeMounts）

如果在 WebSphereLibertyApplication CR 中指定了存储器，那么操作程序可以为每个 pod 创建 StatefulSet 和 PersistentVolumeClaim 。 如果未指定存储器，那么将创建没有持久存储器的 StatefulSet 资源。

以下 CR 定义会使用 .spec.statefulSet.storage 来提供基本存储器。 该操作程序会创建大小为 1Gi 且安装到 /data 文件夹的 StatefulSet。

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  statefulSet:
    storage:
      size: 1Gi
      mountPath: "/data"

WebSphereLibertyApplication CR 定义可以提供更高级的存储器。 利用以下 CR 定义，该操作程序将创建一个名为 pvc 的 PersistentVolumeClaim，其大小为 1Gi 且采用 ReadWriteOnce 访问方式。 此操作程序使用户能够提供整个 .spec.statefulSet.storage.volumeClaimTemplate，以完全控制自动创建的 PersistentVolumeClaim。 要持久存储到多个文件夹，CR 定义需要使用 .spec.volumeMounts 字段，而不是 .spec.statefulSet.storage.mountPath。

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  volumeMounts:
  - name: pvc
    mountPath: /data_1
    subPath: data_1
  - name: pvc
    mountPath: /data_2
    subPath: data_2
  statefulSet:
    storage:
      volumeClaimTemplate:
        metadata:
          name: pvc
        spec:
          accessModes:
          - "ReadWriteMany"
          storageClassName: 'glusterfs'
          resources:
            requests:
              storage: 1Gi

以下 CR 定义未指定存储器，并创建没有持久存储器的 StatefulSet 资源。 如果仅需要一组 pod 的排序和唯一性，那么可以创建不带存储器的 StatefulSet 资源。

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  statefulSet: {}

监视资源 (.spec.monitoring)

WebSphere Liberty 操作程序可以创建 ServiceMonitor 资源，以便与 Prometheus 操作程序集成。

至少为 ServiceMonitor 对象上设置的 Prometheus 提供标签。 在以下示例中，.spec.monitoring 标签为 apps-prometheus。

spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  monitoring:
    labels:
       app-prometheus: ''
    endpoints:
    - interval: '30s'
      basicAuth:
        username:
          key: username
          name: metrics-secret
        password:
          key: password
          name: metrics-secret
      tlsConfig:
        insecureSkipVerify: true

要进行更高级的监视，请使用 Prometheus 端点设置许多 ServicerMonitor 参数（例如认证私钥）。

spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  monitoring:
    labels:
       app-prometheus: ''
    endpoints:
    - interval: '30s'
      basicAuth:
        username:
          key: username
          name: metrics-secret
        password:
          key: password
          name: metrics-secret
      tlsConfig:
        insecureSkipVerify: true

指定多个服务端口（.spec.service.port* 和 .spec.monitoring.endpoints）

如果除了主服务端口外还要提供多个服务端口，请使用 .spec.service.port、.spec.service.targetPort、.spec.service.portName 和 .spec.service.nodePort 字段配置主服务端口。 主端口是从运行应用程序的容器中公开的，而端口值可用于配置路由（或入口）、服务绑定和 Knative 服务。

要为“服务监视器”指定备用端口，请使用 .spec.monitoring.endpoints 字段并指定 port 或 targetPort 字段，否则将缺省为主端口。

使用 .spec.service.port 字段指定主端口，并使用 .spec.service.ports 字段指定其他端口，如以下示例中所示。

spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  service:
    type: NodePort
    port: 9080
    portName: http
    targetPort: 9080
    nodePort: 30008
    ports:
      - port: 9443
        name: https
  monitoring:
    endpoints:
      - basicAuth:
          password:
            key: password
            name: metrics-secret
          username:
            key: username
            name: metrics-secret
        interval: 5s
        port: https
        scheme: HTTPS
        tlsConfig:
          insecureSkipVerify: true
    labels:
      app-monitoring: 'true'

配置探测器 (.spec.probes)

探测器是对应用程序容器执行的运行状况检查，用于确定它处于存活状态还是就绪状态来接收流量。 WebSphere Liberty 操作程序具有 startup、liveness 和 readiness 探测器。

缺省情况下，在应用程序中不会启用探测器。 要使用缺省值启用探测器，请将探测器参数设置为 {}。 以下示例使所有 3 个探测器都使用缺省值。

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
spec:
  probes:
    startup: {}
    liveness: {}
    readiness: {}

  httpGet:
    path: /health/started
    port: 9443
    scheme: HTTPS
  timeoutSeconds: 2
  periodSeconds: 10
  failureThreshold: 20

  httpGet:
    path: /health/live
    port: 9443
    scheme: HTTPS
  initialDelaySeconds: 60
  timeoutSeconds: 2
  periodSeconds: 10
  failureThreshold: 3

  httpGet:
    path: /health/ready
    port: 9443
    scheme: HTTPS
  initialDelaySeconds: 10
  timeoutSeconds: 2
  periodSeconds: 10
  failureThreshold: 10

要覆盖缺省值，请指定其他值。 以下示例将覆盖存活探测器初始延迟缺省值 60 秒，并将初始延迟设置为 90 秒。

spec:
  probes:
    liveness:
      initialDelaySeconds: 90

当探测器 initialDelaySeconds 参数设置为 0 时，将使用缺省值。 要将探测器初始延迟设置为 0，请定义探测器，而不是使用缺省探测器。 以下示例将覆盖缺省值并将初始延迟设置为 0。

spec:
  probes:
    liveness:
      httpGet:
        path: "/health/live"
        port: 9443
      initialDelaySeconds: 0

使用 mpHealth-4.0 (.spec.probes.enableFileBased ) 配置基于文件的探针

从 Liberty 操作员版本 开始，新增的布尔字段 允许您通过 1.5.2 健康 4.0 MicroProfile 功能设置基于文件的健康检查。 .spec.probes.enableFileBased

基于文件的探针在应用程序中默认处于禁用状态。 操作符 Liberty 默认使用 HTTP GET 探针。

• 在 处 .spec.applicationImage 指定的图像 Liberty 需要在运行版本 25.0.0.6 或更高版本的Liberty服务器上安装并启用 功能 mpHealth-4.0 。
• 要启用基于文件的探针并使用默认值，请将 enableFileBased 设置为 true ，并将探针参数设置为 {}。 以下示例使三个探针均采用基于文件的默认值。

  spec:
    probes:
      enableFileBased: true
      startup: {}
      liveness: {}
      readiness: {}

基于文件的启动、存活和就绪探测继承了与 《配置探测器》 章节所述相同的 spec.probes 默认值（无需设置 httpGet）。

启用基于文件的探针后， Liberty 操作员将配置应用程序以监控容器内 目录 /output/health 中的文件。

sh-4.4$ ls -la /output/health
total 0
drwxr-x---. 2 1000730000 root 46 Nov 21 16:07 .
drwxrwx---. 1 default    root 65 Nov 21 16:07 ..
-rw-r-----. 1 1000730000 root  0 Nov 21 16:07 live
-rw-r-----. 1 1000730000 root  0 Nov 21 16:07 ready
-rw-r-----. 1 1000730000 root  0 Nov 21 16:07 started

每隔几秒，使用该 mpHealth-4.0 功能的服务器 Liberty 可能会创建/更新、 ready 和 started 文件 live，将其时间戳更新为新调整的值，以表明运行状态。 检查这些文件 Liberty 的时间间隔可通过 和 .spec.probes.startupCheckInterval .spec.probes.checkInterval 字段进行修改。 默认情况下，这些检查间隔分别设置为 5s 和 100ms。

spec:
  probes:
    enableFileBased: true
    startup: {}
    liveness: {}
    readiness: {}
    checkInterval: 5s
    startupCheckInterval: 100ms

为与非文件型探针的行为保持一致，请将 Liberty 服务器配置为以快于执行单次探测 Kubernetes 所需的时间来检查 live、 ready或 started 文件。 例如，设置一个缓冲区，使得检查间隔保持该属性 interval * 1.5 ⇐ periodSeconds。 在此情况下，探针 WebSphereLibertyApplication 的默认 periodSeconds 值为 10，该值满足约束条件，其检查间隔分别为 5s 和 100ms。 若修改, checkInterval, 或 startupCheckInterval periodSeconds属性值，请保持此约束以避免意外的 pod 停机时间。

spec:
  probes:
    enableFileBased: true
    startup:
      # periodSeconds: 10
    liveness:
      # periodSeconds: 10
    readiness:
      # periodSeconds: 10
    checkInterval: 5s
    startupCheckInterval: 100ms

使用 Knative 部署无服务器应用程序 (.spec.createKnativeService)

如果已在 Kubernetes 集群上安装了 Knative，那么要使用 Knative 在集群上部署无服务器应用程序，该操作程序需要创建 Knative Service 资源来管理工作负载的整个生命周期。 要创建 Knative 服务，请将 .spec.createKnativeService 设置为 true。

spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  createKnativeService: true

该操作程序会在集群中创建 Knative 服务，并使用相应 WebSphereLibertyApplication 字段填充该资源。 此外，它还确保已删除 Kubernetes Service、Route 和 Deployment 等非 Knative 资源。

可填充 Knative 服务资源的 CRD 字段包括 .spec.applicationImage、.spec.serviceAccount.name、.spec.probes.liveness、.spec.probes.readiness、.spec.service.Port、.spec.volumes、.spec.volumeMounts、.spec.env、.spec.envFrom、.spec.pullSecret 和 .spec.pullPolicy。 Knative 不完全支持启动探测器，因此在启用 Knative 服务时 .spec.probes.startup 不适用。

有关如何为任务（例如，启用 HTTPS 连接和设置定制域）配置 Knative 的详细信息，请参阅 Knative 文档。

WebSphereLibertyApplication 中的自动缩放字段不可用于配置 Knative Pod Autoscaler (KPA)。 要了解如何配置 KPA，请参阅配置 Autoscaler。

向外部公开应用程序（.spec.expose、.spec.createKnativeService、.spec.route）

使用“路由”、“Knative 路由”或“入口”资源向外部公开应用程序。

要使用非 Knative 部署中的路由向外部公开应用程序，请将 .spec.expose 设置为 true。

启用 .spec.manageTLS 后，操作程序根据应用程序服务创建受保护路由。 要使用定制证书，请参阅有关 .spec.service.certificateSecretRef 和 .spec.route.certificateSecretRef 的信息。

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  expose: true

要在非 Knative 部署中使用“入口”资源向外部公开应用程序，请完成以下步骤。

1. 要使用“入口”资源公开集群，请安装入口控制器，例如 Nginx 或 Traefik。
2. 确保 Route 资源不在集群中。 仅当集群中不存在 Route 资源时，才会创建“入口”资源。
3. 要使用 Ingress 资源，请将 Operator 对象 ConfigMap 中的变量 defaultHostName 设置为主机名，例如： mycompany.com
4. 启用 TLS。 生成一个证书，并使用 .spec.route.certificateSecretRef 字段指定包含该证书的私钥。

   apiVersion: liberty.websphere.ibm.com/v1
   Kind: WebSphereLibertyApplication
   metadata:
     name: my-app
     namespace: backend
   spec:
     applicationImage: quay.io/my-repo/my-app:1.0
     expose: true
     route:
       certificateSecretRef: mycompany-tls

5. 指定 .spec.route.annotations 以配置“入口”资源。 Nginx、HAProxy、Traefik 等注释专门用于入口控制器实现。

   以下示例指定注释，现有 TLS 私钥和定制主机名。

   apiVersion: liberty.websphere.ibm.com/v1
   Kind: WebSphereLibertyApplication
   metadata:
     name: my-app
     namespace: backend
   spec:
     applicationImage: quay.io/my-repo/my-app:1.0
     expose: true
     route:
       annotations:
         # You can use this annotation to specify the name of the ingress controller to use.
         # You can install multiple ingress controllers to address different types of incoming traffic such as an external or internal DNS.
         kubernetes.io/ingress.class: "nginx"
   
         # The following nginx annotation enables a secure pod connection:
         nginx.ingress.kubernetes.io/ssl-redirect: true
         nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
   
         # The following traefik annotation enables a secure pod connection:
         traefik.ingress.kubernetes.io/service.serversscheme: https
   
       # Use a custom hostname for the Ingress
       host: app-v1.mycompany.com
       # Reference a pre-existing TLS secret:
       certificateSecretRef: mycompany-tls

要将应用程序公开为 Knative 服务，请将 .spec.createKnativeService 和 .spec.expose 设置为 true。 操作程序会创建不安全的 Knative 路由。 要为 Knative 部署配置安全的 HTTPS 连接，请参阅使用 TLS 证书配置 HTTPS。

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  createKnativeService: true
  expose: true

允许或限制入局流量 (.spec.networkPolicy)

缺省情况下，应用程序的网络策略会隔离入局流量。

• 为未公开应用程序创建的缺省网络策略会将入局流量限制为同一名称空间中属于同一应用程序的 pod。 流量仅限于服务所配置的端口。 默认情况下，在指定流量时，流量将暴露在 .spec.service.targetPort 中，否则将退回到使用 .spec.service.port 。 使用相同的逻辑，.spec.service.ports[] 数组中提供的每一个额外 targetPort 或 port 都将暴露流量。
• 缺省情况下，Red Hat OpenShift 支持网络策略。 对于 Red Hat OpenShift 上公开的应用程序，网络策略允许来自服务配置端口上的 Red Hat OpenShift 入口控制器的入局流量。 网络策略还允许来自 Red Hat OpenShift 监视堆栈的入局流量。
• 对于其他 Kubernetes 平台上公开的应用程序，网络策略允许来自服务配置端口上任何名称空间中的任何 pod 的入局流量。 对于部署到其他 Kubernetes 平台的情况，请确保您的网络插件支持网络 Kubernetes 策略。

要禁止为应用程序创建网络策略，请将 .spec.networkPolicy.disable 设置为 true。

spec:
  networkPolicy:
    disable: true

您可以更改网络策略以允许来自特定名称空间或 pod 的入局流量。 缺省情况下，.spec.networkPolicy.namespaceLabels 会设置为用于部署该应用程序的名称空间，.spec.networkPolicy.fromLabels 会设置为属于 .spec.applicationName 指定的应用程序的 pod。 以下示例允许来自标有 frontend 角色且位于同一名称空间中的 pod 的入局流量。

spec:
  networkPolicy:
    fromLabels:
      role: frontend

以下示例允许来自属于 example 名称空间中同一应用程序的 pod 的入局流量。

spec:
  networkPolicy:
    namespaceLabels:
      kubernetes.io/metadata.name: example

以下示例允许来自在 example 名称空间中标有 frontend 角色的 pod 的入局流量。

spec:
  networkPolicy:
    namespaceLabels:
      kubernetes.io/metadata.name: example
    fromLabels:
      role: frontend

将应用程序与操作程序管理的后备服务绑定在一起（.status.binding.name 和 .spec.service.bindable）

使用 Service Binding Operator，应用程序开发人员可以将应用程序与操作程序管理的后备服务绑定在一起。 如果在集群上安装了 Service Binding Operator，那么可以通过创建 ServiceBindingRequest 定制资源来绑定应用程序。

您可以将 WebSphere Liberty 应用程序配置为充当服务绑定规范所定义的供应服务。 根据该规范，“供应服务”资源必须定义用于引用私钥的 .status.binding.name。 要将应用程序公开为“供应服务”，请将 .spec.service.bindable 字段设置为值 true。 操作程序将创建名为 CR_NAME-expose-binding 的 绑定私钥 ，并将 host， port， protocol， basePath和 uri 条目添加到私钥。

要覆盖绑定私钥中条目的缺省值或将新条目添加到私钥，请创建名为 CR_NAME-expose-binding-override 的 覆盖私钥 并将任何条目添加到私钥。 操作程序将读取覆盖私钥的内容，并覆盖绑定私钥中的缺省值。

在 WebSphere Liberty 应用程序公开为“供应服务”后，服务绑定请求可以将该应用程序作为后备服务进行引用。

以下指示信息显示如何将作为服务或生产者的 WebSphere Liberty 应用程序绑定到其他工作负载（例如，pod 或部署）。 无法绑定通过 WebSphere Liberty 操作程序部署的两个 WebSphere Liberty 应用程序。 有关更多信息，请参阅已知问题和限制。

• 设置服务绑定操作程序以访问 WebSphere Liberty 应用程序。
  缺省情况下，服务绑定操作程序无权与通过 WebSphere Liberty 操作程序部署的 WebSphere Liberty 应用程序进行交互。 您必须创建两个 RoleBinding 以授予服务绑定操作程序查看和编辑 WebSphere Liberty 应用程序的访问权。

  1. 在仪表板 Red Hat OpenShift 中，导航至用户管理 > RoleBindings。
  2. 选择创建绑定。
  3. 将绑定类型设置为 Cluster-wide role binding (ClusterRoleBinding)。
  4. 输入绑定的名称。 选择与 WebSphere 应用程序的服务绑定和视图访问权相关的名称。
  5. 对于角色名称，请输入 webspherelibertyapplications.liberty.websphere.ibm.com-v1-view。
  6. 将主题设置为 ServiceAccount。
  7. 这会显示主题名称空间菜单。 选择 openshift-operators。
  8. 在主题名称字段中，输入 service-binding-operator。
  9. 单击创建。
  现在，您已设置第一个角色绑定，请浏览至 RoleBindings 列表，然后再次单击创建绑定。 使用以下指示信息来设置编辑访问权。

  1. 将绑定类型设置为 Cluster-wide role binding (ClusterRoleBinding)。
  2. 输入绑定的名称。 选择与 WebSphere 应用程序的服务绑定和编辑访问权相关的名称。
  3. 在“角色名称”字段中，输入 webspherelibertyapplications.liberty.websphere.ibm.com-v1-edit。
  4. 将主题设置为 ServiceAccount。
  5. 在主题名称空间列表中，选择 openshift-operators。
  6. 在主题名称字段中，输入 service-binding-operator。
  7. 单击创建。

  从 WebSphere Liberty 应用程序（或“服务”）至 pod 或部署（或“工作负载”）的服务绑定现在成功。 进行绑定后，绑定工作负载将重新启动或扩展以将绑定私钥安装至所有容器中的 /bindings。

• 使用 Red Hat 方法设置服务绑定。
  有关更多信息，请参阅 Red Hat 文档或 Red Hat 教程。

  1. 在 Red Hat OpenShift Web 仪表板上，单击侧边栏中的 管理员 ，然后选择 开发者。
  2. 在当前名称空间的拓扑视图中，将鼠标指针悬停在要作为服务绑定的 WebSphere 应用程序的边框上并将箭头拖至 Pod 或部署工作负载。 这会显示标题为创建服务绑定的工具提示。
  3. 这会打开创建服务绑定窗口。 将名称更改为少于 63 个字符的值。 如果名称长度超过 63 个字符，那么服务绑定操作程序可能无法将私钥安装为卷。
  4. 单击创建。
  5. 此时将打开侧边栏。 要查看该绑定的状态，请单击该私钥的名称，然后滚动直到显示状态。
  6. 检查 pod/部署工作负载并验证是否已安装卷。 您还可在容器中打开终端会话并运行 ls /bindings。
• 使用“规范 API 技术预览/社区”方法设置服务绑定。
  此方法比 Red Hat 方法更新，但会获得相同的结果。 如果 WebSphere Liberty 应用程序（例如，app=frontend）没有任何唯一标签，那么必须将标签添加至该应用程序。 设置绑定以使用标签选择器，以便服务绑定操作程序查找具有特定标签的 WebSphere Liberty 应用程序。

  1. 使用 Red Hat OpenShift 操作程序目录安装服务绑定操作程序。
  2. 选择操作符 > 已安装操作符 ，并将命名空间设置为应用程序 WebSphere 和 pod/部署工作负载所共用的命名空间。
  3. 打开服务绑定（规范 API 技术预览）页面。
  4. 单击创建服务绑定。
  5. 选择用于绑定的短名称。 长度超过 63 个字符的名称可能会导致绑定私钥卷安装失败。
  6. 展开 服务 部分。
  7. 在 API 版本字段中，输入 liberty.websphere.ibm.com/v1。
  8. 在种类字段中，输入 WebSphereLibertyApplication。
  9. 在名称字段中，输入应用程序的名称。 您可从 WebSphere Liberty 操作程序页面上的应用程序列表中获取此名称。
  10. 展开工作负载部分。
  11. 将 API 版本字段设置为目标工作负载 YAML 中 apiVersion 的值。 例如，如果工作负载是部署，那么该值为 apps/v1。
  12. 将种类字段设置为目标工作负载 YAML 中 kind 的值。 例如，如果工作负载是部署，那么该值为 Deployment。
  13. 展开选择器子节，然后展开匹配表达式子节。
  14. 单击添加匹配表达式。
  15. 在键字段中，输入您先前设置的标签键。 例如，对于标签 app=frontend，键为 app)。
  16. 在操作程序字段中，输入 Exists。
  17. 展开值子节并单击添加值。
  18. 在值字段中，输入您先前设置的标签值。 例如，如果使用标签 app=frontend，那么该值为 frontend。
  19. 单击创建。
  20. 检查 Pod/部署工作负载并验证是否已安装卷，方法是向下滚动或打开终端会话到容器中并运行 ls /bindings。

将 pod 限制为在指定节点上运行 (.spec.affinity)

使用 .spec.affinity，将 Pod 限制为仅在指定的节点上运行。

要设置必需的标签以便在特定节点上调度 pod，请使用 .spec.affinity.nodeAffinityLabels 字段。

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
  namespace: test
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  affinity:
    nodeAffinityLabels:
      customNodeLabel: label1, label2
      customNodeLabel2: label3

以下示例将需要两个区域（分别名为 zoneA 和 zoneB）的 large 节点类型和首选项。

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
  namespace: test
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key:  node.kubernetes.io/instance-type
            operator: In
            values:
            - large
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 60
        preference:
          matchExpressions:
          - key: failure-domain.beta.kubernetes.io/zone
            operator: In
            values:
            - zoneA
      - weight: 20
        preference:
          matchExpressions:
          - key: failure-domain.beta.kubernetes.io/zone
            operator: In
            values:
            - zoneB

使用 pod 亲缘关系和反亲缘关系，以限制可根据节点上运行的 pod 的标签（而不是根据节点的标签）调度 pod 的节点。

以下示例显示 pod 亲缘关系是必需的并且 Service-A 和 Service-B 的 pod 必须位于同一区域中。 通过 pod 反亲缘关系，最好不要在同一台主机上调度 Service_B 和 Service_C。

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: Service-B
  namespace: test
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: service
            operator: In
            values:
            - Service-A
        topologyKey: failure-domain.beta.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: service
              operator: In
              values:
              - Service-C
          topologyKey: kubernetes.io/hostname

限制 pod 在节点和区域之间的分布（.spec.topologySpreadConstraints)

使用 .spec.topologySpreadConstraints YAML 对象来指定应用程序实例（以及 Semeru Cloud Compiler 实例（如果启用））的 pod 在群集节点和区域之间的分布限制。

使用 .spec.topologySpreadConstraints.constraints 字段，您可以指定要添加的 TopologySpreadConstraints Pod 列表，例如以下示例：

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
  namespace: test
spec:
  topologySpreadConstraints:
    constraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app.kubernetes.io/instance: my-app

默认情况下，操作员会在应用程序实例的 pod（以及 Semeru Cloud Compiler 实例的 pod（如适用））上添加以下 Pod 拓扑扩展约束。 默认行为是限制由同一应用程序实例（或 Semeru Cloud Compiler 生成实例）拥有的 pod 的传播，这些 pod 由 <实例名称> 表示， maxSkew ： 1。

- maxSkew: 1
  topologyKey: kubernetes.io/hostname
  whenUnsatisfiable: ScheduleAnyway
  labelSelector:
    matchLabels:
      app.kubernetes.io/instance: <instance name>
- maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: ScheduleAnyway
  labelSelector:
    matchLabels:
      app.kubernetes.io/instance: <instance name>

要移除操作符的默认拓扑扩展限制，请将 .spec.topologySpreadConstraints.disableOperatorDefaults 标志设为 true。

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
  namespace: test
spec:
  topologySpreadConstraints:
    disableOperatorDefaults: true

或者，通过在 .spec.topologySpreadConstraints.constraints 下为每个要修改的 topologyKey 创建一个新的 TopologySpreadConstraint 来手动覆盖每个约束。

配置 DNS（.spec.dns.policy 和 .spec.dns.config)

DNS 可在 WebSphereLibertyApplication CR 中使用 .spec.dns.policy 字段或 .spec.dns.config 字段进行配置。 .spec.dns.policy 字段是应用程序 pod 的 DNS 策略，默认为 ClusterFirst 策略。 .spec.dns.config 字段是应用程序 pod 的 DNS 配置。

DNS 配置允许用户对应用 Pod 的 DNS 设置进行更多控制。

.spec.dns.config 字段是可选的，它可以与任何 .spec.dns.policy 设置一起使用。 但是，当 .spec.dns.policy 设置为 None 时，必须指定 .spec.dns.config 字段。

spec:
  dns:
    policy: "None"
    config:
      nameservers:
        - 192.0.2.1 # this is an example
      searches:
        - ns1.svc.cluster-domain.example
        - my.dns.search.suffix
      options:
        - name: ndots
          value: "2"
        - name: edns0

有关 DNS 的更多信息，请参阅 DNS Kubernetes 文档。

配置容差 (.spec.tolerations)

节点亲和性是一种属性，它可以作为一种偏好或硬性要求将 pod 吸引到一组节点上。 不过，污点允许节点排斥一组 pod。

阈值适用于 pod，允许调度程序对具有匹配阈值的 pod 进行调度。 调度程序还会评估其他参数作为其功能的一部分。

污点和容忍度共同作用，有助于确保应用程序 pod 不会被调度到不合适的节点上。 如果在节点上应用了一个或多个污点，该节点就不能接受任何不能容忍污点的 pod。

可使用 .spec.tolerations 字段在 WebSphereLibertyApplication CR 中配置迭代。

spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"

有关污点和容忍的更多信息，请参阅污点和 Kubernetes 容忍文档。