CadolesKube/typhoon
7
0
Fork 0
mirror of https://github.com/puppetmaster/typhoon.git synced 2024-12-27 08:49:33 +01:00
Code Issues Packages Projects Releases Wiki Activity
0669d44026
typhoon/azure/flatcar-linux/kubernetes/bootstrap.tf

24 lines
914 B
Terraform
Raw Normal View History

Update CHANGES for control plane static pod switch * Remove old references to bootkube / self-hosted
2019-09-07 22:38:51 +02:00
# Kubernetes assets (kubeconfig, manifests)
Rename bootkube modules to bootstrap * Rename render module from bootkube to bootstrap. Avoid confusion with the kubernetes-incubator/bootkube tool since it is no longer used * Use the poseidon/terraform-render-bootstrap Terraform module (formerly poseidon/terraform-render-bootkube) * https://github.com/poseidon/terraform-render-bootkube/pull/149
2019-09-15 01:24:32 +02:00
module "bootstrap" {
Update Kubernetes from v1.30.2 to v1.30.3 * Update builtin Cilium manifests from v1.15.6 to v1.15.7 * Update builtin flannel manifests from v0.25.4 to v0.25.5
2024-07-20 20:04:32 +02:00
source = "git::https://github.com/poseidon/terraform-render-bootstrap.git?ref=ca1f897b35d1f873649cd7f23b75f3219328df38"
Add module for Typhoon Azure with Container Linux
2018-08-20 03:48:22 +02:00
Migrate Azure module Terraform v0.11 to v0.12 * Replace v0.11 bracket type hints with Terraform v0.12 list expressions * Use expression syntax instead of interpolated strings, where suggested * Update Azure tutorial and worker pools documentation * Define Terraform and plugin version requirements in versions.tf * Require azurerm ~> 1.27 to support Terraform v0.12 * Require ct ~> 0.3.2 to support Terraform v0.12
2019-05-28 06:43:08 +02:00
cluster_name = var.cluster_name
api_servers = [format("%s.%s", var.cluster_name, var.dns_zone)]
etcd_servers = formatlist("%s.%s", azurerm_dns_a_record.etcds.*.name, var.dns_zone)
Allow Calico networking on Azure and DigitalOcean * Introduce "calico" as a `networking` option on Azure and DigitalOcean using Calico's new VXLAN support (similar to flannel). Flannel remains the default on these platforms for now. * Historically, DigitalOcean and Azure only allowed Flannel as the CNI provider, since those platforms don't support IPIP traffic that was previously required for Calico. * Looking forward, its desireable for Calico to become the default across Typhoon clusters, since it provides NetworkPolicy and a consistent experience * No changes to AWS, GCP, or bare-metal where Calico remains the default CNI provider. On these platforms, IPIP mode will always be used, since its available and more performant than vxlan
2019-05-06 09:38:23 +02:00
Introduce the component system for managing pre-installed addons * 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.
2024-05-19 00:05:33 +02:00
networking = var.networking
Allow Calico networking on Azure and DigitalOcean * Introduce "calico" as a `networking` option on Azure and DigitalOcean using Calico's new VXLAN support (similar to flannel). Flannel remains the default on these platforms for now. * Historically, DigitalOcean and Azure only allowed Flannel as the CNI provider, since those platforms don't support IPIP traffic that was previously required for Calico. * Looking forward, its desireable for Calico to become the default across Typhoon clusters, since it provides NetworkPolicy and a consistent experience * No changes to AWS, GCP, or bare-metal where Calico remains the default CNI provider. On these platforms, IPIP mode will always be used, since its available and more performant than vxlan
2019-05-06 09:38:23 +02:00
# only effective with Calico networking
# we should be able to use 1450 MTU, but in practice, 1410 was needed
network_encapsulation = "vxlan"
network_mtu = "1410"
Migrate Azure module Terraform v0.11 to v0.12 * Replace v0.11 bracket type hints with Terraform v0.12 list expressions * Use expression syntax instead of interpolated strings, where suggested * Update Azure tutorial and worker pools documentation * Define Terraform and plugin version requirements in versions.tf * Require azurerm ~> 1.27 to support Terraform v0.12 * Require ct ~> 0.3.2 to support Terraform v0.12
2019-05-28 06:43:08 +02:00
pod_cidr = var.pod_cidr
service_cidr = var.service_cidr
cluster_domain_suffix = var.cluster_domain_suffix
enable_reporting = var.enable_reporting
enable_aggregation = var.enable_aggregation
Allow custom initial node taints on worker pool nodes * Add `node_taints` variable to worker modules to set custom initial node taints on cloud platforms that support auto-scaling worker pools of heterogeneous nodes (i.e. AWS, Azure, GCP) * Worker pools could use custom `node_labels` to allowed workloads to select among differentiated nodes, while custom `node_taints` allows a worker pool's nodes to be tainted as special to prevent scheduling, except by workloads that explicitly tolerate the taint * Expose `daemonset_tolerations` in AWS, Azure, and GCP kubernetes cluster modules, to determine whether `kube-system` components should tolerate the custom taint (advanced use covered in docs) Rel: #550, #663 Closes #429
2021-04-11 21:08:56 +02:00
daemonset_tolerations = var.daemonset_tolerations
Allow CoreDNS and kube-proxy to be optional components * Allow for more minimal base cluster setups, that manage CoreDNS or kube-proxy as applications, with rolling updates, or deploy systems. Or in the case of kube-proxy, its becoming more common to not install it and instead use Cilium * Add a `components` pass-through variable to configure pre-installed components like kube-proxy and CoreDNS. These components can be disabled (individually or together) to allow for managing components with separate plan/apply processes or automations * terraform-render-bootstrap manifest assets are now structured as manifests/{coredns,kube-proxy,network} so adapt the controller layout scripts accordingly * This is similar to some changes in v1.29.2 that allowed for the container networking provider manifests to be skipped Related: https://github.com/poseidon/typhoon/pull/1419, https://github.com/poseidon/typhoon/pull/1421
2024-05-13 06:03:40 +02:00
components = var.components
Add module for Typhoon Azure with Container Linux
2018-08-20 03:48:22 +02:00
}
Migrate Azure module Terraform v0.11 to v0.12 * Replace v0.11 bracket type hints with Terraform v0.12 list expressions * Use expression syntax instead of interpolated strings, where suggested * Update Azure tutorial and worker pools documentation * Define Terraform and plugin version requirements in versions.tf * Require azurerm ~> 1.27 to support Terraform v0.12 * Require ct ~> 0.3.2 to support Terraform v0.12
2019-05-28 06:43:08 +02:00
Reference in New Issue Copy Permalink