Commits on Feb 9, 2023

1. Restructure bare-metal module to use a worker submodule …

   * Add an internal `worker` module to the bare-metal module, to
   allow individual bare-metal machines to be defined and joined
   to an existing bare-metal cluster. This is similar to the "worker
   pools" modules for adding sets of nodes to cloud (AWS, GCP, Azure)
   clusters, but on metal, each piece of hardware is potentially
   unique
   
   New: Using the new `worker` module, a Kubernetes cluster can be defined
   without any `workers` (i.e. just a control-plane). Use the `worker`
   module to define each piece machine that should join the bare-metal
   cluster and customize it in detail. This style is quite flexible and
   suited for clusters with hardware that varies quite a bit.
   
   ```tf
   module "mercury" {
     source = "git::https://github.com/poseidon/typhoon//bare-metal/flatcar-linux/kubernetes?ref=v1.26.2"
   
     # bare-metal
     cluster_name            = "mercury"
     matchbox_http_endpoint  = "http://matchbox.example.com"
     os_channel              = "flatcar-stable"
     os_version              = "2345.3.1"
   
     # configuration
     k8s_domain_name    = "node1.example.com"
     ssh_authorized_key = "ssh-rsa AAAAB3Nz..."
   
     # machines
     controllers = [{
       name   = "node1"
       mac    = "52:54:00:a1:9c:ae"
       domain = "node1.example.com"
     }]
   }
   ```
   
   ```tf
   module "mercury-node1" {
     source = "git::https://github.com/poseidon/typhoon//bare-metal/flatcar-linux/kubernetes/worker?ref=v1.26.2"
   
     cluster_name = "mercury"
   
     # bare-metal
     matchbox_http_endpoint  = "http://matchbox.example.com"
     os_channel              = "flatcar-stable"
     os_version              = "2345.3.1"
   
     # configuration
     name               = "node2"
     mac                = "52:54:00:b2:2f:86"
     domain             = "node2.example.com"
     kubeconfig         = module.mercury.kubeconfig
     ssh_authorized_key = "ssh-rsa AAAAB3Nz..."
   
     # optional
     snippets       = []
     node_labels    = []
     node_tains     = []
     install_disk   = "/dev/vda"
     cached_install = false
   }
   ```
   
   For clusters with fairly similar hardware, you may continue to
   define `workers` directly within the cluster definition. This
   reduces some repetition, but is not quite as flexible.
   
   ```tf
   module "mercury" {
     source = "git::https://github.com/poseidon/typhoon//bare-metal/flatcar-linux/kubernetes?ref=v1.26.1"
   
     # bare-metal
     cluster_name            = "mercury"
     matchbox_http_endpoint  = "http://matchbox.example.com"
     os_channel              = "flatcar-stable"
     os_version              = "2345.3.1"
   
     # configuration
     k8s_domain_name    = "node1.example.com"
     ssh_authorized_key = "ssh-rsa AAAAB3Nz..."
   
     # machines
     controllers = [{
       name   = "node1"
       mac    = "52:54:00:a1:9c:ae"
       domain = "node1.example.com"
     }]
     workers = [
       {
         name   = "node2",
         mac    = "52:54:00:b2:2f:86"
         domain = "node2.example.com"
       },
       {
         name   = "node3",
         mac    = "52:54:00:c3:61:77"
         domain = "node3.example.com"
       }
     ]
   }
   ```
   
   Optional variables `snippets`, `worker_node_labels`, and
   `worker_node_taints` are still defined as a map from machine name
   to a list of snippets, labels, or taints respectively to allow some
   degree of per-machine customization. However, fields like
   `install_disk`, `kernel_args`, `cached_install` and future options
   will not be designed this way. Instead, if your machines vary it
   is recommended to use the new `worker` module to define each node

   

   dghubble committed Feb 9, 2023
   Configuration menu

   • View commit details
   • Copy full SHA for 1caea33
   • Browse repository at this point

   Copy the full SHA

   1caea33 View commit details

   Browse the repository at this point in the history