主持人 > 博客 > 管理 > OpenShift 虛擬化：容器、KVM 和虛擬機

OpenShift 虛擬化：容器、KVM 和虛擬機

OpenShift 虛擬化（上游專案 - Kubernetes：KubeVirt，請參閱。 這裡 и 這裡），即容器原生虛擬化，作為 OpenShift 平台的功能引入，旨在部署和管理作為基本 Kubernetes 實體的虛擬機器 (VM)。 由於技術上的根本差異，此類任務在技術上具有挑戰性。 為了實現這一目標，我們使用了基於紅帽企業 Linux 和 KVM 的熟悉技術，這些技術已經陪伴我們多年並已證明其有效性。

OpenShift 虛擬化：容器、KVM 和虛擬機

在本文中，我們將研究 OpenShift 虛擬化的技術面，這些技術使虛擬機器和容器能夠在單一平台中共存，並將它們作為單一實體進行管理。

計算任務

容器使用命名空間和cgroup等Linux核心機制來隔離進程和管理資源。 通常進程被理解為Python、Java應用程式或可執行文件，但實際上它們可以是任何進程，例如bash、Emacs或vim。

什麼是虛擬機器？ 從hypervisor的角度來看，這也是一個過程。 但不是應用程式進程，而是負責執行特定VM的KVM進程。

OpenShift 虛擬化：容器、KVM 和虛擬機

容器鏡像包含KVM虛擬機器所需的所有工具、程式庫和檔案。 如果我們檢查正在運行的虛擬機器的 pod，我們將看到那裡的幫助程式和 qemu-kvm 進程。 此外，我們還可以使用用於管理虛擬機器的 KVM 工具，例如 qemu-img、qemu-nbd 和 virsh。

OpenShift 虛擬化：容器、KVM 和虛擬機

由於虛擬機器是 Pod，它會自動繼承 Kubernetes 中 Pod 的所有功能。 VM Pod 與常規 Pod 一樣，受調度程序方案和標準（例如污點、容忍度、親和性和反親和性）的約束。 您還可以獲得高可用性等好處。 然而，有一個重要的區別：常規 Pod 不會以通常的方式從一個主機遷移到另一個主機。 如果某個節點離線，則該節點上的 Pod 將會終止並重新指派給叢集中的另一個節點。 對於虛擬機，我們期望看到即時遷移。

為了解決這個問題，創建了自訂資源定義（CDR）來描述負責初始化、監控和管理工作節點之間虛擬機器即時遷移的即時遷移機制。

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
  name: migration-job
spec:
  vmiName: fedora

停用節點時，會自動為那些將即時遷移設定為驅逐策略的虛擬機器建立遷移任務。 透過這種方式，您可以控制虛擬機器在叢集節點之間移動時的行為。 您可以像所有其他 Pod 一樣設定即時遷移並管理虛擬機器。

Сеть

任何 Kubernetes 系統都使用軟體 SDN 網路提供節點和 Pod 之間的通訊。 OpenShift 也不例外，從版本 3 開始，預設使用 OpenShiftSDN。 此外，OpenShift 4 還有另一個名為 Multus 的新功能，它允許您使多個網路可用並同時將 Pod 連接到它們。

OpenShift 虛擬化：容器、KVM 和虛擬機

使用 Multus，管理員可以定義其他 CNI 網絡，然後由特殊的叢集網路操作員在叢集上部署和配置這些網路。 然後，Pod 連接到一個或多個網絡，通常是標準 OpenShiftSDN 和一個附加介面。 如果您的虛擬機器需要，SR-IOV 設備、標準 Linux 橋接器、MACVLAN 和 IPVLAN 設備都可以使用。 下圖顯示如何在 eth1 介面上為橋接網路設定 Multus CNI：

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: multus1
rawCNIConfig: '{ "cniVersion": "0.3.1", "type": "bridge", "master": "eth1", "ipam":
   { "type": "static", "addresses": [ { "address": "191.168.1.1/24" } ] } }'
   type: Raw

