オペレーターの構成例

イメージ・ストリームの参照 (.spec.applicationImage)

イメージ・ストリームからイメージをデプロイするには、CR で「.spec.applicationImage」フィールドを指定する必要があります。

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

前の例では、my-namespace プロジェクトの my-image-stream イメージ・ストリームから 1.0 タグを検索し、CR の「.status.imageReference」フィールドに image-registry.openshift-image-registry.svc:5000/my-namespace/my-image-stream@sha256:***** などの参照イメージを取り込んでいます。 オペレーターは、指定されたイメージ・ストリームを監視し、指定されたタグに対して新しいイメージが使用可能になると、その新しいイメージをデプロイします。

イメージ・ストリームを参照する場合、「.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に指定されていない場合、オペレーターはCRと同じ名前のサービス・アカウントを作成する（例えば、 my-app ）。 さらに、このサービス・アカウントは、プル・シークレットの変更がCRフィールドで検出されたときに動的に更新されます。 .spec.pullSecret.

あるいは、オペレータは、あなたが提供するカスタム ServiceAccount 。 CRで .spec.serviceAccount.name が CR で指定されている場合、オペレータは新しい Pod をプロビジョニングするときに、 read only のパーミッションでサービスアカウントをそのまま使用します。 プライベートレジストリの背後にある画像にアクセスする場合、必要な画像プルシークレットをサービスアカウントに追加するのはあなたの責任です。

デフォルトでは、オペレータは、使用されるサービスアカウントが有効なプルシークレットへの参照を持っていることを確認します。 カスタム・サービス・アカウントを使用している場合、CRで .spec.serviceAccount.skipPullSecretValidation を true に設定することで、このチェックを無効にすることができる。

.spec.serviceAccount.mountToken を設定して、アプリケーション・ポッドへのサービス・アカウント・トークンのマウントを無効にすることができます。 デフォルトでは、サービス・アカウント・トークンはマウントされます。 この構成は、オペレーターが作成するデフォルトのサービス・アカウント、またはユーザーが指定するカスタム・サービス・アカウントのいずれかに適用されます。

アプリケーションが特定の許可を必要とするにもかかわらず、オペレーターに 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 内のアノテーションは、.spec.service.annotations を使用して Service に設定されたアノテーションを除き、リソースに指定されたすべてのアノテーションをオーバーライドします。

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」フィールドによって設定された環境変数は、コンテナー・イメージに指定された環境変数をオーバーライドします。

ConfigMap または Secret 内のすべてのデータをコンテナー内の環境変数として定義するには、.spec.envFrom を使用します。 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 を使用する別の例については、『基本認証資格情報のための環境変数の使用 (Using environment variables for basic authentication credentials)』を参照してください。 コンソール・ロギング環境変数のデフォルト値をオーバーライドする例については、 コンソール・ロギング環境変数のデフォルト値のオーバーライド (.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 フィールドを使ってオートスケーリングが設定されている場合は無視される。

高可用性のための水平ポッド・オートスケーリングの設定 (. spec.autoscaling )

ポッドまたはコンテナーの特権と権限の設定 (.spec.securityContext)

セキュリティー・コンテキストにより、ポッドまたはアプリケーション・コンテナーの特権と権限の設定が制御されます。 デフォルトでは、以下の例に示すように、オペレーターにより、アプリケーション・コンテナーに対して複数の .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

詳しくは、『コンテナーのセキュリティー・コンテキストの設定 (Set the security context for a Container) 』を参照してください。

リソースの永続化 (.spec.statefulSet および .spec.volumeMounts)

WebSphereLibertyApplication CR でストレージが指定されている場合、オペレーターはポッドごとに StatefulSet と PersistentVolumeClaim を作成できます。 ストレージが指定されていない場合、StatefulSet リソースは永続ストレージなしで作成されます。

以下の CR 定義では、基本ストレージを提供するために .spec.statefulSet.storage を使用しています。 オペレーターは、/data フォルダーにマウントする、サイズ 1Gi の 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 定義を指定すると、オペレーターは、サイズが 1Gi および ReadWriteOnce アクセス・モードの pvc という名前の PersistentVolumeClaim を作成します。 オペレーターによって、ユーザーは自動的に作成された PersistentVolumeClaim を完全に制御するために、.spec.statefulSet.storage.volumeClaimTemplate 全体を提供できるようになります。 複数のフォルダーに永続化するには、CR 定義で .spec.statefulSet.storage.mountPath の代わりに「.spec.volumeMounts」フィールドを使用します。

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 リソースを作成します。 ポッド・セットの順序付けと固有性のみが必要な場合は、ストレージなしで 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)

