將使用者叢集遷移至建議功能

總覽

本頁說明如何將 1.30 以上版本的使用者叢集遷移至下列建議功能：

• 遷移至 Dataplane V2 做為容器網路介面 (CNI)。
• 使用 kubeception 將使用者叢集遷移至 Controlplane V2。

• 遷移負載平衡器設定：

  • 從整合式 F5 BIG-IP 負載平衡器設定到 ManualLB

    或

  • 從套裝組合 Seesaw 負載平衡器遷移至 MetalLB。

本頁面適用於負責管理基礎技術架構生命週期的 IT 管理員和作業人員。如要瞭解我們在 Google Cloud 內容中提及的常見角色和範例工作，請參閱「常見 GKE Enterprise 使用者角色和工作」。

最佳做法

建議您先遷移最不重要的環境，例如測試環境。確認遷移作業成功後，請針對每個環境重複執行這項程序，最後再遷移正式環境。這樣一來，您就能驗證每次遷移作業是否成功，並確保工作負載正常運作，再移至下一個更重要的環境。

建議您建立啟用 Controlplane V2 的新使用者叢集，瞭解與 kubeception 叢集的架構差異。新叢集不會影響工作負載。不過，在最糟的情況下，如果遷移失敗，您還是有叢集可供工作負載使用。

如要進一步瞭解遷移規劃，請參閱「規劃叢集遷移至建議功能」。

需求條件

本次遷移作業的相關資訊如下：

• 使用者叢集必須為 1.30 以上版本。
• 所有節點集區都必須與使用者叢集採用相同版本。
• 如果叢集使用 Seesaw 負載平衡器，請確認您並未依賴 Seesaw 保留用戶端 IP，如下一節所述。

保留 Seesaw 用戶端 IP

如要檢查 externalTrafficPolicy，請執行下列指令：

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get svc -A -o yaml | grep "externalTrafficPolicy: Local"

如果遇到這個問題，請與 Google 支援團隊聯絡。

預估時間投入量並規劃維護期間

更新叢集時，系統預設會並行更新所有節點集區。不過，每個節點集區內的節點會依序更新。因此，更新總時間取決於最大節點集區中的節點數量。如要計算每項更新的粗略預估值，請按照下列步驟操作：

• 如果從 Seesaw 遷移至 MetalLB，更新作業大約需要 15 分鐘，才能為 MetalLB 負載平衡器選擇節點集區。本次更新只會更新所選節點集區。
• 如要瞭解遷移程序中的其他更新，請將 15 分鐘乘以節點集區中的節點數。

如要估算時間投入量，請計算需要更新叢集的次數。下列高階步驟說明何時需要執行 gkectl update cluster 來更新叢集：

1. 如果使用者叢集使用永久密碼加密，請停用這項功能並執行 gkectl update cluster。
2. 如果使用者叢集enableDataplaneV2未設定或設為 false，請進行設定變更，然後執行 gkectl update cluster 遷移至 Dataplane V2。

3. 準備遷移負載平衡器和控制層：

   1. 如果管理員叢集已啟用自動修復功能，請停用該功能。然後執行 gkectl update admin。 這項更新不會重新建立管理員叢集節點，因此很快就能完成。
   2. 如果使用者叢集使用 Seesaw，請選擇供 MetalLB 負載平衡器使用的節點集區，然後執行 gkectl update cluster。這項更新只會更新所選節點集區中的節點。

4. 進行所有必要的設定變更，更新負載平衡器並遷移至 Controlplane V2。然後執行 gkectl update cluster。

5. 移轉後，如果您停用了永久密碼加密功能，請重新啟用該功能並執行 gkectl update cluster。

遷移作業的總時間取決於您必須執行 gkectl cluster update 的次數，而這取決於您的設定。舉例來說，假設您要遷移至 Dataplane V2、ControlPlane V2 和 MetalLB。此外，假設最大節點集區中有 10 個節點，而 MetalLB 會使用節點集區中的 3 個節點。如要估算遷移時間，請加上下列項目：

• 遷移至 Dataplane V2 的時間為 150 分鐘，因為 15 分鐘 * 最大集區中的 10 個節點 = 150 分鐘。
• MetalLB 使用的節點集區為 45 分鐘，因為該節點集區有 3 個節點，15 分鐘 * 3 個節點 = 45 分鐘。
• 控制層 V2 和 MetalLB 更新需要 150 分鐘，因為 15 分鐘 * 最大集區中的 10 個節點 = 150 分鐘。

