コンテンツへスキップ

Knative Operatorを使用したインストール

Knativeは、Knativeのインストール、設定、管理を行うKubernetes Operatorを提供しています。クラスタにServingコンポーネント、Eventingコンポーネント、またはその両方をインストールできます。

次の表は、Knative OperatorでサポートされているServingとEventingのバージョンを示しています。

Operator サービング イベント
v1.16 v1.16.0
v1.15.0、v1.15.1、v1.15.2
v1.14.0、v1.14.1、v1.14.2
v1.13.0、v1.13.1、v1.13.2		 v1.16.0
v1.15.0、v1.15.1、v1.15.2、v1.15.3
v1.14.0、v1.14.1、v1.14.2、v1.14.3、v1.14.4、v1.14.5、v1.14.6、v1.14.7
v1.13.0、v1.13.1、v1.13.2、v1.13.3、v1.13.4、v1.13.5、v1.13.6、v1.13.7、v1.13.8

前提条件

Knativeをインストールする前に、次の前提条件を満たす必要があります。

  • **プロトタイピング目的の場合**、KnativeはKubernetesのほとんどのローカル展開で動作します。たとえば、3つのCPUと4GBのメモリを持つローカルの1ノードクラスタを使用できます。

    ヒント

    Knativeクイックスタートプラグインを使用して、開発目的でKnativeのローカルディストリビューションをインストールできます。

  • **本番環境の場合**、次のことが推奨されます。

    • クラスタにノードが1つしかない場合、少なくとも6つのCPU、6GBのメモリ、30GBのディスクストレージが必要です。
    • クラスタに複数のノードがある場合、各ノードに少なくとも2つのCPU、4GBのメモリ、20GBのディスクストレージが必要です。
    • Kubernetes v1.28以降を使用するクラスタが必要です。
    • kubectl CLIをインストールしている必要があります。
    • Kubernetesはイメージを取得できる必要があるため、Kubernetesクラスタはインターネットにアクセスできる必要があります。プライベートレジストリからプルするには、「プライベートコンテナレジストリからのイメージのデプロイ」を参照してください。

注意

提供されているシステム要件は推奨事項に過ぎません。インストールに必要な要件は、ネットワーキングレイヤーなどのオプションコンポーネントを使用するかどうかによって異なる場合があります。

イメージシグネチャの検証

1.9以降のKnativeリリースは、cosignで署名されています。

  1. cosignとjqをインストールします。

  2. マニフェストからイメージを抽出し、署名を検証します。

curl -sSL https://github.com/knative/serving/releases/download/knative-v1.16.0/serving-core.yaml \
  | grep 'gcr.io/' | awk '{print $2}' | sort | uniq \
  | xargs -n 1 \
    cosign verify -o text \
      --certificate-identity=signer@knative-releases.iam.gserviceaccount.com \
      --certificate-oidc-issuer=https://#

注記

KnativeイメージはKEYLESSモードで署名されています。キーレス署名について詳しくは、キーレス署名を参照してください。リリースの署名ID（サブジェクト）はsigner@knative-releases.iam.gserviceaccount.com、発行者はhttps://#です。

Knative Operatorのインストール

Knative ServingとEventingコンポーネントをインストールする前に、最初にKnative Operatorをインストールする必要があります。

警告

Knative Operator 1.5は、v1alpha1とv1beta1の両方のCRDをサポートする最後のバージョンです。既存のOperatorインストールをv1.2以前からv1.3以降にアップグレードする場合は、現在のバージョンをインストールする前に、次のコマンドを実行して既存のカスタムリソースをv1beta1にアップグレードしてください。

kubectl create -f https://github.com/knative/operator/releases/download/knative-v1.5.1/operator-post-install.yaml

最新の安定版Operatorリリースをインストールするには、次のコマンドを実行します。

kubectl apply -f https://github.com/knative/operator/releases/download/knative-v1.16.0/operator.yaml

Knative Operatorのリリースバージョンに関する情報は、リリースページにあります。

Knative Operatorインストールの検証

  1. Operatorはdefault名前空間にインストールされるため、次のコマンドを実行して現在の名前空間をdefaultに設定してください。

    kubectl config set-context --current --namespace=default

  2. 次のコマンドを実行して、Operatorのデプロイメントステータスを確認します。

    kubectl get deployment knative-operator

    Operatorが正しくインストールされている場合、デプロイメントはReadyステータスを示します。

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
knative-operator   1/1     1            1           19h

ログの追跡

Operatorのログを追跡するには、次のコマンドを実行します。