1 次サービス・ポートに加えて複数のサービス・ポートを指定するには、「.spec.service.port」、「 .spec.service.targetPort」、「.spec.service.portName」、および「.spec.service.nodePort」の各フィールドを使用して 1 次サービス・ポートを構成します。 1 次ポートは、アプリケーションを実行するコンテナーから公開され、そのポート値は、Route (または Ingress)、サービス・バインディング、および Knative サービスを構成する際に使用されます。

サービス・モニターの代替ポートを指定するには、「.spec.monitoring.endpoints」フィールドを使用して、「port」または「targetPort」のフィールドのどちらかを指定します。指定しない場合は、デフォルトで 1 次ポートになります。

以下の例に示すように、「.spec.service.port」フィールドで 1 次ポートを指定し、「.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

デフォルト値をオーバーライドするには、別の値を指定します。 以下の例では、liveness (活性) プローブの初期遅延のデフォルト値の 60 秒をオーバーライドし、初期遅延を 90 秒に設定します。

spec:
  probes:
    liveness:
      initialDelaySeconds: 90

プローブの initialDelaySeconds パラメーターが「0」に設定されている場合は、デフォルト値が使用されます。 プローブの初期遅延を「0」に設定するには、デフォルト・プローブを使用せずにプローブを定義します。 以下の例では、デフォルト値をオーバーライドし、初期遅延を「0」に設定しています。

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

(.spec.probes.enableFileBased ) mpHealth-4.0 を使用してファイルベースのプローブを設定する

オペレータバージョン Liberty から、新しいブール型フィールド 1.5.2 が導入され、 .spec.probes.enableFileBased Health 4.0 MicroProfile 機能を使用してファイルベースのヘルスチェックを設定できるようになりました。

ファイルベースのプローブは、アプリケーションではデフォルトで有効化されていません。 オペレータ Liberty はデフォルトで GET HTTP プローブを使用します。

• で指定されたイメージ Liberty は、バージョン 25.0.0.6 または 以降を実行する Liberty .spec.applicationImage サーバーに 機能が mpHealth-4.0 インストールされ有効化されていることを必要とします。
• デフォルト値でファイルベースのプローブを有効にするには、を enableFileBased に設定 true し、プローブパラメータをに設定します {}。 次の例では、3つのプローブすべてがファイルベースのデフォルト値を使用できるようにします。

  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 UP 状態を示すために、新たに調整されたタイムスタンプで、 startedlive ファイルの作成/更新を行う可能性があります。 これらのファイル Liberty をチェックする間隔は、と .spec.probes.startupCheckInterval.spec.probes.checkInterval フィールドを使用して変更できます。 デフォルトでは、これらのチェック間隔はそれぞれ と 5s に設定されています 100ms。

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

