Boots

Deep Dive into Boots

Boots is the DHCP and PXE boot server within the Tinkerbell stack. It plays a crucial role in the initial stages of the bare-metal provisioning process by enabling machines to boot over the network. Boots handles the network booting process, providing the necessary files and instructions to bare-metal machines to start their provisioning journey.

Boots Architecture Overview

Boots is designed to handle the following key tasks:

  1. DHCP (Dynamic Host Configuration Protocol): Assigns IP addresses to machines as they boot, allowing them to communicate over the network.
  2. PXE (Preboot Execution Environment): Provides the necessary boot files, such as iPXE scripts, to initiate the network boot process on bare-metal machines.
  3. Hardware Identification: Identifies machines based on their MAC addresses and provides the appropriate boot configuration tailored to each machine’s needs.

Core Components of Boots

  • Boots Server: The central server that listens for DHCP requests from machines and responds with the appropriate IP address and boot instructions.
  • iPXE Scripts: Scripts provided by Boots that tell the machine how to proceed with the boot process, such as loading an OS installer or a custom boot environment.
  • Hardware Profiles: Definitions that map specific machines (identified by their MAC addresses) to specific boot configurations and workflows.

Boots Boot Flow

Boots is typically the first interaction a bare-metal machine has with the Tinkerbell stack during the provisioning process. Here’s a detailed look at how Boots fits into the flow:

  1. Machine Power-On: A bare-metal machine powers on and starts the boot process. If configured to boot from the network, it sends out a DHCP request to discover a DHCP server.
  2. DHCP Request Handling: Boots receives the DHCP request and responds with:
  • An IP address for the machine.
  • Network configuration details such as the subnet mask, gateway, and DNS servers.
  • The location of the iPXE boot file or script.
  1. PXE Boot Process: After receiving the DHCP response, the machine attempts to boot from the network using PXE. It downloads the iPXE script provided by Boots.
  2. iPXE Execution: The iPXE script directs the machine to download additional boot files or kernels, or it might instruct the machine to load a specific operating system installer, such as OSIE (Operating System Installation Environment).
  3. Provisioning Kickoff: Once the machine has successfully booted via PXE and iPXE, it enters the provisioning process, where other Tinkerbell components, like Hegel and Tink, take over to complete the setup.

Working Examples with Boots

Let’s explore a practical example of how Boots is configured and used in a Tinkerbell provisioning environment.

1. Setting Up Boots

Boots is usually deployed within a Kubernetes environment as part of the Tinkerbell stack. It can be configured to listen for DHCP requests and serve PXE boot files.

Deploying Boots

Here’s an example of a Kubernetes deployment manifest for Boots:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: boots
  namespace: tink-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: boots
  template:
    metadata:
      labels:
        app: boots
    spec:
      containers:
      - name: boots
        image: quay.io/tinkerbell/boots:latest
        ports:
        - containerPort: 67
          name: dhcp
          protocol: UDP
        - containerPort: 4011
          name: proxy-dhcp
          protocol: UDP

This manifest deploys Boots in the tink-system namespace, exposing the necessary ports for DHCP (67/UDP) and PXE booting.

Service Definition

To expose Boots to the network, you’ll need a service definition:

apiVersion: v1
kind: Service
metadata:
  name: boots
  namespace: tink-system
spec:
  selector:
    app: boots
  ports:
  - protocol: UDP
    port: 67
    targetPort: 67
  - protocol: UDP
    port: 4011
    targetPort: 4011

This service ensures that DHCP and PXE boot traffic is correctly routed to the Boots deployment.

2. Hardware Registration and Mapping

Boots works in conjunction with Tink to identify machines and determine their boot configuration. You need to register hardware in Tink, specifying the MAC address and other identifying information.

Here’s an example of a hardware registration YAML:

id: "c2a3b8b2-4f3e-11ec-b2db-0242ac120002"
metadata:
  facility: "on-prem"
  instance:
    device_1: "52:54:00:82:47:9d"
    manufacturer: "Supermicro"
    plan: "t1.small.x86"
    state: "provisioning"
network:
  interfaces:
    - dhcp:
        arch: "x86_64"
        mac: "52:54:00:82:47:9d"
  netboot:
    allow_pxe: true
    osie: {
      commit: "",
      os: "ubuntu"
    }

In this configuration:

  • MAC Address: The MAC address 52:54:00:82:47:9d is used by Boots to identify the machine.
  • PXE Boot Enabled: The allow_pxe flag is set to true, allowing the machine to boot using PXE.
  • OSIE Configuration: The osie section indicates the desired operating system environment to be used during provisioning.

3. Handling DHCP Requests

When the machine sends a DHCP request, Boots responds based on the hardware registration:

  1. IP Address Assignment: Boots assigns an IP address to the machine and provides network configuration details.
  2. PXE Boot Instructions: Boots points the machine to an iPXE script or bootloader.

Example iPXE script content:

#!ipxe
dhcp
chain http://<tink-server>/ipxe?mac=${net0/mac}

In this script:

  • The machine is instructed to use DHCP to get its network configuration.
  • The chain command points the machine to a URL where it can download additional boot instructions, with the MAC address included as a parameter.

4. Customizing the Boot Process

Boots can serve different boot configurations based on the machine’s role or profile. For example, you might have a different iPXE script for control plane nodes versus worker nodes in a Kubernetes cluster.

Example of serving different iPXE scripts:

#!ipxe
set node_type ${http://hegel:50061/metadata/instance/node_type}

ifopen net0

if ${node_type} == "control-plane" {
    chain http://<tink-server>/control-plane.ipxe
} else if ${node_type} == "worker" {
    chain http://<tink-server>/worker.ipxe
} else {
    echo "Unknown node type: ${node_type}"
    exit 1
}

In this example:

  • The iPXE script checks the node type (retrieved from Hegel) and directs the machine to the appropriate boot configuration.

5. Monitoring and Troubleshooting Boots

You can monitor the Boots logs to troubleshoot issues related to DHCP and PXE booting. For example, if a machine fails to obtain an IP address or boot correctly, the Boots logs can provide insight into what went wrong.

kubectl logs -n tink-system deployment/boots

This command retrieves the logs for the Boots deployment, where you can see DHCP requests, PXE boot interactions, and any errors that occurred.

Advanced Boots Use Cases

  1. Multiple PXE Environments: Boots can be configured to serve different PXE environments based on various factors, such as the machine’s MAC address, hardware profile, or metadata. This allows for complex environments where different machines need to boot into different installers or configurations.
  2. Dynamic Boot Options: By integrating Boots with Hegel, you can dynamically adjust the boot process based on metadata. For example, you could serve a different OS installer based on the machine’s role or the environment it’s being provisioned into.
  3. PXE Boot Security: While PXE booting is inherently insecure (as it involves downloading boot files over the network without encryption), you can implement security measures like network segmentation, IP filtering, and the use of secure boot to mitigate risks.

Conclusion

Boots is a critical component of the Tinkerbell stack, enabling network booting for bare-metal machines. It handles the DHCP and PXE boot process, providing machines with the necessary instructions to start their provisioning journey. By configuring Boots correctly and integrating it with Tinkerbell’s other components like Hegel, you can automate and streamline the initial stages of bare-metal provisioning, ensuring that machines are booted and configured according to your infrastructure needs.