Every day more business environments are making a migration to Cloud or Kubernetes/Openshift and it is necessary to meet these requirements for demonstrations. Kubernetes is not a friendly environment to carry it in a notebook with medium capacity (8GB to 16GB of RAM) and less with a demo that requires certain resources. Deploy Kubernetes on kubeadm, containerd, metallb and weave This case is based on the Kubeadm-based deployment (https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) for Kubernetes deployment, using containerd (https://containerd.io/) as the container life cycle manager and to obtain a minimum network management we will use metallb (https://metallb.universe.tf/) that will allow us to emulate the power of the cloud providers balancers (as AWS Elastic Load Balancer) and Weave (https://www.weave.works/blog/weave-net-kubernetes-integration/) that allows us to manage container networks and integrate seamlessly with metallb. Finally, taking advantage of the infrastructure, we deploy the real-time resource manager K8dash (https://github.com/herbrandson/k8dash) that will allow us to track the status of the infrastructure and the applications that we deploy in it. Although the Ansible roles that we have used before (see https://github.com/aescanero/disasterproject) allow us to deploy the environment with ease and cleanliness, we will examine it to understand how the changes we will use in subsequent chapters (using k3s) have an important impact on the availability and performance of the deployed demo/development environment. First step: Install Containerd The first step in the installation is the dependencies that Kubernetes has and a very good reference about them is the documentation that Kelsey Hightower makes available to those who need to know Kubernetes thoroughly (https://github.com/kelseyhightower/kubernetes-the-hard-way), especially of all those who are interested in Kubernetes certifications such as CKA (https://www.cncf.io/certification/cka/). We start with a series of network packages We install the container life manager (a Containerd version that includes CRI and CNI) and take advantage of the packages that come with the Kubernetes network interfaces (CNI or Container Network Interface) The package includes the service for systemd so it is enough to start the service: Second Step: kubeadm and kubelet Now we download the executables of kubernetes, in the case of the first machine to configure it will be the “master” and we have to download the kubeadm binaries (the installer of kubernetes), kubelet (the agent that will connect with containerd on each machine. To know which one is the stable version of kubernetes we need to execute: And we download the binaries (in the master all and in the nodes only kubelet is necessary) […]
When we must choose between Docker or Podman? A lot of times we find that there are very few resources and we need an environment to perform a complete product demonstration at customer. In those cases we’ll need to simulate an environment in the simplest way possible and with minimal resources. For this we’ll adopt containers, but which is the best solution for those small environments? Docker Docker is the standard container environment, it is the most widespread and put together a set of powerful tools such as a client on the command line, an API server, a container lifecycle manager (containerd), and a container launcher (runc). Install docker is easy, since docker supplies a script that execute the process of prepare and configure the necessary requirements and repositories and finally installs and configures docker leaving the service ready to use. Podman Podman is a container environment that does not use a service and therefore does not have an API server, requests are made only from the command line, which has advantages and disadvantages that we will explain at the article. Install podman is easy in a Centos environment (yum install -y podman for Centos 7 and yum install -y container-tools for Centos 8) but you need some work in a Debian environment: Deploy with Ansible In our case we have used the Ansible roles developed at https://github.com/aescanero/disasterproject, to deploy two virtual machines, one with podman and the other with docker. In the case of using a Debian based distribution we must to install Ansible: We proceed to download the environment and configure Ansible: Edit the inventory.yml file which must have the following format: There are some global variables that hang from “vars:”, which are: network_name: Descriptive name of the libvirt network that we will use and that will also be the name of the interface that will be configured on the KVM host and that will serve as the gateway of the virtual machines network: the first three fields of the IPv4 address to conform a network with mask 255.255.255.0, virtual machines must have an IP of that range (minus .1 and .255) The format of each machine is defined by the following attributes: machine_name: Descriptive name of the virtual machine to be deployed, it will also be the hostname of the virtual machine. memory: Virtual machine memory in MB vcpus: Number of virtual CPUs in the virtual machine […]
If we want to raise virtual machines in a Linux environment that does not have a graphical environment, we can raise virtual machines using the command line with a XML template. This article explains how the deployment performed with Ansible-libvirt at KVM, Ansible and how to deploy a test environment works internally Install Qemu-KVM and Libvirt First: we must to install libvirt and Qemu-KVM. In Ubuntu / Debian is installed with: And in CentOS / Redhat with: To launch the service we must do: $ sudo systemctl enable libvirtd && sudo systemctl start libvirtd Configure a network template Libvirt provides us with a powerful tool for managing virtual machines called ‘virsh’, which we must use to be able to manage KVM virtual machines from the command line. For a virtual machine we mainly need three elements, the first is a network configuration that provides IP to virtual machines via DHCP. To do this libvirt needs XML template like the next template (which we will designate “net.xml”): Whose main elements are: NETWORK_NAME: Descriptive name that we are going to use to designate the network, for example, “test_net” or “production_net”. BRIDGE_NAME: Each network creates an interface on the host server that will serve as gateway of the input/output packets of that previous network to the outside. Here we assign a descriptive name that let as identify the interface. IP_HOST: The IP that such interface will have on the host server and that will be the gateway of the virtual machines. NETWORK_MASK: Depends on the network, usually for testing must be use a class C (255.255.255.0) BEGIN_DHCP_RANGE: To assign IPs to virtual machines using libvirt, there are an internal DHCP server (dnsmasq based), here we define the first IP of the range that we can serve to virtual machines. END_DHCP_RANGE: And here we define the last IP that virtual machines can obtain. Preparing the operating system image The second element is the virtual machine image, this image can be created or downloaded, the second is recommended to reduce the deployment time. An image source for virtual machines with KVM / libvirt is Vagrant (https://app.vagrantup.com/boxes/search?provider=libvirt), to obtain an image of the virtual machine that interests us, we must download from https://app.vagrantup.com/APP_NAME/boxes/APP_TAG/versions/APP_VERSION/providers/libvirt.box where APP_NAME is the name of the application we want to download (e.g. debian), APP_TAG is the distribution of this application (e.g. stretch64) and finally APP_VERSION is the version of the application (e.g. […]
We will always follow the philosophy “KISS” (keep it simple stupid!) “For the creation of local development environments with virtual machines, we will focus on the performance that KVM gives us and Ansible capabilities.