Knative OSS へのワークロードの移行

このガイドでは、ワークロードを移行して、Google Kubernetes Engine を使用してオープンソースの Knative サービスで動作するようにします。通常は、ワークロードを移行するために、Knative serving コンポーネントを新しい GKE クラスタにインストールしてから、各サービスをその Knative クラスタに再デプロイする必要があります。

オープンソースの Knative を使用、管理、サポートするのはお客様自身の選択と責任ですが、Knative に移行することで、Google Kubernetes Engine プラットフォームでワークロードの実行を継続できます。

大きな違い:

サポートは Google Kubernetes Engine に限定されます。Knative のサポートについては、Knative コミュニティにお問い合わせください。
Google Cloud CLI（gcloud）は Google Kubernetes Engine でのみサポートされています。Knative は、kubectl コマンドと kn コマンドをサポートしています。kn のインストール方法

始める前に

新しい GKE クラスタにアクセスできる必要があります。
- 同じ Google Cloud プロジェクトまたは新しい Google Cloud プロジェクトで新しいクラスタを作成できます。
- クラスタが Knative の要件を満たしている必要があります。
- クラスタの作成方法を確認してください。
  - Standard クラスタ
  - 限定公開クラスタ
クラスタ構成は新しい Knative クラスタに手動で移行する必要があります。たとえば、次の構成を手動で移行します。
新しい IAM アクセス制御と RBAC アクセス制御を作成して構成する必要があります。
- アクセス制御を構成する
- Workload Identity

Google Kubernetes Engine への Knative のインストール

Knative には、選択可能なインストールオプションとネットワーキングレイヤがいくつか用意されています。次の Knative インストール手順では、Knative Operator メソッドと Istio ネットワーキングレイヤを使用します。

Knative Operator をインストールします。

Operator をクラスタにデプロイします。

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

VERSION は、Knative Operator のバージョンに置き換えます。

例:

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

default Namespace を使用するように kubectl CLI を設定します。
```
kubectl config set-context --current --namespace=default
```

Operator が正常に作成されたことを確認します。

kubectl get deployment knative-operator

結果:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
knative-operator   1/1     1            1           6m43s

Knative Serving コンポーネントをインストールします。
1. 次の内容で YAML ファイル（たとえば、SERVING_FILENAME.yaml）を作成します。
```
apiVersion: v1
kind: Namespace
metadata:
  name: knative-serving
---
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
```
2. YAML ファイルをクラスタにデプロイします。
```
kubectl apply -f SERVING_FILENAME.yaml
```
  SERVING_FILENAME は、作成した YAML ファイルに置き換えます。
サイドカーインジェクションをネットワーキングレイヤとして使用して Istio をインストールします。

別の Istio インストールを実行して構成することもできます。Knative のウェブサイトで、Istio のインストールオプションを確認してください。このインストールには 30 分以上かかることがあります。
1. リリースページから Istio をダウンロードします。
2. Docker のレート制限を回避するため、--set hub=gcr.io/istio-release フラグを指定して次のコマンドを実行し、Istio をインストールします。
```
istioctl install --set hub=gcr.io/istio-release
```
3. 次のコマンドを実行して、サイドカーインジェクションを有効にします。
```
kubectl label namespace default istio-injection=enabled
```
4. 省略可: デフォルトでは、Istio は istio-system Namespace にインストールされます。別の Namespace を構成する場合は、次の操作を行います。
  1. Istion のカスタム Namespace を構成するには、SERVING_FILENAME.yaml 構成ファイルに spec.config.istio 属性を追加します。例:
```
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  # ...
  config:
    istio:
      local-gateway.LOCAL_GATEWAY_NAMESPACE.knative-local-gateway: "knative-local-gateway.ISTIO_NAMESPACE.svc.cluster.local"
```
    次のように置き換えます。
    - LOCAL_GATEWAY_NAMESPACE は、Knative Serving をインストールした Namespace です。デフォルト: knative-serving
    - ISTIO_NAMESPACE は、Istio がインストールされている Namespace です。デフォルト: istio-system
  2. 更新された SERVING_FILENAME.yaml サービスを Knative クラスタにデプロイします。
```
kubectl apply -f SERVING_FILENAME.yaml
```
  3. Istio のインストールを検証するには、istio-ingressgateway が指定された Namespace に存在することを確認します。
```
kubectl get svc istio-ingressgateway -n ISTIO_NAMESPACE
```
    ISTIO_NAMESPACE は、Istio をインストールした Namespace に置き換えます。デフォルト: istio-system
    
    結果:
```
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                                      AGE
istio-ingressgateway   LoadBalancer   10.232.10.190   34.123.5.116   15021:30337/TCP,80:32549/TCP,443:31210/TCP   119m
```

サービスの移行

サービスを移行するには、サービスの YAML 構成ファイルを Knative クラスタにデプロイします。

次のコマンドを実行して、Knative serving サービスをローカルの YAML ファイルにエクスポートします。
```
gcloud run services describe SERVICE --format export --namespace NAMESPACE --cluster CLUSTER --platform gke > FILENAME.yaml
```
次のように置き換えます。
- SERVICE: Knative serving サービスの名前。
- NAMESPACE: サービスが実行されている Namespace。
- CLUSTER: サービスが実行されているクラスタの名前。
- FILENAME: 任意の一意のファイル名。
エクスポートされた FILENAME.yaml ファイルを変更し、次のいずれかの属性とその値を削除して、不要な Knative serving 構成を削除します。
- metadata.annotations.kubectl.kubernetes.io/last-applied-configuration
- metadata.managedFields
- spec.template.spec.containers.readinessProbes
- spec.template.spec.enableServiceLinks
  
  たとえば、spec: > template: > spec: > containers: の属性から次の構成を削除する必要があります。
```
...
 readinessProbe:
   successThreshold: 1
   tcpSocket: {}
...
```
変更した .yaml ファイルを Knative クラスタにデプロイします。
```
kubectl apply -f SERVICE.yaml
```
SERVICE は、サービスの構成ファイルの名前に置き換えます。
テストドメインまたは cURL コマンドを使用して、デプロイしたサービスにアクセスします。ワイルドカード DNS サービスを使用して、サービスへの外部アクセスをテストできます。その他のオプションについては、Knative ドキュメントの DNS の構成セクションをご覧ください。

Magic DNS（sslip.io）を使用するには、次のコマンドを実行します。

sslip.io を直接使用することもできます。
```
kubectl apply -f https://github.com/knative/serving/releases/download/knative-vVERSION/serving-default-domain.yaml
```
VERSION は、Knative Serving のバージョンに置き換えます。

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

サービスへのトラフィックの移行

新しくデプロイしたサービスをテストし、本番環境のトラフィックをすべて移行する準備ができたら、カスタムドメインを構成し、登録事業者で DNS レコードを更新します。カスタムドメインを構成するの手順を実施します。