kubectl logs -f deploy/knative-operator

Knative Servingのインストール

Knative Servingをインストールするには、カスタムリソース（CR）を作成し、CRにネットワーキングレイヤーを追加し、DNSを設定する必要があります。

Knative Servingカスタムリソースの作成

Operatorで利用可能な最新のKnative Servingのカスタムリソースを作成するには

  1. 次のYAMLをファイルにコピーします。

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

    注記

    spec.versionフィールドを使用してバージョンを指定しない場合、Operatorは利用可能な最新のバージョンをデフォルトで使用します。

  2. 次のコマンドを実行してYAMLファイルを適用します。

    kubectl apply -f <filename>.yaml

    ここで、<filename>は前の手順で作成したファイルの名前です。

ネットワーキングレイヤーのインストール

Knative Operatorは、異なるネットワーク層オプションを使用してKnative Servingコンポーネントを構成できます。イングレスがKnative Serving CRで指定されていない場合、Istioがデフォルトのネットワーク層になります。デフォルトのIstioネットワーク層を使用する場合は、クラスタにIstioをインストールする必要があります。このため、Kourierをネットワーク層として構成する方が簡単だと感じるかもしれません。

以下の各タブをクリックして、さまざまなイングレスでKnative Servingを構成する方法を確認してください。

次の手順では、Kourierをインストールし、そのKnative統合を有効にします。

  1. Knative ServingでKourierを使用するように構成するには、次のようにServing CR YAMLファイルにspec.ingress.kourierとspec.config.networkを追加します。

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  # ...
  ingress:
    kourier:
      enabled: true
  config:
    network:
      ingress-class: "kourier.ingress.networking.knative.dev"

  2. 次のコマンドを実行して、Serving CRのYAMLファイルを適用します。

    kubectl apply -f <filename>.yaml

    ここで、<filename>はServing CRファイルの名前です。

  3. 次のコマンドを実行して、外部IPまたはCNAMEを取得します。

    kubectl --namespace knative-serving get service kourier

    後でDNSを構成するために保存してください。

次の手順では、IstioをインストールしてKnative統合を有効にします。

  1. Istioをインストールします。.

  2. デフォルトのistio-system以外の名前空間にIstioをインストールした場合

    1. 次のように、Serving CR YAMLファイルにspec.config.istioを追加します。

      apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  # ...
  config:
    istio:
      local-gateways: |
        - name: knative-local-gateway
          namespace: <local-gateway-namespace>
          service: knative-local-gateway.<istio-namespace>.svc.cluster.local

      ここで

      • <local-gateway-namespace>はローカルゲートウェイの名前空間で、Knative Servingの名前空間knative-servingと同じです。
      • <istio-namespace>はIstioがインストールされている名前空間です。

    2. 次のコマンドを実行して、Serving CRのYAMLファイルを適用します。

      kubectl apply -f <filename>.yaml

      ここで、<filename>はServing CRファイルの名前です。

  3. 次のコマンドを実行して、外部IPまたはCNAMEを取得します。

    kubectl get svc istio-ingressgateway -n <istio-namespace>

    後でDNSを構成するために保存してください。

次の手順では、Contourをインストールし、そのKnative統合を有効にします。

  1. 適切に構成されたContourをインストールします。

    kubectl apply --filename https://github.com/knative/net-contour/releases/download/knative-v1.16.0/contour.yaml

  2. Knative ServingでContourを使用するように構成するには、Serving CR YAMLファイルにspec.ingress.contourとspec.config.networkを追加します。

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  # ...
  ingress:
    contour:
      enabled: true
  config:
    network:
      ingress-class: "contour.ingress.networking.knative.dev"

  3. 次のコマンドを実行して、Serving CRのYAMLファイルを適用します。

    kubectl apply -f <filename>.yaml

    ここで、<filename>はServing CRファイルの名前です。

  4. 次のコマンドを実行して、外部IPまたはCNAMEを取得します。

    kubectl --namespace contour-external get service envoy

    後でDNSを構成するために保存してください。

Knative Servingのデプロイメントの検証

  1. Knativeデプロイメントを監視します。

    kubectl get deployment -n knative-serving

    Knative Servingが正常にデプロイされた場合、Knative ServingのすべてのデプロイメントにREADYステータスが表示されます。サンプル出力は次のとおりです。

    NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
