OpenShift Serverless 上の開発者は、使い慣れた言語およびフレームワークと共に、提供される Kubernetes ネイティブの API を使用してアプリケーションおよびコンテナーのワークロードをデプロイできます。OpenShift Serverless のインストールについての詳細は、「OpenShift Serverless のインストール」を参照してください。

OpenShift Container Platform 上の OpenShift Serverless を使用することにより、ステートフル、ステートレスおよびサーバーレスワークロードのすべてを、自動化された操作によって単一のマルチクラウドコンテナープラットフォームで実行することができます。開発者は、それぞれのマイクロサービス、レガシーおよびサーバーレスアプリケーションをホストするために単一プラットフォームを使用することができます。

OpenShift Serverless はオープンソースの Knative プロジェクトをベースとし、エンタープライズレベルのサーバーレスプラットフォームを有効にすることで、ハイブリッドおよびマルチクラウド環境における移植性と一貫性をもたらします。

アプリケーションは、カスタムリソース定義 (CRD、Customer Resource Definition) および Kubernetes の関連コントローラーを使用して作成され、任意の場所で実行できる OCI 準拠の Linux コンテナーとしてパッケージ化されます。

OpenShift Serverless でアプリケーションをデプロイするには、Knative サービスを作成する必要があります。詳細は、「Knative サービスの使用開始」を参照してください。

OpenShift Container Platform 上の Knative Serving は、サーバーレスアプリケーションのデプロイおよび提供をサポートするために Kubernetes および Istio をベースにビルドされます。

これは、OpenShift Container Platform クラスター上のサーバーレスワークロードの動作を定義し、制御するために使用される Kubernetes カスタムリソース定義 (CRD) のセットを作成します。

これらの CRD は、サーバーレスコンテナーの迅速なデプロイメント、Pod の自動スケーリング、Istio コンポーネントのルーティングおよびネットワークプログラミング、デプロイされたコードおよび設定の特定の時点のスナップショットの表示などの複雑なユースケースに対応するビルディングブロックとして使用できます。

Knative Client (kn) は、oc または kubectl ツールの機能を拡張し、OpenShift Container Platform での Knative コンポーネントとの対話を可能にします。kn は、開発者が YAML ファイルを直接編集しなくてもアプリケーションをデプロイし、管理できるようにします。

OpenShift Serverless が正常に実行されるようにクラスターのサイズを適切に設定する必要があります。MachineSet API を使用して、クラスターを必要なサイズにスケールアップすることができます。

最初のサーバーレスアプリケーションを初めて使用する場合は、CPU が 10 つ、メモリーが 40 GB の OpenShift クラスターが最低要件となります。これは、通常 2 つのマシンを追加することによってデフォルト MachineSet のいずれかをスケールアップする必要があることを意味します。

OpenShift Container Platform でのロギング、モニタリング、メータリングおよびトレーシングなどの高度なユースケースの場合は、追加のリソースをデプロイする必要があります。このようなユースケースで推奨される要件は 24 vCPU および 96GB メモリーです。

OpenShift Serverless のインストールには、サービスメッシュのインストールされたバージョンが必要です。詳細は、OpenShift Container Platform ドキュメントで「Installing Service Mesh」を参照してください。

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
metadata:
  name: basic-install
  namespace: istio-system
spec:
  istio:
    global:
      multitenant: true
      proxy:
        autoInject: disabled
      omitSidecarInjectorConfigMap: true
      disablePolicyChecks: false
      defaultPodDisruptionBudget:
        enabled: false
    istio_cni:
      enabled: true
    gateways:
      istio-ingressgateway:
        autoscaleEnabled: false
        type: LoadBalancer
      istio-egressgateway:
        enabled: false
      cluster-local-gateway:
        autoscaleEnabled: false
        enabled: true
        labels:
          app: cluster-local-gateway
          istio: cluster-local-gateway
        ports:
          - name: status-port
            port: 15020
          - name: http2
            port: 80
            targetPort: 8080
          - name: https
            port: 443
    mixer:
      enabled: false
      policy:
        enabled: false
      telemetry:
        enabled: false
    pilot:
      autoscaleEnabled: false
      sidecar: false
    kiali:
      enabled: false
    tracing:
      enabled: false
    prometheus:
      enabled: false
    grafana:
      enabled: false
    sidecarInjectorWebhook:
      enabled: false

apiVersion: maistra.io/v1
kind: ServiceMeshMemberRoll
metadata:
  name: default
  namespace: istio-system
spec:
  members:
  - knative-serving
  - mynamespace

OpenShift Serverless Operator は、OpenShift Container Platform の Operator のインストール手順に従ってインストールできます。

