當在做虛擬機（VM）遷移時(live migration)，OpenShift 的排程器（Scheduler）如何在Cluster裡，決定目標主機？OpenShift 又如何確保這次遷移能夠成功？
這篇主要是將我這幾天針對在同一個Cluster內使用不同世代的CPU的worker node進行遷移測試，將心得整理出來，討論OpenShift Virtualization如何在不同世代的CPU的Woker node上做出選擇，且確保遷移成功。

先來看OpenShift 虛擬機遷移的決策機制
OpenShift Virtualization 在決定虛擬機的目標主機時，主要依賴 Kubernetes 的排程器機制，並透過一系列的控制器和操作器來豐富其決策邏輯。核心考量點包括：

1. 資源可用性 (Resource Availability)：
   *CPU、記憶體 (CPU, Memory)：*這是最基本的考量。排程器會檢查目標節點是否有足夠的可用 CPU 和記憶體資源來容納待遷移的虛擬機。這包括虛擬機請求的資源量（requests）和限制的資源量（limits）。
   *儲存 (Storage)：*虛擬機通常需要綁定到持久性儲存（Persistent Volume, PV）。在遷移過程中，排程器會確保目標節點可以訪問或重新連接到虛擬機所需的儲存。如果使用共享儲存（如Ceph RBD、NFS等），這通常不是問題；如果使用本地儲存，則可能需要複雜的遷移策略，例如使用容器原生虛擬機資料遷移（Container-Native Virtual Machine Data Migration）或複製功能。
   *網路 (Network)：*目標節點需要具備虛擬機所需的網路介面和連接性。OpenShift 的 SDN 或 CNI 插件會確保遷移後虛擬機的網路能正常運作。

2. 節點親和性與反親和性 (Node Affinity and Anti-Affinity)：
   *節點親和性 (Node Affinity)：*管理員可以透過 Kubernetes 的節點親和性規則，指定虛擬機更傾向於在哪些節點上執行。例如，可以指定只在具有特定標籤的節點上執行。
   *節點反親和性 (Node Anti-Affinity)：*為了高可用性或避免單點故障，可以設定節點反親和性，確保某個虛擬機不會與另一個特定的虛擬機在同一個節點上，或者某組虛擬機不會全部集中在少數節點上。

3. 污點與容忍度 (Taints and Tolerations)：
   節點可以被標記為“污點”（Taints），表示它們不希望被某些 Pod（虛擬機在 OpenShift 中也以 Pod 的形式運行）排程。只有當 Pod 具有對應的“容忍度”（Tolerations）時，才能被排程到這些有污點的節點上。這可以用於將特定工作負載限制在專用節點上。

當然還有更多的考量，如節點資源拓撲 (Node Resource Topology)，虛擬機排程策略 (VM Scheduling Strategies)之類的，但有點離題太遠先不在這邊考慮。

就以CPU來考量的話，OpenShift如何知道每個節點支援的程度呢？
這個跟節點特性發現 (Node Feature Discovery, NFD) Operator功能有關。
NFD Operator 在節點上運行，自動發現並暴露節點的硬體特性（例如 CPU 型號、GPU、特定指令集、PCI 設備等）作為 Kubernetes 節點標籤。這些標籤對於虛擬機的排程決策至關重要，特別是在確保虛擬機遷移到具有兼容硬體特性的節點時。

以CPU型號來舉例，在VM上下 lscpu command來查看目前所辨識的CPU：
lscpu | grep -i model
以我的lab來說，看到的型號為：
AMD EPYC-Milan Processor
這時如果執行live migration， Scheduler 會確認目標節點會有cpu.model.migration.node.kubevirt.io/EPYC-Milan: "true" 的標籤才有可能在考慮的節點之一。

這個標籤的含義：

cpu.model.migration.node.kubevirt.io: 這是一個 KubeVirt（OpenShift Virtualization 的底層技術）使用的常用標籤前綴，用於管理與節點層級 CPU 相關的功能和遷移能力。
EPYC-Milan: 這特指 AMD EPYC Milan 系列處理器。
"true": 這表示與此標籤關聯的功能或能力在應用此標籤的節點上是啟用或受支援的。
如果移除這個標籤，則此節點不會是VM live migration考量的節點。