非ファイルベースのプローブの動作に合わせるには、サーバー Liberty が、 ready、または started ファイルをチェックする速度を live、が単一のプローブを実行 Kubernetes するのに要する時間よりも速く設定してください。 例えば、バッファを設定して、チェック間隔が の特性を維持するように interval * 1.5 ⇐ periodSecondsする。 この場合、プローブ WebSphereLibertyApplication はデフォルト periodSeconds 値 を持ち 10、チェック間隔 および 5s で制約 100msを満たします。 , checkInterval, または startupCheckInterval periodSecondsプロパティの値を変更する場合は、予期しないポッドのダウンタイムを回避するため、この制約を維持してください。

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

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」フィールドがそのリソースに取り込まれます。 また、オペレーターによって 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 があります。 startup (始動) プローブは Knative で完全にはサポートされないため、Knative サービスが有効になっている場合には、.spec.probes.startup は適用されません。

HTTPS 接続の有効化やカスタム・ドメインのセットアップなどのタスクに合わせて Knative を構成する方法について詳しくは、Knative 資料を参照してください。

WebSphereLibertyApplication の自動スケーリングのフィールドは、Knative Pod Autoscaler (KPA) の構成には使用されません。 KPA の構成方法については、『Autoscaler の構成』を参照してください。

アプリケーションの外部への公開 (.spec.expose、.spec.createKnativeService、.spec.route)

Route、Knative Route、または Ingress のリソースを使用してアプリケーションを外部に公開します。

非 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 を使用してアプリケーションを外部に公開するには、以下のステップを実行します。

1. Ingress リソースを使用してクラスターを公開するには、Nginx や Traefik などの Ingress コントローラーをインストールしてください。
2. Route リソースがクラスター上にないことを確認します。 Ingress リソースは、クラスター上で Route リソースが使用可能でない場合にのみ作成されます。
3. Ingressリソースを使用するには、 Operator ConfigMapdefaultHostName オブジェクト内の変数をホスト名（例：）に設定してください。 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 を指定して、Ingress リソースを構成します。 Nginx、HAProxy、Traefik などのアノテーションは、Ingress コントローラーの実装に固有のものです。

   以下の例では、アノテーション、既存の 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 の構成 (Configuring HTTPS with TLS certificates)』を参照してください。

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)

デフォルトでは、アプリケーションのネットワーク・ポリシーによって着信トラフィックが分離されます。

• 公開されていないアプリケーション用に作成されているデフォルトのネットワーク・ポリシーは、着信トラフィックを、同じアプリケーションに含まれる同じ名前空間内のポッドに制限します。 トラフィックは、サービスによって構成されたポートのみに制限されます。 デフォルトでは、トラフィックは .spec.service.targetPort が指定されたときに公開され、それ以外は .spec.service.port を使うようにフォールバックします。 同じロジックを使えば、.spec.service.ports[] 配列にtargetPortまたはportが追加されるごとに、トラフィックが公開されます。
• Red Hat OpenShift は、デフォルトでネットワーク・ポリシーをサポートします。 Red Hat OpenShift の公開されたアプリケーションの場合、サービス構成のポート上の Red Hat OpenShift Ingress コントローラーからの着信トラフィックは、ネットワーク・ポリシーにより許可されます。 ネットワーク・ポリシーにより、Red Hat OpenShift モニター・スタックからの着信トラフィックも許可されます。
• その他の Kubernetes プラットフォームの公開されたアプリケーションの場合、ネットワーク・ポリシーによって、サービス構成のポート上の任意の名前空間にあるすべてのポッドからの着信トラフィックが許可されます。 他の Kubernetes プラットフォームへの展開では、ネットワークプラグインがネットワーク Kubernetes ポリシー をサポートしていることを確認してください。

アプリケーションのネットワーク・ポリシーの作成を無効にするには、.spec.networkPolicy.disable を「true」に設定します。

spec:
  networkPolicy:
    disable: true

特定の名前空間やポッドからの着信トラフィックを許可するように、ネットワーク・ポリシーを変更できます。 デフォルトでは、.spec.networkPolicy.namespaceLabels はアプリケーションのデプロイ先と同じ名前空間に設定され、.spec.networkPolicy.fromLabels は .spec.applicationName によって指定された同じアプリケーションに属するポッドに設定されます。 以下の例では、同じ名前空間内にあり、 frontend 役割のラベルが付いたポッドからの着信トラフィックを許可します。