activator              1/1     1            1           18s
autoscaler             1/1     1            1           18s
autoscaler-hpa         1/1     1            1           14s
controller             1/1     1            1           18s
domain-mapping         1/1     1            1           12s
domainmapping-webhook  1/1     1            1           12s
webhook                1/1     1            1           17s

  2. Knative Servingカスタムリソースのステータスを確認します。

    kubectl get KnativeServing knative-serving -n knative-serving

    Knative Servingが正常にインストールされている場合、次の内容が表示されます。

    NAME              VERSION             READY   REASON
knative-serving   <version number>    True

DNSの構成

ホストヘッダー付きのcurlコマンドを実行する必要がないように、DNSを構成できます。

次のタブを展開すると、DNSを構成するための手順が表示されます。選択したDNSの手順に従ってください。

Knativeは、デフォルトのDNSサフィックスとしてsslip.ioを使用するようにKnative Servingを構成するdefault-domainというKubernetesジョブを提供しています。

kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.16.0/serving-default-domain.yaml

警告

これは、クラスタのLoadBalancerサービスがIPv4アドレスまたはホスト名を公開する場合にのみ機能するため、minikube tunnelが実行されていない限り、IPv6クラスタやminikubeなどのローカル設定では機能しません。

これらの場合は、「実DNS」または「DNSなし」タブを参照してください。

KnativeのDNSを構成するには、ネットワーク設定で取得した外部IPまたはCNAMEを取得し、次のようにDNSプロバイダーで構成します。

  • ネットワーク層が外部IPアドレスを生成した場合は、ドメインのワイルドカードAレコードを構成します。

    # Here knative.example.com is the domain suffix for your cluster
*.knative.example.com == A 35.233.41.212

  • ネットワーク層がCNAMEを生成した場合は、ドメインのCNAMEレコードを構成します。

    # Here knative.example.com is the domain suffix for your cluster
*.knative.example.com == CNAME a317a278525d111e89f272a164fd35fb-1510370581.eu-central-1.elb.amazonaws.com

  • DNSプロバイダーの構成が完了したら、既存のServing CRにspec.config.domainを追加して適用します。

    # Replace knative.example.com with your domain suffix
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ...
  config:
    domain:
      "knative.example.com": ""
  ...

ホストヘッダーを使用してサンプルアプリケーションまたは独自のKnativeアプリケーションにアクセスするためにcurlを使用しており、「マジックDNS (sslip.io)」または「実DNS」の方法を使用できない場合は、一時的な方法があります。これは、たとえばローカルのminikubeを使用している場合やIPv6クラスタを使用している場合など、「マジックDNS」の方法を使用できない場合や、「実DNS」の方法のようにDNS設定を変更せずにKnativeを評価したい場合に役立ちます。

この方法を使用してcurlでアプリケーションにアクセスするには

  1. クラスタの外部からアクセス可能なドメインを使用するようにKnativeを構成します。

    kubectl patch configmap/config-domain \
      --namespace knative-serving \
      --type merge \
      --patch '{"data":{"example.com":""}}'

  2. アプリケーションの開始後、アプリケーションのURLを取得します。

    kubectl get ksvc
    出力は次のようになります。
    NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
helloworld-go   http://helloworld-go.default.example.com   helloworld-go-vqjlf   helloworld-go-vqjlf   True

  3. セクション3で説明されているネットワーク層によって定義された外部IPまたはCNAMEに接続するようにcurlに指示し、-H "Host:"コマンドラインオプションを使用してKnativeアプリケーションのホスト名を指定します。たとえば、ネットワーク層が外部IPとポートをhttp://192.168.39.228:32198として定義し、前に説明したhelloworld-goアプリケーションにアクセスしたい場合は、次を使用します。

    curl -H "Host: helloworld-go.default.example.com" http://192.168.39.228:32198
    提供されたhelloworld-goサンプルアプリケーションの場合、デフォルト設定を使用すると、出力は次のようになります。
    Hello Go Sample v1!
    恒久的な解決策については、「実DNS」の方法を参照してください。

Knative Eventingのインストール

Knative Eventingをインストールするには、カスタムリソース（CR）を適用する必要があります。必要に応じて、さまざまなイベントソースを使用してKnative Eventingコンポーネントをインストールすることもできます。

Knative Eventingカスタムリソースの作成

Operatorで利用可能な最新のKnative Eventingのカスタムリソースを作成するには

  1. 次のYAMLをファイルにコピーします。

    apiVersion: v1
kind: Namespace
metadata:
  name: knative-eventing
---
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing

    注記

    spec.versionフィールドを使用してバージョンを指定しない場合、Operatorはデフォルトで利用可能な最新バージョンを使用します。

  2. 次のコマンドを実行してYAMLファイルを適用します。

    kubectl apply -f <filename>.yaml

