DEV Community: Houssam Bourkane

Exposing Kubernetes Metrics: Adding Metrics Server to Your Local Cluster

Houssam Bourkane — Fri, 16 May 2025 14:02:03 +0000

This guide is the second part of the "Build a Kubernetes Lab with Vagrant & Ansible" series. In this article, we’ll add resource usage monitoring to your cluster by installing the Kubernetes Metrics Server.

Prerequisites
Step 1: Install Metrics Server
Step 2: Patch the Deployment
Step 3: Verify Installation
Step 4: Use the Metrics API
What's Next?
Useful links

📌 Prerequisite: Your Local Cluster Must Be Running

This article assumes you have already completed the first part of the series, where we created a local Kubernetes cluster using Vagrant and Ansible. If not, go back and follow Part 1: Build Your Local Kubernetes Cluster first.

Reminder: You should have exported your Kubernetes configuration locally with the following command:

vagrant ssh kubmaster -c "sudo cat /etc/kubernetes/admin.conf" > ~/kubeconfig-vagrant.yaml

Set this file as your config path:

export KUBECONFIG=~/kubeconfig-vagrant.yaml

Step 1: Install Metrics Server

We’ll use the official manifest from the Kubernetes SIG repository to install the Metrics Server:

KUBECONFIG=$KUBECONFIG kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml &> /dev/null

This deploys the metrics-server in the kube-system namespace. However, some environments (like local or self-hosted) require additional flags to work properly.

Step 2: Patch the Deployment

By default, the metrics server may not collect metrics correctly in local environments due to self-signed certificates or insecure Kubelet connections.

To fix that, apply the following patch to the deployment:

KUBECONFIG=$KUBECONFIG kubectl patch deployment metrics-server \
  -n kube-system \
  --type='json' \
  -p='[
    {
      "op": "add",
      "path": "/spec/template/spec/containers/0/command",
      "value": [
        "/metrics-server",
        "--kubelet-insecure-tls",
        "--kubelet-preferred-address-types=InternalIP"
      ]
    }
  ]' &> /dev/null

This tells the metrics server to:

Ignore TLS errors from kubelet (safe for local)
Prefer InternalIP when communicating with nodes

Step 3: Verify Installation

Once installed and patched, verify that everything is working:

KUBECONFIG=$KUBECONFIG kubectl get deployment metrics-server -n kube-system

If it shows READY and AVAILABLE, you're good to go!

Step 4: Use the Metrics API

You can now query live resource usage data:

View Node Metrics

KUBECONFIG=$KUBECONFIG kubectl top nodes

View Pod Metrics (All Namespaces)

KUBECONFIG=$KUBECONFIG kubectl top pods -A

You now have visibility into CPU and memory usage across your cluster.

What's Next?

With your metrics server up and running, you're ready to:

Explore Kubernetes Horizontal Pod Autoscaling (HPA)
Set up resource dashboards like Lens or K9s
Monitor cluster health trends locally

In the next part of the series, we’ll configure the NGINX Ingress Controller to manage external traffic to your services.

Resources

Kubernetes at Home: Set Up Your Own Cluster Using Vagrant & Ansible

Houssam Bourkane — Thu, 15 May 2025 23:30:03 +0000

TL;DR: Learn how to build a lightweight Kubernetes cluster on your local machine using Vagrant, Ansible, and VMware Fusion. Perfect for ARM-based Mac users looking to experiment with Kubernetes in a reproducible environment.

Why This Guide?

Setting up a Kubernetes cluster manually can be complex and time-consuming. But with the power of Vagrant for managing virtual machines and Ansible for automating setup tasks, you can spin up a local cluster with minimal effort and maximum reproducibility. This tutorial walks you through building a two-node cluster on macOS with ARM chips (e.g., M1/M2), but it's adaptable to other setups.

Prerequisites
Project Structure
Step 1: Configure Vagrant
Step 2: Configure Ansible
Step 3: Ansible Playbook for Kubernetes Setup
Step 4: Test and Deploy the Cluster
What's Next?
Useful links

Prerequisites

Before we start, ensure you have the following installed:

For macOS ARM users, refer to this special setup guide: Run Vagrant VMs in a M1/M2/M3 Apple Sillicon Chip

Project Structure

Create a project directory and replicate the following structure:

