Wirtualizacja OpenShift (projekt upstream – Kubernetes: KubeVirt, zob. i ), wcześniej znana jako Virtualizacja natywna dla kontenerów, została zaprezentowana jako funkcjonalność platformy OpenShift, która ma na celu wdrażanie i zarządzanie maszynami wirtualnymi (VM) jako podstawowymi jednostkami Kubernetes. Zadanie to jest technicznie skomplikowane ze względu na fundamentalne różnice w technologiach. Aby osiągnąć ten cel, wykorzystano dobrze znane technologie oparte na Red Hat Enterprise Linux i KVM, które są z nami od lat i udowodniły swoją skuteczność.
W tym artykule omówimy techniczne aspekty wirtualizacji OpenShift, które umożliwiają współistnienie maszyn wirtualnych i kontenerów w ramach jednej platformy, która zarządza nimi jako jednością.
Zadania obliczeniowe
Kontenery wykorzystują mechanizmy jądra Linux, takie jak namespaces i cgroups, do izolacji procesów i zarządzania zasobami. Zwykle pod pojęciem procesów rozumiane są aplikacje Python, Java lub pliki wykonywalne, ale w rzeczywistości mogą to być jakiekolwiek procesy, ten sam bash, Emacs czy vim.
A co to jest maszyna wirtualna? Z perspektywy hipernadzorcy – to też proces. Ale nie proces aplikacji, a proces KVM odpowiedzialny za wykonanie konkretnej maszyny wirtualnej.
Obraz kontenera zawiera wszystkie narzędzia, biblioteki i pliki niezbędne do maszyny wirtualnej KVM. Jeśli zbadać pod działającej maszyny wirtualnej, zobaczymy tam pomocników i procesy qemu-kvm. Ponadto mamy dostęp do narzędzi KVM do zarządzania maszynami wirtualnymi, takich jak qemu-img, qemu-nbd i virsh.
Ponieważ maszyna wirtualna to pod, automatycznie dziedziczy wszystkie funkcjonalności poda w Kubernetes. Do VM-podów stosuje się te same schematy i kryteria planista, takie jak taints, tolerations, affinity i anti-affinity. Otrzymujesz także korzyści w postaci wysokiej dostępności itd. Istnieje jednak jedna ważna różnica: zwykłe pody nie migrują między hostami w znanym nam sensie. Jeśli węzeł zostanie wyłączony, pod na nim zostaje przerwany i przekształcony na inny węzeł w klastrze. A w przypadku maszyny wirtualnej oczekujemy zobaczyć migrację na żywo.
Aby rozwiązać ten problem, stworzono definicję zasobów niestandardowych (CDR), która opisuje mechanizm migracji na żywo, odpowiedzialny za inicjację, 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
Podczas dezaktywacji węzła dla tych maszyn wirtualnych, które mają ustawioną strategię ewakuacji Live Migration, automatycznie tworzone są zadania migracji. Dzięki temu można kontrolować zachowanie maszyn wirtualnych podczas przemieszczania ich między węzłami klastra. Możesz zarówno skonfigurować Live Migration, jak i zarządzać VM, jak i wszystkimi innymi podami.
Sieć
Każdy system Kubernetes zapewnia łączność między węzłami a podami za pomocą programowych sieci SDN. OpenShift nie jest wyjątkiem i od wersji 3 domyślnie wykorzystuje do tego OpenShiftSDN. W OpenShift 4 wprowadzono także nową funkcję o nazwie Multus, która pozwala na udostępnienie wielu sieci i jednoczesne podłączanie do nich podów.
Dzięki Multus administrator może określić dodatkowe sieci CNI, które następnie będą wdrażane i konfigurowane w klastrze przez specjalnego operatora Cluster Network Operator. Następnie pod’y są podłączane do jednej lub wielu z tych sieci, zazwyczaj do standardowego OpenShiftSDN oraz dodatkowego interfejsu. Urządzenia SR-IOV, standardowe mostki Linux, urządzenia MACVLAN i IPVLAN – wszystko to również można wykorzystać, jeśli jest to potrzebne Twojej VM. Na poniższym rysunku pokazano, jak ustawić Multus CNI dla mostu sieciowego 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 VM można podłączyć do zewnętrznej sieci bezpośrednio, omijając SDN. Jest to ważne dla maszyn wirtualnych przeniesionych do OpenShift z Red Hat Virtualization lub VMware vSphere, ponieważ przy dostępie na drugim poziomie OSI nie będzie zmiany ustawień sieciowych. Oznacza to również, że VM może mieć adres sieciowy, do którego dostęp omija SDN. Dzięki temu możemy efektywnie korzystać ze specjalistycznych adapterów sieciowych lub podłączać się bezpośrednio do macierzy dyskowej...
Aby dowiedzieć się więcej o tym, jak tworzyć i podłączać maszyny wirtualne OpenShift virtualization do sieci, możesz . Ponadto, , wdrażany w składzie OpenShift virtualization, oferuje jeszcze jeden dobrze znany sposób na tworzenie i zarządzanie konfiguracjami sieciowymi na fizycznych węzłach, które są wykorzystywane pod hypervisorami.
Przechowywanie
Podłączenie i zarządzanie dyskami maszyn wirtualnych w ramach wirtualizacji OpenShift odbywa się z wykorzystaniem koncepcji Kubernetes, takich jak StorageClasses, PersistentVolumeClaims (PVC) oraz PersistentVolume (PV), a także standardowych protokołów przechowywania danych dla środowiska Kubernetes. Dzięki temu administratorzy Kubernetes oraz zespoły odpowiedzialne za aplikacje otrzymują jednolity i znany mechanizm zarządzania zarówno dla kontenerów, jak i maszyn wirtualnych. Dla wielu administratorów środowisk wirtualizacyjnych ta koncepcja może być znajoma, ponieważ stosuje ten sam zasadę separacji plików konfiguracyjnych VM i dysków, którą wykorzystuje OpenStack oraz wiele innych platform chmurowych.
Jednak nie można za każdym razem tworzyć nowego dysku dla VM, ponieważ podczas migracji z hypervisora do OpenShift, musimy zachować dane. Nawet gdy uruchamiamy nową VM, zawsze szybciej jest to zrobić z szablonu, niż stworzyć od podstaw. Dlatego potrzebujemy funkcjonalności importu istniejących dysków.
Aby uprościć to zadanie, wirtualizacja OpenShift uruchamia projekt Containerized Data Importer (CDI), który redukuje import obrazów dysków z kilku źródeł do tworzenia wpisu w 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ń przedstawioną na poniższym rysunku:
Po zakończeniu działania CDI, PVC będzie zawierać dysk maszyny wirtualnej gotowy do użycia i przekształcony do standardowego formatu OpenShift…
Pracując z wirtualizacją OpenShift, przyda się również OpenShift Container Storage (OCS), rozwiązanie Red Hat oparte na systemie plików Ceph, realizujące funkcjonalność stałego magazynu dla kontenerów. Oprócz standardowych metod dostępu PVC – RWO (blokowy) i RWX (plikiowy) – OCS zapewnia RWX dla urządzeń raw block, co jest bardzo przydatne przy organizacji współdzielonego dostępu blokowego dla aplikacji o wysokich wymaganiach wydajnościowych. Ponadto OCS wspiera nowy standard żądania grupy obiektów Object Bucket Claim, umożliwiający aplikacjom bezpośrednie korzystanie z obiektowego magazynu danych.
Maszyny wirtualne w kontenerach
Jeśli chcesz sprawdzić, jak to działa, wiedz, że wirtualizacja OpenShift jest już dostępna w wersji Tech Preview w ramach OpenShift 3.11 i nowszych. Właściciele aktywnej subskrypcji OpenShift mogą korzystać z wirtualizacji OpenShift całkowicie za darmo, bez żadnych dodatkowych formalności. W momencie publikacji tego posta aktualne są wersje OpenShift 4.4 oraz OpenShift virtualization 2.3; jeśli korzystasz z wcześniejszych wersji, warto zaktualizować, aby uzyskać najnowsze funkcje. W pełni wspierana wersja wirtualizacji OpenShift ma zostać wydana w drugiej połowie 2020 roku.
Aby uzyskać więcej informacji, skontaktuj się z w celu uzyskania instrukcji instalacji, w tym , która zawiera informacje na temat konfiguracji zewnętrznych sieci.
Źródło: habr.com
