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

考慮事項

SLB 再利用の制限

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

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

  • ACS クラスターでイントラネット SLB インスタンスを再利用するには、SLB インスタンスと ACS クラスターが同じ仮想プライベートクラウド (VPC) 内にある必要があります。

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

    • 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 インスタンスを再利用する場合は、各クラスターで namespace と 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 コンソールで手動で変更した設定が上書きされる可能性があります。

  重要

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

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

SLB のクォータ制限

• CCM は、Type=LoadBalancer の Service ごとに SLB インスタンスを作成します。デフォルトでは、最大 60 個の CLB インスタンスと 60 個の NLB インスタンスを持つことができます。このクォータを増やすには、Quota Centerコンソールにログインしてアプリケーションを送信。

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

  • バックエンドサーバーの数：デフォルトでは、CLB インスタンスには最大 200 台のバックエンドサーバーを、NLB インスタンスには最大 400 台の ECS、ENI、または IP ベースのバックエンドサーバーをアタッチできます。必要なクォータは次のように計算されます：バックエンドサーバーの数 × targetPort の数。クォータを増やすには、事前にQuota Centerコンソールにログインしてアプリケーションを送信。

  • インスタンスがサーバーグループにアタッチできる回数：デフォルトでは、同じ ECS インスタンスまたは ENI は、CLB インスタンスの最大 50 の異なるバックエンドサーバーグループ、および NLB インスタンスの最大 200 の異なるバックエンドサーバーグループにアタッチできます。より多くのサーバーグループにアタッチするには、Quota Centerコンソールにログインしてアプリケーションを送信。

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

• CCM は、Service で定義されたポートに基づいてリスナーを作成します。デフォルトでは、CLB または NLB インスタンスに最大 50 個のリスナーを追加できます。リスナーをさらに追加するには、Quota Centerコンソールにログインしてアプリケーションを送信。

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

  SLB のクォータをクエリするには、「Server Load Balancer クォータ管理」をご参照ください。

ステップ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 マニフェストの selector と一致させる必要があります
     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 Service を作成し、アプリケーションを公開できます。