Emulation is where the hypervisor emulates a certain piece of hardware that it presents to the guest VM, regardless of what the actual physical hardware is.

• Advantages: portable, widest hardware compatibility.
• Disadvantages: Worst user experience and performance.

Full virtualization is that the virtual machine simulates hardware to allow an unmodified guest OS to be run in isolation. each guest OS is unaware of each other.

• Advantages: truly isolated, much security.
• Disadvantages:

Paravirtualization does not need to simulate the hardware for the virtual machines. The hypervisor is installed on a physical server and a guest OS is installed on hypervisor.

• Advantages: good image portability, access hardware directly
• Disadvantages: complex driver architecture, compatibility is limited by the vendors

Notes: Xen could be both Full or Para depends on the hypervisor whether modified. Operating system-level virtualization also knowns as “containerization”.

Bare-metal does not require admins to install a server OS first which means the hypervisor has direct access to hardware resources.

• Advantages: high performance, scalability, and stability
• Disadvantages: hardware support more limited
• Examples: VMware ESX AND ESXi, Microsoft Hyper-V, Citrix Systems XenServer

Hosted hypervisor requires admins to install an OS on hardware first.

• Advantages: better hardware compatibility
• Disadvantages: worse performance than Bare-metal
• Examples: VMware Workstation, VirtualBox

1. A “disk” for the guest system(Logical volume)
2. An operating system kernel for the hypervisor to run(Ubuntu installer)
3. A configuration file(vm01.cfg)

VM image is a reusable resource that we use to create virtual instances.

• Dom0 is a management interface that typically runs a Linux OS and works with the hypervisor and its guest domains. It started as soon as a Xen host is booted. It has direct access to the physical hardware and has native drivers for it. It then presents simplified abstract drivers to DomU guests.
• DomU is regular guests run in unprivileged domains.

There are three ways to provide networking to guests. Bridged networking, Routing, NAT. Bridged networking is the default.

The Backend network driver usually resides in the backend domain(typically Dom0), and the Frontend network driver resides int he frontend domain(typically DomU). They create a similar pair of devices for each virtual network interface.

Bridged is the default Xen configuration that uses bridging within the backend domain (typically domain 0) to allow all domains to appear on the network as individual hosts. The backend virtual network devices are added to this bridge along with a physical Ethernet device to provide connectivity off the host

In a routed network configuration a point-to-point link is created between the backend domain (typically domain 0) and each domU virtual network interface. Because routes are created dynamically as domains are created it is usually necessary for each guest network interface to have a known static IP address.

The volume provides additional disk storage for guests(DomU), especially to create storage options not linked to a particular guest instance.

1. Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.
2. The infrastructure Terraform can manage includes low-level components such as compute instances, storage, and networking, as well as high-level components such as DNS entries, SaaS features, etc.
3. Terraform generates an execution plan describing what it will do to reach the desired state, and then executes it to build the described infrastructure. As the configuration changes, Terraform is able to determine what changed and create incremental execution plans which can be applied.

VMs allowing physical machines to run multiple operating systems and multiple isolated apps, it uses the physical machine's underlying infrastructure through hypervisor that imitates dedicated hardware.

Containers allows developers to minimize the resources they need by only packaging an application and its exact dependencies. Instead of running on a hypervisor the containers run on top of a container runtime environment which is installed on an operating system. While VMs use virtualized hardware, containers use underlying resources of the host operating system.

A container image is an unchangeable, static file that includes executable code so it can run an isolated process on information technology (IT) infrastructure. The image is comprised of system libraries, system tools, and other platforms settings

• FROM — this initializes a new build stage and sets the Base Image for subsequent instructions. As such, a valid Dockerfile must start with FROM instruction.
• RUN — will execute any commands in a new layer on top of the current image and commit the results. The resulting committed image will be used for the next step in the Dockerfile.
• ENV — sets the environment variable to the value . This value will be in the environment for all subsequent instructions in the build stage and can be replaced inline in many as well.
• EXPOSE — informs Docker that the container listens on the specified network ports at runtime. You can specify whether the port listens on TCP or UDP, and the default is TCP if the protocol is not specified. This makes it possible for the host and the outside world to access the isolated Docker Container
• VOLUME — creates a mount point with the specified name and marks it as holding externally mounted volumes from the native host or other containers.
• WORKDIR - create the app directory for inside the Docker image
• COPY - copy from somewhere into the root of the somewhere
• CMD - define the command to run the app

