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 の要件を満たしている必要があります。
- クラスタの作成方法を学習してください。
  - 標準クラスタ
  - 限定公開クラスタ
次のようなクラスタ構成（ただし、これらに限定されません）は、新しい 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 名前空間を使用するように 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 名前空間にインストールされます。別の名前空間を構成する場合は、次の手順を使用します。
  1. Istion のカスタム名前空間を構成するには、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 をインストールした名前空間です。デフォルト: knative-serving
    - ISTIO_NAMESPACE は、Istio がインストールされている名前空間です。デフォルト: istio-system
  2. 更新された SERVING_FILENAME.yaml サービスを Knative クラスタにデプロイします。
```
kubectl apply -f SERVING_FILENAME.yaml
```
  3. Istio のインストールを検証するには、istio-ingressgateway が指定された名前空間に存在することを確認します。
```
kubectl get svc istio-ingressgateway -n ISTIO_NAMESPACE
```
    ISTIO_NAMESPACE は、Istio をインストールした名前空間に置き換えます。デフォルト: 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 は、サービスが実行されている名前空間に置き換えます。
- 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 レコードを更新できます。カスタムドメインを構成するの手順を実行してください。。