.
├── ansible
│   ├── ansible.cfg
│   ├── inventory.ini
│   └── k8s-cluster-setup.yml
└── Vagrantfile

Step 1: Configure Vagrant

Install the VMware Desktop plugin:

vagrant plugin install vagrant-vmware-desktop

Next, reserve two static private IPs from your LAN. Scan your local network using:

nmap -sn 192.168.1.0/24

Replace 192.168.1.0 with you LAN network IP

Update your Vagrantfile with something like this:

Vagrant.configure("2") do |config|
  config.vm.define "kubmaster" do |kub|
    kub.vm.box = "spox/ubuntu-arm"
    kub.vm.box_version = "1.0.0"
    kub.vm.hostname = 'kubmaster'
    kub.vm.provision "docker"
    kub.vm.network "public_network", ip: "192.168.1.101", bridge: "en0: Wifi"
    kub.vm.provider "vmware_desktop" do |v|
      v.allowlist_verified = true
      v.gui = false
      v.vmx["memsize"] = "4096"
      v.vmx["numvcpus"] = "2"
    end
  end

  config.vm.define "kubnode1" do |kubnode|
    kubnode.vm.box = "spox/ubuntu-arm"
    kubnode.vm.box_version = "1.0.0"
    kubnode.vm.hostname = 'kubnode1'
    kubnode.vm.provision "docker"
    kubnode.vm.network "public_network", ip: "192.168.1.102", bridge: "en0: Wifi"
    kubnode.vm.provider "vmware_desktop" do |v|
      v.allowlist_verified = true
      v.gui = false
      v.vmx["memsize"] = "4096"
      v.vmx["numvcpus"] = "2"
    end
  end
end

Replace the IPs with ones that match your LAN.

Now bring up the VMs:

vagrant up

Step 2: Configure Ansible

`ansible/inventory.ini`

[master]
kubmaster ansible_host=192.168.1.101 ansible_ssh_private_key_file=.vagrant/machines/kubmaster/vmware_desktop/private_key

[workers]
kubnode1 ansible_host=192.168.1.102 ansible_ssh_private_key_file=.vagrant/machines/kubnode1/vmware_desktop/private_key

[all:vars]
ansible_user=vagrant

Make sure to replace the IP addresses

`ansible/ansible.cfg`

[defaults]
inventory = inventory.ini
host_key_checking = False

Step 3: Ansible Playbook for Kubernetes Setup

`ansible/k8s-cluster-setup.yml`

This playbook performs the following:

Prepares all nodes: disables swap, installs required packages, configures kernel modules, adds K8s repositories, installs kubeadm, kubelet, and kubectl.
Initializes the master node and stores the cluster join command.
Sets up Flannel CNI for networking.
Joins worker nodes using the generated join command.

---
- name: Prepare Kubernetes Nodes
  hosts: all
  become: yes

  tasks:  

    - name: Disable swap (runtime)
      command: swapoff -a
      when: ansible_swaptotal_mb > 0

    - name: Comment out swap line in /etc/fstab
      lineinfile:
        path: /etc/fstab
        regexp: '^\s*([^#]\S*\s+\S+\s+swap\s+\S+)\s*$'
        line: '# \1'
        backrefs: yes

    - name: Apply mount changes
      command: mount -a

    - name: Stop AppArmor
      systemd:
        name: apparmor
        state: stopped
        enabled: no

    - name: Restart containerd
      systemd:
        name: containerd
        state: restarted

    - name: Configure sysctl for Kubernetes
      copy:
        dest: /etc/sysctl.d/kubernetes.conf
        content: |
          net.bridge.bridge-nf-call-ip6tables = 1
          net.bridge.bridge-nf-call-iptables = 1

    - name: Apply sysctl settings
      command: sysctl --system

    - name: Install transport and curl
      apt:
        name:
          - apt-transport-https
          - curl
        update_cache: yes
        state: present

    - name: Add Kubernetes APT key
      shell: |
        curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
      args:
        creates: /etc/apt/keyrings/kubernetes-apt-keyring.gpg

    - name: Add Kubernetes APT repository
      apt_repository:
        repo: "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.33/deb/ /"
        filename: "kubernetes"
        state: present

    - name: Install Kubernetes components
      apt:
        name:
          - kubelet
          - kubeadm
          - kubectl
          - kubernetes-cni
        update_cache: yes
        state: present

    - name: Enable kubelet service
      systemd:
        name: kubelet
        enabled: yes