Notes: Docker RUN vs CMD vs ENTRYPOINT

• RUN executes command(s) in a new layer and creates a new image. E.g., it is often used for installing software packages.
• CMD sets default command and/or parameters, which can be overwritten from command line when docker container runs.
• ENTRYPOINT configures a container that will run as an executable.

The Registry is a stateless, highly scalable server-side application that stores and lets you distribute Docker images. Docker Hub repositories allow you to share container images with your team, customers, or the Docker community at large.

Volumes are the preferred mechanism for persisting data generated by and used by Docker containers. While bind mounts are dependent on the directory structure of the host machine, volumes are completely managed by Docker. Volumes have several advantages over bind mounts:

• Volumes are easier to back up or migrate than bind mounts.
• You can manage volumes using Docker CLI commands or the Docker API.
• Volumes work on both Linux and Windows containers.
• Volumes can be more safely shared among multiple containers.
• Volume drivers let you store volumes on remote hosts or cloud providers, to encrypt the contents of * * * * volumes, or to add other functionality.
• New volumes can have their content pre-populated by a container.

In addition, volumes are often a better choice than persisting data in a container’s writable layer, because a volume does not increase the size of the containers using it, and the volume’s contents exist outside the lifecycle of a given container.

• User-defined bridge networks are best when you need multiple containers to communicate on the same Docker host.
• Host networks are best when the network stack should not be isolated from the Docker host, but you want other aspects of the container to be isolated.
• Overlay networks are best when you need containers running on different Docker hosts to communicate, or when multiple applications work together using swarm services.
• Macvlan networks are best when you are migrating from a VM setup or need your containers to look like physical hosts on your network, each with a unique MAC address.
• Third-party network plugins allow you to integrate Docker with specialized network stacks.

Differences between user-defined bridges and the default bridge:

• User-defined bridges provide better isolation and interoperability between containerized applications.
• User-defined bridges provide automatic DNS resolution between containers.
• Containers can be attached and detached from user-defined networks on the fly.

Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration.

Docker Swarm is a system that lets us manage containers across a collection of Docker hosts. Docker Swarm is native clustering for Docker. It turns a pool of Docker hosts into a single virtual Docker host. Swarm has a simple architecture. It clusters together multiple Docker hosts and serves the standard Docker API on top of that cluster.

A swarm is made up of manager and worker nodes. Manager do the dispatching and organizing of work on the swarm. Each unit of work is called a task. Managers also handle all the cluster management functions that keep the swarm healthy and active. You can have many manager nodes, if there is more than one then the manager node will conduct an election for a leader.

Worker nodes run the tasks dispatched from manager nodes. Out of the box, every node, managers and workers, will run tasks. You can instead configure a swarm manager node to only perform management activities and not run tasks.

As a task is a pretty atomic unit swarms use a bigger abstraction, called a service as a building block. Services defined which tasks are executed on your nodes. Each service consists of a container image and a series of commands to execute inside one or more containers on the nodes. You can run services in a number of modes

• Master Components

  • kube-apiserver
  • etcd
  • kube-scheduler
  • kube-controller-manager
  • cloud-controller-manager

• Node Components

  • kubelet
  • kube-proxy
  • Container Runtime

• Addons

  • DNS
  • Web UI(Dashboard)
  • Container Resource Monitoring
  • Cluster-level Logging

A Pod is the basic execution unit of a Kubernetes application–the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your Cluster.

A Pod encapsulates an application’s container (or, in some cases, multiple containers), storage resources, a unique network IP, and options that govern how the container(s) should run. A Pod represents a unit of deployment: a single instance of an application in Kubernetes, which might consist of either a single container or a small number of containers that are tightly coupled and that share resources.

• Pods that run a single container
• Pods that run multiple containers that need to work together

Templates

apiVersion: v1
kind: Pod
metadata:
  name: kuard
spec:
  volumes:
  - name: "kuard-data"
    hostPath:
      path: "/var/lib/kuard"
  containers:
    - image: gcr.io/kuar-demo/kuard-amd64:1
      name: kuard
      volumeMounts:
        - mountPath: "/data"
        name: "kuard-data"
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP