b3c384fbc0
* 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.
4.0 KiB
Components
Typhoon's component model allows for managing cluster components independent from the cluster's lifecycle, upgrading in a rolling or automated fashion, or customizing components in advanced ways.
Typhoon clusters install core components like CoreDNS, kube-proxy, and a chosen CNI provider (flannel, calico, or cilium) by default. Since v1.30.1, pre-installed components are optional. Other "addon" components like Nginx Ingress, Prometheus, or Grafana may be optionally applied though the component model (after cluster creation).
Components
Pre-installed by default:
- CoreDNS
- kube-proxy
- CNI provider (set via
var.networking)- flannel
- Calico
- Cilium
Addons:
Pre-installed Components
By default, Typhoon clusters install CoreDNS, kube-proxy, and a chosen CNI provider (flannel, calico, or cilium). Disable any or all of these components using the components system.
module "yavin" {
source = "git::https://github.com/poseidon/typhoon//google-cloud/fedora-coreos/kubernetes?ref=v1.30.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..."
# pre-installed components (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
}
}
}
!!! warn Disabling pre-installed components is for advanced users who intend to manage these components separately. Without a CNI provider, cluster nodes will be NotReady and wait for the CNI provider to be applied.
Managing Components
If you choose to manage components youself, a recommended pattern is to use a separate Terraform workspace per component, like you would any application.
mkdir -p infra/components/{coredns, cilium}
tree components/coredns
components/coredns/
├── backend.tf
├── manifests.tf
└── providers.tf
Let's consider managing CoreDNS resources. Configure the kubernetes provider to use the kubeconfig credentials of your Typhoon cluster(s) in a providers.tf file. Here we show provider blocks for interacting with Typhoon clusters on AWS, Azure, or Google Cloud, assuming each cluster's kubeconfig-admin output was written to local file.
provider "kubernetes" {
alias = "aws"
config_path = "~/.kube/configs/aws-config"
}
provider "kubernetes" {
alias = "google"
config_path = "~/.kube/configs/google-config"
}
...
Typhoon maintains Terraform modules for most addon components. You can reference main, a tagged release, a SHA revision, or custom module of your own. Define the CoreDNS manifests using the addons/coredns module in a manifests.tf file.
# CoreDNS manifests for the aws cluster
module "aws" {
source = "git::https://github.com/poseidon/typhoon//addons/coredns?ref=v1.30.1"
providers = {
kubernetes = kubernetes.aws
}
}
# CoreDNS manifests for the google cloud cluster
module "aws" {
source = "git::https://github.com/poseidon/typhoon//addons/coredns?ref=v1.30.1"
providers = {
kubernetes = kubernetes.google
}
}
...
Plan and apply the CoreDNS Kubernetes resources to cluster(s).
terraform plan
terraform apply
...
module.aws.kubernetes_service_account.coredns: Refreshing state... [id=kube-system/coredns]
module.aws.kubernetes_config_map.coredns: Refreshing state... [id=kube-system/coredns]
module.aws.kubernetes_cluster_role.coredns: Refreshing state... [id=system:coredns]
module.aws.kubernetes_cluster_role_binding.coredns: Refreshing state... [id=system:coredns]
module.aws.kubernetes_service.coredns: Refreshing state... [id=kube-system/coredns]
...