A virtualização OpenShift (projeto upstream – Kubernetes: KubeVirt, ver. e ), anteriormente conhecida como Virtualização nativa de Contêineres, foi apresentada como uma funcionalidade da plataforma OpenShift, destinada à implantação e gerenciamento de máquinas virtuais (VMs) como entidades básicas do Kubernetes. Essa tarefa é tecnicamente complexa, devido às diferenças fundamentais das tecnologias. Para alcançar o objetivo proposto, foram utilizadas tecnologias conhecidas, baseadas em Red Hat Enterprise Linux e KVM, que têm nos acompanhado por muitos anos e demonstraram sua eficácia.
Neste artigo, examinaremos os aspectos técnicos da virtualização OpenShift que possibilitam a coexistência de VMs e contêineres dentro de uma única plataforma que os gerencia como um todo.
Tarefas computacionais
Os contêineres utilizam mecanismos do kernel Linux, como namespaces e cgroups, para isolar processos e gerenciar recursos. Normalmente, processos referem-se a aplicativos Python, Java ou arquivos executáveis, mas na verdade, podem ser qualquer processo, como bash, Emacs ou vim.
E o que é uma máquina virtual? Do ponto de vista do hipervisor, também é um processo. Mas não um processo de aplicativo, e sim um processo KVM responsável pela execução de uma VM específica.
A imagem do contêiner contém todas as ferramentas, bibliotecas e arquivos necessários para a máquina virtual KVM. Se inspecionarmos o pod da VM em funcionamento, poderemos ver os ajudantes e processos qemu-kvm. Além disso, temos acesso às ferramentas KVM para gerenciar máquinas virtuais, como qemu-img, qemu-nbd e virsh.
Como uma máquina virtual é um pod, ela herda automaticamente toda a funcionalidade de um pod no Kubernetes. Para os pods de VM, assim como para os pods comuns, aplicam-se esquemas e critérios de agendamento, como taints, tolerations, affinity e anti-affinity. Além disso, você obtém vantagens como alta disponibilidade, etc. No entanto, há uma diferença importante: os pods comuns não migram de host para host no sentido habitual. Se um nó for desligado, o pod nele é interrompido e realocado para outro nó no cluster. No caso de uma máquina virtual, esperamos ver migração ao vivo.
Para sanar essa lacuna, foi criada uma definição de recurso personalizado (CDR), descrevendo o mecanismo de migração ao vivo, que é responsável pela inicialização, monitoramento e gerenciamento de migrações ao vivo de VMs entre nós de trabalho.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Ao desativar um nó, para suas máquinas virtuais que têm a estratégia de evasão definida como Live Migration, tarefas de migração são criadas automaticamente. Isso permite controlar o comportamento das máquinas virtuais ao mover entre os nós do cluster. Você pode configurar o Live Migration e gerenciar a VM, assim como todos os outros pods.
Rede
Qualquer sistema Kubernetes garante conectividade entre nós e pods por meio de redes SDN programáticas. OpenShift não é uma exceção e a partir da versão 3, utiliza por padrão o OpenShiftSDN para isso. Além disso, no OpenShift 4, uma nova funcionalidade chamada Multus foi introduzida, permitindo que várias redes sejam disponibilizadas e conectadas simultaneamente a pods.
Com o Multus, o administrador pode especificar redes CNI adicionais que serão implantadas e configuradas no cluster por meio do operador Cluster Network Operator. Após isso, os pods se conectam a uma ou mais dessas redes, geralmente à OpenShiftSDN padrão e a uma interface adicional. Dispositivos SR-IOV, Linux Bridge padrão, dispositivos MACVLAN e IPVLAN também podem ser usados, se necessário para sua VM. Abaixo está um exemplo de como definir o Multus CNI para uma rede bridge na interface 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
No contexto da virtualização do OpenShift, isso significa que a VM pode ser conectada diretamente a uma rede externa, contornando a SDN. Isso é importante para máquinas virtuais migradas para o OpenShift a partir do Red Hat Virtualization ou VMware vSphere, pois, com o acesso na segunda camada do OSI, não haverá alteração nas configurações de rede. Isso também significa que a VM pode ter um endereço de rede cujas requisições contornam a SDN. Assim, podemos usar de forma eficiente adaptadores de rede especializados ou nos conectar diretamente a SANs...
Para saber mais sobre como criar e conectar máquinas virtuais do OpenShift virtualization à rede, você pode . Além disso, , implantado como parte do OpenShift virtualization, oferece mais uma forma familiar de criar e gerenciar configurações de rede em nós físicos utilizados por hipervisores.
Armazenamento
A conexão e gerenciamento de discos de máquinas virtuais no ambiente de virtualização OpenShift é feito usando conceitos do Kubernetes como StorageClasses, PersistentVolumeClaims (PVC) e PersistentVolume (PV), além de protocolos de armazenamento padrão do Kubernetes. Assim, administradores do Kubernetes e as equipes responsáveis pelos aplicativos recebem um mecanismo único e familiar para gerenciar tanto contêineres quanto máquinas virtuais. Para muitos administradores de ambientes de virtualização, esse conceito pode parecer familiar, pois utiliza o mesmo princípio de separação de arquivos de configuração de VM e discos aplicado no OpenStack e em muitas outras plataformas em nuvem.
No entanto, não podemos simplesmente criar um novo disco para cada VM, pois ao migrar de um hypervisor para o OpenShift, precisamos preservar os dados. Mesmo ao implantar uma nova VM, é sempre mais rápido fazê-lo a partir de um modelo do que criar do zero. Portanto, precisamos da funcionalidade de importação de discos existentes.
Para simplificar essa tarefa, o OpenShift virtualization implanta o projeto Containerized Data Importer (CDI), que reduz a importação de imagens de disco de várias fontes a criar uma entrada no 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
É esta entrada que ativa o CDI, iniciando a sequência de ações mostradas na figura abaixo:
Depois que o CDI é concluído, o PVC conterá um disco de máquina virtual pronto para uso e formatado conforme o padrão do OpenShift...
Ao trabalhar com o OpenShift virtualization, o OpenShift Container Storage (OCS) também será útil, uma solução da Red Hat baseada no sistema de arquivos Ceph, implementando funcionalidade de armazenamento persistente para contêineres. Além dos métodos de acesso padrão do PVC – RWO (bloco) e RWX (arquivo) – o OCS fornece RWX para dispositivos de bloco bruto, o que é muito útil para organizar acesso em bloco compartilhado para aplicativos com altas exigências de desempenho. Além disso, o OCS suporta o novo padrão de solicitação de grupos de objetos chamado Object Bucket Claim, permitindo que os aplicativos usem diretamente o armazenamento de objetos.
Máquinas virtuais em contêineres
Se você está interessado em verificar como isso funciona, saiba que a virtualização OpenShift já está disponível na versão Tech Preview como parte do OpenShift 3.11 e superior. Os proprietários de uma assinatura ativa do OpenShift podem utilizar a virtualização OpenShift completamente grátis e sem qualquer complicação adicional. No momento da publicação deste post, as versões atuais são OpenShift 4.4 e OpenShift virtualization 2.3; se você estiver usando versões anteriores, vale a pena atualizar para obter os recursos mais recentes. A versão totalmente suportada da virtualização OpenShift deve ser lançada na segunda metade de 2020.
Para mais informações, consulte para orientações de instalação, incluindo , onde são fornecidas informações sobre a configuração de redes externas.
Fonte: habr.com
