Google Cloud Auto Scaler、マネージド インスタンス グループ、ターゲット プール、ネットワーク ロードバランサがどのように連携するかが少しわかりにくいと思います。ドキュメントが少し少なく、NLB (HTTPS が必要なので必要であり、現在の HTTP ロードバランサでは不十分です) の使用方法と Auto Scaler の間に明確なつながりがありません。Auto Scaler の主な使用例は、NLB の背後にあるインスタンスを管理することだと思います。
問題 1: マネージド インスタンス グループにターゲット プールを割り当てても ([set-target-pool][1] 経由)、既存のインスタンスはそのターゲット プールに割り当てられないようです (私たちのミスかもしれません)。
問題 2: 管理対象グループ インスタンスは、パブリック IP (ただし一時的) を持っていない限り、NLB でローテーションされないようです。これも私たちのミスかもしれませんが、プライベート IP で十分ではないでしょうか?
問題 3: マネージド インスタンス グループ上のインスタンスが不健全になった場合 (たとえば、HTTP に応答しなくなった場合)、NLB はそれをローテーションから削除します (ヘルス チェック経由)。ただし、Auto Scaler は正常な状態を維持し、それを有効な実行中のインスタンスと見なしているようです。
何が欠けているのでしょうか?
答え1
HTTPSロードバランシングはアルファ版が利用可能になりましたそして、それがあなたにとって最善の解決策となるかもしれません。
問題1: インスタンスグループマネージャは、グループが完全に同質であることを前提としています。そのため、マネージドインスタンスグループインスタンスをターゲット プールに追加するように構成されている場合、既存のインスタンスだけでなく将来のインスタンスも追加するのは当然です。一部のインスタンスをターゲット プールに追加し、一部のインスタンスを追加しないように分割する必要がある場合は、インスタンス グループを分離する必要があります。
問題 2: プライベート IP アドレスのみを持つインスタンスでネットワーク負荷分散を使用することは可能です。ただし、転送ルールには外部 IP アドレスが必要です。
問題 3: 正解です。Autoscaler はヘルス チェックを行わないため、負荷分散ヘルス チェックに失敗したインスタンスを自動的に破棄することはありません。現在これが必要な場合は、手動で行う必要があります (インスタンス グループ マネージャーの「再作成」呼び出しを使用することをお勧めします)。