クラシックで IBM Cloud Kubernetes Service を使用して `dl-reverse-proxy` をホストする

クラシックで IBM Cloud Kubernetes Service を使用して dl-reverse-proxy for IBM Cloud® Direct Link をセットアップするには、以下の手順に従います。

IBM Cloud Kubernetes Service クラスターの作成

IBM Cloud アカウントに IBM Cloud Kubernetes Service クラスターを作成します。このクラスターは、 Satellite ロケーションとプライベート・ネットワーク上の IBM Cloud との間の接続として機能します。

クラスターのネットワーキングの基本を確認します。特に、以下の準備ができていることを確認してください。
- VLAN 管理(クラシック・クラスターのみ): クラスターのネットワーク接続用にパブリック VLAN とプライベート VLAN の両方を管理して選択します。
- サブネット・ルーティング: IBM Cloud インフラストラクチャー・アカウントの仮想ルーター機能 (VRF) または VLAN スパンニングを有効にして、ワーカー・ノードがプライベート・ネットワーク上で相互に通信し、プライベート・クラウド・サービス・エンドポイントと内部的に通信できるようにします。
- IP アドレス・スキーマ: クラスターとオンプレミス・ネットワークの間にサブネットの競合が存在しないことを確認します。
クラスターを作成するための準備に必要なステップを確認します。
CLI で標準クラシック・クラスターまたは VPC クラスターを作成します。以下の機能を使用してクラスターを作成します。
- クラシック・クラスター:
  - ゾーン: 任意の複数ゾーン対応ゾーン
  - ワーカー・ノード・フレーバー: 任意のクラシック・インフラストラクチャー・フレーバー
  - ネットワーク接続: パブリック VLAN とプライベート VLAN
  - ワーカー・プール: 少なくとも 2 つのワーカー・ノード
  - バージョン： 1.20.7 またはそれ以降
  - クラウド・サービス・エンドポイント: パブリック・エンドポイントとプライベート・エンドポイントの両方
  - サブネット: オンプレミス・データ・センターまたは別のクラウド・プロバイダーでセットアップした Satellite ロケーションのサブネットとデフォルト範囲が競合する場合は、 --pod-subnet オプションと --service-subnet オプションにサブネットを含めます。
- VPC クラスター:
  - ゾーン: 任意の複数ゾーン対応 VPC ゾーン
  - ワーカー・ノード・フレーバー: 任意の VPC インフラストラクチャー・フレーバー
  - バージョン： 1.20.7 またはそれ以降
  - ワーカー・プール: 少なくとも 2 つのワーカー・ノード
  - サブネット: オンプレミス・データ・センターまたは別のクラウド・プロバイダーでセットアップした Satellite ロケーションのサブネットとデフォルト範囲が競合する場合は、 --pod-subnet オプションと --service-subnet オプションにサブネットを含めます。
  - クラウド・サービス・エンドポイント: --disable-public-service-endpoint オプションを指定 しないで 、パブリック・エンドポイントとプライベート・エンドポイントの両方が作成されるようにします。
クラシック・クラスターまたは VPC クラスターの可用性を高めるために、複数のゾーンにデフォルトのワーカー・プールを分散させます。各ゾーンに少なくとも 2 つのワーカー・ノードが存在することを確認します。これにより、後続のステップで構成するプライベート ALB の可用性が高くなり、バージョンの更新を適切に受け取ることができます。
IBM Cloud Kubernetes Service クラスタをこのセッションのコンテキストとして設定します。
```
ibmcloud ks cluster config --cluster <cluster_name_or_ID>
```
NGINX リバース・プロキシーの名前空間を作成します。
```
kubectl create ns dl-reverse-proxy
```

クラスターでのプライベート Ingress ALB のセットアップ

プライベート・ネットワーク上の NGINX リバース・プロキシーのサービスを公開する IBM Cloud Kubernetes Service クラスターのプライベート Ingress アプリケーション・ロード・バランサー (ALB) をセットアップします。詳しくは、クラスター内のアプリをプライベート・ネットワークにのみ公開する場合の考慮事項と、 Ingress ALB を使用してアプリをプライベートに公開する場合の具体的なガイダンスを確認してください。

各ゾーンに、 「タイプ」 が private の ALB が少なくとも 1 つ存在することを確認します。
```
ibmcloud ks alb ls -c <cluster_name_or_ID>
```
プライベート ALB の状況が enabled であることを確認します。無効になっている場合は、以下のコマンドを実行して各プライベートALBを有効にする。
```
ibmcloud ks ingress alb enable classic --alb <ALB_ID> -c <cluster_name_or_ID> --version 0.45.0_1228_iks
```

オプション: 各パブリック ALB を無効にします。

