From c88580a7c8c2fe8be57957d948661148f362ec53 Mon Sep 17 00:00:00 2001 From: Benjamin Affolter <5555767+bliemli@users.noreply.github.com> Date: Sun, 22 Sep 2024 16:27:45 +0200 Subject: [PATCH] Proofread getting started chapter --- .../21_create-vm.md | 32 +-- .../22_lifecycle.md | 209 +++++++++--------- .../23_console.md | 26 ++- .../getting-started-with-kubevirt/24_ssh.md | 74 ++++--- .../25_vm-changes.md | 43 ++-- .../getting-started-with-kubevirt/_index.md | 27 +-- 6 files changed, 214 insertions(+), 197 deletions(-) diff --git a/content/en/docs/getting-started-with-kubevirt/21_create-vm.md b/content/en/docs/getting-started-with-kubevirt/21_create-vm.md index 58ac888..1a23df6 100644 --- a/content/en/docs/getting-started-with-kubevirt/21_create-vm.md +++ b/content/en/docs/getting-started-with-kubevirt/21_create-vm.md @@ -8,11 +8,11 @@ description: > --- -## Creating a Virtual Machine +## Creating a virtual machine -To create a Virtual Machine in our kubernetes cluster we have to create and apply a `VirtualMachine` yaml manifest. +To create a virtual machine in our Kubernetes cluster we have to create and apply a `VirtualMachine` manifest. -This is a very basic example of a bootable virtual machine manifest. +This is a very basic example of a bootable virtual machine manifest: ```yaml apiVersion: kubevirt.io/v1 @@ -36,40 +36,40 @@ spec: {{% alert title="Note" color="info" %}} -A VirtualMachine yaml requires a memory resource specification. Therefore, we always have `spec.domain.resources.requests.memory` set. +A VirtualMachine manifest requires a memory resource specification. Therefore, we always have `spec.domain.resources.requests.memory` set. You may also use `spec.domain.memory.guest` or `spec.domain.memory.hugepages.size` as a resource specification. {{% /alert %}} -### {{% task %}} Review VirtualMachine manifest +### {{% task %}} Review the VirtualMachine manifest Do you see any problems with the specification above? Try to answer the following questions: -* What happens when you run this vm? +* What happens when you run this VM? * What is required to successfully boot a machine? {{% details title="Task Hint" %}} -Our created manifest does not contain any bootable devices. Our vm is able to start, but it will just hang as there are +Our created manifest does not contain any bootable devices. Our VM is able to start, but it will just hang as there are no bootable devices available. ![No bootable device](../no-bootable-device.png) -Having a bootable disk within your yaml specification is all you need to start the vm. However, as there is no network -interface specified which is connected to the underlying network our system would not be capable of interacting with the +Having a bootable disk within the specification is all you need to start the VM. However, as there is no network +interface specified which is connected to the underlying network, our system would not be capable of interacting with the outside world. {{% /details %}} ### {{% task %}} Write your own VirtualMachine manifest -Create a new empty file `firstvm.yaml` in the folder `{{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/` and copy the `VirtualMachine` manifest from above as a starting point. Starting from the basic manifest you need to add a bootable disk for your vm and a network and interface specification. -To achieve that you need to specify the following parts in the `VirtualMachine` manifest: +Create a new file `firstvm.yaml` in the folder `{{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/` and copy the `VirtualMachine` manifest from above as a starting point. You then need to add a bootable disk for your VM and a network and interface specification. +To achieve this you need to specify the following parts in the `VirtualMachine` manifest: * `spec.template.spec.domain.devices` * `spec.template.spec.networks` * `spec.template.spec.volumes` -The easiest way is to use an ephemeral `containerDisk` mountable as a volume. Regarding the network we connect our VM to the underlying kubernetes default network. +The easiest way is to use an ephemeral `containerDisk` mountable as a volume. Regarding the network, we simply connect our VM to the underlying Kubernetes default network: ```yaml spec: @@ -95,8 +95,9 @@ spec: Make sure you implement the required parts for a container disk and the network interface specification in you VM manifest. -{{% details title="Task Hint: Resulting yaml" %}} -Your VirtualMachine yaml should look like this: +{{% details title="Task hint: Resulting yaml" %}} +Your VirtualMachine definition should look like this: + ```yaml apiVersion: kubevirt.io/v1 kind: VirtualMachine @@ -135,7 +136,7 @@ spec: ### {{% task %}} Create the VirtualMachine -Since you have completed the yaml configuration for the VM it's now time to create it our VM in the kubernetes cluster. +It is now time to create the VM on the Kubernetes cluster using the definition you just created: ```shell kubectl create -f {{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/firstvm.yaml --namespace=$USER @@ -146,4 +147,3 @@ The output should be: ```shell virtualmachine.kubevirt.io/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm created ``` - diff --git a/content/en/docs/getting-started-with-kubevirt/22_lifecycle.md b/content/en/docs/getting-started-with-kubevirt/22_lifecycle.md index 3dac3d0..d9f7399 100644 --- a/content/en/docs/getting-started-with-kubevirt/22_lifecycle.md +++ b/content/en/docs/getting-started-with-kubevirt/22_lifecycle.md @@ -7,20 +7,20 @@ description: > Start & Stop your VirtualMachine using kubectl or virtctl --- -In the previous section we have written our VirtualMachine specification and have applied the manifest to the kubernetes cluster. +In the previous section, we wrote a VirtualMachine specification and applied the manifest to the Kubernetes cluster. ## Lifecycle -When the underlying technology `libvirt` refers to a VM it often also uses the concept of guest domains. +When the underlying technology `libvirt` refers to a VM it often also uses the concept of so-called _guest domains_. -According to [libvirt.org](https://wiki.libvirt.org/VM_lifecycle.html) a guest domain can be in several states: +According to [libvirt.org](https://wiki.libvirt.org/VM_lifecycle.html), a guest domain can be in several states: -1. **Undefined** - This is a baseline state. Libvirt does not know anything about domains in this state because the domain hasn't been defined or created yet. -2. **Defined** or **Stopped** - The domain has been defined, but it's not running. This state is also called stopped. Only persistent domains can be in this state. When a transient domain is stopped or shutdown, it ceases to exist. -3. **Running** - The domain has been created and started either as transient or persistent domain. Either domain in this state is being actively executed on the node's hypervisor. -4. **Paused** - The domain execution on hypervisor has been suspended. Its state has been temporarily stored until it is resumed. The domain does not have any knowledge whether it was paused or not. If you are familiar with processes in operating systems, this is the similar. -5. **Saved** - Similar to the paused state, but the domain state is stored to persistent storage. Again, the domain in this state can be restored and it does not notice that any time has passed. +1. **Undefined**: This is a baseline state. Libvirt does not know anything about domains in this state because the domain hasn't been defined or created yet. +2. **Defined** or **Stopped**: The domain has been defined but it's not running. This state is also called stopped. Only persistent domains can be in this state. When a transient domain is stopped or shut down, it ceases to exist. +3. **Running**: The domain has been created and started either as transient or persistent domain. Either domain in this state is being actively executed on the node's hypervisor. +4. **Paused**: The domain execution on the hypervisor has been suspended. Its state has been temporarily stored until it is resumed. The domain does not have any knowledge whether it was paused or not. +5. **Saved**: Similar to the paused state, but the domain state is stored to persistent storage. Again, the domain in this state can be restored and it does not notice that any time has passed. ![VM Lifecycle](../vm_lifecycle_graph.png) @@ -29,17 +29,17 @@ In this section we will have a look how to use the states `Running`, `Stopped (D {{% /alert %}} -## List your VirtualMachines +## List your virtual machines -Since you created the VirtualMachine in the previous section you may verify the creation with: +Since you created the VirtualMachine resource in the previous section you may verify its creation with: -```shell +```bash kubectl get virtualmachine --namespace=$USER ``` -You should see your virtual machines listed as following: +You should see your virtual machines listed as follows: -```shell +```bash NAME AGE STATUS READY {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm 10m Stopped False ``` @@ -47,40 +47,32 @@ NAME AGE STATUS READY This indicated that the VM has been created but is still in a stopped state. {{% alert title="Note" color="info" %}} -In kubernetes the resource `VirtualMachine` has a shortname `vm`. Therefore, the following command is equivalent to the one above: +In Kubernetes, the resource `VirtualMachine` has a shortname `vm`. Therefore, the following command is equivalent to the one above: -```shell +```bash kubectl get vm --namespace=$USER ``` - -From now on we will use the shortname `vm`. - -You can list all shortnames with: - -```shell -kubectl api-resources -``` {{% /alert %}} ## {{% task %}} Working with your VMs -There are two ways of starting and stopping your VirtualMachine. You can patch your VirtualMachine resource with `kubectl` or use `virtctl` to +There are two ways of starting and stopping your virtual machines. You can patch your VirtualMachine resource with `kubectl` or use `virtctl` to start the VM. Try starting and stopping your VM with both methods. -### Start/Stop with Kubectl +### Start/stop with kubectl -Your VirtualMachine resource contains a field `spec.running` which indicated the desired state of the VM. You can check +Your VirtualMachine resource contains a field `spec.running` which indicates the desired state of the VM. You can check the resource with: -```shell +```bash kubectl describe vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --namespace=$USER ``` -Alternatively you can also directly select the relevant field using a jsonpath: +Alternatively you can directly select the relevant field using a jsonpath: -```shell +```bash kubectl get vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm -o jsonpath='{.spec.running}' --namespace=$USER ``` @@ -88,244 +80,255 @@ kubectl get vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}} With `kubectl` all you have to do to start and stop your VM is patching the field `spec.running`. {{% /alert %}} -Use the following command to start your vm: +Use the following command to start your VM: -```shell +```bash kubectl patch vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --type merge -p '{"spec":{"running":true}}' --namespace=$USER ``` -the output should be: +The output should be: -```shell +```bash virtualmachine.kubevirt.io/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm patched ``` -Now check the state of your vm again: +Now check the state of your VM again: -```shell +```bash kubectl get vm --namespace=$USER ``` -You should see that the VM is now in a Running state: +You should see that the VM is now in `Running` state: -```shell +```bash NAME AGE STATUS READY {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm 11m Running True ``` Stopping the VM is similar to starting. Just set `spec.running` back to `false`: -```shell + +```bash kubectl patch vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --type merge -p '{"spec":{"running":false}}' --namespace=$USER ``` The output should again be: -```shell +```bash virtualmachine.kubevirt.io/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm patched ``` {{% alert title="Note" color="info" %}} -The process of starting and stopping VMs takes a bit of time. Make sure the VM is in status Stopped, before you start it again. +The process of starting and stopping VMs takes a bit of time. Make sure the VM is in status `Stopped` before you start it again. {{% /alert %}} -### Start/Stop with Virtctl +### Start/stop with `virtctl` The binary `virtctl` provides an easier way of interacting with KubeVirt VMs. Start your VM with: -```shell + +```bash virtctl start {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --namespace=$USER ``` The output should be: -```shell +```bash VM {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm was scheduled to start ``` If you check the state of your VM you'll see that it had the same effect as using the `kubectl` command: -```shell +```bash kubectl get vm --namespace=$USER ``` -Your VM is in the Running state: +Your VM is in `Running` state: -```shell +```bash NAME AGE STATUS READY {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm 11m Running True ``` -For stopping your VM simply use -```shell +To stop your VM, simply use: + +```bash virtctl stop {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --namespace=$USER ``` The output should be: -```shell +```bash VM {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm was scheduled to stop ``` -### Pause a VirtualMachine with Virtctl +### Pause a VirtualMachine with `virtctl` Pausing a VM is as simple as: -```shell + +```bash virtctl pause vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --namespace=$USER ``` -Will result in an error: -```shell +However, if you try to execute above command, it will result in an error: + +```bash Error pausing VirtualMachineInstance lab02-firstvm. VirtualMachine lab02-firstvm is not set to run ``` -Obviously we can not pause a **stopped** VM, so start the VM and try the pause command again: +Obviously we can not pause a stopped VM, so start the VM first and then try the pause command again: -```shell +```bash virtctl start {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --namespace=$USER ``` -Make sure the VM is in the started status before you pause it, by checking with the following command `kubectl get vm --namespace=$USER` +Make sure the VM shows it has started before you pause it: -```shell -virtctl pause vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --namespace=$USER +```bash +kubectl get vm --namespace=$USER ``` +Now pause it: + +```bash +virtctl pause vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --namespace=$USER +``` The output should be: -```shell +```bash VMI {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm was scheduled to pause ``` -Again verify the state of the VM +Again, verify the state of the VM: -```shell +```bash kubectl get vm --namespace=$USER ``` - Resuming a VM can be done with: -```shell + +```bash virtctl unpause vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --namespace=$USER ``` The output should be: -```shell +```bash VMI {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm was scheduled to unpause ``` -## Involved Components +## Involved components -When your VM is in a `running` state you may have noticed that there is an additional pod running. Make sure your VM is +When your VM is in a running state, you may have noticed that there is an additional Pod running. Make sure your VM is running and issue the following command: -```shell +```bash kubectl get pods --namespace=$USER ``` The output will be similar to: -```shell + +```bash NAME READY STATUS RESTARTS AGE $USER-webshell-885dbc579-lwhtd 2/2 Running 0 1d virt-launcher-{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm-mfxrs 3/3 Running 0 90s ``` -For each running VM there is a `virt-launcher` pod which is responsible to start the effective VM process in the container and observes the VM state. +For each running VM there is a `virt-launcher` Pod which is responsible to start the effective VM process in the container and observes the VM state. -Beside the existence of the `virt-launcher` pod a new custom resource `VirtualMachineInstance` is present. This resource is +Beside the existence of the `virt-launcher` Pod, a new custom resource `VirtualMachineInstance` is present. This resource is created under the hood by the `virt-controller` and will only be available as long as the VM is running. It represents a single running virtual machine instance. You may see your `VirtualMachineInstance` with the following command: -```shell +```bash kubectl get vmi --namespace=$USER ``` {{% alert title="Note" color="info" %}} -Remember that `vmi` is the shortname for `VirtualMachineInstance` just like `vm` for `VirtualMachine`. +Note that `vmi` is the shortname for `VirtualMachineInstance` just like `vm` for `VirtualMachine`. {{% /alert %}} The output will be similar to: -```shell + +```bash NAME AGE PHASE IP NODENAME READY {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm 3m59s Running 10.244.3.144 training-worker-0 True ``` -This indicates that our {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm is running on the kubernetes node `training-worker-0` +Above output also indicates that our {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm is running on Kubernetes node `training-worker-0`. {{% alert title="Note" color="info" %}} You may use `-o wide` to get more details about the VM. -```shell +```bash kubectl get vmi -o wide --namespace=$USER ``` -With `wide` you can see if your VM is Live-Migratable or is currently in a paused state. +With `wide` you can see if your VM is live-migratable or is currently in a paused state. The output of a paused VM will be: -```shell +```bash NAME AGE PHASE IP NODENAME READY LIVE-MIGRATABLE PAUSED {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm 7m52s Running 10.244.3.144 training-worker-0 False True True ``` {{% /alert %}} -## {{% task %}} (Optional) Under the hood: Explore virt-launcher Pod +## {{% task %}} (Optional) Under the hood: Explore the virt-launcher Pod -In this optional Lab we're going to explore the virt-launcher Pod, which we discovered in the previous lab. +In this optional lab we are going to explore the virt-launcher Pod, which we discovered in the previous task. -For every `VirtualMachineInstance` or `VMI` (running VM) one virt-launcher pod is created. The virt-launcher pod provides boundaries (cgoups, namespaces), the interface to the Kubernetes ecosystem and manages and monitors the lifecycle of the VMI. +For every `VirtualMachineInstance` or `VMI` (running VM), one virt-launcher Pod is created. The virt-launcher Pod provides boundaries (cgoups, namespaces), the interface to the Kubernetes ecosystem and manages and monitors the lifecycle of the VMI. -In its core, the virt-launcher pod runs a `libvirtd` instance, which manages the lifecycle of the VMI process. +In its core, the virt-launcher Pod runs a `libvirtd` instance, which manages the lifecycle of the VMI process. -With the following command, we can have a look at the pod manifest(replace the `` with the actual pod `kubectl get pods --namespace=$USER`): +With the following command, we can have a look at the Pod's manifest (replace the Pod name with the actual Pod's name from `kubectl get pods --namespace=$USER`): -```shell +```bash kubectl get pod virt-launcher-lab02-firstvm- -o yaml --namespace=$USER ``` -or simply use the describe command +Or simply use the describe command: -```shell +```bash kubectl describe pod virt-launcher-lab02-firstvm- --namespace=$USER ``` -Explore the pod yaml or use the describe command: +Explore the Pod definition or use the describe command: -* Labels -* ownerReference -* init containers and containers - * container-disk-binary - * volumecontainerdisk-init - * compute - * volumecontainerdisk - * guest-console-log -* resource limits abd requests -* volumes and mounts -* status +* `labels` +* `ownerReference` +* `initContainers` and `containers` + * `container-disk-binary` + * `volumecontainerdisk-init` + * `compute` + * `volumecontainerdisk` + * `guest-console-log` +* `limits` and `requests` +* `volumes` and `volumeMounts` +* `status` -You can even exec into the Pod and list the running processes, where you can find the running libvirt, qemu-kvm, processes +You can even exec into the Pod and list the running processes, where you can find the running libvirt and qemu-kvm processes: -```shell +```bash kubectl exec --stdin --tty --namespace=$USER virt-launcher-lab02-firstvm- -- /bin/bash ``` -```shell +```bash ps -ef ``` Press `CTRL + d` or type `exit` to exit the shell of the pod again. - {{% alert title="Note" color="info" %}} -This does not connect to a shell withing the `VirtualMachineInstance` but a shell into the pod which is managing the `VirtualMachineInstance`. +This does not connect to a shell within the `VirtualMachineInstance` but to the pod which is managing the `VirtualMachineInstance`. -Connecting into the shell of a `VirtualMachineInstance` will be explained in the next Lab. +Connecting to the shell of a `VirtualMachineInstance` will be explained in the next lab. {{% /alert %}} diff --git a/content/en/docs/getting-started-with-kubevirt/23_console.md b/content/en/docs/getting-started-with-kubevirt/23_console.md index 08078bb..9d8d9a9 100644 --- a/content/en/docs/getting-started-with-kubevirt/23_console.md +++ b/content/en/docs/getting-started-with-kubevirt/23_console.md @@ -8,19 +8,19 @@ description: > --- -## Console Access +## Console access -If your VM is running you can open a console to the VM using the `virtctl` tool. +If your VM is running, you can open a console on the VM using the `virtctl` tool. -First list your VMs to get the name of your VirtualMachine. +First, list your VMs to get the name of your VirtualMachine: -```shell +```bash kubectl get vm --namespace=$USER ``` The output should be: -```shell +```bash NAME AGE STATUS READY {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm 10m Running True ``` @@ -28,14 +28,15 @@ NAME AGE STATUS READY ### {{% task %}} Entering the console -Now enter the console with -```shell +Enter the console using: + +```bash virtctl console {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --namespace=$USER ``` -Congratulations. You successfully connected to your VMs console. The expected output is: +Congratulations, you successfully connected to your VMs console! The expected output is: -```shell +```bash Successfully connected to {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm console. The escape sequence is ^] login as 'cirros' user. default password: 'gocubsgo'. use 'sudo' for root. @@ -46,13 +47,14 @@ training-worker-0 login: You probably have to hit `Enter` to get to the login prompt. {{% /alert %}} -Now use the default credentials to login. +You can now use the default credentials to log in: * User: `cirros` * Password: `gocubsgo` -And execute a couple of commands -```shell +Try executing a couple of commands, such as: + +```bash whoami ping acend.ch ``` diff --git a/content/en/docs/getting-started-with-kubevirt/24_ssh.md b/content/en/docs/getting-started-with-kubevirt/24_ssh.md index a97fb50..8c193e4 100644 --- a/content/en/docs/getting-started-with-kubevirt/24_ssh.md +++ b/content/en/docs/getting-started-with-kubevirt/24_ssh.md @@ -7,35 +7,37 @@ description: > Accessing ports of the running VirtualMachine --- -In the previous section we accessed our VM console using the `virtctl` tool. In this section we will expose the SSH port +In the previous chapter, we accessed our VM console using the `virtctl` tool. In this section we will expose the SSH port of our VM and access it directly. {{% alert title="Note" color="info" %}} -This can be done for any port you want to use. For example if your virtual machine provides a webserver you can expose +This can be done for any port you want to use. For example, if your virtual machine provides a webserver, you can expose the webserver port. {{% /alert %}} -## Checking available Services +## Checking available Services resources -As you see with the following command creating the VM does not create any kubernetes service for it. -```shell +As you see with the following command, creating the VM does not create any Kubernetes Service for it. + +```bash kubectl get service --namespace=$USER ``` -In your namespace you should only see the service of your webshell: -```shell +In your Namespace you should only see the service of your webshell: + +```bash NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE $USER-webshell ClusterIP 10.43.248.212 3000/TCP 1d ``` -## Exposing port 22(ssh) on the kubernetes pod network +## Exposing the SSH port inside the Kubernetes cluster -To access the SSH port from the kubernetes default pod network we have to create a simple service. -For this we use a Service of type `ClusterIP`. +To access the SSH port from the Kubernetes default Pod network we have to create a simple Service resource. +For this, we use a Service of type `ClusterIP`. -The needed configuration for the kubernetes `Service` looks like this. Create a file `svc_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm-ssh.yaml` in the `{{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}` directory and use the following yaml configuration. +Create a file `svc_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm-ssh.yaml` in the `{{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}` directory and write the following Service configuration to it: ```yaml apiVersion: v1 @@ -53,20 +55,22 @@ spec: type: ClusterIP ``` -Apply the service with: -```shell +Apply the Service with: + +```bash kubectl apply -f {{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/svc_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm-ssh.yaml --namespace=$USER ``` You may now log in from your webshell terminal to the ssh port of the virtual machine using the following command (password: `gocubsgo`): -```shell + +```bash ssh cirros@{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm-ssh.$USER.svc.cluster.local ``` {{% alert title="Note" color="info" %}} We could also use the `virtctl` command to create a service for us. The command for the service above would be: -```shell +```bash virtctl expose vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --name={{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm-ssh --port=22 --namespace=$USER ``` @@ -74,56 +78,60 @@ We will use this approach in the next section. {{% /alert %}} -## Exposting SSH port for external use +## Exposing the SSH port for external use -Our exposed Service with type `ClusterIP` is only reachable from within the kubernetes cluster. On our kubernetes -cluster we can expose the port 22(ssh) as a `NodePort` service to access it from the outside of the cluster. +Our exposed Service with type `ClusterIP` is only reachable from within the Kubernetes cluster. On our Kubernetes +cluster, we can expose ports such as the one for SSH as a `NodePort` Service to access it from the outside of the cluster. This time we will use the `virtctl` command to expose the port as type `NodePort`. Us this command to create the Service: -```shell +```bash virtctl expose vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --name={{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm-ssh-np --port=22 --type=NodePort --namespace=$USER ``` -If you check your services you should now see both services for your VM: -```shell +You should now see both Services you just created for your VM: + +```bash kubectl get service --namespace=$USER ``` Which should produce a similar output: -```shell + +```bash NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm-ssh ClusterIP 10.43.89.29 22/TCP 17m {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-ssh-np NodePort 10.43.223.242 22:32664/TCP 49s $USER-webshell ClusterIP 10.43.248.212 3000/TCP 1d ``` -With this, our service is reachable from every node on the indicated port. You may check the PORT(S) column for the -assigned Port. In this example our assigned NodePort is `32664/TCP` which targets port 22 on our VM. +With this, our service is reachable from every node on the indicated port. You may check the `PORT(S)` column for the +assigned port. In this example, our assigned NodePort is `32664/TCP`, which then targets port 22 on our VM. + +To connect to the port indicated by the NodePort Service, we need to know the worker nodes' IP addresses. You can get them with: -To connect to the NodePort we actually need to know the IPs of our worker-nodes. You can directly get the IPs with: -```shell +```bash kubectl get nodes --selector=node-role.kubernetes.io/master!=true -o jsonpath={.items[*].status.addresses[?\(@.type==\"ExternalIP\"\)].address} --namespace=$USER ``` Which will produce a similar output to this: -```shell + +```bash 188.245.73.202 116.203.61.242 159.69.207.154 ``` {{% alert title="Note" color="info" %}} -You can also see the IPs of the nodes using: +You could also see the nodes' IP addresses nodes using: -```shell +```bash kubectl get nodes -o wide ``` {{% /alert %}} -Since the NodePort Service is accessible on any worker node you can simply pick one IP and issue the following command +Since the NodePort Service is accessible on any worker node, you can simply pick one IP address and issue the following command from within your webshell (make sure you replace the IP and the assigned NodPort to match your details): -```shell + +```bash ssh cirros@188.245.73.202 -p 32664 ``` -Using the NodePort is also possible from the outside. You should be able to use the same command from outside your -webshell (for example from your Computer). +You should be able to use the same command from outside your webshell, e.g., from your computer. diff --git a/content/en/docs/getting-started-with-kubevirt/25_vm-changes.md b/content/en/docs/getting-started-with-kubevirt/25_vm-changes.md index 9be3d74..ef070f7 100644 --- a/content/en/docs/getting-started-with-kubevirt/25_vm-changes.md +++ b/content/en/docs/getting-started-with-kubevirt/25_vm-changes.md @@ -7,67 +7,70 @@ description: > Changing files in your running VM. --- -In the previous section we gained access to the vm console. In this section we will use this access to make a change -to our running vm and observe what happens if we restart the VM. +In the previous chapter, we gained access to the VM's console. In this chapter, we will use this access to make a change +to our running VM and observe what happens if we restart the VM. -### {{% task %}} Create a File +### {{% task %}} Create a file Head over to your vm console with: -```shell + +```bash virtctl console {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --namespace=$USER ``` Login with the specified credentials and create a file: -```shell +```bash touch myfile ``` -And verify that the file really is present: +Verify that the file really is present. Check it with: -Check the file status with: -```shell +```bash stat myfile ``` -Exit the console and restart your vm with: +Exit the console and restart your VM with: -```shell +```bash virtctl restart {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --namespace=$USER ``` The output should be: -```shell +```bash VM {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm was scheduled to restart ``` Ask yourself: * After restarting, is the created file still present? -* If yes or no, why? +* And why do you think so? {{% details title="Task Hint" %}} Check yourself with entering the console again with: -```shell + +```bash virtctl console {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --namespace=$USER ``` Check the file status with: -```shell + +```bash stat myfile ``` The output fill be: -```shell + +```bash stat: can't stat 'myfile': No such file or directory ``` -This means that the file is gone. but why? +This means that the file is gone. But why? -Do you remember that we added a Container Disk to our VM manifest in the first section? A Container Disk is always +Do you remember that we added a container disk to our VM manifest in the first section? A container disk is always ephemeral and is therefore an easy way to provide a disk wich does not have to be persistent. We will have a closer look about storage in a later section. {{% /details %}} @@ -77,9 +80,9 @@ look about storage in a later section. {{% alert title="Cleanup resources" color="warning" %}} {{% param "end-of-lab-text" %}} -Stop your running VM with -```shell +Stop your running VM with: + +```bash virtctl stop {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --namespace=$USER ``` {{% /alert %}} - diff --git a/content/en/docs/getting-started-with-kubevirt/_index.md b/content/en/docs/getting-started-with-kubevirt/_index.md index 3ca4905..410f3a2 100644 --- a/content/en/docs/getting-started-with-kubevirt/_index.md +++ b/content/en/docs/getting-started-with-kubevirt/_index.md @@ -4,24 +4,24 @@ weight: 1 labfoldernumber: "02" sectionnumber: 2 description: > - Create and run your first Virtual Machine. + Create and run your first virtual machine --- -## Lab Goals +## Lab goals * Get familiar with the lab environment * Create your first VM using KubeVirt -* Start and Stop a VM using `virtctl` or `kubectl` -* Connect to the console of the VM +* Start and stop a VM using `virtctl` or `kubectl` +* Connect to the VM's console * Expose and access ports of your VM -* Changing a file inside of a VM and observe behaviour +* Change a file inside a VM and observe the behaviour ## Folder structure -This is your first lab where you will create and apply files to the kubernetes cluster. It may make sense to structure -your files according to the labs. Feel free to create a folder structure something like +This is your first lab where you will create and apply files to the Kubernetes cluster. It may make sense to structure +your files according to the labs. Feel free to create a folder structure something like this: ```text {{% param "labsfoldername" %}} @@ -31,19 +31,20 @@ your files according to the labs. Feel free to create a folder structure somethi [...] ``` -Make sure you're in the correct directory -```shell +Make sure you're in the correct directory: + +```bash cd {{% param "projecthome" %}} ``` -And initialize the lab structure by executing the following command +Initialize the directory structure by executing the following command: -```shell +```bash mkdir -p {{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{01..{{% param "maxlabnumber" %}}}/ ``` -And verify the structure: +Finally, verify the structure: -```shell +```bash tree {{% param "labsfoldername" %}} ```