Container Compute Service (ACS) クラスターで Cloud Controller Manager (CCM) をアップグレードすると、システムは事前チェックを実行し、各 Server Load Balancer (SLB) インスタンスが対応する Kubernetes サービス仕様と一致することを確認します。不一致が見つかった場合、事前チェックは失敗し、意図した変更を説明するエラーメッセージが返されます。
このトピックでは、各事前チェックエラーをカテゴリ別に一覧表示し、根本原因を説明し、解決手順を説明します。
事前準備
Cloud Controller Manager のドキュメントを確認し、新しいバージョンで導入される変更点を理解してください。
事前チェックの進行中は、いかなるサービスも変更しないでください。事前チェック中にサービスを変更すると、不正確な結果が生じる可能性があります。その場合は、事前チェックを再実行してください。それでも事前チェックが失敗する場合は、チケットを送信してください。
CCM は、Kubernetes サービスのアノテーションに基づいて SLB インスタンスを管理します。CCM が SLB インスタンスを管理している間に SLB コンソールで手動で変更すると、設定ドリフトが発生し、これが事前チェック失敗の一般的な原因となります。ロードバランサーは、Kubernetes サービスのアノテーションを通じて完全に管理するか、外部で管理される SLB を使用するかのいずれかの方法を選択し、両方のアプローチを混在させないでください。
SLB の仕様と課金の不一致
これらのエラーは、SLB インスタンスの仕様、帯域幅、課金方法がサービスアノテーションで指定された内容と異なる場合に発生します。
modify the slb instance spec
原因：SLB インスタンスの仕様が、サービスアノテーションの値と一致しません。
解決策：サービスアノテーションの service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec を、実際の SLB インスタンスの仕様と一致するように設定します。詳細については、「アノテーションを使用した CLB インスタンスの設定」をご参照ください。
modify the slb internet spec
原因：SLB の最大帯域幅または課金方法が、サービスアノテーションと一致しません。
解決策：
帯域幅が正しくない場合は、サービスアノテーションの
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-bandwidthを SLB インスタンスと一致するように設定します。詳細については、「帯域幅課金型の CLB インスタンスの作成」をご参照ください。課金方法が正しくない場合は、サービスアノテーションの
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-charge-typeを SLB インスタンスと一致するように設定します。詳細については、「帯域幅課金型の CLB インスタンスの作成」をご参照ください。
modify loadbalancer instance charge type
原因：サービスの課金方法が SLB インスタンスと異なります。
解決策：
SLB コンソールで Classic Load Balancer (CLB) インスタンスの課金方法を PayByCLCU に手動で変更した場合は、サービスから
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-specアノテーションを削除します。SLB コンソールで課金方法を変更していない場合は、事前チェック中にサービスを変更せず、事前チェックを再実行してください。
サービスのライフサイクルの不一致
これらのエラーは、SLB インスタンスのライフサイクルが Kubernetes サービスと同期していない場合に発生します。
create a new load balancer
原因：サービスの作成または既存のサービスの同期の一環として、SLB インスタンスが作成されています。
解決策：サービスが Pending または Running 状態であるかを確認します：
kubectl get svc <service-name> -n <namespace><service-name> をサービス名に、<namespace> をサービスの名前空間に置き換えます。
サービスが Running 状態で、パブリック IP アドレスを持っている場合は、事前チェックを再実行してください。
サービスが Pending 状態の場合は、チケットを送信してください。
delete the load balancer
原因：サービスは存在しなくなりましたが、関連付けられた SLB インスタンスが削除されていません。
解決策：
SLB インスタンスが不要になった場合は、SLB コンソールで削除してください。
SLB インスタンスがまだ必要な場合は、チケットを送信してください。
リスナー設定の不一致
これらのエラーは、サービスポートの設定が SLB リスナーの設定と異なる場合に発生します。これは通常、SLB コンソールでリスナーを手動で変更した後に発生します。
stop listener / start listener
原因：サービスポートが SLB リスナーポートと異なります。
解決策：
SLB コンソールでリスナーを変更していない場合は、事前チェック中にサービスを変更せず、事前チェックを再実行してください。
SLB コンソールでリスナーを手動で変更した場合は、サービス設定を SLB リスナーと比較し、リスナー設定を復元してから、事前チェックを再実行してください：
kubectl -n <namespace> describe svc <service-name>
delete listener
原因：サービスポートが SLB リスナーポートと異なります。
解決策：
SLB コンソールでリスナーを変更していない場合は、事前チェック中にサービスを変更せず、事前チェックを再実行してください。
SLB コンソールでリスナーを手動で変更した場合は、余分なリスナーを削除し、事前チェックを再実行してください。
create listener
原因：サービスポートが SLB リスナーポートと異なります。
解決策：
SLB コンソールでリスナーを変更していない場合は、事前チェック中にサービスを変更せず、事前チェックを再実行してください。
SLB コンソールでリスナーを手動で変更した場合は、不足しているリスナーを追加し、事前チェックを再実行してください。
update listener
原因：サービスポートが SLB リスナーポートと異なります。
解決策：
SLB コンソールでリスナーを変更していない場合は、事前チェック中にサービスを変更せず、事前チェックを再実行してください。
SLB コンソールでリスナーを手動で変更した場合は、サービス設定を SLB リスナー設定と比較し、リスナー設定 (証明書、アクセス制御設定、ヘルスチェック、Cookie を含む) を復元します。その後、事前チェックを再実行してください。これらの設定を制御するアノテーションの詳細については、「アノテーションを使用した CLB インスタンスの設定」をご参照ください。
kubectl -n <namespace> describe svc <service-name>
バックエンドサーバーと vServer グループの不一致
これらのエラーは、サービスエンドポイントが SLB インスタンスのバックエンドサーバーまたは vServer グループの設定と異なる場合に発生します。
remove backend servers / add backend servers
原因：サービスエンドポイントが SLB バックエンドサーバーの設定と異なります。
解決策：
SLB コンソールでバックエンドサーバーの設定を変更していない場合は、事前チェック中にサービスエンドポイントを変更せず、事前チェックを再実行してください。
SLB コンソールでバックエンドサーバーの設定を手動で変更した場合は、SLB インスタンスの vServer グループ設定を復元し、事前チェックを再実行してください。
create VServerGroup / delete VServerGroup / add VServerGroup backends / remove VServerGroup backends
原因：サービスエンドポイントが SLB インスタンスの vServer グループ設定と異なります。
解決策：
SLB コンソールで vServer グループを変更していない場合は、事前チェック中にサービスエンドポイントを変更せず、事前チェックを再実行してください。
create VServerGroupエラーが複数回の事前チェック後も続く場合は、チケットを送信してください。SLB コンソールでバックエンドサーバーの設定を手動で変更した場合は、SLB インスタンスの vServer グループ設定を復元し、事前チェックを再実行してください。
サポートの利用
解決手順に従っても事前チェックが失敗し続ける場合は、チケットを送信してください。トラブルシューティングを迅速化するために、次の情報を含めてください：
ACS クラスター ID
アップグレード元とアップグレード先の CCM バージョン
正確な事前チェックのエラーメッセージ
サービスの YAML 出力：
kubectl get svc <service-name> -n <namespace> -o yamlSLB インスタンス ID と SLB コンソールでの現在の設定