- name: Initialize Kubernetes Master
  hosts: master
  become: yes
  vars:
    pod_cidr: "10.244.0.0/16"

  tasks:

    - name: Remove default containerd config
      file:
        path: /etc/containerd/config.toml
        state: absent

    - name: Restart containerd
      systemd:
        name: containerd
        state: restarted
        enabled: yes

    - name: Wait for containerd socket to be available
      wait_for:
        path: /run/containerd/containerd.sock
        state: present
        timeout: 20

    - name: Initialize Kubernetes control plane
      command: kubeadm init --apiserver-advertise-address={{ ansible_host }} --node-name {{ inventory_hostname }} --pod-network-cidr={{ pod_cidr }}
      register: kubeadm_output
      args:
        creates: /etc/kubernetes/admin.conf

    - name: Extract join command
      shell: |
        kubeadm token create --print-join-command
      register: join_command
      changed_when: false

    - name: Set join command fact
      set_fact:
        kube_join_command: "{{ join_command.stdout }}"

    - name: Create .kube directory for vagrant user
      become_user: vagrant
      file:
        path: /home/vagrant/.kube
        state: directory
        mode: 0755

    - name: Copy Kubernetes admin config to vagrant user
      copy:
        src: /etc/kubernetes/admin.conf
        dest: /home/vagrant/.kube/config
        remote_src: yes
        owner: vagrant
        group: vagrant
        mode: 0644

- name: Configure networking
  hosts: all
  become: yes

  tasks:

    - name: Ensure br_netfilter loads at boot
      copy:
        dest: /etc/modules-load.d/k8s.conf
        content: |
          br_netfilter

    - name: Load br_netfilter kernel module now
      command: modprobe br_netfilter

    - name: Configure sysctl for Kubernetes networking
      copy:
        dest: /etc/sysctl.d/k8s.conf
        content: |
          net.bridge.bridge-nf-call-iptables = 1
          net.bridge.bridge-nf-call-ip6tables = 1

    - name: Apply sysctl settings
      command: sysctl --system

- name: Configure flannel
  hosts: master
  become: yes

  tasks:

    - name: Apply Flannel CNI plugin
      become_user: vagrant
      command: kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
      environment:
        KUBECONFIG: /home/vagrant/.kube/config


- name: Join worker nodes to cluster
  hosts: workers
  become: yes
  vars:
    kube_join_command: "{{ hostvars['kubmaster']['kube_join_command'] }}"

  tasks:
    - name: Remove default containerd config
      file:
        path: /etc/containerd/config.toml
        state: absent

    - name: Restart containerd
      systemd:
        name: containerd
        state: restarted
        enabled: yes
    - name: Wait until the Kubernetes API server is reachable
      wait_for:
        host: "{{ hostvars['kubmaster']['ansible_host'] }}"
        port: 6443
        delay: 10
        timeout: 120
        state: started

    - name: Join the node to Kubernetes cluster
      command: "{{ kube_join_command }}"
      args:
        creates: /etc/kubernetes/kubelet.conf

Step 4: Test and Deploy the Cluster

Test Ansible SSH connectivity:

ansible all -m ping -i ansible/inventory.ini

Run the full cluster setup:

ansible-playbook -i ansible/inventory.ini ansible/k8s-cluster-setup.yml

Retrieve the kubeconfig file locally:

vagrant ssh kubmaster -c "sudo cat /etc/kubernetes/admin.conf" > ~/kubeconfig-vagrant.yaml

Test your cluster:

KUBECONFIG=~/kubeconfig-vagrant.yaml kubectl get nodes

You should see both the master and worker nodes in Ready status.

What's Next?

You now have a fully functioning local Kubernetes cluster on ARM-based hardware, with everything automated and reproducible. You can now:

Experiment with Helm charts
Try GitOps with ArgoCD
Deploy sample apps

Stay tuned for the next part of this series!

Useful Links

