本頁面將概略說明全域外部應用程式負載平衡器和傳統版應用程式負載平衡器的差異，並詳細說明如何將現有的傳統版應用程式負載平衡器資源遷移至全域外部應用程式負載平衡器。
如要充分運用全域外部應用程式負載平衡器的進階流量管理功能，建議您將傳統版應用程式負載平衡器資源遷移至全域外部應用程式負載平衡器基礎架構。
比較傳統版應用程式負載平衡器和全域外部應用程式負載平衡器
遷移資源前，請先瞭解傳統版應用程式負載平衡器和全域外部應用程式負載平衡器的差異。
功能差異
全域外部應用程式負載平衡器不支援下列功能。這些功能僅適用於傳統版應用程式負載平衡器：
- 標準網路級別
-
如要為 GKE 叢集部署全域外部應用程式負載平衡器，請改用 GKE Gateway 控制器。如需設定操作說明，請參閱「部署 Gateway」。
資料層差異
下表列出傳統版應用程式負載平衡器和全域外部應用程式負載平衡器在資料層的差異。這些差異會影響負載平衡器對某些常見事件的回應方式。
| 事件 | 傳統版應用程式負載平衡器回應 | 全域外部應用程式負載平衡器回應 |
| 狀態/錯誤代碼 | ||
| 所有後端的運作狀態皆不良 | 傳回 HTTP 502 | 會傳回 HTTP 503 |
| 要求使用已遭禁止的 SSL 密碼 | 傳回 HTTP 502 | 會傳回 HTTP 503 |
| 後端重設早期上游連線 | 傳回 HTTP 502 | 會傳回 HTTP 503 |
| 連線升級失敗 (例如升級至 WebSocket) | 會傳回 HTTP 400 | 傳回 HTTP 403 |
| 標題太大 | 會傳回 HTTP 413 | 傳回 HTTP 431 |
| 配額與限制 | ||
| 網址對應設定 | 這兩種負載平衡器的網址對應設定限制有顯著差異。詳情請參閱「配額：網址對應」說明文件。 | |
| 標頭處理 | ||
| 要求使用無主體的自訂 HTTP 方法 | 將 Transfer Encoding: Chunked 標頭新增至傳送至後端的要求 |
將 Content-Length: 0 標頭新增至傳送至後端的要求 |
新增至傳送至後端的要求的 X-Forwarded-For 標頭格式 |
在 IP 之間使用「, 」分隔符號 |
在 IP 之間使用「,」分隔符 (半形逗號後不得有空格) |
| 保留標頭大小寫 | 標頭大小寫會保留 | 所有標頭鍵都會轉換為小寫 |
| 重複的標頭名稱 | 允許 | 重複的標頭可合併為單一標頭，並依序附加值並以半形逗號分隔，這符合 RFC 7230 的規定。 |
| (僅限 HTTP/1.1) 無效的標頭名稱 (例如標頭中含有不支援的字元) | 允許 (適用於 HTTP/1.1) | 傳回 HTTP 502 (適用於 HTTP/1.1) |
(僅限 HTTP/1.1) 要求中重複 (但相同) 的 Content-Length 標頭 |
允許 (適用於 HTTP/1.1) | 傳回 HTTP 502 (適用於 HTTP/1.1) |
| (僅限 HTTP/1.1) 標頭中的多個主機 | 新增 2 個以上的主機，且第一個主機有效時，系統會接受標頭 | 新增 2 個以上主機，其中任何一個主機無效時，負載平衡器會傳回 HTTP 502 |
(僅限 HTTP/1.1) Connection: Keep-Alive
標頭 |
根據預設，在傳送至後端的要求中加入 Keep-Alive header |
預設不會新增此標頭 |
| 要求處理 | ||
| 要求中的反斜線 | 網址未變更 | 轉換為斜線 |
| 合併要求中的重複斜線 | 不合併的斜線 | 合併斜線 |
| 要求路徑中的 `#` | 允許 | 會傳回 HTTP 400 |
| (僅限 HTTP/1.1) 要求路徑中含有無效字元 (例如 `\\x7f\\x7f`) | 允許 (適用於 HTTP/1.1) | 傳回 HTTP 502 (適用於 HTTP/1.1) |
| 流量分配 (網址對應設定) | ||
| 用戶端要求包含連接埠號碼 | 即使您在網址對應中設定了含有通訊埠的主機，系統仍會忽略通訊埠編號。系統只會考量主機名稱。舉例來說，example.com:5000 的要求會與 example.com 的後端服務進行比對。 |
系統會同時考量主機名稱和通訊埠號碼。舉例來說，example.com:5000 的要求會與 example.com:5000 的後端服務進行比對。如果沒有符合的項目，系統會使用預設的後端服務。 |
如要進一步瞭解差異和支援的功能，請參閱「負載平衡器功能比較」和「Application Load Balancer 總覽」。
從傳統版遷移至全域外部應用程式負載平衡器
如要遷移至全域外部應用程式負載平衡器，您必須將負載平衡資源的負載平衡架構 (具體來說，是後端服務和轉送規則) 從 EXTERNAL 變更為 EXTERNAL_MANAGED。為此，您必須執行一系列遷移步驟，以便在實際完成遷移前，先使用新的負載平衡配置測試部分網路流量。在資源遷移期間，您可以控制要將多少百分比的要求傳送至傳統版應用程式負載平衡器基礎架構或全域外部應用程式負載平衡器基礎架構。
下圖顯示遷移前後負載平衡資源的負載平衡配置。
請注意上圖中的下列事項：
- 在資源遷移完成前，所有要求都會使用傳統的應用程式負載平衡器基礎架構。
- 在資源遷移期間，部分要求會傳送至全域外部應用程式負載平衡器基礎架構，其餘要求則會傳送至傳統版應用程式負載平衡器基礎架構。
- 資源遷移完成後，所有要求都會使用全域外部應用程式負載平衡器基礎架構。
為確保轉換作業順利進行，請按照指定順序遷移下列傳統版 Application Load Balancer 資源：
遷移附加至負載平衡器轉送規則的所有後端服務。
遷移附加至負載平衡器轉送規則的所有後端值區。您要在轉送規則層級執行這項操作，因為後端 bucket 沒有負載平衡配置。
遷移負載平衡器的轉送規則。
您只能在已遷移轉送規則所附加的所有後端服務和後端值區後，再遷移轉送規則。
遷移狀態
您可以將資源設為不同的狀態，然後將負載平衡配置方案變更為 EXTERNAL_MANAGED，藉此遷移資源。
PREPARE：將資源設為此狀態，以便準備遷移。TEST_BY_PERCENTAGE：如要測試已準備的資源，請將資源設為此狀態，以便傳送部分網路流量。這個階段為選用階段。TEST_ALL_TRAFFIC：將資源設為此狀態，即可透過全域外部應用程式負載平衡器基礎架構，而非傳統應用程式負載平衡器基礎架構，將所有網路流量傳送至資源。
遷移流程
為確保不會發生服務中斷時間，您必須按照特定順序，將資源從傳統版應用程式負載平衡器基礎架構遷移至全域外部應用程式負載平衡器基礎架構，然後將負載平衡架構從 EXTERNAL 變更為 EXTERNAL_MANAGED，完成遷移作業。
遷移負載平衡器的後端服務。
針對每項後端服務重複執行下列步驟。
為後端服務做好遷移準備。
在任何流量可透過全域外部應用程式負載平衡器基礎架構傳送之前，請將後端服務的狀態設為
PREPARE。這可讓後端服務處理全域外部應用程式負載平衡器基礎架構網路流量。後端服務需要一些時間 (約六分鐘) 才能準備好透過全域外部應用程式負載平衡器基礎架構傳送流量。選用：測試已準備好的後端服務。
後端服務處於
PREPARE狀態後，請將其狀態設為TEST_BY_PERCENTAGE，並將傳統版應用程式負載平衡器網路流量百分比設為全域外部應用程式負載平衡器基礎架構。雖然這個階段是選用的，但我們建議您在遷移後端服務前先測試流量。建議先從較低的百分比值開始，並監控資源的記錄。如果後端服務的運作情況符合預期，請逐步將百分比提高至 100%。
在
TEST_BY_PERCENTAGE狀態下，您無法使用全域外部應用程式負載平衡器基礎架構的其他功能。將所有傳統版 Application Load Balancer 網路流量傳送至已準備好的後端服務。
後端服務測試成功後，請將其狀態設為
TEST_ALL_TRAFFIC，並將所有傳統應用程式負載平衡器網路流量傳送至已準備好的後端服務。後端服務需要一些時間 (約六分鐘) 才能處理網路流量。在
TEST_ALL_TRAFFIC狀態下，您無法使用全域外部應用程式負載平衡器基礎架構的其他功能。將已遷移後端服務的負載平衡架構變更為
EXTERNAL_MANAGED。在全域外部應用程式負載平衡器基礎架構上測試準備好的後端服務後，請將其負載平衡架構變更為
EXTERNAL_MANAGED。後端服務需要一段時間 (約六分鐘) 才能完全遷移。後端服務的負載平衡架構變更為EXTERNAL_MANAGED後，您就可以使用全域外部應用程式負載平衡器基礎架構的進階功能。
遷移負載平衡器的後端值區。您可以在轉送規則層級執行這項操作，因為後端值區沒有負載平衡配置。
針對每個值層重複執行下列步驟。
準備後端 bucket 以便遷移。
在任何流量可透過全域外部應用程式負載平衡器基礎架構傳送之前，請將後端集區的狀態設為
PREPARE，並等待一段時間 (約六分鐘)。選用：測試已準備好的後端服務。
後端值區處於
PREPARE狀態後，請將其狀態設為TEST_BY_PERCENTAGE，並將傳統版應用程式負載平衡器網路流量百分比設為全域外部應用程式負載平衡器基礎架構。將所有傳統版應用程式負載平衡器網路流量傳送至準備好的後端桶。
將後端值區的狀態設為
TEST_ALL_TRAFFIC，並將所有傳統應用程式負載平衡器網路流量傳送至該值區。後端值區需要一些時間 (約六分鐘) 才能處理網路流量。在
TEST_ALL_TRAFFIC狀態下，您無法使用全域外部應用程式負載平衡器基礎架構的其他功能。
遷移轉送規則。
針對每個轉送規則，將轉送規則的負載平衡配置變更為
EXTERNAL_MANAGED，然後稍待片刻 (約六分鐘)。轉送規則的負載平衡架構變更為EXTERNAL_MANAGED後，您就可以使用全域外部應用程式負載平衡器基礎架構的進階功能。
如需詳細的逐步程序，請參閱「從傳統版應用程式負載平衡器遷移資源」。
下圖顯示傳統版應用程式負載平衡器資源處於不同的遷移狀態。
資源遷移完成後，如果您想將其回溯至傳統應用程式負載平衡器，請在遷移後的 90 天內變更負載平衡器配置。90 天過後，您就無法復原資源。
使用工作階段相依性
遷移具有工作階段親和性的傳統應用程式負載平衡器後端服務時，請考量下列注意事項：
為
TEST_BY_PERCENTAGE設定值可將指定傳統版應用程式負載平衡器的部分流量重新導向至全域外部應用程式負載平衡器。這會中斷用戶端 IP 相依性。變更遷移百分比 (例如增加 10%) 會中斷相同百分比用戶端 IP 位址 (此範例為 10%) 的工作階段相依性，直到下次要求重新建立相依性為止。設定
TEST_BY_PERCENTAGE的值會將沒有工作階段 Cookie 的流量百分比重新導向至全域外部應用程式負載平衡器。它也會將所有含有工作階段 Cookie 的流量重新導向至產生 Cookie 的負載平衡器機隊。如果將
TEST_BY_PERCENTAGE的值設為 0%，或未設定，或是將後端服務設為PREPARE狀態，則會使所有導向全域外部應用程式負載平衡器的現有 Cookie 失效。將後端服務的負載平衡機制變更為
EXTERNAL_MANAGED會使傳統版應用程式負載平衡器機隊產生的所有 Cookie 失效。這樣一來，如果應用程式使用全域外部應用程式負載平衡器時發生問題，您就能回復流量。舉例來說，如果用戶端提供傳統應用程式負載平衡器機隊的 Cookie，但後端服務配置為EXTERNAL_MANAGED，則用戶端的 Cookie 將不會受到支援。全域外部應用程式負載平衡器會忽略 Cookie 並建立新的 Cookie。
復原已遷移的資源
遷移資源後，如果您想將資源從全域外部應用程式負載平衡器基礎架構回溯至傳統應用程式負載平衡器基礎架構，可以在變更負載平衡器配置方案後的 90 天內執行此操作。
將後端服務回溯至 EXTERNAL 配置時，需要回溯轉送規則。將轉送規則回溯至 EXTERNAL 架構時，不需要回溯後端服務。
如要回復資源，請按照下列步驟操作：
- 移除資源上設定的全域外部應用程式負載平衡器的任何新進階流量管理功能。
回溯轉送規則。
將轉送規則的負載平衡配置方案從
EXTERNAL_MANAGED變更為EXTERNAL。回復後端值區。
- 將後端資料集的遷移狀態設為
TEST_ALL_TRAFFIC，然後稍候一段時間 (約六分鐘)。 - 選用：如要減少流量，請將後端區塊的遷移狀態設為
TEST_BY_PERCENTAGE，並設定流量的百分比。 - 將後端值區的遷移狀態設為
PREPARE。 - 將後端桶回復為遷移前的狀態。
- 將後端資料集的遷移狀態設為
復原後端服務。
- 將後端服務的遷移狀態設為
TEST_ALL_TRAFFIC，然後稍候片刻 (約六分鐘)。 - 選用：如要減少流量，請將後端服務的遷移狀態設為
TEST_BY_PERCENTAGE，並設定流量的百分比。 - 將後端服務的遷移狀態設為
PREPARE。 - 將後端服務還原為遷移前的狀態。
- 將後端服務的遷移狀態設為
如需詳細的逐步操作說明，請參閱「將已遷移的資源回溯至傳統應用程式負載平衡器」。
追蹤遷移程序
遷移資源時，您可以查看下列項目，確認負載平衡配置：
全域外部應用程式負載平衡器的記錄和監控資訊主頁。如需更多資訊，請參閱「全域外部應用程式負載平衡器記錄與監控」。
下列 HTTP 要求和回應標頭的值：
X-External-Managed-Migration-Scheme-Override：這個要求標頭會根據其值轉送要求。如果標頭值為EXTERNAL，系統會將要求導向傳統版應用程式負載平衡器基礎架構。如果值為EXTERNAL_MANAGED，則會透過全域外部應用程式負載平衡器基礎架構轉送要求。使用這個標頭將要求導向特定負載平衡器機隊。
X-External-Managed-Migration-Selected-Scheme：這個要求和回應標頭會向後端和用戶端告知用於將要求導向的負載平衡配置。標頭會傳回用戶端，並傳遞至客戶的後端。如果要求是透過傳統版應用程式負載平衡器基礎架構轉送，其值為
EXTERNAL。如果要求是透過全域外部應用程式負載平衡器基礎架構轉送，其值就是EXTERNAL_MANAGED。