OpenShift Container Platform の Operator のインストール手順に従い、OpenShift Serverless Operator をホストクラスターにインストールできます。

詳細は、OpenShift Container Platform ドキュメントの「Operator のクラスターへの追加」を参照してください。

OpenShift Serverless Operator を使用して Knative Serving をインストールするには、KnativeServing オブジェクトを作成する必要があります。

apiVersion: v1
kind: Namespace
metadata:
 name: knative-serving
---
apiVersion: serving.knative.dev/v1alpha1
kind: KnativeServing
metadata:
 name: knative-serving
 namespace: knative-serving

Knative Serving をアンインストールするには、そのカスタムリソースを削除してから knative-serving namespace を削除する必要があります。

Operator の削除に関する OpenShift Container Platform の手順に従い、OpenShift Serverless Operator をホストクラスターから削除できます。

詳細は、OpenShift Container Platform ドキュメントの「クラスターからの Operator の削除」を参照してください。

OpenShift Serverless Operator のアンインストール後に、Operator CRD および API サービスはクラスター上に残ります。この手順を使用して、残りのコンポーネントを完全にアンインストールします。

サービスを作成するには、service.yaml ファイルを作成する必要があります。

以下のサンプルをコピーできます。このサンプルは helloworld-go というサンプルの golang アプリケーションを作成し、このサンプルを使用してそのアプリケーションのイメージを指定することができます。

apiVersion: serving.knative.dev/v1alpha1 1
kind: Service
metadata:
  name: helloworld-go 2
  namespace: default 3
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go 4
          env:
            - name: TARGET 5
              value: "Go Sample v1"

サーバーレスアプリケーションをデプロイするには、service.yaml ファイルを使用する必要があります。

サービスが作成され、アプリケーションがデプロイされるので、Knative はこのバージョンのアプリケーションのイミュータブルなリビジョンを新規に作成します。

また、Knative はネットワークプログラミングを実行し、アプリケーションのルート、ingress、サービスおよびロードバランサーを作成し、アクティブでない Pod を含む Pod をトラフィックに基づいて自動的にスケールアップ/ダウンします。

アプリケーション開発者がアプリケーションをモニターできるようにするには、クラスターの人による操作によって、クラスターを設定する必要があります。以下の手順では、その方法を示します。

管理者によるモニタリングの手動の設定は不要ですが、以下の手順を実行してモニタリングが正常にインストールしていることを確認できます。

このセクションでは、OpenShift Container Platform モニタリングツールの使用により Knative Serving Pod の自動スケーリングメトリクスを視覚化する方法例を示します。

OpenShift Container Platform クラスター管理者は、いくつかの CLI コマンドを使用してクラスターロギングをデプロイでき、OpenShift Container Platform Web コンソールを使用して Elasticsearch Operator および Cluster Logging Operator をインストールできます。Operator がインストールされている場合、クラスターロギングのカスタムリソース (CR) を作成してクラスターロギング Pod およびクラスターロギングのサポートに必要な他のリソースをスケジュールします。Operator はクラスターロギングのデプロイ、アップグレード、および維持を行います。

クラスターロギングは、instance という名前のクラスターロギングのカスタムリソース (CR) を変更することで設定できます。CR は、ログを収集し、保存し、視覚化するために必要なロギングスタックのすべてのコンポーネントを含む完全なクラスターロギングデプロイメントを定義します。Cluster Logging Operator は ClusterLogging カスタムリソースを監視し、ロギングデプロイメントを適宜調整します。

管理者およびアプリケーション開発者は、表示アクセスのあるプロジェクトのログを表示できます。

OpenShift Container Platform クラスターロギングは、小規模および中規模の OpenShift Container Platform クラスター用に調整されたデフォルト設定で使用されるように設計されています。

以下のインストール方法には、サンプルのクラスターロギングのカスタムリソース (CR) が含まれます。これを使用して、クラスターロギングインスタンスを作成し、クラスターロギングのデプロイメントを設定することができます。

デフォルトのクラスターロギングインストールを使用する必要がある場合は、サンプル CR を直接使用できます。

デプロイメントをカスタマイズする必要がある場合、必要に応じてサンプル CR に変更を加えます。以下では、クラスターロギングのインスタンスをインストール時に実行し、インストール後に変更する設定について説明します。クラスターロギングのカスタムリソース外で加える変更を含む、各コンポーネントの使用方法については、設定についてのセクションを参照してください。

