DEV Community

Korakrit Chariyasathian
Korakrit Chariyasathian

Posted on

Hyper-V Configuration Guide for Kubernetes and Supporting Network Services

#architecture #kubernetes #microsoft #networking

This document describes a baseline, production-ready approach for configuring Hyper-V Virtual Machines used with Kubernetes (Control Plane / Worker Nodes) and an FRR (Free Range Routing) VM. The focus is on correct network adapter design, virtual switch usage, and security-related settings to ensure long-term stability and predictable behavior.

Architecture Overview

  • The Hyper-V host provides at least two virtual switches:

    • vEthernet-External: Used for Internet access
    • K8S-Internal: Used for intra-cluster (node-to-node) communication

  • Every Kubernetes node (Control Plane and Worker):

    • Has two NICs
    • External NIC → Internet access
    • Internal NIC → Cluster communication

  • The FRR VM acts strictly as an L3 router

Baseline: Create a New Virtual Machine (Applies to All VMs)

1. Create New Virtual Machine

  1. Open Hyper-V Manager → New → Virtual Machine
  2. Specify Name:
    • Control Plane: is-kube-control
    • Worker: is-kube-worker-XX
    • FRR: is-frrouting-vm
  3. Specify Generation:
    • Generation 2 (Required)
      • UEFI-based firmware
      • Secure Boot support
      • Required for modern Linux kernels (Kubernetes / FRR)

2. Assign Memory

  • Disable Dynamic Memory (recommended)
  • Startup Memory:
    • Control Plane / Worker: ≥ 4 GB
    • FRR VM: ≥ 2 GB

Rationale:

  • Kubernetes does not behave well with Dynamic Memory
  • Avoids latency, eviction, and scheduling edge cases

3. Configure Networking (Initial Wizard Step)

  • Assign the first NIC to:
    • vEthernet-External
  • The second NIC will be added after VM creation

4. Connect Virtual Hard Disk

  • Create a new virtual hard disk
  • Format: VHDX (Dynamic)
  • Recommended size:
    • Control Plane / Worker: ≥ 40 GB
    • FRR VM: ≥ 20 GB

5. Installation Options

  • Select Install an operating system later
  • Mount the ISO after VM creation

Operating System Baseline

  • OS: Ubuntu 24.04 LTS (Server)
  • Installation Mode: Minimal Install
  • Initial State:
    • No additional packages installed
    • Docker / containerd / Kubernetes components not installed yet
  • Enabled services:
    • SSH only (for initial access and automation)

This approach minimizes the attack surface and ensures a clean baseline before installing Kubernetes or FRR components.

Netplan Baseline Configuration

Static network configuration is used to ensure deterministic routing and traffic flow.

Example: /etc/netplan/50-cloud-init.yaml

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses:
        - 192.168.1.10/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

    eth1:
      dhcp4: false
      addresses:
        - 10.10.0.10/24
Enter fullscreen mode Exit fullscreen mode
  • eth0:
    • External NIC (vEthernet-External)
    • Default route and Internet access
  • eth1:
    • Internal NIC (K8S-Internal)
    • Node-to-node / Pod network traffic

Note: No default route is configured on the internal NIC to avoid asymmetric routing issues.

Post-Creation VM Configuration (Before First Boot)

1. Firmware / Secure Boot

  • VM Settings → Firmware
  • Secure Boot:
    • Enabled
    • Template: Microsoft UEFI Certificate Authority

Compatible with Ubuntu, Debian, RHEL, Rocky Linux, and FRR-based systems.

2. Processor / Hardware Acceleration

  • Virtual processors: ≥ 2 vCPU
  • Nested Virtualization:
    • Disable unless explicitly required (e.g., KinD, KVM-in-VM)

Default Hyper-V processor settings are sufficient. No additional hardware acceleration tuning is required.

3. Memory Settings

  • Dynamic Memory: Disabled
  • Leave advanced memory mapping options at default values

4. Network Adapters – Advanced Features

External NIC (vEthernet-External)

  • Enable:
    • MAC Address Spoofing (Kubernetes nodes only)
    • VRSS
    • RSC
  • Disable:
    • DHCP Guard
    • Router Guard

Internal NIC (K8S-Internal)

  • Add a second Network Adapter
  • Switch: K8S-Internal
  • MAC Address Spoofing:
    • Kubernetes Nodes: Recommended: On
    • FRR VM: Off

5. VLAN Configuration

  • VLAN Mode: Untagged (Default)

6. Integration Services

Keep the default integration services enabled:

  • Heartbeat
  • Key-Value Pair Exchange
  • Shutdown
  • Time Synchronization

Optional:

  • Guest Service Interface (only if file copy from host is required)

No integration services need to be disabled for Kubernetes or FRR.

Part 1: Control Plane Node Configuration

Network Adapter Layout

NIC Hyper-V Switch Purpose
NIC-1 vEthernet-External Internet, image pulls, external APIs
NIC-2 K8S-Internal Pod-to-Pod and Node-to-Node traffic

MAC Address Spoofing

  • External NIC: On (Required)
  • Internal NIC:
    • Overlay CNI (Flannel VXLAN, Calico VXLAN): Optional
    • Non-overlay / L2 CNI: On

Best practice: Enable MAC Address Spoofing on both NICs.

Resource Recommendation

  • CPU: ≥ 2 vCPU
  • Memory: ≥ 4 GB
  • Disk: ≥ 40 GB

Part 2: Worker Node Configuration

Network Adapter Layout

NIC Hyper-V Switch Purpose
NIC-1 vEthernet-External Internet and image pulls
NIC-2 K8S-Internal East–West cluster traffic

MAC Address Spoofing

  • External NIC: On (Mandatory)
  • Internal NIC: Depends on CNI

Recommended: Enable on both NICs to avoid future edge cases.

Resource Recommendation

  • CPU: ≥ 2 vCPU (scale with workload)
  • Memory: 4–8 GB
  • Disk: ≥ 40 GB

Part 3: FRR VM Configuration

Network Adapter Layout

NIC Hyper-V Switch Purpose
NIC-1 vEthernet-External Upstream / Internet routing
NIC-2 K8S-Internal Internal routing / peering

MAC Address Spoofing

  • All NICs: Off

Rationale:

  • FRR operates strictly at Layer 3
  • Always uses its own interface MAC addresses
  • No container, bridge, or L2 forwarding traffic

Resource Recommendation

  • CPU: ≥ 2 vCPU
  • Memory: ≥ 2 GB
  • Disk: ≥ 20 GB

Summary of Best Practices

  • Kubernetes Nodes:

    • Enable MAC Address Spoofing at least on the External NIC
    • Prefer enabling it on both NICs

  • FRR VM:

    • MAC Address Spoofing is not required

  • Clearly separate External and Internal NIC roles

  • Overlay CNIs reduce Layer-2 dependencies but do not eliminate the need for spoofing on egress NICs

Additional Notes

  • Re-evaluate MAC Address Spoofing if the CNI or network design changes
  • Enabling MAC Address Spoofing has no meaningful performance impact on Hyper-V

Author's Note

This guide was written primarily as a set of personal design and implementation notes. Its purpose is to document not only what was configured, but why specific decisions were made, in order to preserve architectural intent and reduce ambiguity during future maintenance, scaling, or redesign efforts.

The content of this document was drafted with the assistance of an AI system and subsequently reviewed and curated by the author.

Top comments (0)