Note: from this release, karch
minor releases (ex.: 1.8.x) will be made
against the corresponding kops
release. On CoreOS, compatibility is guaranteed
between these versions. You should therefore use karch
v1.8.x
with kops
v1.8.y
.
- It is now possible to configure (runtime,kubelet) and system resource reservation on nodes
- The APIServer
--runtime-config
flag is now exposed, allowing users to easily enable/disable Kubernetes API groups batch/v2alpha1
-
[refactoring] Remove efs/ebs-pv and revisit folder structure
Coupling the creation of a complete Kubernetes cluster and of resources (PersistentVolumes, in the case of the efs-pv and ebs-fv volumes) was a really bad idea:
- If the Kubernetes API Server is down, it blocks any plan/apply on your Terraform code using these modules, being unable to run Terraform when an outage occured in a cluster isn't... cool :(
- It even prevents you to create a custom cluster from scratch
It is therefore advised to create your Kubernetes infrastructure (including EBS/EFS volumes, karch module calls...) in one piece of Terraform code and to use the "terraform_remote_state" datasources from another to retrieve some data you'd need to provision resources (such as Secrets or PersistentVolumes) from the original codebase or - more precisely - from the state bound to it.
-
Some alpha API Groups have been enabled. This will soon be configurable with a list variable
ebs-pv
andefs-pv
volumes: these were a really bad idea: they imply that, for eachplan
orapply
call you'll be willing to make, the Kubernetes API server must be up. This is totally impossible during cluster bootstrap (without commenting code) and when the API server is unreachable. You don't want yourterraform apply
to be down during outages :)
- Relative path handling issue wrt Terraform 10.0.6
- OIDC Server templating fix
- Use dashes in all output names
ode security group ID as output of the kops-cluster
module
- Helper module to provision EBS volumes as kubernetes persistent volumes (includes the ability to restore them from a snapshot)
- Possibility to configure an OIDC provider to the Kubernetes API (tested with Google and Github)
- We're not creating an S3 VPC endpoint automatically, however you can create
it outside of the
kops-cluster
module using the exportedvpc-id
.
- It is now possible to create
kops
clusters with RBAC enabled by default - etcd volumes are encrypted
- support for kops ability to disable the automatic creation of security groups when creating a LoadBalancer service
- During
terraform destroy
, avoid errors that occur in case the cluster has already been deleted outside of Terraform - Kops cluster domain and your cluster's kube-dns domain are now setup accordingly
- premature Internet Gateway destroy triggering Terraform errors on destroyed (could be worked around by running destroy twice)
- the ASG generated by kops with the
kops-ig
module now have their names exposed as outputs (so that you can - for instance - expose your ingress controllers as a NodePort on the host and wire them to an ELB) - Terraform variable to attach custom security groups to an instance group (for the same purpose essentially)
- kops-created subnets now have their subnet ids exposed as outputs (so that you can use Terraform to create resources in these same subnets)
A Terraform module designed as a wrapper around kops, it makes it possible to
spawn kops clusters using the kops-cluster
and kops-ip
modules, supports
cluster updates and deletes and exposes resources created by kops to the rest of
your Terraform code, as simple Terraform outputs.