ここで、<filename>は前の手順で作成したファイルの名前です。

特定のバージョンのEventingのインストール

クラスタ管理者は、spec.versionフィールドを使用して、特定のバージョンのKnative Eventingをインストールできます。たとえば、Knative Eventing v1.7をインストールする場合は、次のKnativeEventing CRを適用できます。

apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  version: "1.7"

同等の変更を行うには、次のコマンドを実行することもできます。

kn operator install --component eventing -v 1.7 -n knative-eventing

spec.versionが指定されていない場合、Knative Operatorは利用可能な最新のKnative Eventingバージョンをインストールします。ユーザーが無効または利用できないバージョンを指定した場合、Knative Operatorは何もしません。Knative Operatorには常に最新の3つのマイナーリリースバージョンが含まれています。

Knative EventingがすでにOperatorによって管理されている場合、KnativeEventing CRのspec.versionフィールドを更新することで、Operatorを変更することなく、Knative Eventingのバージョンをアップグレードまたはダウングレードできます。

Knative Operatorは、一度に1つのマイナーリリースバージョンのみのアップグレードまたはダウングレードを許可することに注意してください。たとえば、現在のKnative Eventingデプロイメントがバージョン1.4の場合、1.6にアップグレードする前に1.5にアップグレードする必要があります。

カスタマイズされたKnative Eventingのインストール

Operatorは、独自の要件に合わせてカスタマイズされたKnative Eventingをインストールする柔軟性を提供します。カスタマイズされたKnative EventingのマニフェストがOperatorからアクセスできる限り、それらをインストールできます。

カスタマイズされたマニフェストをインストールするには、上書きモードと追加モードの2つのモードがあります。上書きモードでは、.spec.manifestsの下で、Knative Eventingのインストールに必要なすべてマニフェストを定義する必要があります。Operatorはデフォルトのマニフェストをインストールしなくなります。追加モードでは、.spec.additionalManifestsの下で、カスタマイズされたマニフェストのみを定義する必要があります。カスタマイズされたマニフェストは、デフォルトのマニフェストが適用された後にインストールされます。

上書きモード

インストールするすべてのKnative Eventingマニフェストをカスタマイズする場合は、上書きモードを使用します。

たとえば、カスタマイズされたKnative Eventingのみをインストールする場合は、次のEventing CRを作成して適用できます。

apiVersion: v1
kind: Namespace
metadata:
  name: knative-eventing
---
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  version: $spec_version
  manifests:
  - URL: https://my-eventing/eventing.yaml

この例では、https://my-eventing/eventing.yamlで利用可能なバージョン$spec_versionでカスタマイズされたKnative Eventingをインストールします。

注意

spec.manifestsはリンクのリストをサポートしているため、カスタマイズされたKnative Eventingを1つまたは複数のリンクで利用可能にできます。URLの順序は重要です。最初に適用するマニフェストを一番上に配置します。

spec.versionとspec.manifestsの両方を利用して、バージョンとカスタマイズされたKnative Eventingへの有効なリンクを指定することを強くお勧めします。どちらのフィールドもスキップしないでください。

追加モード

追加モードを使用して、カスタマイズされたマニフェストをデフォルトのマニフェストに追加できます。

たとえば、いくつかのリソースのみをカスタマイズしたいが、デフォルトのKnative Eventingをインストールしたい場合は、次のEventing CRを作成して適用できます。

apiVersion: v1
kind: Namespace
metadata:
  name: knative-eventing
---
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  version: $spec_version
  additionalManifests:
  - URL: https://my-eventing/eventing-custom.yaml

この例では、デフォルトのKnative Eventingをインストールし、https://my-eventing/eventing-custom.yamlで利用可能なカスタマイズされたリソースをインストールします。

Knative Operatorは、バージョン$spec_versionでKnative Eventingのデフォルトのマニフェストをインストールし、その後、それらに基づいてカスタマイズされたマニフェストをインストールします。

イベントソースを使用したKnative Eventingのインストール

Knative Operatorは、さまざまなイベントソースを使用してKnative Eventingコンポーネントを構成できます。以下の各タブをクリックして、さまざまなイベントソースを使用してKnative Eventingを構成する方法を確認してください。

イベントソースとしてCephをインストールするようにKnative Eventingを構成するには

  1. 次のように、Eventing CR YAMLファイルにspec.source.cephを追加します。

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  # ...
  source:
    ceph:
      enabled: true

  2. 次のコマンドを実行してYAMLファイルを適用します。

    kubectl apply -f <filename>.yaml

    ここで、<filename>は前の手順で作成したファイルの名前です。

