{"id":584,"date":"2023-12-14T19:38:27","date_gmt":"2023-12-14T19:38:27","guid":{"rendered":"http:\/\/virtuality.pt\/?p=584"},"modified":"2023-12-14T22:22:15","modified_gmt":"2023-12-14T22:22:15","slug":"deploying-a-kubernetes-cluster-with-kubeadm-on-top-of-vagrant-boxes-on-vmware-fusion","status":"publish","type":"post","link":"https:\/\/virtuality.pt\/?p=584","title":{"rendered":"Deploying a Kubernetes cluster with kubeadm on top of Vagrant Boxes on VMware Fusion"},"content":{"rendered":"\n

Yesterday, I utilized Vagrant to deploy three VMs on my laptop through VMware Fusion. Now, I’m gearing up to configure a Kubernetes cluster for testing and study purposes\u2014ideal for when I’m on the move or when my primary lab isn’t accessible.<\/p>\n\n\n\n

With these VMs in place, I’ll designate one as the master node and the remaining two as workers. Following standard Kubernetes setup procedures, I’ll initialize the master node, join the workers, and it will be ready to begin deploying and testing applications within this simulated cluster environment.<\/p>\n\n\n\n

Vagrant’s convenience lies in its ability to swiftly recreate these VMs and experiment with diverse configurations without impacting my primary setup. This flexibility proves invaluable for testing and learning experiences.<\/p>\n\n\n\n

Before starting the configuration it’s advised to always check the requisites:<\/p>\n\n\n\n

https:\/\/kubernetes.io\/docs\/setup\/production-environment\/tools\/kubeadm\/install-kubeadm\/<\/a><\/p>\n\n\n\n

Important disable swap on all nodes:<\/p>\n\n\n\n

## note that this is temporary and when you reboot the machine it will use swap again\n\nswapoff -a\n\n# in my case i know that the swap in \/etc\/fstab starts with \/swap.img\n\nsudo sed -i 's|\\(^\/swap\\)|#\\1|' \/etc\/fstab\n \n# i run this sed to add a # before the \/swap you can allways\n\nsudo vi \/etc\/fstab <\/code><\/pre>\n\n\n\n
and disable swap mount on boot<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
After validating the requisites, let’s deploy the container runtime with more detailed info in:<\/p>\n\n\n\n
https:\/\/kubernetes.io\/docs\/setup\/production-environment\/container-runtimes<\/a><\/p>\n\n\n\n
In my case, I will deploy containerd but there are more container runtimes you can choose check the link above if you don’t want to use containerd.<\/p>\n\n\n\n
ON ALL NODES !!!<\/strong><\/p>\n\n\n\n
Modules and filters:<\/p>\n\n\n\n
cat <<EOF | sudo tee \/etc\/modules-load.d\/k8s.conf\noverlay\nbr_netfilter\nEOF\n\nsudo modprobe overlay\nsudo modprobe br_netfilter\n\n# sysctl params required by setup, params persist across reboots\n\ncat <<EOF | sudo tee \/etc\/sysctl.d\/k8s.conf\nnet.bridge.bridge-nf-call-iptables  = 1\nnet.bridge.bridge-nf-call-ip6tables = 1\nnet.ipv4.ip_forward                 = 1\nEOF\n\n# Apply sysctl params without reboot\nsudo sysctl --system<\/code><\/pre>\n\n\n\n
check if modules are loaded:<\/p>\n\n\n\n
lsmod |grep br_netfilter<\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Let’s also check if the filters are set to 1<\/p>\n\n\n\n
sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.ipv4.ip_forward\n\n<\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Install containerd from docker Repo:<\/p>\n\n\n\n
https:\/\/docs.docker.com\/engine\/install\/ubuntu\/<\/a><\/p>\n\n\n\n
ON ALL NODES !!!<\/strong><\/p>\n\n\n\n
sudo apt-get update\nsudo apt-get install ca-certificates curl gnupg\nsudo install -m 0755 -d \/etc\/apt\/keyrings\ncurl -fsSL https:\/\/download.docker.com\/linux\/ubuntu\/gpg | sudo gpg --dearmor -o \/etc\/apt\/keyrings\/docker.gpg\nsudo chmod a+r \/etc\/apt\/keyrings\/docker.gpg\n\n# Add the repository to Apt sources:\necho \\\n  \"deb [arch=$(dpkg --print-architecture) signed-by=\/etc\/apt\/keyrings\/docker.gpg] https:\/\/download.docker.com\/linux\/ubuntu \\\n  $(. \/etc\/os-release && echo \"$VERSION_CODENAME\") stable\" | \\\n  sudo tee \/etc\/apt\/sources.list.d\/docker.list > \/dev\/null\nsudo apt-get update<\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
now install containerd (on all nodes :))<\/p>\n\n\n\n
sudo apt-get install containerd.io<\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Let’s check if it’s running and installed<\/p>\n\n\n\n
systemctl status containerd<\/code><\/pre>\n\n\n\n
Guess what? ON ALL NODES \ud83d\ude42<\/strong><\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
we are using Ubuntu and if you run:<\/p>\n\n\n\n
ps -p 1<\/code><\/pre>\n\n\n\n
You will see that Ubuntu is running Systemd<\/p>\n\n\n\n
When systemd<\/a> is chosen as the init system for a Linux distribution, the init process generates and consumes a root control group (cgroup<\/code>) and acts as a cgroup manager.<\/p>\n\n\n\n
systemd has a tight integration with cgroups and allocates a cgroup per systemd unit. As a result, if you use systemd<\/code> as the init system with the cgroupfs<\/code> driver, the system gets two different cgroup managers.<\/p>\n\n\n\n
Two cgroup managers result in two views of the available and in-use resources in the system. In some cases, nodes that are configured to use\u00a0cgroupfs<\/code>\u00a0for the kubelet and container runtime, but use\u00a0systemd<\/code>\u00a0for the rest of the processes become unstable under resource pressure.<\/p>\n\n\n\n
To play safe just run this on all nodes<\/p>\n\n\n\n
sudo containerd config default | sudo tee \/etc\/containerd\/config.toml\n\nsudo sudo sed -i 's\/SystemdCgroup \\= false\/SystemdCgroup \\= true\/g' \/etc\/containerd\/config.toml\n\nsudo systemctl restart containerd\n\nsudo systemctl status containerd<\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Ok at this time the container runtime is ready<\/p>\n\n\n\n
On ALL NODES \ud83d\ude42<\/strong><\/p>\n\n\n\n
sudo apt-get update\nsudo apt-get install -y apt-transport-https ca-certificates curl gpg<\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
curl -fsSL https:\/\/pkgs.k8s.io\/core:\/stable:\/v1.29\/deb\/Release.key | sudo gpg --dearmor -o \/etc\/apt\/keyrings\/kubernetes-apt-keyring.gpg\n\n#and \n\necho 'deb [signed-by=\/etc\/apt\/keyrings\/kubernetes-apt-keyring.gpg] https:\/\/pkgs.k8s.io\/core:\/stable:\/v1.29\/deb\/ \/' | sudo tee \/etc\/apt\/sources.list.d\/kubernetes.list<\/code><\/pre>\n\n\n\n
Install kubelet , kubeadm and kubectl<\/p>\n\n\n\n
sudo apt-get update\nsudo apt-get install -y kubelet kubeadm kubectl\nsudo apt-mark hold kubelet kubeadm kubectl<\/code><\/pre>\n\n\n\n
Now let’s start the cluster configuration:<\/strong><\/p>\n\n\n\n
##just on the Masternode\n\nsudo kubeadm init --pod-network-cidr=10.210.0.0\/16 --apiserver-advertise-address=192.168.0.235\n\n### in my case i wanted to use the IPS : 192.168.0.x for kubernetes  192.168.0.235 it's the kmaster01 ip aka master node they where defined on Vagrantfile on the past post<\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Note that is important to copy the kubeadm join text and save it on a file because we are going to use it later to join the nodes.<\/p>\n\n\n\n
Let’s run the instructions on the Screen<\/p>\n\n\n\n
mkdir -p $HOME\/.kube\nsudo cp -i \/etc\/kubernetes\/admin.conf $HOME\/.kube\/config\nsudo chown $(id -u):$(id -g) $HOME\/.kube\/config\n\n##i have run this with my user cpotrica<\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Now let’s setup the CNI for Pod networking there are lots of solutions here is a list:<\/p>\n\n\n\n
https:\/\/kubernetes.io\/docs\/concepts\/cluster-administration\/addons\/<\/a><\/p>\n\n\n\n
I’m going to use Antrea (I Wonder why \ud83d\ude42 )<\/p>\n\n\n\n
kubectl apply -f https:\/\/raw.githubusercontent.com\/vmware-tanzu\/antrea\/master\/build\/yamls\/antrea.yml\n\n<\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Let’s Join the Nodes:<\/p>\n\n\n\n
# @ knode01 and knode02\n\nkubeadm join 192.168.0.235:6443 --token m1q7ou.16exuspsnhi81cxk \\\n\n--discovery-token-ca-cert-hash sha256:d51ff7073131a64eaab1689f743a17484a0f9dc88d5f45a305af411b5d5256aa\n\n## note that this will be the information after you kubeadm init not mine.<\/code><\/pre>\n\n\n\n
knode01<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
knode02<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
On master node “kmaster01”<\/p>\n\n\n\n
kubectl get nodes <\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
you will see knode01 and knode02 as workers<\/p>\n\n\n\n
Let’s check on the master node the system pods running<\/p>\n\n\n\n
kubectl get pod -o wide -A<\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Now let’s create a small pod just to test<\/p>\n\n\n\n
kubectl run nginx --image=nginx\n\n#create the an nginx pod just for testing\n\n#check if its available and running\n\nkubectl get pod<\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
At this point, we have a running Kubernetes cluster on the Vagrant box we created before !!<\/p>\n\n\n\n
Shortly, I plan to delve deeper into this cluster setup. My upcoming posts will explore more advanced topics, such as implementing a load balancer, orchestrating deployments, and diving into other intricate functionalities.<\/p>\n\n\n\n
HF !!!<\/p>\n","protected":false},"excerpt":{"rendered":"
Yesterday, I utilized Vagrant to deploy three VMs on my laptop through VMware Fusion. Now, I’m gearing up to configure a Kubernetes cluster for testing and study purposes\u2014ideal for when I’m on the move or when my primary lab isn’t accessible. With these VMs in place, I’ll designate one as the master node and the remaining two as workers. Following standard Kubernetes setup procedures, I’ll initialize the master node, join the workers, and it will be ready to begin deploying and testing applications within this simulated cluster environment. Vagrant’s convenience lies in its ability to swiftly recreate these VMs and experiment with diverse configurations without impacting my primary setup. This flexibility proves invaluable for testing and learning experiences. Before starting Read More \/ Ler Mais<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-584","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/virtuality.pt\/index.php?rest_route=\/wp\/v2\/posts\/584","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/virtuality.pt\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/virtuality.pt\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/virtuality.pt\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/virtuality.pt\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=584"}],"version-history":[{"count":2,"href":"https:\/\/virtuality.pt\/index.php?rest_route=\/wp\/v2\/posts\/584\/revisions"}],"predecessor-version":[{"id":605,"href":"https:\/\/virtuality.pt\/index.php?rest_route=\/wp\/v2\/posts\/584\/revisions\/605"}],"wp:attachment":[{"href":"https:\/\/virtuality.pt\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=584"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/virtuality.pt\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=584"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/virtuality.pt\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=584"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}