Vagrant: https://developer.hashicorp.com/vagrant/install
Ansible: https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html
VMware Fusion Tech Preview: https://knowledge.broadcom.com/external/article/315638/download-and-install-vmware-fusion.html
ARM-specific setup guide: https://dev.to/houssambourkane/run-vagrant-vms-in-a-m1m2m3-macos-chip-2p3l
Vagrant VMware utility: https://developer.hashicorp.com/vagrant/docs/providers/vmware/vagrant-vmware-utility

Run Vagrant VMs in a M1/M2/M3 Apple Sillicon Chip

Houssam Bourkane — Sun, 18 Feb 2024 00:01:02 +0000

If you're a Mac user equipped with an Apple Silicon chip (M1/M2/M3...) and facing challenges setting up a Vagrant infrastructure due to the lack of supported hypervisors, this tutorial is tailored for you. It will guide you through configuring Vagrant to run using VMware Fusion technology as a hypervisor. Simply follow the steps outlined, and should you encounter any issues along the way, feel free to reach out to me for assistance.

Step 1: Install Rosetta

/usr/sbin/softwareupdate --install-rosetta --agree-to-license

Step 2: Install VMware Fusion tech (you will have to create a VMware account)

https://customerconnect.vmware.com/downloads/get-download?downloadGroup=FUS-TP2023

You may also need to provide a license key, you can opt for the free one.

Step 3: Create a symbolic link

ln -s /Applications/VMWare\ Fusion\ Tech\ Preview.app /Applications/VMWare\ Fusion.app

Step 4: Install vagrant (on MacOS)

brew tap hashicorp/tap
brew install hashicorp/tap/hashicorp-vagrant

Step 5: Install vagrant vmware utility

https://releases.hashicorp.com/vagrant-vmware-utility/1.0.22/vagrant-vmware-utility_1.0.22_darwin_amd64.dmg

Step 6: Install vagrant plugin

vagrant plugin install vagrant-vmware-desktop

Step 7: Create a Vagrantfile

This configuration will create 2 VMs (master and slave)

mkdir vagrant-project
cd vagrant-project
touch Vagrantfile
cat << EOF > Vagrantfile
Vagrant.configure("2") do |config|
    config.vm.define "master" do |master|
        master.vm.box = "spox/ubuntu-arm" 
        master.vm.box_version = "1.0.0"
        master.vm.hostname = 'master'
        master.vm.provision "docker"

        master.vm.network :private_network, ip: "192.168.56.101"

        master.vm.provider "vmware_desktop" do |v|
            v.allowlist_verified = true
            v.gui = false
            v.vmx["memsize"] = "2048"
            v.vmx["numvcpus"] = "2"
      end
    end

    config.vm.define "slave" do |slave|
        slave.vm.box = "spox/ubuntu-arm" 
        slave.vm.box_version = "1.0.0"
        slave.vm.hostname = 'slave'
        slave.vm.provision "docker"

        slave.vm.network :private_network, ip: "192.168.56.102"

        slave.vm.provider "vmware_desktop" do |v|
            v.allowlist_verified = true
            v.gui = false
            v.vmx["memsize"] = "2048"
            v.vmx["numvcpus"] = "2"
      end
    end
  end
EOF

Note: gui parameter is mandatory

Step 8: Now you can run the vagrant program

vagrant up

Additional commands

Check the status of the VMs

vagrant status

Connect to the VMs

vagrant ssh <hostname>

In our example we can use either

vagrant ssh master

vagrant ssh slave

Stop the VMs

vagrant halt

Delete the VMs

vagrant destroy

How DNS works - Part 2

Houssam Bourkane — Sat, 06 Jan 2024 22:30:20 +0000

Records
- A record
- AAAA record
- CNAME record
- MX record
- NS record
Useful shell commands
- nslookup
- dig
- whois
- host
- ping
- traceroute or tracert
Useful links

Records

DNS records (aka zone files) are instructions that live in authoritative DNS servers and provide information about a domain including what IP address is associated with that domain and how to handle requests for that domain. These records consist of a series of text files written in what is known as DNS syntax. DNS syntax is just a string of characters used as commands that tell the DNS server what to do. All DNS records also have a ‘TTL’, which stands for time-to-live, and indicates how often a DNS server will refresh that record.

A record

The "A" stands for "address" and this is the most fundamental type of DNS record: it indicates the IP address of a given domain.

Here is an example of an A record:

example.com	record type	value	TTL
@	A	192.0.2.1	14400

