Container Compute Service:既存のロードバランサーを使用したアプリケーションの公開

注意事項

SLB の再利用に関する制限

• 再利用する SLB インスタンスは、次の要件を満たす必要があります。

  • SLB コンソールで手動で作成した SLB インスタンスのみ再利用できます。クラウドコントローラーマネージャー (CCM) によって自動的に作成されたインスタンスや、クラスター API サーバーによって使用されているインスタンスは再利用できません。

  • ACK クラスターでイントラネット SLB インスタンスを再利用するには、SLB インスタンスと ACK クラスターが同じ Virtual Private Cloud (VPC) 内にある必要があります。

  • SLB インスタンスのアドレスタイプは、Service のアクセスタイプと一致する必要があります。

    • サービスがパブリック (アノテーション service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "internet" で指定) を提供する場合、 SLB インスタンスのアドレスタイプはインターネットである必要があります。

    • Service が内部アクセス (アノテーション service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" で指定) を提供する場合、SLB インスタンスの アドレスタイプ は 内部ネットワーク である必要があります。

  • 複数の Service で、同じ SLB インスタンスの同じリスナーポートを使用することはできません。

  • クラスター間で SLB インスタンスを再利用する場合は、各クラスターで名前空間と Service 名の組み合わせが一意であることを確認してください。

• CCM は、type: LoadBalancer の Service に対してのみ SLB インスタンスを設定します。

  重要

  type: LoadBalancer の Service を別のタイプに変更すると、CCM は SLB インスタンスに追加された設定を削除します。その結果、Service は SLB インスタンス経由でアクセスできなくなります。

• CCM は宣言型 API を使用し、特定の条件下で Service の設定に基づいて SLB の設定を自動的に調整します。service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true" アノテーションが設定されている場合、SLB コンソールで手動で変更した設定が上書きされる可能性があります。

  重要

  SLB コンソールで、ACS によって管理される SLB インスタンスの構成を手動で変更しないでください。そうしないと、構成が失われ、サービスにアクセスできなくなる可能性があります。

• 既存の LoadBalancer サービスの SLB インスタンスを変更することはできません。SLB インスタンスを変更したい場合は、新しい Service を作成する必要があります。

SLB のクォータ制限

• CCM は、Type=LoadBalancer の Service ごとに SLB インスタンスを 1 つ作成します。デフォルトのクォータは、CLB インスタンス 60 個とネットワークロードバランサー (NLB) インスタンス 60 個です。このクォータを増やすには、Quota Centerコンソールにログインしてアプリケーションを送信してください。

• CCM は、Service の設定に基づいて、ECS インスタンスまたは Elastic Network Interface (ENI) を SLB のバックエンドサーバーグループにアタッチし、targetPort ごとに個別のサーバーグループを作成します。クォータ制限は次のとおりです。

  • バックエンドサーバー数：CLB インスタンスは最大 200 のバックエンドサーバーをサポートし、NLB インスタンスは最大 400 の ECS、ENI、または IP ベースのサーバーをサポートします。クォータの計算式：バックエンドサーバー数 × targetPorts。クォータを増やすには、事前にQuota Centerコンソールにログインしてアプリケーションを送信してください。

  • インスタンスごとのサーバーグループアタッチメント数：1 つの ECS インスタンスまたは ENI は、最大 50 の CLB バックエンドサーバーグループと 200 の NLB バックエンドサーバーグループにアタッチできます。この制限を増やすには、Quota Centerコンソールにログインしてアプリケーションを送信してください。

  • ローリングアップデート中の追加クォータ：古い Pod が削除される前に新しい Pod が作成されるため、想定を超える追加のクォータが消費される可能性があります。事前に十分なクォータを確保してください。

• CCM は Service のポートに基づいてリスナーを作成します。デフォルトの制限は、CLB または NLB インスタンスごとに 50 リスナーです。リスナーを追加するには、Quota Centerコンソールにログインしてアプリケーションを送信してください。

• 詳細については、「CLB の制限」および「NLB の制限」をご参照ください。

  Server Load Balancer クォータ管理で SLB のクォータを照会します。

ステップ 1：サンプルアプリケーションのデプロイ

以下の手順では、kubectl を使用してアプリケーションをデプロイする方法を説明します。

1. Cloud Shell 上の kubectl を使用してクラスターに接続します。

2. `my-nginx.yaml` という名前のファイルを作成し、次の内容を記述します。

   YAML コンテンツの表示

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-nginx                 # サンプルアプリケーションの名前。
     labels:
       app: nginx
   spec:
     replicas: 3                    # レプリカ数。
     selector:
       matchLabels:
         app: nginx                 # この値は、アプリケーションを公開するために Service マニフェストのセレクターと一致する必要があります。
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginx:latest
           ports:
           - containerPort: 80        # このポートは Service で公開する必要があります。

3. 次のコマンドを実行して、my-nginx サンプルアプリケーションをデプロイします。

   kubectl apply -f my-nginx.yaml

4. 次のコマンドを実行して、アプリケーションが実行中であることを確認します。

   kubectl get deployment my-nginx

   想定される出力：

   NAME       READY   UP-TO-DATE   AVAILABLE   AGE
   my-nginx   3/3     3            3           50s

ステップ 2：Service を使用したアプリケーションの公開

コンソールまたは kubectl のいずれかを使用して LoadBalancer サービスを作成し、アプリケーションを公開できます。