spec:
  logStore:
    elasticsearch:
      resources:
        limits:
          cpu:
          memory:
        requests:
          cpu: 1
          memory: 16Gi
      type: "elasticsearch"
  collection:
    logs:
      fluentd:
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
        type: "fluentd"
  visualization:
    kibana:
      resources:
        limits:
          cpu:
          memory:
        requests:
          cpu:
          memory:
     type: kibana
  curation:
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      type: "curator"

  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        storage:
          storageClassName: "gp2"
          size: "200G"

  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        storage: {}

  spec:
    curation:
    type: "curator"
    resources:
    curator:
      schedule: "30 3 * * *"

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 2
      resources:
        limits:
          memory: 2Gi
        requests:
          cpu: 200m
          memory: 2Gi
      storage: {}
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources:
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      replicas: 1
  curation:
    type: "curator"
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      schedule: "*/5 * * * *"
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 1Gi

OpenShift クラスターロギングにより、アプリケーションがコンソールに書き込むログは Elasticsearch で収集されます。以下の手順で、Knative Serving を使用してデプロイされたアプリケーションにこれらの機能を適用する方法の概要を示します。

アプリケーションの各インスタンス (リビジョンコンテナー) によって処理される同時要求の数は、リビジョンテンプレートに target アノテーションまたは containerConcurrency フィールドを追加して指定できます。

以下は、リビジョンテンプレートで使用される target のサンプルです。

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: myapp
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: 50
    spec:
      containers:
      - image: myimage

以下は、リビジョンテンプレートで使用される containerConcurrency のサンプルです。

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: myapp
spec:
  template:
    metadata:
      annotations:
    spec:
      containerConcurrency: 100
      containers:
      - image: myimage

target と containerConcurrency の両方の値を追加することにより、同時要求の target 数をターゲットとして設定できますが、これにより要求の containerConcurrency 数のハード制限も設定されます。

たとえば、target 値が 50 で、containerConcurrency 値が 100 の場合、要求のターゲットに設定された数は 50 になりますが、ハード制限は 100 になります。

containerConcurrency 値が target 値よりも低い場合、実際に処理できる数よりも多くの要求をターゲットとして設定する必要はないため、target 値は小さい値に調整されます。

autoscaling.knative.dev/target: 50

containerConcurrency: 0 | 1 | 2-N

minScale および maxScale アノテーションは、アプリケーションを提供できる Pod の最小および最大数を設定するために使用できます。これらのアノテーションは、コールドスタートを防いだり、コンピューティングコストをコントロールするために使用できます。

minScale および maxScale は、リビジョンテンプレートで以下のように設定できます。

spec:
  template:
    metadata:
      autoscaling.knative.dev/minScale: "2"
      autoscaling.knative.dev/maxScale: "10"

これらのアノテーションをリビジョンテンプレートで使用することで、この設定が PodAutoscaler オブジェクトに伝播します。

oc として知られる OpenShift コマンドラインインターフェース (CLI) をダウンロードし、インストールすることができます。

# subscription-manager register
# subscription-manager refresh
# subscription-manager attach --pool=<pool_id> 1
# subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-x86_64-rpms"
# yum install openshift-serverless-clients

oc CLI にログインしてクラスターにアクセスし、これを管理できます。

これで、プロジェクトを作成でき、クラスターを管理するための他のコマンドを実行することができます。

この基本的なワークフローを使用して、サービス上で作成 (create)、読み取り (read)、更新 (update)、削除 (delete) (CRUD) 操作を行います。以下の例では、環境変数 TARGET を読み取る単純な Hello World サービスをデプロイし、その出力を印刷します。

YAML ファイルを直接編集せずに kn を使用して Knative サービスを変更することで、自動スケーリング機能にアクセスできます。

適切なフラグと共に service create および service update コマンドを使用して、自動スケーリング動作を設定します。

kn は、Knative サービス上でルート指定されたトラフィックを取得するリビジョンを制御するのに役立ちます。

Knative サービスは、トラフィックのマッピングを許可します。これは、サービスのリビジョンのトラフィックの割り当てられた部分へのマッピングです。これは特定のリビジョンに固有の URL を作成するオプションを提供し、トラフィックを最新リビジョンに割り当てる機能を持ちます。

サービスの設定が更新されるたびに、サービスルートがすべてのトラフィックを準備状態にある最新リビジョンにポイントする状態で、新規リビジョンが作成されます。

この動作は、トラフィックの一部を取得するリビジョンを定義して変更することができます。

$ kn service update svc --traffic @latest=10 --traffic svc-vwxyz=90

本書で説明されている手順に関連して問題が生じた場合には、カスタマーポータルにアクセスして、テクノロジープレビュー機能のサポートについて確認してください。