spec:
  networkPolicy:
    fromLabels:
      role: frontend

以下の例では、example 名前空間内にある、同じアプリケーションに属するポッドからの着信トラフィックを許可しています。

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

以下の例では、 example 名前空間内の frontend 役割のラベルが付いたポッドからの着信トラフィックを許可します。

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 アプリケーションは、Service Binding Specification によって定義される Provisioned Service として動作するように構成できます。 仕様に従って、Provisioned Service リソースでは、シークレットを参照する .status.binding.name を定義する必要があります。 アプリケーションを Provisioned Service として公開するには、「.spec.service.bindable」フィールドの値を「true」に設定します。 オペレーターは、 CR_NAME-expose-binding という名前の バインディング・シークレット を作成し、 host、 port、 protocol、 basePath、および uri の各エントリーをシークレットに追加します。

バインディング・シークレット内のエントリーのデフォルト値をオーバーライドするか、シークレットに新しいエントリーを追加するには、 CR_NAME-expose-binding-override という名前の オーバーライド・シークレット を作成し、シークレットにエントリーを追加します。 オペレーターは、オーバーライド・シークレットの内容を読み取って、バインディング・シークレットのデフォルト値をオーバーライドします。

WebSphere Liberty アプリケーションが Provisioned Service として公開されると、サービス・バインディング要求は、そのアプリケーションをバッキング・サービスとして参照できます。

以下の手順は、WebSphere Libertyアプリケーションをサービスまたはプロデューサーとして他のワークロード (ポッドやデプロイメントなど) にバインドする方法を示しています。 WebSphere Liberty オペレーターを介してデプロイされた 2 つの WebSphere Liberty アプリケーションをバインドすることはできません。 詳しくは、既知の問題と制限を参照してください。

• WebSphere Libertyアプリケーションにアクセスするためのサービス・バインディング・オペレーターをセットアップします。
  デフォルトでは、サービス・バインディング・オペレーターには、 WebSphere Liberty オペレーターを介してデプロイされた WebSphere Liberty アプリケーションと対話する権限がありません。 サービス・バインディング・オペレーターにWebSphere Libertyアプリケーションの表示権限と編集権限を付与するには、2 つの RoleBindings を作成する必要があります。

  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アプリケーション (または「サービス」) からポッドまたはデプロイメント (または「ワークロード」) へのサービス・バインディングが成功するようになりました。 バインディングが行われると、バインドされたワークロードが再始動またはスケーリングされ、すべてのコンテナーの/bindingsにバインディング・シークレットがマウントされます。

• Red Hat メソッドを使用してサービス・バインディングをセットアップします。
  詳しくは、Red Hat 資料または Red Hat チュートリアルを参照してください。

  1. Red Hat OpenShift Web ダッシュボードで、サイドバーの 「管理者」 をクリックし、 「開発者」を選択します。
  2. 現在の名前空間のトポロジービューで、サービスとしてバインドする WebSphere アプリケーションの境界線の上にカーソルを移動し、矢印をポッドまたはデプロイメントのワークロードにドラッグします。 サービス・バインディングの作成というタイトルのツールチップが表示されます。
  3. 「サービス・バインディングの作成」ウィンドウが開きます。 名前を 63 文字未満の値に変更してください。 サービス・バインディング・オペレーターは、名前が 63 文字を超えると、シークレットをボリュームとしてマウントできない場合があります。
  4. 「作成」 をクリックします。
  5. サイドバーが開きます。 バインディングの状況を確認するには、シークレットの名前をクリックし、状況が表示されるまでスクロールします。
  6. ポッド/デプロイメントのワークロードを調べて、ボリュームがマウントされていることを確認します。 また、コンテナー内で端末セッションを開き、ls /bindingsを実行することもできます。
