Minimal and free Kubernetes distribution with Terraform
Go to file
Dalton Hubble 1caea3388c 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
2023-02-09 08:29:28 -08:00
.github Change Dependabot pip watcher to check weekly 2021-05-05 11:34:57 -07:00
addons Update Nginx Ingress and monitoring addon components 2022-12-05 09:38:38 -08:00
aws Update Calico from v3.24.5 to v3.25.0 2023-01-24 08:29:08 -08:00
azure Update Calico from v3.24.5 to v3.25.0 2023-01-24 08:29:08 -08:00
bare-metal Restructure bare-metal module to use a worker submodule 2023-02-09 08:29:28 -08:00
digital-ocean Update Calico from v3.24.5 to v3.25.0 2023-01-24 08:29:08 -08:00
docs Update Kubernetes from v1.26.0 to v1.26.1 2023-01-19 08:27:56 -08:00
google-cloud Update Calico from v3.24.5 to v3.25.0 2023-01-24 08:29:08 -08:00
theme Migrate from internal hosting to GitHub pages 2022-07-27 21:56:42 -07:00
.gitignore Update Kubernetes from v1.25.1 to v1.25.2 2022-09-22 08:15:30 -07:00
CHANGES.md Restructure bare-metal module to use a worker submodule 2023-02-09 08:29:28 -08:00
CONTRIBUTING.md Fix typos in docs and CONTRIBUTING.md 2017-12-09 19:58:09 -08:00
DCO Add CONTRIBUTING.md and DCO agreement 2017-08-13 12:27:17 -07:00
LICENSE Rename project and organization 2017-08-14 19:24:04 -07:00
README.md Remove Twitter badge from README, we're on the Fediverse now 2023-01-19 08:43:49 -08:00
mkdocs.yml Migrate from internal hosting to GitHub pages 2022-07-27 21:56:42 -07:00
requirements.txt Bump mkdocs-material from 9.0.6 to 9.0.11 2023-02-07 09:12:43 -08:00

README.md

Typhoon Release Stars Sponsors Mastodon

Typhoon is a minimal and free Kubernetes distribution.

  • Minimal, stable base Kubernetes distribution
  • Declarative infrastructure and configuration
  • Free (freedom and cost) and privacy-respecting
  • Practical for labs, datacenters, and clouds

Typhoon distributes upstream Kubernetes, architectural conventions, and cluster addons, much like a GNU/Linux distribution provides the Linux kernel and userspace components.

Features

Modules

Typhoon provides a Terraform Module for each supported operating system and platform.

Typhoon is available for Fedora CoreOS.

Platform Operating System Terraform Module Status
AWS Fedora CoreOS aws/fedora-coreos/kubernetes stable
Azure Fedora CoreOS azure/fedora-coreos/kubernetes alpha
Bare-Metal Fedora CoreOS bare-metal/fedora-coreos/kubernetes stable
DigitalOcean Fedora CoreOS digital-ocean/fedora-coreos/kubernetes beta
Google Cloud Fedora CoreOS google-cloud/fedora-coreos/kubernetes stable
Platform Operating System Terraform Module Status
AWS Fedora CoreOS (ARM64) aws/fedora-coreos/kubernetes alpha

Typhoon is available for Flatcar Linux.

Platform Operating System Terraform Module Status
AWS Flatcar Linux aws/flatcar-linux/kubernetes stable
Azure Flatcar Linux azure/flatcar-linux/kubernetes alpha
Bare-Metal Flatcar Linux bare-metal/flatcar-linux/kubernetes stable
DigitalOcean Flatcar Linux digital-ocean/flatcar-linux/kubernetes beta
Google Cloud Flatcar Linux google-cloud/flatcar-linux/kubernetes stable
Platform Operating System Terraform Module Status
AWS Flatcar Linux (ARM64) aws/flatcar-linux/kubernetes alpha
Azure Flatcar Linux (ARM64) azure/flatcar-linux/kubernetes alpha

Documentation

Usage

Define a Kubernetes cluster by using the Terraform module for your chosen platform and operating system. Here's a minimal example:

module "yavin" {
  source = "git::https://github.com/poseidon/typhoon//google-cloud/fedora-coreos/kubernetes?ref=v1.26.1"

  # Google Cloud
  cluster_name  = "yavin"
  region        = "us-central1"
  dns_zone      = "example.com"
  dns_zone_name = "example-zone"

  # configuration
  ssh_authorized_key = "ssh-ed25519 AAAAB3Nz..."

  # optional
  worker_count = 2
  worker_preemptible = true
}

# Obtain cluster kubeconfig
resource "local_file" "kubeconfig-yavin" {
  content  = module.yavin.kubeconfig-admin
  filename = "/home/user/.kube/configs/yavin-config"
}

Initialize modules, plan the changes to be made, and apply the changes.

$ terraform init
$ terraform plan
Plan: 62 to add, 0 to change, 0 to destroy.
$ terraform apply
Apply complete! Resources: 62 added, 0 changed, 0 destroyed.

In 4-8 minutes (varies by platform), the cluster will be ready. This Google Cloud example creates a yavin.example.com DNS record to resolve to a network load balancer across controller nodes.

$ export KUBECONFIG=/home/user/.kube/configs/yavin-config
$ kubectl get nodes
NAME                                       ROLES    STATUS  AGE  VERSION
yavin-controller-0.c.example-com.internal  <none>   Ready   6m   v1.26.1
yavin-worker-jrbf.c.example-com.internal   <none>   Ready   5m   v1.26.1
yavin-worker-mzdm.c.example-com.internal   <none>   Ready   5m   v1.26.1

List the pods.

$ kubectl get pods --all-namespaces
NAMESPACE     NAME                                      READY  STATUS    RESTARTS  AGE
kube-system   calico-node-1cs8z                         2/2    Running   0         6m
kube-system   calico-node-d1l5b                         2/2    Running   0         6m
kube-system   calico-node-sp9ps                         2/2    Running   0         6m
kube-system   coredns-1187388186-zj5dl                  1/1    Running   0         6m
kube-system   coredns-1187388186-dkh3o                  1/1    Running   0         6m
kube-system   kube-apiserver-controller-0               1/1    Running   0         6m
kube-system   kube-controller-manager-controller-0      1/1    Running   0         6m
kube-system   kube-proxy-117v6                          1/1    Running   0         6m
kube-system   kube-proxy-9886n                          1/1    Running   0         6m
kube-system   kube-proxy-njn47                          1/1    Running   0         6m
kube-system   kube-scheduler-controller-0               1/1    Running   0         6m

Non-Goals

Typhoon is strict about minimalism, maturity, and scope. These are not in scope:

  • In-place Kubernetes Upgrades
  • Adding every possible option
  • Openstack or Mesos platforms

Help

Schedule a meeting via Github Sponsors to discuss your use case.

Motivation

Typhoon powers the author's cloud and colocation clusters. The project has evolved through operational experience and Kubernetes changes. Typhoon is shared under a free license to allow others to use the work freely and contribute to its upkeep.

Typhoon addresses real world needs, which you may share. It is honest about limitations or areas that aren't mature yet. It avoids buzzword bingo and hype. It does not aim to be the one-solution-fits-all distro. An ecosystem of Kubernetes distributions is healthy.

Social Contract

Typhoon is not a product, trial, or free-tier. Typhoon does not offer support, services, or charge money. And Typhoon is independent of operating system or platform vendors.

Typhoon clusters will contain only free components. Cluster components will not collect data on users without their permission.

Sponsors

Poseidon's Github Sponsors support the infrastructure and operational costs of providing Typhoon.





If you'd like your company here, please contact dghubble at psdn.io.