遷移作業總共約需 345 分鐘，也就是 5 小時 45 分鐘。

如有需要，您可以分階段遷移。以先前的範例來說，您可以在一個維護時段內遷移至 Dataplane V2，並在一個或兩個維護時段內完成其餘遷移作業。

規劃遷移期間的停機時間

規劃遷移作業時，請考量下列停機時間：

• 控制層停機：遷移期間會影響 Kubernetes API 伺服器的存取權。如要遷移至 Controlplane V2，kubeception 使用者叢集的控制層會停機，因為系統會遷移 loadBalancer.vips.controlPlaneVIP。停機時間通常不到 10 分鐘，但實際時間取決於您的基礎架構。
• 工作負載停機時間：類型為 LoadBalancer 的服務所用的虛擬 IP (VIP) 無法使用。只有在從 Seesaw 遷移至 MetalLB 時，才會發生這種情況。在 MetalLB 遷移程序中，系統會停止使用者叢集中所有 VIP 的網路連線，Kubernetes 服務類型為 LoadBalancer 的連線會停止約兩到十分鐘。遷移作業完成後，連線就會恢復正常運作。

下表說明遷移作業的影響：

• 受影響：遷移期間服務會明顯中斷。
• 不受影響：服務不會中斷，或中斷時間極短，幾乎不會造成影響。

為遷移作業做好準備

為確保遷移作業順利完成，請按照下列各節的步驟操作。

分配新的 IP 位址

如要遷移至 Controlplane V2，請在與工作站節點 (節點集區中的節點) 相同的 VLAN 中，分配新的靜態 IP 位址。

• 您需要一個 IP 位址才能使用 loadBalancer.vips.controlPlaneVIP。

• 為每個控制層節點分配一個 IP 位址。您需要分配的 IP 位址數量，取決於使用者叢集是否為高可用性 (HA) 或非 HA。

  • 非 HA：一個 IP 位址
  • 高可用性：三個 IP 位址

更新防火牆規則

如果您要遷移至 Controlplane V2，請更新使用者叢集的防火牆規則。請確認使用者叢集控制層節點新分配的 IP 位址，可以連上所有必要 API 和其他目的地，如「使用者叢集節點的防火牆規則」一文所述。

檢查叢集和節點集區版本

確認所有節點集區都使用與使用者叢集相同的版本，且版本必須為 1.30 以上。如果沒有，請先升級節點集區，將使用者叢集設定檔中的 gkeOnPremVersion 升級至目標版本，再繼續進行遷移作業。如要檢查版本，請執行下列指令：

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

請將 ADMIN_CLUSTER_KUBECONFIG 替換為管理員叢集 kubeconfig 檔案的路徑。

檢查叢集健康狀態

檢查叢集健康狀態，並修正 gkectl diagnose cluster 指令回報的任何問題：

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name USER_CLUSTER_NAME

更改下列內容：

• ADMIN_CLUSTER_KUBECONFIG：管理員叢集 kubeconfig 檔案的路徑。
• USER_CLUSTER_NAME：使用者叢集的名稱。

在管理員叢集中停用自動修復功能

如果您要遷移使用者叢集，改用 Controlplane V2，且已在管理員叢集中啟用自動修復功能，請停用自動修復功能。檢查管理員叢集設定檔的 autoRepair.enabled 欄位。如果該欄位未設定或設為 true，請執行下列步驟：

1. 在管理員叢集設定檔中，將 autoRepair.enabled 設為 false。例如：

   autoRepair:
     enabled: false
   

2. 更新管理員叢集：

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config ADMIN_CLUSTER_CONFIG
   

更改下列內容：

• ADMIN_CLUSTER_KUBECONFIG：管理員叢集 kubeconfig 檔案的路徑。
• ADMIN_CLUSTER_CONFIG：管理員叢集設定檔的路徑。

遷移作業完成後，請務必重新啟用管理員叢集中的自動修復功能。

檢查永久密碼加密功能是否有問題

如果您要遷移使用者叢集以使用 Controlplane V2，請檢查是否發生「永遠開啟的密碼加密」問題。

如果使用者叢集曾啟用「永久密碼加密」，您必須先按照「停用永久密碼加密並解密密碼」一文中的步驟操作，才能開始遷移作業。否則，新的 Controlplane V2 叢集就無法解密密鑰。

