Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce the component system for managing pre-installed addons #1453

Merged
merged 1 commit into from
May 19, 2024

Conversation

dghubble
Copy link
Member

@dghubble dghubble commented May 18, 2024

  • Previously: Typhoon provisions clusters with kube-system components like CoreDNS, kube-proxy, and a chosen CNI provider (among flannel, Calico, or Cilium) pre-installed. This is convenient since clusters come with "batteries included". But it also means upgrading these components is generally done in lock-step, by upgrading to a new Typhoon / Kubernetes release
  • It can be valuable to manage these components with a separate plan/apply process or through automations and deploy systems. For example, this allows managing CoreDNS separately from the cluster's lifecycle.
  • These "components" will continue to be pre-installed by default, but a new components variable allows them to be disabled and managed as "addons", components you apply after cluster creation and manage on a rolling basis. For some of these, we may provide Terraform modules to aide in managing these components.
module "cluster" {
  ...

  # defaults shown
  components = {
    enable = true
    coredns = {
      enable = true
    }
    kube_proxy = {
      enable = true
    }
    # Only the CNI set in var.networking will be installed
    flannel = {
      enable = true
    }
    calico = {
      enable = true
    }
    cilium = {
      enable = true
    }
  }
}

An earlier variable install_container_networking = true/false has been removed, since it can now be achieved with this more extensible and general components mechanism by setting the chosen networking provider enable field to false.

* Previously: Typhoon provisions clusters with kube-system components
like CoreDNS, kube-proxy, and a chosen CNI provider (among flannel,
Calico, or Cilium) pre-installed. This is convenient since clusters
come with "batteries included". But it also means upgrading these
components is generally done in lock-step, by upgrading to a new
Typhoon / Kubernetes release
* It can be valuable to manage these components with a separate
plan/apply process or through automations and deploy systems. For
example, this allows managing CoreDNS separately from the cluster's
lifecycle.
* These "components" will continue to be pre-installed by default,
but a new `components` variable allows them to be disabled and
managed as "addons", components you apply after cluster creation
and manage on a rolling basis. For some of these, we may provide
Terraform modules to aide in managing these components.

```
module "cluster" {
  # defaults
  components = {
    enable = true
    coredns = {
      enable = true
    }
    kube_proxy = {
      enable = true
    }
    # Only the CNI set in var.networking will be installed
    flannel = {
      enable = true
    }
    calico = {
      enable = true
    }
    cilium = {
      enable = true
    }
  }
}
```

An earlier variable `install_container_networking = true/false` has
been removed, since it can now be achieved with this more extensible
and general components mechanism by setting the chosen networking
provider enable field to false.
@dghubble dghubble merged commit b3c384f into main May 19, 2024
@dghubble dghubble deleted the components branch May 19, 2024 23:35
@kalmufti
Copy link

So with this new system, would this be the proper way to skip cilium and manage it on my own?

module "cluster" {
  ...
  networking  = "cilium"

  components = {
    cilium = {
      enable = false
    }
  }

or just set networking = "none"

@dghubble
Copy link
Member Author

Yes, that example looks right. Typhoon does still need to know which CNI provider you've chosen in order to allow the right firewall / security policies between nodes.

Setting networking to none should cause a validation error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants