操作器配置範例

瀏覽 WebSphere® Liberty 操作器範例，以瞭解如何使用自訂資源 (CR) 參數來配置操作器。

如需 WebSphereLibertyApplication 自訂資源定義 (CRD) 可配置參數的相關資訊，請參閱 WebSphereLibertyApplication 自訂資源。

參照映像檔串流 (.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.serviceAccountName)

當操作器部署 WebSphere Liberty 操作器 CR 時，它可以建立 ServiceAccount 資源。如果未在 CR 中指定 .spec.serviceAccountName，則操作器會建立與 CR 同名的服務帳戶，例如 my-app。

如果應用程式需要特定許可權，但仍希望操作器建立 ServiceAccount，您可以手動建立角色連結，以將角色連結至所操作建立的服務帳戶。若要進一步瞭解角色型存取控制 (RBAC)，請參閱 Kubernetes 文件。

新增或變更標籤 (.metadata.labels)

依預設，操作器會將下列標籤新增至針對 WebSphere Liberty 操作器 CR 建立的所有資源。

表 1. WebSphere Liberty 運算子標籤預設值
標籤	預設值	說明：
`app.kubernetes.io/instance`	`metadata.name`	此元件的唯一名稱或 ID。您無法變更預設值。
`app.kubernetes.io/name`	`metadata.name`	此名稱代表此元件。
`app.kubernetes.io/managed-by`	`websphere-liberty-operator`	此工具用於管理此元件。
`app.kubernetes.io/component`	`backend`	所建立元件的類型。如需完整清單，請參閱 Red Hat OpenShift 文件。
`app.kubernetes.io/part-of`	`applicationName`	此元件所屬較高層次應用程式的名稱。如果元件不是獨立式應用程式，請配置此標籤。
`app.kubernetes.io/version`	`version`	元件的版本。

您可以新增標籤或改寫現有標籤，但 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 清單中，將主控台記載預設值置換為您自己的值。

下表列出主控台記載環境變數及其預設值。

表 2. 預設主控台記載環境變數
變數名稱	預設值
`WLP_LOGGING_CONSOLE_LOGLEVEL`	`info`
`WLP_LOGGING_CONSOLE_SOURCE`	`message,accessLog,ffdc,audit`
`WLP_LOGGING_CONSOLE_FORMAT`	`json`

若要置換主控台記載環境變數的預設值，請在 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.autoscaling）

若要執行應用程式的多個實例以取得高可用性，請針對多個靜態實例使用 .spec.replicas 欄位，或針對自動調整大小使用 .spec.autoscaling 欄位，這會根據資源耗用自動建立或刪除實例。自動調整大小需要 .spec.autoscaling.maxReplicas 和 .spec.resources.requests.cpu 欄位。

設定 Pod 或儲存器的專用權及許可權 (.spec.securityContext)

安全環境定義會控制 Pod 或應用程式儲存器的專用權及許可權設定。依預設，操作器會為應用程式儲存器設定數個 .spec.securityContext 參數，如下列範例所示。

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

若要置換預設值或設定更多參數，請變更 .spec.securityContext 參數，例如:


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

如需相關資訊，請參閱設定儲存器的安全環境定義。如需安全環境定義參數的相關資訊，請參閱 SecurityContext v1 核心

持續保存資源（.spec.statefulSet 和 .spec.volumeMounts）

如果在 WebSphere Liberty 操作器 CR 中指定儲存體，則操作器可以為每一個 Pod 建立 StatefulSet 和 PersistentVolumeClaim。如果未指定儲存體，則會建立不含持續性儲存體的 StatefulSet 資源。

下列 CR 定義使用 .spec.statefulSet.storage 來提供基本儲存體。操作器會建立大小為 1Gi 的 StatefulSet，以裝載至 /data 資料夾。

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"

WebSphere Liberty 操作器 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

限制: 建立 StatefulSet 之後，無法新增或變更持續性儲存體及 PersistentVolumeClaim 。

下列 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 操作器整合。

限制: 操作員監視不支援與 Knative Service 整合。需要 Prometheus 運算子才能使用 ServiceMonitor。

至少為 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 欄位來配置主要服務埠。主要埠是從執行應用程式的儲存器公開，而埠值是用來配置路徑 (或 Ingress)、服務連結及 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: {}

下列程式碼 Snippet 顯示 startup 探測器的預設值。


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

下列程式碼 Snippet 顯示 liveness 探測器的預設值。


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

下列程式碼 Snippet 顯示 readiness 探測器的預設值。


  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

使用 Knative (.spec.createKnativeService) 部署無伺服器應用程式

如果 Knative 安裝在 Kubernetes 叢集上，若要在叢集上部署具有 Knative 的無伺服器應用程式，則操作器會建立 Knative Service 資源，以管理工作量的整個生命週期。若要建立 Knative 服務，請將 .spec.createKnativeService 設為 true。

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

操作器會在叢集中建立 Knative 服務，並在資源中移入適用的 WebSphereLibertyApplication 欄位。此外，它還可確保刪除非 Knative 資源，例如 Kubernetes Service、Route 及 Deployment。

可以移入 Knative 服務資源的 CRD 欄位包括 .spec.applicationImage、 .spec.serviceAccountName、 .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 不適用。

如需如何針對諸如啟用 HTTP 連線及設定自訂網域等作業配置 Knative 的詳細資料，請參閱 Knative 文件。

WebSphereLibertyApplication 中的自動調整欄位不會用來配置 Knative Pod 自動縮放控制器 (KPA)。若要瞭解如何配置 KPA，請參閱配置自動縮放控制器。

在外部公開應用程式（.spec.expose、.spec.createKnativeService、.spec.route）

使用 Route、Knative Route 或輸入資源，在外部公開應用程式。

若要在非 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 部署中使用 Ingress 在外部公開應用程式，請完成下列步驟。

若要使用輸入資源來公開叢集，請安裝進入控制器，例如 Nginx 或 Traefik。
確保 Route 資源不在叢集上。只有在叢集上無法使用 Route 資源時，才會建立輸入資源。
若要使用 Ingress 資源，請將 websphere-liberty-operator ConfigMap 物件中的 defaultHostName 變數設為主機名稱，例如 mycompany.com

啟用 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

指定 .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 部署配置安全 HTTP 連線，請參閱使用 TLS 憑證配置 HTTP。

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。資料流量僅限於服務所配置的埠。
依預設， 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

下列範例容許來自 Pod 的送入資料流量，這些 Pod 在 example 名稱空間中標示有 frontend 角色。

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

連結應用程式與操作器管理的支持服務 (.status.binding.name 和 .spec.service.bindable)

服務連結操作員可讓應用程式開發人員將應用程式與操作員管理的支持服務連結在一起。如果叢集上已安裝「服務連結操作器」，則可以透過建立 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 應用程式互動。您必須建立兩個角色連結，以提供 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. 按一下建立。
現在您已設定第一個角色連結，請導覽至角色連結清單，然後再次按一下建立連結。使用下列指示來設定編輯存取權。
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 Operator 型錄來安裝「服務連結」操作器。
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. 向下捲動或在儲存器中開啟終端機階段作業並執行 ls /bindings，以檢查 Pod/部署工作量並驗證磁區是否已裝載。

限制 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