開始遷移前，請執行下列指令，查看是否曾啟用永久密碼加密功能：

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

如果上述指令的輸出內容為空白，表示您從未啟用永久密碼加密功能。您可以開始遷移。

如果上述指令的輸出內容不為空白，表示先前已啟用永久密碼加密功能。遷移前，請務必完成下一節的步驟，確保新的 Controlplane V2 叢集可以解密密鑰。

以下範例顯示非空白輸出內容：

{"generatedKeyVersions":{"keyVersions":[1]}}

停用永久密碼加密，並視需要解密密碼

如要停用永久密碼加密功能並解密密碼，請按照下列步驟操作：

1. 在使用者叢集設定檔中，如要停用永續加密密鑰，請在 secretsEncryption 區段中新增 disabled: true 欄位：

   secretsEncryption:
       mode: GeneratedKey
       generatedKey:
           keyVersion: KEY_VERSION
           disabled: true
   

2. 更新叢集：

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config USER_CLUSTER_CONFIG
   

   更改下列內容：

   • ADMIN_CLUSTER_KUBECONFIG：管理員叢集 kubeconfig 檔案的路徑
   • USER_CLUSTER_CONFIG：使用者叢集設定檔的路徑

3. 對特定 DaemonSet 執行輪動式更新，方法如下：

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     rollout restart statefulsets kube-apiserver \
     -n USER_CLUSTER_NAME

4. 以 YAML 格式取得使用者叢集中所有密鑰的資訊清單：

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
     get secrets -A -o yaml > SECRETS_MANIFEST.yaml

5. 為確保所有 Secret 都以純文字形式儲存在 etcd 中，請在使用者叢集中重新套用所有 Secret：

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
     apply -f SECRETS_MANIFEST.yaml

   您現在可以開始遷移至 Controlplane V2。遷移作業完成後，您可以在叢集上重新啟用永久密碼加密。

檢查工作負載 Webhook 設定錯誤的問題

如果將使用者叢集遷移至 Controlplane V2，請檢查工作負載 Webhook 設定錯誤的問題。

如果 Webhook 包含 kube-system 命名空間中的系統 Pod，請新增 namespaceSelector，篩除 kube-system 命名空間。

例如：

  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system

啟用節點集區，供 MetalLB 使用

如要從套裝組合的 Seesaw 負載平衡器遷移至 MetalLB，請按照本節步驟操作。如果使用者叢集設定檔中含有 loadBalancer.kind: Seesaw，叢集就會使用 Seesaw。如要遷移整合的 F5 BIG-IP 設定，請跳至下一節「遷移至 Dataplane V2」。

選擇節點集區，並啟用 MetalLB 服務。遷移作業會在該節點集區的節點上部署 MetalLB。

1. 在使用者叢集設定檔的 nodePools 區段中，選擇節點集區或新增節點集區，然後將 enableLoadBalancer 設為 true。例如：

   nodePools:
     - name: pool-1
       replicas: 3
       enableLoadBalancer: true
   

2. 更新叢集：

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config USER_CLUSTER_CONFIG
   

如要進一步瞭解 MetalLB，請參閱「使用 MetalLB 進行套裝組合負載平衡」。

遷移至 Dataplane V2

遷移前，請先執行下列指令，檢查叢集是否已啟用 DataPlane V2：

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -o yaml | grep enableDataplaneV2

如果已啟用 Dataplane V2，請跳至下一節「準備遷移負載平衡器」。

如要遷移至 Dataplane V2，可以選擇下列做法：

• 將叢集升級至 1.31 版。如需詳細步驟，請參閱「啟用 Dataplane V2」。

• 更新 1.30 叢集。

在這兩種情況下，您都需要暫時移除 NetworkPolicy 規格，如後續步驟所述。

如要遷移至 Dataplane V2，請按照下列步驟操作。如果您對暫時移除「NetworkPolicy」規格有疑慮，請與 Google 支援團隊聯絡。

如果叢集使用 NetworkPolicy，請暫時從叢集中移除其規格，方法如下：

1. 檢查叢集是否套用任何非系統 NetworkPolicy：

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy -A -o wide | grep -v kube-system
   

