Wirtualizacja OpenShift (projekt nadrzędny - Kubernetes: KubeVirt, patrz. и ), в девичестве Container-native Virtualization, был представлен, как функционал платформы OpenShift, который предназначен для развертывания и управления виртуальными машинами (ВМ), как базовыми сущностями Kubernetes. Такого рода задача является технически сложной, по причине фундаментальных различий технологий. Для того, чтобы добиться поставленной цели, были использованы всем знакомые технологии на базе Red Hat Enterprise Linux и KVM, которые с нами не один год и доказали свою эффективность.
W tym artykule przyjrzymy się technicznym aspektom wirtualizacji OpenShift, które umożliwiają maszynom wirtualnym i kontenerom współistnienie w ramach jednej platformy, która zarządza nimi jak pojedynczym bytem.
Zadania obliczeniowe
Контейнеры задействуют механизмы Linux-ядра, такие как namespaces и cgroups, для изоляции процессов и управления ресурсами. Обычно под процессами понимаются приложения Python, Java или исполняемые файлы, но на самом деле это могут быть любые процессы, тот же bash, Emacs или vim.
Czym jest maszyna wirtualna? Z punktu widzenia hypervisora jest to również proces. Ale nie proces aplikacji, ale proces KVM odpowiedzialny za uruchomienie określonej maszyny wirtualnej.
Obraz kontenera zawiera wszystkie narzędzia, biblioteki i pliki potrzebne dla maszyny wirtualnej KVM. Jeśli sprawdzimy zasobnik uruchomionej 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 jest podem, automatycznie dziedziczy wszystkie funkcje podu w Kubernetes. Pody maszyn wirtualnych podlegają tym samym schematom harmonogramowania i kryteriom, co zwykłe pody, takim jak skażenia, tolerancje, powinowactwo i antypowinowactwo. Otrzymujesz również korzyści wysokiej dostępności itp. Istnieje jednak jedna ważna różnica: zwykłe pody nie migrują z hosta na hosta w zwykłym sensie. Jeśli węzeł ulegnie awarii, pod na nim zostanie zakończony i ponownie przypisany do innego węzła w klastrze. W przypadku maszyny wirtualnej spodziewamy się migracji na żywo.
Aby zaradzić tej luce, stworzono niestandardową definicję zasobów (CDR) opisującą mechanizm migracji na żywo, który odpowiada za inicjowanie, monitorowanie i zarządzanie migracjami na żywo maszyn wirtualnych pomiędzy węzłami roboczymi.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Gdy węzeł jest dezaktywowany, zadania migracji są automatycznie tworzone dla tych maszyn wirtualnych, które mają Live Migration ustawione jako strategię eksmisji. W ten sposób możesz kontrolować zachowanie maszyn wirtualnych podczas przemieszczania się między węzłami klastra. Możesz zarówno skonfigurować Live Migration, jak i zarządzać maszynami wirtualnymi, tak jak wszystkimi innymi podami.
Sieć
Każdy system Kubernetes zapewnia komunikację między węzłami i podami za pomocą sieci SDN oprogramowania. OpenShift nie jest wyjątkiem i od wersji 3 domyślnie używa do tego celu OpenShiftSDN. Ponadto OpenShift 4 ma inną nową funkcję o nazwie Multus, która umożliwia udostępnianie wielu sieci i jednoczesne podłączanie do nich podów.
С помощью Multus администратор может задать дополнительные сети CNI, которые потом будут развертываются и настраиваются на кластере специальным оператором Cluster Network Operator. После чего pod’ы подключаются к одной или нескольким из этих сетей, обычно к стандартному OpenShiftSDN и дополнительному интерфейсу. Устройства SR-IOV, стандартные Linux Bridge, устройства MACVLAN и IPVLAN – все это тоже можно использовать, если это нужно вашей ВМ. На рисунке ниже показано, как задать Multus CNI для bridge сети на интерфейсе 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 kontekście wirtualizacji OpenShift oznacza to, że maszynę wirtualną można podłączyć bezpośrednio do sieci zewnętrznej, omijając SDN. Jest to ważne w przypadku maszyn wirtualnych migrowanych do OpenShift z Red Hat Virtualization lub VMware vSphere, ponieważ jeśli istnieje dostęp do drugiej warstwy OSI, nie będzie żadnych zmian w ustawieniach sieciowych. Oznacza to również, że maszyna wirtualna może mieć adres sieciowy, który omija SDN. W ten sposób możemy skutecznie używać wyspecjalizowanych kart sieciowych lub łączyć się bezpośrednio z systemem pamięci masowej przez sieć…
Możesz dowiedzieć się więcej o tym, jak tworzyć i podłączać wirtualne maszyny wirtualizacji OpenShift do sieci . Ponadto , wdrożony jako część wirtualizacji OpenShift, oferuje inny znany sposób tworzenia i zarządzania konfiguracjami sieciowymi na węzłach fizycznych, które działają pod kontrolą hiperwizorów.
magazynowanie
Dołączanie i zarządzanie dyskami maszyn wirtualnych w wirtualizacji OpenShift odbywa się przy użyciu koncepcji Kubernetes, takich jak StorageClasses, PersistentVolumeClaims (PVC) i PersistentVolume (PV), a także standardowych protokołów pamięci masowej Kubernetes. Zapewnia to administratorom Kubernetes i zespołom aplikacji pojedynczy, znany mechanizm zarządzania zarówno kontenerami, jak i maszynami wirtualnymi. A dla wielu administratorów wirtualizacji ta koncepcja może wydawać się znajoma, ponieważ wykorzystuje tę samą zasadę oddzielania plików konfiguracji maszyn wirtualnych i dysków, która jest stosowana w OpenStack i wielu innych platformach chmurowych.
Jednak nie możemy po prostu utworzyć nowego dysku dla maszyny wirtualnej za każdym razem, ponieważ podczas migracji z hiperwizora do OpenShift musimy zachować dane. A nawet gdy wdrażamy nową maszynę wirtualną, zawsze szybciej jest zrobić to z szablonu niż tworzyć ją od podstaw. Dlatego potrzebujemy funkcjonalności importowania istniejących dysków.
Aby uprościć to zadanie, wirtualizacja OpenShift wdraża projekt Containerized Data Importer (CDI), który redukuje proces importowania obrazów dysków z wielu źródeł do utworzenia 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
Ten wpis aktywuje CDI, rozpoczynając sekwencję działań pokazaną na poniższym rysunku:
Po zakończeniu CDI dysk PVC będzie zawierał dysk maszyny wirtualnej gotowy do użycia i sformatowany zgodnie ze standardowym formatem OpenShift…
Pracując z wirtualizacją OpenShift, przydatne okaże się również rozwiązanie OpenShift Container Storage (OCS), rozwiązanie Red Hat oparte na systemie plików Ceph, które implementuje trwałą funkcjonalność pamięci masowej dla 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 organizowania współdzielonego dostępu do bloków dla aplikacji o wysokich wymaganiach wydajnościowych. Ponadto OCS obsługuje nowy standard Object Bucket Claim, który pozwala aplikacjom na bezpośrednie korzystanie z pamięci masowej danych obiektowych.
Maszyny wirtualne w kontenerach
Jeśli chcesz sprawdzić, jak to działa, wirtualizacja OpenShift jest już dostępna w wersji Tech Preview jako część OpenShift 3.11 i nowszych. Posiadacze aktywnej subskrypcji OpenShift mogą korzystać z wirtualizacji OpenShift całkowicie bezpłatnie i bez żadnych dodatkowych kroków. W momencie publikacji tego posta aktualne są OpenShift 4.4 i wirtualizacja OpenShift 2.3, jeśli używasz poprzednich wersji, powinieneś dokonać aktualizacji, aby uzyskać najnowsze funkcje. W pełni obsługiwana wersja wirtualizacji OpenShift powinna zostać wydana w drugiej połowie 2020 roku.
Aby uzyskać więcej informacji prosimy o kontakt aby uzyskać instrukcje dotyczące instalacji, w tym , w którym znajdują się informacje na temat konfigurowania sieci zewnętrznych.
Źródło: www.habr.com