The "@" symbol in this example indicates that this is a record for the root domain, and the "14400" value is the TTL (time to live), listed in seconds. The default TTL for A records is 14,400 seconds. This means that if an A record gets updated, it takes 240 minutes (14,400 seconds) to take effect.

AAAA record

Here is an example of an AAAA record:

example.com	record type:	value:	TTL
@	AAAA	2001:0db8:85a3:0000: 0000:8a2e:0370:7334	14400

CNAME record

A "canonical name" (CNAME) record points from an alias domain to a "canonical" domain. A CNAME record is used in lieu of an A record, when a domain or subdomain is an alias of another domain. All CNAME records must point to a domain, never to an IP address. Imagine a scavenger hunt where each clue points to another clue, and the final clue points to the treasure. A domain with a CNAME record is like a clue that can point you to another clue (another domain with a CNAME record) or to the treasure (a domain with an A record).

For example, suppose blog.example.com has a CNAME record with a value of "example.com" (without the "blog"). This means when a DNS server hits the DNS records for blog.example.com, it actually triggers another DNS lookup to example.com, returning example.com’s IP address via its A record. In this case we would say that example.com is the canonical name (or true name) of blog.example.com.

Oftentimes, when sites have subdomains such as blog.example.com or shop.example.com, those subdomains will have CNAME records that point to a root domain (example.com). This way if the IP address of the host changes, only the DNS A record for the root domain needs to be updated and all the CNAME records will follow along with whatever changes are made to the root.

Example of a CNAME record:

blog.example.com	record type:	value:	TTL
@	CNAME	is an alias of example.com	32600

In this example you can see that blog.example.com points to example.com, and assuming it is based on our example A record we know that it will eventually resolve to the IP address 192.0.2.1.

MX record

An MX (Mail Exchange) record in DNS guides email to a specific mail server. It specifies the route for email messages based on the Simple Mail Transfer Protocol (SMTP), the standard protocol for email. Similar to CNAME records, an MX record always points to a different domain.
Example of an MX record:

example.com	record type:	priority:	value:	TTL
@	MX	10	mailhost1.example.com	45000
@	MX	20	mailhost2.example.com	45000

The 'priority' numbers before the domains for these MX records indicate preference; the lower 'priority' value is preferred. The server will always try mailhost1 first because 10 is lower than 20. In the result of a message send failure, the server will default to mailhost2.

The email service could also configure this MX record so that both servers have equal priority and receive an equal amount of mail:

example.com	record type:	priority:	value:	TTL
@	MX	10	mailhost1.example.com	45000
@	MX	10	mailhost2.example.com	45000

This configuration enables the email provider to equally balance the load between the two servers.

NS record