2. 如果上一個步驟的輸出內容不為空白，請將每個NetworkPolicy規格儲存至檔案，以便在更新叢集後重新套用規格。

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
   

   更改下列內容：

   • NETWORK_POLICY_NAME：您要儲存的 NetworkPolicy 名稱。
   • NETWORK_POLICY_NAMESPACE：NetworkPolicy 的命名空間。

3. 使用下列指令刪除 NetworkPolicy：

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE
   

如要遷移至 Dataplane V2，請按照下列步驟操作：

1. 在使用者叢集設定檔中，將 enableDataplaneV2 設為 true。

2. 如要啟用 DataPlane V2，請更新叢集：

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
   --config USER_CLUSTER_CONFIG
   

3. 如果您在先前的步驟中移除了任何非系統 NetworkPolicy 規格，請在更新完成後，使用下列指令重新套用：

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
   

完成這些步驟後，Dataplane V2 就會啟用。接著，準備將叢集遷移至建議的負載平衡器和 Controlplane V2。

準備遷移負載平衡器

如果使用者叢集使用 Seesaw 負載平衡器或整合式 F5 BIG-IP，請按照本節中的步驟，變更必要的使用者叢集設定檔。否則請跳至下一節「準備遷移至 Controlplane V2」。

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.5
  ingressVIP: 198.51.100.20
kind: "f5BigIP" "ManualLB"
f5BigIP:
  address: "203.0.113.2"
  credentials:
  fileRef:
    path: "my-config-folder/user-creds.yaml"
    entry: "f5-creds"
  partition: "my-f5-user-partition"

addresses:
  -   "192.0.2.0/26"
  -   "192.0.2.64-192.0.2.72"
  -   "192.0.2.75/32"

loadBalancer:
  vips:
    controlPlaneVIP: "198.51.100.50"
    ingressVIP: "198.51.100.10"
  kind: "MetalLB" "Seesaw"
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
      - name: "address-pool-1"
        addresses:
        - "198.51.100.10/32"
        - "198.51.100.80 - 198.51.100.89"

為遷移至 Controlplane V2 做好準備

如果叢集未啟用 Controlplane V2：

• 更新使用者叢集設定檔。
• 如果叢集使用手動負載平衡 (loadBalancer.kind: "ManualLB")，請一併更新負載平衡器的設定。

以下各節將說明這些步驟。

如果叢集已啟用 Controlplane V2，請跳至「遷移使用者叢集」一節。

更新使用者叢集設定檔

對現有的使用者叢集設定檔進行下列變更：

1. 將 enableControlplaneV2 設為 true。
2. 您也可以選擇讓 Controlplane V2 使用者叢集的控制層具備高可用性 (HA)。如要從非 HA 叢集變更為 HA 叢集，請將 masterNode.replicas 從 1 變更為 3。
3. 將使用者叢集控制層節點的靜態 IP 位址新增至 network.controlPlaneIPBlock.ips 區段。控制層節點的 IP 位址必須與工作站節點位於相同的 VLAN。必須提供主機名稱。
4. 在「network.controlPlaneIPBlock」部分填入 netmask 和 gateway。
5. 如果「network.hostConfig」部分為空白，請填寫相關資訊。
6. 確認「loadBalancer.vips.controlPlaneVIP」欄位是否包含控制層 VIP 的新 IP 位址。IP 位址必須與控制層節點 IP 位於相同的 VLAN。
7. 如果使用者叢集使用手動負載平衡，請將 loadBalancer.manualLB.controlPlaneNodePort 和 loadBalancer.manualLB.konnectivityServerNodePort 設為 0。啟用 Controlplane V2 時，這些欄位並非必要，但值必須為 0。
8. 如果使用者叢集使用手動負載平衡，請按照下一節所述設定負載平衡器。

視需要調整負載平衡器中的對應

如果使用者叢集已使用手動負載平衡，您需要在負載平衡器上設定一些對應。如果您要從整合式 F5 BIG-IP 設定遷移至手動負載平衡，則無須在負載平衡器上進行任何設定變更，可以直接跳至下一節「遷移使用者叢集」。

針對您在 network.controlPlaneIPBlock 區段中指定的每個 IP 位址，在控制層節點的負載平衡器中設定下列對應：

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPSNodePort)

使用者叢集中的所有節點 (包括控制層節點和工作站節點) 都需要這些對應項目。由於 NodePort 是在叢集上設定，Kubernetes 會在所有叢集節點上開啟 NodePort，因此叢集中的任何節點都能處理資料層流量。