就 OpenShift 虛擬化而言，這意味著虛擬機器可以繞過 SDN 直接連接到外部網路。 這對於從 Red Hat Virtualization 或 VMware vSphere 遷移到 OpenShift 的虛擬機器非常重要，因為如果您有權存取第二個 OSI 層，網路設定將不會發生變化。 這也意味著虛擬機器可能具有繞過 SDN 的網路位址。 因此，我們可以有效地使用專門的網路適配器，或透過網路直接連接到儲存系統......

您可以詳細了解如何建立 OpenShift 虛擬化虛擬機器並將其連接到網絡 這裡。 另外， 奈米態算子作為 OpenShift 虛擬化的一部分部署，提供了另一種熟悉的方式來建立和管理虛擬機器管理程式下使用的實體節點上的網路配置。

存儲

OpenShift 虛擬化中的連接和管理虛擬機器磁碟是使用 Kubernetes 概念（例如 StorageClasses、PersistentVolumeClaims (PVC) 和 PersistentVolume (PV)）以及 Kubernetes 環境的儲存協定標準來執行的。 這為 Kubernetes 管理員和應用程式團隊提供了一種通用、熟悉的方式來管理容器和虛擬機器。 對於許多虛擬化環境的管理員來說，這個概念可能聽起來很熟悉，因為它使用與 OpenStack 和許多其他雲端平台中使用的相同的分離 VM 設定檔和磁碟的原理。

但是，我們不能每次都簡單地為虛擬機器建立一個新磁碟，因為從虛擬機器管理程式遷移到 OpenShift 時，我們需要保存資料。 是的，即使我們部署新的虛擬機，從模板進行部署也總是比從頭開始創建要快。 因此，我們需要匯入現有磁碟的功能。

為了簡化此任務，OpenShift 虛擬化部署了容器化資料導入器 (CDI) 項目，該項目減少了從多個來源匯入磁碟的磁碟映像以建立 PVC 條目的次數。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: "fedora-disk0"
  labels:
    app: containerized-data-importer
  annotations:
    cdi.kubevirt.io/storage.import.endpoint: "http://10.0.0.1/images/Fedora-Cloud-Base-31-1.9.x86_64.qcow2"
spec:
  storageClassName: ocs-gold
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

正是這個條目激活了 CDI，觸發了下圖所示的操作序列：

OpenShift 虛擬化：容器、KVM 和虛擬機

CDI 完成後，PVC 將包含可供使用的虛擬機器磁碟並轉換為標準 OpenShift 格式...
在使用 OpenShift 虛擬化時，OpenShift Container Storage (OCS)（一種基於 Ceph 檔案系統的紅帽解決方案，可為容器實現持久性儲存功能）也很有用。 除了標準 PVC 存取方法 - RWO（區塊）和 RWX（檔案）之外，OCS 還為原始區塊裝置提供 RWX，這對於具有高效能要求的應用程式共用區塊存取非常有用。 此外，OCS支援新的Object Bucket Claim標準，允許應用程式直接使用物件資料儲存。

容器中的虛擬機

如果您有興趣了解其工作原理，請注意 OpenShift 虛擬化已作為 OpenShift 3.11 及更高版本的一部分在技術預覽版中提供。 現有 OpenShift 訂閱的擁有者可以完全免費使用 OpenShift 虛擬化，無需任何額外步驟。 在撰寫本文時，OpenShift 4.4 和 OpenShift 虛擬化 2.3 是最新版本；如果您使用的是先前的版本，則應該升級以獲得最新功能。 完全支援的 OpenShift 虛擬化版本應於 2020 年下半年發布。

取得更多資訊，請聯繫 OpenShift 文檔 安裝說明，包括 多重設定部分，它提供有關設定外部網路的資訊。

來源： www.habr.com

添加評論