KubeVirt는 서비스 지향 아키텍처와 choreography 패턴을 사용하여 구축되었습니다.
스택
+---------------------+ | KubeVirt | ~~+---------------------+~~ | Orchestration (K8s) | +---------------------+ | Scheduling (K8s) | +---------------------+ | Container Runtime | ~~+---------------------+~~ | Operating System | +---------------------+ | Virtual(kvm) | ~~+---------------------+~~ | Physical | +---------------------+
가상화 서비스가 필요한 사용자는 Virtualization API(아래 참조)에 말하고, 이는 다시 Kubernetes 클러스터에 말하여 요청된 Virtual Machine Instance(VMI)를 예약합니다. 스케줄링, 네트워킹 및 스토리지는 모두 Kubernetes에 위임되고, KubeVirt는 가상화 기능을 제공합니다.
추가 서비스
KubeVirt는 Kubernetes 클러스터에 추가 기능을 제공하여 가상 머신 관리를 수행합니다.
쿠버네티스가 Pod를 처리하는 방식을 떠올려보면, Pod는 Kubernetes API 서버에 Pod 사양을 게시하여 생성된다는 것을 기억할 수 있습니다. 그런 다음 이 사양은 API 서버 내부의 객체로 변환되고, 이 객체는 특정 유형 또는 kind입니다 . 이것이 사양에서 호출되는 방식입니다. Pod는 Pod유형입니다. 쿠버네티스 내의 컨트롤러는 이러한 Pod 객체를 처리하는 방법을 알고 있습니다. 따라서 새 Pod 객체가 표시되면 해당 컨트롤러는 Pod를 활성화하고 필요한 상태와 일치시키기 위해 필요한 작업을 수행합니다.
KubeVirt에서도 이와 동일한 메커니즘이 사용됩니다. 따라서 KubeVirt는 새로운 기능을 제공하기 위해 세 가지를 제공합니다.
- 추가 유형(소위 Custom Resource Definition (CRD))이 Kubernetes API에 추가되었습니다.
- 이러한 새로운 유형과 관련된 클러스터 전체 논리에 대한 추가 컨트롤러
- 새로운 유형과 관련된 노드별 논리에 대한 추가 데몬
세 단계가 모두 완료되면 다음을 수행할 수 있습니다.
- Kubernetes에서 이러한 새로운 유형의 새 객체를 만듭니다(우리의 경우 VMI).
- 그리고 새로운 컨트롤러는 일부 호스트에 예약된 VMI를 확보하기 위해 노력합니다.
- 그리고 데몬은
virt-handler호스트를 관리하고kubeletVMI를 실행하고 필요한 상태와 일치할 때까지 구성합니다.
마지막으로, 컨트롤러와 데몬은 모두 Kubernetes 클러스터 위에서 Pod(또는 유사한 것)로 실행되고 , Kubernetes 클러스터와 함께 설치되지 않습니다. 유형은 앞서 말했듯이 Kubernetes API 서버 내부에서도 정의됩니다. 이를 통해 사용자는 Kubernetes와 통신할 수 있지만 VMI를 수정할 수 있습니다.
다음 다이어그램은 추가 컨트롤러와 데몬이 Kubernetes와 통신하는 방법과 추가 유형이 저장되는 위치를 보여줍니다.
그리고 단순화된 버전:
응용 프로그램 레이아웃
- Cluster
- KubeVirt 구성 요소
- virt-controller
- virt-handler
- libvirtd
- …
- KubeVirt Managed Pod
- VMI Foo
- VMI Bar
- …
- KubeVirt Custom Resource
- VirtualMachine(VM) Foo -> VirtualMachineInstance(VMI) Foo
- VirtualMachineInstanceReplicaSet(VMIRS) 막대 -> VirtualMachineInstance(VMI) 막대
VirtualMachineInstance(VMI)는 인스턴스의 기본 임시 빌딩 블록을 나타내는 사용자 지정 리소스입니다. 많은 경우 이 객체는 사용자가 직접 생성하지 않고 상위 수준 리소스가 생성합니다. VMI의 상위 수준 리소스는 다음과 같습니다.
- VirtualMachine(VM) Foo – VM 데이터와 상태를 유지하면서 중지 및 시작할 수 있는 상태 기반 VM입니다.
- VirtualMachineInstanceReplicaSet(VMIRS) Bar – 템플릿에 정의된 유사한 구성을 가진 임시 VMI 그룹인 Pod ReplicaSet과 유사합니다.
네이티브 워크로드
KubeVirt는 Kubernetes 클러스터 위에 배포됩니다. 즉, KubeVirt를 통해 관리되는 VMI 옆에서 Kubernetes 네이티브 워크로드를 계속 실행할 수 있습니다.
또한: 네이티브 워크로드를 실행할 수 있고 KubeVirt가 설치되어 있다면 VM 기반 워크로드도 실행할 수 있어야 합니다. 예를 들어, 애플리케이션 운영자는 일반 Pod에서 해당 기능을 사용하는 것과 비교하여 VM에 대한 클러스터 기능을 사용하기 위해 추가 권한이 필요하지 않아야 합니다.
보안 측면에서 KubeVirt를 설치하고 사용할 때 사용자에게 네이티브 워크로드와 관련하여 이미 가지고 있지 않은 권한을 부여해서는 안 됩니다. 예를 들어, 권한이 없는 애플리케이션 운영자는 KubeVirt 기능을 사용하여 권한이 있는 Pod에 액세스해서는 안 됩니다.
Razor
우리는 가상 머신을 좋아하고, 그것이 매우 중요하다고 생각하며, Kubernetes에서 사용하기 쉽게 만들기 위해 열심히 노력합니다. 하지만 VM보다 더 좋은 디자인과 모듈식, 재사용 가능한 구성 요소를 좋아합니다. 우리는 종종 딜레마에 직면합니다. VM에 가장 최적화된 방식으로 KubeVirt에서 문제를 해결해야 할까요, 아니면 더 긴 경로를 취해 Pod 기반 워크로드에도 솔루션을 도입해야 할까요?
이러한 딜레마를 해결하기 위해 우리는 KubeVirt Razor를 생각해냈습니다: “무언가가 Pod에 유용하다면, 그것을 VM에만 구현해서는 안 됩니다.”
예를 들어, 우리는 VM을 외부 네트워크 리소스에 어떻게 연결해야 할지 논의했습니다. 가장 빠른 방법은 KubeVirt 특정 코드를 도입하여 VM을 호스트 브리지에 연결하는 것 같습니다. 그러나 우리는 Multus 와 CNI를 통합 하고 개선하는 더 긴 경로를 선택했습니다.
VirtualMachine
VirtualMachine은 클러스터 내부의 VirtualMachineInstance에 추가 관리 기능을 제공합니다. 여기에는 다음이 포함됩니다.
- API 안정성
- 컨트롤러 수준에서 시작/중지/재시작 기능
- VirtualMachineInstance 재생성에 대한 전파를 통한 오프라인 구성 변경
- VirtualMachineInstance가 실행 중이어야 하는 경우 실행 중인지 확인하십시오.
컨트롤러 인스턴스와 가상 머신 인스턴스 간의 1:1 관계에 초점을 맞춥니다. 여러 면에서 spec.replica가 1로 설정된 StatefulSet 과 매우 유사합니다.
VirtualMachine을 사용하는 방법
VirtualMachine은 spec.running이 true로 설정된 경우 동일한 이름을 가진 VirtualMachineInstance 개체가 클러스터에 존재하도록 합니다 . 또한 spec.running이 false로 설정된 VirtualMachineInstance가 클러스터에서 제거되도록 합니다.
spec.runStrategy 연관된 VirtualMachineInstance 객체의 상태를 제어하는 데 사용할 수 있는 필드가 있습니다 . 혼란스럽고 모순되는 상태를 피하기 위해 이러한 필드는 상호 배타적입니다.
spec.runStrategy 대 spec.running 에 대한 자세한 설명은 Run Strategies에서 찾을 수 있습니다 .
시작 및 중지
VirtualMachine을 생성한 후에는 다음과 같이 켜거나 끌 수 있습니다.
# Start the virtual machine: virtctl start vm # Stop the virtual machine: virtctl stop vm
kubectl다음도 사용할 수 있습니다:
# Start the virtual machine:
kubectl patch virtualmachine vm --type merge -p \
'{"spec":{"running":true}}'
# Stop the virtual machine:
kubectl patch virtualmachine vm --type merge -p \
'{"spec":{"running":false}}'
VM의 수명 주기 에 대한 자세한 내용은 관련 섹션에서 확인하세요 .
컨트롤러 상태
VirtualMachineInstance가 생성되면 VirtualMachine의 status.created 및 status.ready 필드를 통해 상태가 추적됩니다. 클러스터에 VirtualMachineInstance가 있는 경우 status.created는 true입니다. 만약 VirtualMachineInstance이 준비된 경우 status.ready는 true입니다.
VirtualMachineInstance가 최종 상태에 도달하고 spec.running 은 true 이면, VirtualMachine 컨트롤러는 status.ready를 false로 설정하고 VirtualMachineInstance를 다시 생성합니다.
또한, 이 status.printableStatus필드는 VirtualMachine의 상태에 대한 높은 수준의 요약 정보를 제공합니다. 이 정보는 CLI를 사용하여 VirtualMachines를 나열할 때도 표시됩니다.
$ kubectl get virtualmachines NAME AGE STATUS VOLUME vm1 4m Running vm2 11s Stopped
현재 지원되는 상태 목록과 그 의미는 다음과 같습니다. 상태는 향후 릴리스에서 추가/제거될 수 있으므로 자동화된 프로그램에서 사용하는 경우 주의해야 합니다.
- Stopped : 가상 머신이 현재 중지되어 있으며 시작할 수 없습니다.
- Provisioning: 가상 머신과 관련된 클러스터 리소스(예: DataVolumes)가 프로비저닝되고 준비됩니다.
- Starting: 가상 머신이 실행될 준비를 하고 있습니다.
- Running: 가상 머신이 실행 중입니다.
- Paused: 가상 머신이 일시 중지되었습니다.
- Migrating: 가상 머신이 다른 호스트로 마이그레이션되는 중입니다.
- Stopping: 가상 머신이 중지되고 있습니다.
- Terminating: 가상 머신은 삭제 중이며, 관련 리소스(VirtualMachineInstance, DataVolumes 등)도 삭제 중입니다.
- Unknown: 가상 머신의 상태를 얻을 수 없습니다. 일반적으로 이는 가상 머신이 실행 중인 호스트와 통신하는 데 오류가 발생하기 때문입니다.
다시 시작
VirtualMachineInstance 재시작은 VirtualMachineInstance를 삭제하여 트리거할 수 있습니다. 이렇게 하면 VirtualMachine의 템플릿에서 구성 변경 사항도 전파됩니다.
# Restart the virtual machine (you delete the instance!): kubectl delete virtualmachineinstance vm
virtctl을 사용하여 vm이라는 VirtualMachine을 다시 시작하려면:
$ virtctl restart vm
이렇게 하면 VirtualMachineInstance에 대한 정상적인 재시작이 수행되고 새 virt-launcher Pod에서 VirtualMachineInstance가 다시 예약됩니다.
virtctl을 사용하여 vm이라는 VirtualMachine을 강제로 다시 시작하려면:
$ virtctl restart vm --force --grace-period=0
이렇게 하면 일반적인 재시작을 수행하며, 명령에서 전달된 초로 GracePeriodSeconds를 설정하여 VirtualMachineInstance의 virt-launcher Pod를 삭제합니다.
현재는 grace-period=0으로만 설정 가능합니다.
참고: 강제 재시작은 데이터 손상을 일으킬 수 있으므로 커널 패닉이나 VirtualMachine이 정상적인 재시작에 응답하지 않는 경우에 사용해야 합니다.
펜싱 고려 사항
VirtualMachine은 현재 VirtualMachineInstance의 인스턴스가 클러스터에서 삭제될 때까지 VirtualMachineInstance를 다시 시작하거나 재생성하지 않습니다.
서비스로 노출
VirtualMachine은 서비스로 노출될 수 있습니다. 실제 서비스는 VirtualMachineInstance가 추가 상호 작용 없이 시작되면 사용 가능합니다.
예를 들어 virctl을 사용해서 VirtualMachine이 생성되고 시작되기 전에 SSH 포트(22)를 ClusterIP서비스 로 노출합니다.
$ virtctl expose virtualmachine vmi-ephemeral --name vmiservice --port 27017 --target-port 22
VirtualMachineInstance에 적용되는 모든 서비스 노출 옵션은 VirtualMachine에도 적용됩니다.
자세한 내용은 서비스 객체를 참조하세요 .
VirtualMachine을 사용하는 경우
재시작 사이에 API 안정성이 필요한 경우
VirtualMachine은 VirtualMachineInstance API 구성이 재시작 간에 일관되도록 합니다. 전형적인 예로는 가상 머신의 펌웨어 UUID에 바인딩된 라이선스가 있습니다. 이는 VirtualMachine사용자가 UUID를 처리하지 않아도 UUID가 항상 동일하게 유지되도록 합니다.
가장 중요한 이점 중 하나는 안정적인 API가 필요하더라도 사용자가 여전히 기본 로직을 사용할 수 있다는 것입니다.
다음 재시작 시 구성 업데이트를 선택해야 하는 경우
VirtualMachineInstance 구성이 클러스터 내부에서 수정 가능해야 하고 이러한 변경 사항이 다음 VirtualMachineInstance 재시작 시 적용되어야 하는 경우, 즉 핫플러그가 관련되지 않음을 의미합니다.
클러스터가 개별 VirtualMachineInstance를 관리하도록 하려는 경우
선언적 시스템으로서의 Kubernetes는 VirtualMachineInstance를 관리하는 데 도움이 될 수 있습니다. 이 VirtualMachineInstance를 애플리케이션이 실행 중인 상태로 유지하도록 하면 VirtualMachine은 인스턴스가 계속 실행되도록 합니다.
참고 : 현재 믿음은 VirtualMachineInstance가 실행되어야 한다고 정의되어 있다면 실행되어야 한다는 것입니다. 이는 VM이 꺼지면 계속 다운되는 많은 기존 가상화 플랫폼과 다릅니다. 필요한 경우 재시작 정책을 추가할 수 있습니다. 필요하면 사용 사례를 제공하세요!
예
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
labels:
kubevirt.io/vm: vm-cirros
name: vm-cirros
spec:
running: false
template:
metadata:
labels:
kubevirt.io/vm: vm-cirros
spec:
domain:
devices:
disks:
- disk:
bus: virtio
name: containerdisk
- disk:
bus: virtio
name: cloudinitdisk
machine:
type: ""
resources:
requests:
memory: 64M
terminationGracePeriodSeconds: 0
volumes:
- name: containerdisk
containerDisk:
image: kubevirt/cirros-container-disk-demo:latest
- cloudInitNoCloud:
userDataBase64: IyEvYmluL3NoCgplY2hvICdwcmludGVkIGZyb20gY2xvdWQtaW5pdCB1c2VyZGF0YScK
name: cloudinitdisk
이 매니페스트를 vm.yaml로 저장 하고 Kubernetes에 제출하면 컨트롤러 인스턴스가 생성됩니다.
$ kubectl create -f vm.yaml virtualmachine "vm-cirros" created
spec.running이 false로 설정되어 있으므로 vmi가 생성되지 않습니다.
$ kubectl get vmis No resources found.
VirtualMachine을 시작해 보겠습니다.
$ virtctl start vm vm-cirros
예상대로 VirtualMachineInstance가 vm-cirros생성되었습니다.
$ kubectl describe vm vm-cirros
Name: vm-cirros
Namespace: default
Labels: kubevirt.io/vm=vm-cirros
Annotations: <none>
API Version: kubevirt.io/v1
Kind: VirtualMachine
Metadata:
Cluster Name:
Creation Timestamp: 2018-04-30T09:25:08Z
Generation: 0
Resource Version: 6418
Self Link: /apis/kubevirt.io/v1/namespaces/default/virtualmachines/vm-cirros
UID: 60043358-4c58-11e8-8653-525500d15501
Spec:
Running: true
Template:
Metadata:
Creation Timestamp: <nil>
Labels:
Kubevirt . Io / Ovmi: vm-cirros
Spec:
Domain:
Devices:
Disks:
Disk:
Bus: virtio
Name: containerdisk
Volume Name: containerdisk
Disk:
Bus: virtio
Name: cloudinitdisk
Volume Name: cloudinitdisk
Machine:
Type:
Resources:
Requests:
Memory: 64M
Termination Grace Period Seconds: 0
Volumes:
Name: containerdisk
Registry Disk:
Image: kubevirt/cirros-registry-disk-demo:latest
Cloud Init No Cloud:
User Data Base 64: IyEvYmluL3NoCgplY2hvICdwcmludGVkIGZyb20gY2xvdWQtaW5pdCB1c2VyZGF0YScK
Name: cloudinitdisk
Status:
Created: true
Ready: true
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 15s virtualmachine-controller Created virtual machine: vm-cirros
Kubectl 명령줄 상호 작용
명령줄을 통해 VirtualMachine을 조작하고 싶을 때마다 kubectl 명령을 사용할 수 있습니다. 다음은 이를 수행하는 방법을 보여주는 예입니다.
# Define a virtual machine:
kubectl create -f vm.yaml
# Start the virtual machine:
kubectl patch virtualmachine vm --type merge -p \
'{"spec":{"running":true}}'
# Look at virtual machine status and associated events:
kubectl describe virtualmachine vm
# Look at the now created virtual machine instance status and associated events:
kubectl describe virtualmachineinstance vm
# Stop the virtual machine instance:
kubectl patch virtualmachine vm --type merge -p \
'{"spec":{"running":false}}'
# Restart the virtual machine (you delete the instance!):
kubectl delete virtualmachineinstance vm
# Implicit cascade delete (first deletes the virtual machine and then the virtual machine instance)
kubectl delete virtualmachine vm
# Explicit cascade delete (first deletes the virtual machine and then the virtual machine instance)
kubectl delete virtualmachine vm --cascade=true
# Orphan delete (The running virtual machine is only detached, not deleted)
# Recreating the virtual machine would lead to the adoption of the virtual machine instance
kubectl delete virtualmachine vm --cascade=false