設定對應後，負載平衡器會在標準 HTTP 和 HTTPS 連接埠上，監聽您為使用者叢集 Ingress VIP 設定的 IP 位址流量。負載平衡器會將要求轉送至叢集中的任何節點。要求轉送至其中一個叢集節點後，內部 Kubernetes 網路會將要求轉送至目的地 Pod。

遷移使用者叢集

首先，請仔細檢查您對使用者叢集設定檔所做的變更。除了更新叢集以進行遷移作業外，所有負載平衡器和 Controlplane V2 設定都無法變更。

如要更新叢集，請執行下列指令：

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Controlplane V2 遷移

在 Controlplane V2 遷移期間，更新作業會執行下列動作：

1. 建立啟用 ControlPlane V2 的新叢集控制層。
2. 停止 kubeception 叢集的 Kubernetes 控制層。
3. 擷取 kubeception 叢集的 etcd 快照。
4. 關閉 kubeception 叢集的使用者叢集控制層節點。在遷移作業完成前，節點不會遭到刪除，因為這樣一來，系統就能還原至該 kubeception 叢集，以利從失敗中復原。
5. 使用先前步驟中建立的 etcd 快照，在新控制平面中還原叢集資料。
6. 將 kubeception 叢集的節點集區節點連線至新的控制層，可透過新的 controlPlaneVIP 存取。
7. 調解還原的使用者叢集，以符合啟用 ControlPlane V2 的叢集最終狀態。

注意事項：

• 遷移期間，使用者叢集工作負載不會停機。
• 遷移期間，使用者叢集控制層會停機一段時間。具體來說，從停止 kubeception 叢集的 Kubernetes 控制層，到完成將 kubeception 叢集的節點集區節點連線至新的控制層，這段期間控制層將無法使用。(在測試中，這段停機時間不到 7 分鐘，但實際長度取決於您的基礎架構)。
• 遷移作業完成後，系統會刪除 kubeception 叢集的使用者叢集控制層節點。如果管理員叢集的 network.ipMode.type 設為 "static"，您可以回收部分未使用的靜態 IP 位址。您可以使用 kubectl get nodes -o wide 列出管理員叢集節點物件，查看目前使用的 IP 位址。 如要回收這些 IP 位址，請從管理員叢集設定檔中移除這些位址，然後執行 gkectl update admin。

遷移後

更新完成後，請執行下列步驟：

1. 確認使用者叢集正在執行：

   kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG
   

   輸出結果會與下列內容相似：

   cp-vm-1       Ready    control-plane,master   18m
   cp-vm-2       Ready    control-plane,master   18m
   cp-vm-3       Ready    control-plane,master   18m
   worker-vm-1   Ready                           6m7s
   worker-vm-2   Ready                           6m6s
   worker-vm-3   Ready                           6m14s
   

2. 如果您已遷移至 Controlplane V2，請更新管理員叢集的防火牆規則，移除 kubeception 使用者叢集的控制層節點。

3. 如果停用了永久密碼加密功能，請重新啟用。

   1. 在使用者叢集設定檔中，移除 disabled: true 欄位。

   2. 更新使用者叢集：

      gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          --config USER_CLUSTER_CONFIG
      

4. 如果您在管理員叢集中停用了自動修復功能，請重新啟用該功能。

   1. 在管理員叢集設定檔中，將 autoRepair.enabled 設為 true。

   2. 更新叢集：

      gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          --config ADMIN_CLUSTER_CONFIG
      

負載平衡器遷移

如果您已遷移負載平衡器，請確認負載平衡器元件是否順利運作。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods \
    --namespace kube-system --selector app=metallb

metallb-controller-744884bf7b-rznr9   1/1     Running
metallb-speaker-6n8ws                 1/1     Running
metallb-speaker-nb52z                 1/1     Running
metallb-speaker-rq4pp                 1/1     Running

kubectl --kubeconfig CLUSTER_KUBECONFIG \
api-resources --verbs=list -o name | xargs -n 1 kubectl --kubeconfig
CLUSTER_KUBECONFIG get --show-kind --ignore-not-found
--selector=onprem.cluster.gke.io/legacy-f5-resource=true -A

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-sspwrd   Opaque   4      14h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         14h
kube-system   serviceaccount/load-balancer-f5   0         14h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           14h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           14h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         14h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   14h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T05:16:40Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T05:16:41Z