ibmcloud ks ingress alb disable classic --alb <ALB_ID> -c <cluster_name_or_ID>

NGINX リバース・プロキシーがアクセス可能なプライベート ALB のカスタム・ドメインをセットアップし、オプションでドメインの TLS をセットアップします。
1. DNS サービス・プロバイダーを介してカスタム・ドメインを作成します。 Ingress の要件を満たすには、カスタム・ドメインが 130 文字以下でなければなりません。
2. プライベート ALB の IP アドレスを A レコードとして追加するか (クラシック・クラスター)、VPC ホスト名を CNAME として追加して (VPC クラスター)、カスタム・ドメインをプライベート ALB にマップします。 ALB の IP アドレス (クラシック) またはホスト名 (VPC) を見つけるには、ibmcloud ks ingress alb ls -c <cluster_name_or_ID> を実行します。 VPCクラスタでは、ホスト名がALBに割り当てられることに注意してください。これは、 10.X.X.X IPアドレスが固定ではなく、時間の経過とともに変更される可能性があるためです。
3. TLS終端を使用するには、カスタム・ドメインのTLS証明書を含むシークレットを dl-reverse-proxy ネームスペースに作成します。例えば、使用する TLS 証明書が IBM Cloud Certificate Manager に保管されている場合は、それに関連付けられたシークレットを、以下のコマンドを実行してクラスター内にインポートできます。詳しくは、 Ingress を使用したカスタム・ドメインを参照してください。
```
ibmcloud ks ingress secret create --name <secret_name> --cluster <cluster_name_or_ID> --cert-crn <certificate_crn> --namespace dl-reverse-proxy
```

カスタムドメインを使用するIngressリソースファイルを定義し、受信ネットワークトラフィックを、以降のステップで作成する nginxsvc。 <custom_ingress_domain> を、登録したドメインに置き換え、 <secret_name> を、ドメインの TLS 証明書用に作成したシークレットに置き換えます。

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: dl-ingress-resource
  annotations:
    kubernetes.io/ingress.class: "private-iks-k8s-nginx"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
spec:
  tls:
  - hosts:
    - <custom_ingress_domain>
    secretName: <secret_name>
  rules:
  - host: <custom_ingress_domain>
  http:
    paths:
    - path: /
      pathType: Prefix
      backend:
        service:
          name: nginxsvc
          port:
            number: 80

クラスタにIngressリソースを作成します。

kubectl apply -f dl-ingress-resource.yaml -n dl-reverse-proxy

これで、クラスター内のプライベート Ingress ALB は、 IBM Cloud プライベート・ネットワーク上のカスタム・ドメインを使用してリバース・プロキシー・サービスを公開するように構成されました。

NGINX リバース・プロキシーのデプロイ

Ingress ALB によってプライベート・ネットワーク上に公開されているクラスターに NGINX リバース・プロキシーをデプロイし、ご使用のロケーションの Satellite リンク・トンネル・サーバーを指すようにリバース・プロキシーを構成します。

次のステップでは、ローカルの YAML ファイルを編集して使用し、 ConfigMap, NGINX デプロイメントとサービスを作成します。別の方法として、 kubernetes/examples リポジトリの https-nginx ディレクトリなど、NGINX HTTPS サンプルリポジトリをクローンし、 Docker イメージを IBM Cloud Container Registry のネームスペースにプッシュします。サンプル・リポジトリーを使用する場合は、 default.conf ファイルなどの NGINX 構成に、このセクションのステップ 2 で指定したサーバー・ブロックが含まれていることを確認してください。

リンク・トンネル・サーバーのプライベート・サービス・エンドポイントを取得します。出力で、 location タイプのエンドポイントについてリストされている Address を探します。

ibmcloud sat endpoint ls --location <location_ID>

この出力例では、トンネル・サーバー・エンドポイントは c-04.private.us-east.link.satellite.cloud.ibm.com です。ポートを含めないでください。

ID                           Name                                            Destination Type   Address
c1hnscnw0h7i5uf0t8eg_zE6Nx   openshift-api-c1muom3w0kfdne2kb37g              location           TCP   d-04-ws.private.us-east.link.satellite.cloud.ibm.com:33809
c1hnscnw0h7i5uf0t8eg_2F3Xo   openshift-api-c2e3ishw0sdo08f5902g              location           TCP   d-04-ws.private.us-east.link.satellite.cloud.ibm.com:34222
c1hnscnw0h7i5uf0t8eg_EczUw   satellite-cos-c1hnscnw0h7i5uf0t8eg              cloud              TLS   m65f0b26d6c5f695647f5-6b64a6ccc9c596bf59a86625d8fa2202-c000.us-east.satellite.appdomain.cloud:30235
c1hnscnw0h7i5uf0t8eg_56zpT   satellite-cosCrossRegion-c1hnscnw0h7i5uf0t8eg   cloud              TLS   m65f0b26d6c5f695647f5-6b64a6ccc9c596bf59a86625d8fa2202-c000.us-east.satellite.appdomain.cloud:31774
...