イベントソースとしてGitHubをインストールするようにKnative Eventingを構成するには

  1. 次のように、Eventing CR YAMLファイルにspec.source.githubを追加します。

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  # ...
  source:
    github:
      enabled: true

  2. 次のコマンドを実行してYAMLファイルを適用します。

    kubectl apply -f <filename>.yaml

    ここで、<filename>は前の手順で作成したファイルの名前です。

イベントソースとしてGitLabをインストールするようにKnative Eventingを構成するには

  1. 次のように、Eventing CR YAMLファイルにspec.source.gitlabを追加します。

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  # ...
  source:
    gitlab:
      enabled: true

  2. 次のコマンドを実行してYAMLファイルを適用します。

    kubectl apply -f <filename>.yaml

    ここで、<filename>は前の手順で作成したファイルの名前です。

イベントソースとしてKafkaをインストールするようにKnative Eventingを構成するには

  1. 次のように、Eventing CR YAMLファイルにspec.source.kafkaを追加します。

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  # ...
  source:
    kafka:
      enabled: true

  2. 次のコマンドを実行してYAMLファイルを適用します。

    kubectl apply -f <filename>.yaml

    ここで、<filename>は前の手順で作成したファイルの名前です。

イベントソースとしてRabbitMQをインストールするようにKnative Eventingを構成するには、

  1. 次のように、Eventing CR YAMLファイルにspec.source.rabbitmqを追加します。

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  # ...
  source:
    rabbitmq:
      enabled: true

  2. 次のコマンドを実行してYAMLファイルを適用します。

    kubectl apply -f <filename>.yaml

    ここで、<filename>は前の手順で作成したファイルの名前です。

イベントソースとしてRedisをインストールするようにKnative Eventingを構成するには

  1. 次のように、Eventing CR YAMLファイルにspec.source.redisを追加します。

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  # ...
  source:
    redis:
      enabled: true

  2. 次のコマンドを実行してYAMLファイルを適用します。

    kubectl apply -f <filename>.yaml

    ここで、<filename>は前の手順で作成したファイルの名前です。

Knative Eventingデプロイメントの検証

  1. Knativeデプロイメントを監視します。

    kubectl get deployment -n knative-eventing

    Knative Eventingが正常にデプロイされた場合、Knative EventingのすべてのデプロイメントにREADYステータスが表示されます。サンプル出力は次のとおりです。

    NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
eventing-controller     1/1     1            1           43s
eventing-webhook        1/1     1            1           42s
imc-controller          1/1     1            1           39s
imc-dispatcher          1/1     1            1           38s
mt-broker-controller    1/1     1            1           36s
mt-broker-filter        1/1     1            1           37s
mt-broker-ingress       1/1     1            1           37s
pingsource-mt-adapter   0/0     0            0           43s
sugar-controller        1/1     1            1           36s

  2. Knative Eventingカスタムリソースのステータスを確認します。

    kubectl get KnativeEventing knative-eventing -n knative-eventing

    Knative Eventingが正常にインストールされている場合、次の内容が表示されます。

    NAME               VERSION             READY   REASON
knative-eventing   <version number>    True

Knativeのアンインストール

Knative Operatorは、Knativeリソースの安全でない削除を防ぎます。Knative ServingとKnative EventingのCRが正常に削除されても、KnativeのすべてのCRDはクラスタに残ります。Knative CRDに依存するすべてのリソースは引き続き機能します。

Knative Servingコンポーネントの削除

Knative Serving CRを削除するには、次のコマンドを実行します。

kubectl delete KnativeServing knative-serving -n knative-serving

Knative Eventingコンポーネントの削除

Knative Eventing CRを削除するには、次のコマンドを実行します。

kubectl delete KnativeEventing knative-eventing -n knative-eventing

Knative Operatorの削除

リリースページを使用してKnativeをインストールした場合は、次のコマンドを実行してOperatorを削除します。

kubectl delete -f https://github.com/knative/operator/releases/download/knative-v1.16.0/operator.yaml

ソースからKnativeをインストールした場合は、ソースのルートディレクトリで次のコマンドを使用してアンインストールします。

ko delete -f config/

次のステップ

サイトトラフィックを理解するために、アナリティクスと Cookie を使用しています。お客様のサイト利用に関する情報は、その目的で Google と共有されます。詳細はこちら。

× OK