* Add example for lauch config with mixed lifecycles
* Set what on-demand instance is
* Tweak wording
Co-authored-by: Thomas O'Neill <toneill@new-innov.com>
Co-authored-by: Daniel Piddock <daniel.piddock@teamcmp.com>
Fix for:
Error: Provider produced inconsistent final plan
When expanding the plan for module.eks.random_pet.workers_launch_template[0]
to include new values learned so far during apply, provider
"registry.terraform.io/hashicorp/random" changed the planned action from
CreateThenDelete to DeleteThenCreate.
NOTES: Starting in v12.1.0 the `cluster_id` output depends on the
`wait_for_cluster` null resource. This means that initialisation of the
kubernetes provider will be blocked until the cluster is really ready,
if the module is set to manage the aws_auth ConfigMap and user followed
the typical Usage Example. kubernetes resources in the same plan do not
need to depend on anything explicitly.
NOTES: Addition of the IMDSv2 metadata configuration block to Launch Templates will cause a diff to be generated for existing Launch Templates on first Terraform apply. The defaults match existing behaviour.
In order to ensure proper ordering when running terraform destroy. This will block Terraform from removing up security group rules before the cluster has finished its clean up chores.
In order to be a text file according to POSIX, file needs to be composed of
text lines. Text line is defined as sequence of characters ending in \n. Sadly,
`~}` did strip everything including the \n, so the kubeconfing did not end
with a new line. Output empty string at the end to make sure of it.
NOTES: New variable `worker_create_cluster_primary_security_group_rules` to allow communication between pods on workers and pods using the primary cluster security group (Managed Node Groups or Fargate). It defaults to `false` to avoid potential conflicts with existing security group rules users may have implemented.
BREAKING CHANGES: The default `cluster_version` is now 1.16. Kubernetes 1.16 includes a number of deprecated API removals, and you need to ensure your applications and add ons are updated, or workloads could fail after the upgrade is complete. For more information on the API removals, see the [Kubernetes blog post](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/). For action you may need to take before upgrading, see the steps in the [EKS documentation](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html). Please set explicitly your `cluster_version` to an older EKS version until your workloads are ready for Kubernetes 1.16.
* Create kubeconfig with non-executable permissions
Kubeconfig does not really need to be executable, so let's not create it with executable bit set.
* Bump tf version
* Remove template_file for generating kubeconfig
Push logic from terraform down to the template. Makes the formatting
slightly easier to follow
* Remove template_file for generating userdata
Updates to the eks_cluster now do not trigger recreation of launch
configurations
* Remove template_file for LT userdata
* Remove template dependency
* Add support for EC2 principal in assume worker role policy for China AWS
* Remove local partition according to requested change
Co-authored-by: Valeri GOLUBEV <vgolubev@kyriba.com>
