Ảo hóa OpenShift (dự án ngược dòng - Kubernetes: KubeVirt, xem. и ), в девичестве Container-native Virtualization, был представлен, как функционал платформы OpenShift, который предназначен для развертывания и управления виртуальными машинами (ВМ), как базовыми сущностями Kubernetes. Такого рода задача является технически сложной, по причине фундаментальных различий технологий. Для того, чтобы добиться поставленной цели, были использованы всем знакомые технологии на базе Red Hat Enterprise Linux и KVM, которые с нами не один год и доказали свою эффективность.
Trong bài viết này, chúng ta sẽ xem xét các khía cạnh kỹ thuật của ảo hóa OpenShift giúp máy ảo và vùng chứa có thể cùng tồn tại trong một nền tảng duy nhất quản lý chúng như một thực thể duy nhất.
Nhiệm vụ tính toán
Контейнеры задействуют механизмы Linux-ядра, такие как namespaces и cgroups, для изоляции процессов и управления ресурсами. Обычно под процессами понимаются приложения Python, Java или исполняемые файлы, но на самом деле это могут быть любые процессы, тот же bash, Emacs или vim.
Máy ảo là gì? Từ quan điểm của hypervisor, đây cũng là một quá trình. Nhưng không phải quy trình ứng dụng mà là quy trình KVM chịu trách nhiệm thực thi một VM cụ thể.
Hình ảnh vùng chứa chứa tất cả các công cụ, thư viện và tệp cần thiết cho máy ảo KVM. Nếu chúng tôi kiểm tra nhóm của một máy ảo đang chạy, chúng tôi sẽ thấy các trình trợ giúp và quy trình qemu-kvm ở đó. Ngoài ra, chúng tôi có quyền truy cập vào các công cụ KVM để quản lý máy ảo như qemu-img, qemu-nbd và virsh.
Vì máy ảo là một nhóm nên nó sẽ tự động kế thừa tất cả chức năng của nhóm trong Kubernetes. Nhóm VM, giống như nhóm thông thường, phải tuân theo các sơ đồ và tiêu chí của bộ lập lịch chẳng hạn như vết bẩn, dung sai, ái lực và chống ái lực. Bạn cũng nhận được những lợi ích của tính sẵn sàng cao, v.v. Tuy nhiên, có một điểm khác biệt quan trọng: các nhóm thông thường không di chuyển từ máy chủ này sang máy chủ khác theo nghĩa thông thường. Nếu một nút ngoại tuyến, nhóm trên đó sẽ bị chấm dứt và được gán lại cho một nút khác trong cụm. Và trong trường hợp máy ảo, chúng tôi mong đợi sẽ thấy sự di chuyển trực tiếp.
Để giải quyết khoảng trống này, một định nghĩa tài nguyên tùy chỉnh (CDR) đã được tạo để mô tả cơ chế di chuyển trực tiếp chịu trách nhiệm khởi tạo, giám sát và quản lý việc di chuyển trực tiếp các máy ảo giữa các nút công nhân.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Khi một nút bị vô hiệu hóa, các tác vụ di chuyển sẽ tự động được tạo cho những máy ảo đã đặt Di chuyển trực tiếp làm chiến lược trục xuất. Bằng cách này bạn có thể kiểm soát hành vi của máy ảo khi di chuyển giữa các nút cụm. Bạn có thể vừa định cấu hình Di chuyển trực tiếp vừa quản lý VM, giống như tất cả các nhóm khác.
Сеть
Bất kỳ hệ thống Kubernetes nào cũng cung cấp liên lạc giữa các nút và nhóm bằng mạng SDN phần mềm. OpenShift cũng không ngoại lệ và bắt đầu từ phiên bản 3, sử dụng OpenShiftSDN theo mặc định cho việc này. Ngoài ra, OpenShift 4 còn có một tính năng mới khác gọi là Multus, cho phép bạn cung cấp nhiều mạng và kết nối các nhóm với chúng cùng một lúc.
С помощью 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
Liên quan đến ảo hóa OpenShift, điều này có nghĩa là máy ảo có thể được kết nối trực tiếp với mạng bên ngoài, bỏ qua SDN. Điều này rất quan trọng đối với các máy ảo được di chuyển sang OpenShift từ Red Hat Virtualization hoặc VMware vSphere, vì nếu bạn có quyền truy cập vào lớp OSI thứ hai thì sẽ không có thay đổi nào trong cài đặt mạng. Điều này cũng có nghĩa là VM có thể có địa chỉ mạng bỏ qua SDN. Như vậy, chúng ta có thể sử dụng hiệu quả các adapter mạng chuyên dụng, hoặc kết nối trực tiếp với hệ thống lưu trữ qua mạng...
Bạn có thể tìm hiểu thêm về cách tạo và kết nối máy ảo ảo hóa OpenShift với mạng ... Ngoài ra, , được triển khai như một phần của ảo hóa OpenShift, cung cấp một cách quen thuộc khác để tạo và quản lý cấu hình mạng trên các nút vật lý được sử dụng trong trình ảo hóa.
Lưu trữ
Việc kết nối và quản lý đĩa máy ảo trong ảo hóa OpenShift được thực hiện bằng cách sử dụng các khái niệm Kubernetes như StorageClasses, PersistentVolumeClaims (PVC) và PersistentVolume (PV), cũng như tiêu chuẩn giao thức lưu trữ cho môi trường Kubernetes. Điều này mang lại cho quản trị viên và nhóm ứng dụng Kubernetes một cách phổ biến, quen thuộc để quản lý cả vùng chứa và máy ảo. Và đối với nhiều quản trị viên môi trường ảo hóa, khái niệm này nghe có vẻ quen thuộc vì nó sử dụng cùng một nguyên tắc tách các tệp và đĩa cấu hình VM được sử dụng trong OpenStack và nhiều nền tảng đám mây khác.
Tuy nhiên, chúng ta không thể cứ tạo một đĩa mới cho VM mỗi lần, vì khi di chuyển từ bộ ảo hóa sang OpenShift, chúng ta cần lưu dữ liệu. Có, ngay cả khi chúng tôi triển khai một máy ảo mới, việc thực hiện từ mẫu luôn nhanh hơn so với tạo từ đầu. Vì vậy, chúng tôi cần chức năng nhập các đĩa hiện có.
Để đơn giản hóa tác vụ này, ảo hóa OpenShift triển khai dự án Trình nhập dữ liệu trong vùng chứa (CDI), giúp giảm việc nhập hình ảnh đĩa của các đĩa từ nhiều nguồn để tạo mục nhập 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
Chính mục này sẽ kích hoạt CDI, kích hoạt chuỗi hành động được hiển thị trong hình bên dưới:
Sau khi CDI hoàn thành, PVC sẽ chứa đĩa máy ảo sẵn sàng để sử dụng và được chuyển đổi sang định dạng OpenShift tiêu chuẩn...
Khi làm việc với ảo hóa OpenShift, OpenShift Container Storage (OCS), một giải pháp Red Hat dựa trên hệ thống tệp Ceph triển khai chức năng lưu trữ liên tục cho các container, cũng rất hữu ích. Ngoài các phương thức truy cập PVC tiêu chuẩn - RWO (khối) và RWX (file) - OCS còn cung cấp RWX cho các thiết bị khối thô, rất hữu ích trong việc chia sẻ quyền truy cập khối cho các ứng dụng có yêu cầu hiệu suất cao. Ngoài ra, OCS hỗ trợ tiêu chuẩn Yêu cầu nhóm đối tượng mới, cho phép các ứng dụng sử dụng trực tiếp việc lưu trữ dữ liệu đối tượng.
Máy ảo trong container
Nếu bạn muốn kiểm tra cách thức hoạt động của nó thì hãy biết rằng ảo hóa OpenShift đã có sẵn trong phiên bản Tech Preview như một phần của OpenShift 3.11 trở lên. Chủ sở hữu đăng ký OpenShift hiện có có thể sử dụng ảo hóa OpenShift hoàn toàn miễn phí và không cần bất kỳ bước bổ sung nào. Tại thời điểm đăng bài này, OpenShift 4.4 và OpenShift virtualization 2.3 đang là phiên bản hiện tại, nếu bạn đang sử dụng các phiên bản trước thì nên nâng cấp để có được những tính năng mới nhất. Phiên bản ảo hóa OpenShift được hỗ trợ đầy đủ sẽ được phát hành vào nửa cuối năm 2020.
Để biết thêm thông tin, vui lòng tham khảo để biết hướng dẫn cài đặt, bao gồm , cung cấp thông tin về cách thiết lập mạng bên ngoài.
Nguồn: www.habr.com
