Wirtualizacja OpenShift (projekt upstream – Kubernetes: KubeVirt, zob. и ), z domu Container-native Virtualization, została wprowadzona jako funkcjonalność platformy OpenShift, która przeznaczona jest do wdrażania i zarządzania maszynami wirtualnymi (VM) jako podstawowymi jednostkami Kubernetes. Tego rodzaju zadanie jest trudne technicznie ze względu na zasadnicze różnice technologiczne. Aby osiągnąć ten cel wykorzystaliśmy znane technologie oparte na Red Hat Enterprise Linux i KVM, które są z nami od wielu lat i udowodniły swoją skuteczność.
W tym artykule przyjrzymy się technicznym aspektom wirtualizacji OpenShift, które umożliwiają współistnienie maszyn wirtualnych i kontenerów w ramach jednej platformy, która zarządza nimi jako pojedynczą jednostką.
Zadania obliczeniowe
Kontenery wykorzystują mechanizmy jądra Linuksa, takie jak przestrzenie nazw i grupy c, do izolowania procesów i zarządzania zasobami. Zwykle przez procesy rozumie się aplikacje Python, Java lub pliki wykonywalne, ale w rzeczywistości mogą to być dowolne procesy, takie jak bash, Emacs czy vim.
Co to jest maszyna wirtualna? Z punktu widzenia hypervisora jest to również proces. Ale nie proces aplikacji, ale proces KVM odpowiedzialny za wykonanie konkretnej maszyny wirtualnej.
Obraz kontenera zawiera wszystkie narzędzia, biblioteki i pliki potrzebne maszynie wirtualnej KVM. Jeśli sprawdzimy pod działającej maszyny wirtualnej, zobaczymy tam pomocników i procesy qemu-kvm. Dodatkowo mamy dostęp do narzędzi KVM do zarządzania maszynami wirtualnymi takich jak qemu-img, qemu-nbd i virsh.
Ponieważ maszyna wirtualna jest podem, automatycznie dziedziczy całą funkcjonalność poda w Kubernetes. Pody maszyn wirtualnych, podobnie jak zwykłe pody, podlegają schematom i kryteriom harmonogramu, takim jak skażenia, tolerancje, powinowactwo i antypowinowactwo. Otrzymujesz także korzyści w postaci wysokiej dostępności itp. Jest jednak jedna istotna różnica: zwykłe pody nie migrują z hosta na host w zwykłym tego słowa znaczeniu. Jeśli węzeł przejdzie w tryb offline, znajdujący się na nim pod zostanie zakończony i ponownie przypisany do innego węzła w klastrze. W przypadku maszyny wirtualnej spodziewamy się migracji na żywo.
Aby wypełnić tę lukę, utworzono niestandardową definicję zasobów (CDR) opisującą mechanizm migracji na żywo, który jest odpowiedzialny za inicjowanie, monitorowanie i zarządzanie migracjami na żywo maszyn wirtualnych między węzłami roboczymi.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Kiedy węzeł jest dezaktywowany, zadania migracji są tworzone automatycznie dla tych maszyn wirtualnych, dla których jako strategię eksmisji ustawiono opcję Live Migration. W ten sposób możesz kontrolować zachowanie maszyn wirtualnych podczas przemieszczania się pomiędzy węzłami klastra. Możesz zarówno skonfigurować migrację na żywo, jak i zarządzać maszyną wirtualną, tak jak wszystkimi innymi podami.
Sieć
Dowolny system Kubernetes zapewnia komunikację pomiędzy węzłami i podami za pomocą programowych sieci SDN. OpenShift nie jest wyjątkiem i począwszy od wersji 3 domyślnie używa do tego OpenShiftSDN. Ponadto OpenShift 4 ma kolejną nową funkcję o nazwie Multus, która pozwala udostępnić wiele sieci i połączyć się z nimi jednocześnie.
Za pomocą Multus administrator może zdefiniować dodatkowe sieci CNI, które następnie zostaną wdrożone i skonfigurowane w klastrze przez specjalnego Operatora Sieci Klastrowej. Pody są następnie podłączane do jednej lub więcej takich sieci, zwykle do standardowego OpenShiftSDN i dodatkowego interfejsu. Jeśli Twoja maszyna wirtualna tego potrzebuje, można używać urządzeń SR-IOV, standardowych urządzeń Linux Bridge, MACVLAN i IPVLAN. Poniższy rysunek pokazuje jak ustawić Multus CNI dla sieci mostkowej na interfejsie eth1:
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
W odniesieniu do wirtualizacji OpenShift oznacza to, że maszynę wirtualną można podłączyć bezpośrednio do sieci zewnętrznej, z pominięciem SDN. Jest to ważne w przypadku maszyn wirtualnych migrowanych do OpenShift z Red Hat Virtualization lub VMware vSphere, ponieważ jeśli masz dostęp do drugiej warstwy OSI, nie nastąpi żadna zmiana w ustawieniach sieciowych. Oznacza to również, że maszyna wirtualna może mieć adres sieciowy omijający SDN. Dzięki temu możemy efektywnie wykorzystywać specjalizowane karty sieciowe, bądź łączyć się bezpośrednio z systemem pamięci masowej poprzez sieć...
Możesz dowiedzieć się więcej o tym, jak tworzyć i łączyć maszyny wirtualne wirtualizacji OpenShift z siecią . Ponadto , wdrożony jako część wirtualizacji OpenShift, oferuje kolejny znany sposób tworzenia konfiguracji sieciowych i zarządzania nimi w węzłach fizycznych używanych w ramach hiperwizorów.
magazynowanie
Podłączanie i zarządzanie dyskami maszyn wirtualnych w ramach wirtualizacji OpenShift odbywa się z wykorzystaniem koncepcji Kubernetes, takich jak StorageClasses, PersistentVolumeClaims (PVC) i PersistentVolume (PV), a także standardowych protokołów przechowywania dla środowiska Kubernetes. Dzięki temu administratorzy Kubernetes i zespoły aplikacji mają wspólny, znajomy sposób zarządzania zarówno kontenerami, jak i maszynami wirtualnymi. Dla wielu administratorów środowisk wirtualizacyjnych koncepcja ta może wydawać się znajoma, ponieważ wykorzystuje tę samą zasadę oddzielania plików konfiguracyjnych i dysków maszyn wirtualnych, która jest używana w OpenStack i wielu innych platformach chmurowych.
Nie możemy jednak po prostu utworzyć za każdym razem nowego dysku dla maszyny wirtualnej, ponieważ podczas migracji z hypervisora do OpenShift musimy zapisać dane. Tak, nawet jeśli wdrażamy nową maszynę wirtualną, zawsze szybciej jest to zrobić z szablonu, niż tworzyć ją od zera. Dlatego potrzebujemy funkcjonalności do importowania istniejących dysków.
Aby uprościć to zadanie, wirtualizacja OpenShift wdraża projekt Containerized Data Importer (CDI), który ogranicza importowanie obrazów dysków z wielu źródeł do tworzenia wpisu 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
To właśnie ten wpis aktywuje CDI, uruchamiając sekwencję działań pokazaną na poniższym rysunku:
Po zakończeniu CDI, PVC będzie zawierał dysk maszyny wirtualnej gotowy do użycia i przekonwertowany do standardowego formatu OpenShift...
Podczas pracy z wirtualizacją OpenShift przydatne jest również OpenShift Container Storage (OCS), rozwiązanie firmy Red Hat oparte na systemie plików Ceph, które implementuje funkcjonalność trwałego przechowywania kontenerów. Oprócz standardowych metod dostępu PVC - RWO (blok) i RWX (plik) - OCS zapewnia RWX dla surowych urządzeń blokowych, co jest bardzo przydatne do współdzielenia dostępu blokowego dla aplikacji o wysokich wymaganiach wydajnościowych. Ponadto OCS obsługuje nowy standard Object Bucket Claim, który umożliwia aplikacjom bezpośrednie korzystanie z obiektowej pamięci masowej.
Maszyny wirtualne w kontenerach
Jeśli jesteś zainteresowany sprawdzeniem jak to działa, to wiedz, że wirtualizacja OpenShift jest już dostępna w wersji Tech Preview w ramach OpenShift 3.11 i wyższych. Właściciele istniejącej subskrypcji OpenShift mogą korzystać z wirtualizacji OpenShift całkowicie bezpłatnie i bez wykonywania dodatkowych czynności. W momencie pisania tego postu, OpenShift 4.4 i wirtualizacja OpenShift 2.3 są aktualne; jeśli używasz poprzednich wersji, powinieneś dokonać aktualizacji, aby uzyskać najnowsze funkcje. W pełni obsługiwana wersja wirtualizacji OpenShift powinna zostać udostępniona w drugiej połowie 2020 roku.
Aby uzyskać więcej informacji prosimy o kontakt instrukcje instalacji, w tym , który zawiera informacje na temat konfigurowania sieci zewnętrznych.
Źródło: www.habr.com