NS stands for ‘nameserver,’ and the nameserver record indicates which DNS server is authoritative for that domain (i.e. which server contains the actual DNS records. Basically, NS records tell the Internet where to go to find out a domain's IP address. A domain often has multiple NS records which can indicate primary and secondary nameservers for that domain. Without properly configured NS records, users will be unable to load a website or application.

Here is an example of an NS record:

example.com	record type:	value:	TTL
@	NS	ns1.exampleserver.com	21600

Note that NS records can never point to a canonical name (CNAME) record
When NS records are updated, it may take several hours for the changes to be replicated throughout the DNS.

There are other DNS records that i didn't cover which will be included in the links below.

Useful shell commands

You may need to install network utils and packages before running the commands below.

nslookup

A network tool for querying DNS to obtain information about domain names and IP addresses. While it's older and less feature-rich than dig, it's available on many systems and provides basic DNS lookup capabilities.

nslookup - brings the interactive mode
> [domain] - query dns server for domain
> [ip_address] - reverse dns lookup
> set type=x - determines the type of DNS record that the DNS server will use to answer the query (x = DNS record type)
> set recursive - query other DNS servers if the default server does not have the information
> ls -a domain - list all canonical (true) names and aliases in domain
> ls -d domain - list all available records for domain.
> ls -t [type] domain - list all DNS TYPE records for domain
> exit - quit the interactive mode

Example

$ nslookup # Open nslookup interactive mode
> google.com
Server:     172.20.10.1
Address:    172.20.10.1#53

Non-authoritative answer:
Name:   google.com
Address: 172.217.20.174

> set type=AAAA # Set AAAA type for next queries (IPv6)
> google.com
Server:     172.20.10.1
Address:    172.20.10.1#53

Non-authoritative answer:
google.com  has AAAA address 2a00:1450:4007:80c::200e

dig

A versatile DNS (Domain Name System) tool for querying DNS information, providing detailed responses, and supporting various query types. It offers extensive options and is commonly used for troubleshooting and DNS analysis.

dig [domain] - query dns server for name
dig +short [domain] - short form of query output
dig [DNS_record] [domain] - query dns for given DNS record
dig -x [ip_address] - reverse dns lookup
dig @nameserver [domain] - query different name server

Example

$ dig @8.8.8.8 +short google.com
>> 216.58.214.174

whois

Checks information about ownership of a domain name
whois [domain] - querying databases that store the registered users or assignees, such as a domain name, an IP addresses

host

A simple command-line utility for DNS lookups, capable of translating domain names to IP addresses and vice versa. It provides basic DNS information in a straightforward format, suitable for quick queries and basic troubleshooting.

host [domain] - query dns server for domain
host [ip_address] - reverse dns lookup
host -t [DNS_record] [domain] - query dns for given DNS record

Example

$ host youtube.com
>> youtube.com has address 142.250.201.174
   youtube.com has IPv6 address 2a00:1450:4007:80e::200e
   youtube.com mail is handled by 0 smtp.google.com.

$ host -t A youtube.com
>> youtube.com has address 216.58.214.174

$ host -t NS youtube.com
>> youtube.com name server ns2.google.com.
   youtube.com name server ns4.google.com.
   youtube.com name server ns1.google.com.
   youtube.com name server ns3.google.com.

ping

A ping measures the latency of a connection for a target location. For demonstration purposes, I’ll run a ping test using 8.8.8.8, Google’s public DNS address.

Example

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=116 time=90.834 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=48.649 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=47.372 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 47.372/62.285/90.834/20.194 ms

traceroute or tracert

A traceroute traces a packet’s path, from the starting point to the destination.

Example

$ traceroute google.com
>> traceroute to google.com (142.250.178.142), 64 hops max, 52 byte packets
 1  172.20.10.1 (172.20.10.1)  6.461 ms  3.192 ms  2.537 ms
 2  * * *
 3  * 192.168.4.30 (192.168.4.30)  62.968 ms  34.551 ms
 4  192.168.255.19 (192.168.255.19)  43.909 ms  33.963 ms  40.175 ms
 5  194.149.185.144 (194.149.185.144)  24.554 ms  33.511 ms  39.744 ms
 6  194.149.173.32 (194.149.173.32)  39.917 ms  48.690 ms  32.094 ms
 7  * * 194.149.166.22 (194.149.166.22)  63.474 ms
 8  194.149.166.62 (194.149.166.62)  29.755 ms  38.763 ms  40.086 ms
 9  72.14.221.62 (72.14.221.62)  41.002 ms  41.752 ms
    72.14.211.26 (72.14.211.26)  47.443 ms
10  108.170.245.1 (108.170.245.1)  38.538 ms
    108.170.244.193 (108.170.244.193)  54.826 ms  36.586 ms
11  142.251.64.131 (142.251.64.131)  39.879 ms  34.754 ms
    142.251.64.129 (142.251.64.129)  38.454 ms
12  142.251.64.129 (142.251.64.129)  42.599 ms
    142.251.64.131 (142.251.64.131)  31.373 ms
    108.170.244.241 (108.170.244.241)  45.710 ms
13  par21s22-in-f14.1e100.net (142.250.178.142)  29.977 ms
    209.85.251.179 (209.85.251.179)  32.639 ms
    par21s22-in-f14.1e100.net (142.250.178.142)  38.448 ms

The packet has gone through 13 routers in order to reach the final destination

Useful links

How DNS works - Part 1

Houssam Bourkane — Wed, 27 Dec 2023 15:13:27 +0000

The Domain Name System (DNS) functions as the Internet's equivalent of a phonebook. When humans seek information online, they use domain names such as nytimes.com. However, web browsers communicate with Internet Protocol (IP) addresses. DNS plays a crucial role by translating domain names into corresponding IP addresses. The DNS lookup takes place seamlessly in the background for the web browser, requiring no user interaction beyond the initial request from the computer. But let's see how it works.

How DNS works in the background

When you type a domain name in the browser, the first thing that your DNS resolver look for before reaching DNS servers is checking if there is a match in your :

Browser DNS cache : for example in chrome you can check the DNS cache on chrome://net-internals/#dns.
Host file : located in /etc/hosts on Linux and macOS.

If no match is found, it will try to resolve the domain name through a DNS lookup, there are 4 DNS servers involved :

DNS Recursor: Imagine the DNS recursor as a helpful librarian in a library. When you ask this librarian (server) to find a specific book (IP address) for you, it gets queries from your computer (through applications like web browsers). The librarian, or DNS recursor, then makes additional requests to fulfill your request for information.

Root Nameserver: Think of the root server as the first guide in a library that helps you find the right section of books. It's like an index pointing to different racks of books. The root server is the starting point for translating human-readable names (like website addresses) into IP addresses.

TLD Nameserver: Picture the top-level domain (TLD) server as a specific section of books in a library. It's like a particular rack. This server is the next step in the search for a specific IP address, and it handles the last part of a website address (like "com" in example.com).

Authoritative Nameserver: Envision the authoritative nameserver as a dictionary in a library, where a specific name (hostname) can be translated into its definition (IP address). This nameserver is the final stop in the query. If it has the information you're looking for, it returns the IP address to the DNS recursor (the librarian) that initially made the request.

The 8 steps in a DNS lookup:

A user types ‘example.com’ into a web browser and the query travels into the Internet and is received by a DNS recursive resolver.
The resolver then queries a DNS root nameserver.
The root server then responds to the resolver with the address of a Top Level Domain (TLD) DNS server (such as .com or .net), which stores the information for its domains. When searching for example.com, our request is pointed toward the .com TLD.
The resolver then makes a request to the .com TLD.
The TLD server then responds with the IP address of the Authoritative nameserver, example.com.
Lastly, the recursive resolver sends a query to the Authoritative nameserver.
The IP address for example.com is then returned to the resolver from the Authoritative nameserver.
The DNS resolver then responds to the web browser with the IP address of the domain requested initially.

Once the 8 steps of the DNS lookup have returned the IP address for example.com, the browser is able to make the request for the web page:

The browser makes a HTTP request to the IP address.
The server at that IP returns the webpage to be rendered in the browser.

DEV Community: Houssam Bourkane

Exposing Kubernetes Metrics: Adding Metrics Server to Your Local Cluster

Table of Contents

📌 Prerequisite: Your Local Cluster Must Be Running

Step 1: Install Metrics Server

Step 2: Patch the Deployment

Step 3: Verify Installation

Step 4: Use the Metrics API

View Node Metrics

View Pod Metrics (All Namespaces)

What's Next?

Resources

Kubernetes at Home: Set Up Your Own Cluster Using Vagrant & Ansible

Why This Guide?

Table of Contents

Prerequisites

Project Structure

Step 1: Configure Vagrant

Step 2: Configure Ansible

ansible/inventory.ini

ansible/ansible.cfg

Step 3: Ansible Playbook for Kubernetes Setup

ansible/k8s-cluster-setup.yml

Step 4: Test and Deploy the Cluster

Test Ansible SSH connectivity:

Run the full cluster setup:

Retrieve the kubeconfig file locally:

Test your cluster:

What's Next?

Useful Links

Run Vagrant VMs in a M1/M2/M3 Apple Sillicon Chip

Step 1: Install Rosetta

Step 2: Install VMware Fusion tech (you will have to create a VMware account)

Step 3: Create a symbolic link

Step 4: Install vagrant (on MacOS)

Step 5: Install vagrant vmware utility

Step 6: Install vagrant plugin

Step 7: Create a Vagrantfile

Step 8: Now you can run the vagrant program

Additional commands

Check the status of the VMs

Connect to the VMs

Stop the VMs

Delete the VMs

How DNS works - Part 2

Records

A record

AAAA record

CNAME record

MX record

NS record

Useful shell commands

nslookup

Example

dig

Example

whois

host

Example

ping

Example

traceroute or tracert

Example

Useful links

How DNS works - Part 1

How DNS works in the background

The 8 steps in a DNS lookup:

`ansible/inventory.ini`

`ansible/ansible.cfg`

`ansible/k8s-cluster-setup.yml`