NGINX リバース・プロキシーの ConfigMap を作成し、ファイルを confnginx.yaml として保存します。 server ブロックで、 <custom_ingress_domain> をプライベート Ingress ALB 用に登録したドメインに置き換え、 <tunnel_server_ep> をステップ 1 で見つけたトンネル・サーバー・エンドポイントに置き換えます。

apiVersion: v1
kind: ConfigMap
metadata:
  name: confnginx
data:
  nginx.conf: |
    user  nginx;
    worker_processes  1;
    error_log  /var/log/nginx/error.log warn;
    events {
        worker_connections  1024;
    }
    http {
      include       /etc/nginx/mime.types;
      default_type  application/octet-stream;
      log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$http_x_forwarded_for"';
      access_log  /var/log/nginx/access.log  main;
      sendfile        on;
      keepalive_timeout  65;
      server {
        listen 80;

        server_name <custom_ingress_domain>;

        proxy_connect_timeout 180;
        proxy_send_timeout 180;
        proxy_read_timeout 180;

        location / {
          proxy_pass https://<tunnel_server_ep>;
          proxy_ssl_server_name on;
          proxy_http_version 1.1;
          proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection "upgrade";
        }
      }
    }

IBM Cloud Kubernetes Service クラスタに ConfigMap を作成する。
```
kubectl apply -f confnginx.yaml -n dl-reverse-proxy
```

NGINX リバース・プロキシーのデプロイメント構成とサービスを作成して、そのデプロイメントがプライベート Ingress ロード・バランシングに組み込まれるようにします。ファイルを nginx-app.yaml として保存します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          ports:
          - containerPort: 80
          volumeMounts:
            - name: nginx-config
              mountPath: /etc/nginx/nginx.conf
              subPath: nginx.conf
      volumes:
        - name: nginx-config
          configMap:
            name: confnginx
---
apiVersion: v1
kind: Service
metadata:
  name: nginxsvc
  labels:
    app: nginx
spec:
  type: NodePort
  ports:
  - port: 80
    protocol: TCP
    name: http
  - port: 443
    protocol: TCP
    name: https
  - port: 8080
    protocol: TCP
    name: tcp
  selector:
    app: nginx

IBM Cloud Kubernetes Service クラスター内にデプロイメントとサービスを作成します。
```
kubectl apply -f nginx-app.yaml -n dl-reverse-proxy
```

これで、リバース・プロキシーは、カスタム Ingress サブドメインへの着信接続を終了し、 Satellite リンク・トンネル・サーバーへの新規接続を開き、トンネル・サーバーに要求を転送するように構成されました。

リバース・プロキシーを使用するためのリンクの構成

リバース・プロキシーへの Direct Link 接続を介してトラフィックを送信するように、 Satellite ロケーションのリンク・トンネル・クライアントを構成します。

Satellite のリンク構成変更が正常に行われたことを確認するには、ロケーションの 「状態」 が normal であることを確認します。
```
ibmcloud sat location get --location <location_name_or_ID>
```
タイプ cloud のリンク・エンドポイントを作成して、トラフィックが Satellite の場所から IBM Cloud に流れることを確認します。例えば、 IBM Cloud サービスのプライベート・サービス・エンドポイントの cloud エンドポイントを作成してから、 Satellite ロケーションで実行されている Red Hat OpenShift on IBM Cloud クラスターからサービスへの接続をテストします。を作成することができます。
タイプ location のリンク・エンドポイントを作成して、トラフィックが IBM Cloud から Satellite のロケーションに流れることを確認します。例えば、自分のロケーションの Satellite クラスター内のアプリの IP アドレス用の location エンドポイントを作成し、 IBM Cloud プライベート・ネットワーク内のサービスからアプリへの接続をテストすることができます。

リンク・エンドポイントを介して流れるすべてのトラフィックが Direct Link 接続を使用するように、 Satellite リンク・セットアップが正常に構成されました。

クラシックで IBM Cloud Kubernetes Service を使用して dl-reverse-proxy をホストする

IBM Cloud Kubernetes Service クラスターの作成

クラスターでのプライベート Ingress ALB のセットアップ

NGINX リバース・プロキシーのデプロイ

リバース・プロキシーを使用するためのリンクの構成

クラシックで IBM Cloud Kubernetes Service を使用して `dl-reverse-proxy` をホストする