• Spec API Tech Preview/Community メソッドを使用して、サービス・バインディングをセットアップします。
  このメソッドは Red Hat メソッドよりも新しくなっていますが、同じ結果が得られます。 固有のラベルがない場合は、app=frontendなどのラベルをWebSphere Libertyアプリケーションに追加する必要があります。 サービス・バインディング・オペレーターが特定のラベルを持つWebSphere Libertyアプリケーションを検索できるように、ラベル・セレクターを使用するようにバインディングを設定します。

  1. Red Hat OpenShiftオペレーター・カタログを使用して、サービス・バインディング・オペレーターをインストールします。
  2. 「オペレーター」 > 「インストール済みオペレーター」 を選択し、名前空間を WebSphere アプリケーションとポッド/デプロイメント ワークロードの両方で使用されるものと同じものに設定します。
  3. サービス・バインディング (仕様 API 技術プレビュー) ページを開きます。
  4. ServiceBinding の作成をクリックします。
  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を実行します。

指定されたノードで実行するようにポッドを制限 (.spec.affinity)

.spec.affinity を使用して、指定されたノードでのみポッドが実行されるように制約します。

特定ノードでポッドのスケジューリングに必要なラベルを設定するには、「.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」という名前の 2 つのゾーンの、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

ポッドのアフィニティーとアンチアフィニティーを使用して、ノード上のラベルではなく、ノード上で既に実行されているポッドのラベルに基づいて、ポッドがスケジュール対象となるノードを制限します。

以下の例は、ポッド・アフィニティーが必須であること、また Service-A と Service-B のポッドが同じゾーンになければならないことを示しています。 ポッドのアンチアフィニティーを介した場合、同じホストで 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

ポッドがノードとゾーン間でどのように分散されるかを制限する（.spec.topologySpreadConstraints）

.spec.topologySpreadConstraints YAML オブジェクトを使用して、アプリケーション・インスタンス（および有効な場合は Semeru Cloud Compiler インスタンス）のポッドがクラスタのノードとゾーン間でどのように分散されるかの制約を指定します。

` .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

デフォルトでは、オペレーターはアプリケーション・インスタンスのポッド（および該当する場合は Semeru Cloud Compiler インスタンスのポッド）に以下のポッド・トポロジ・スプレッド制約を追加します。 デフォルトの動作は、同じアプリケーションインスタンス（または Semeru クラウドコンパイラ生成インスタンス）が所有するポッドの拡散を制限することです。<インスタンス名>で示され、 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

あるいは、新しい制約を作成して手動で各制約を上書きします。TopologySpreadConstraint下.spec.topologySpreadConstraints.constraintsそれぞれtopologyKey変更したい。

DNSの設定(.spec.dns.policyと.spec.dns.config)

DNSはWebSphereLibertyApplication CRで.spec.dns.policyフィールドまたは.spec.dns.configフィールドを使って設定できます。 .spec.dns.policy フィールドはアプリケーションポッドの DNS ポリシーで、デフォルトは ClusterFirst ポリシーです。 .spec.dns.configフィールドは、アプリケーションポッドのDNS設定です。

DNS Configでは、アプリケーションポッドの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)

ノードアフィニティは、優先順位またはハード要件として、ポッドをノードのセットに引きつけるプロパティです。 しかし、テインによって、ノードはポッドのセットを撃退することができる。

公差はポッドに適用され、スケジューラが一致するテイントを持つポッドをスケジューリングできるようにする。 スケジューラは、その機能の一環として他のパラメータも評価する。

テイントとトレレーションは、アプリケーション・ポッドが不適切なノードにスケジューリングされないようにするために連携します。 ノードに1つ以上のテイントが適用されると、そのノードはテイントを許容しないポッドを受け入れることができなくなる。

公差はWebSphereLibertyApplication CRで.spec.tolerationsフィールドを使って設定できます。

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

汚染と許容に関する詳細については、 汚染と許容の Kubernetes ドキュメントを参照してください。