Release notes for kops 1.17 series

Significant changes

  • To address the issue of IPv4 only clusters being susceptible to MitM attacks via IPv6 rogue router advertisements, the affected components have been upgraded as follows:

  • The default instance type for AWS has been changed to t3.medium. This should provide better performance and reduced costs in clusters where the average CPU usage is low.

  • Support for Ubuntu 20.04 (Focal) has been added.

Breaking changes

  • Support for Docker versions 1.11, 1.12 and 1.13 has been removed because of the dockerproject.org shut down. Those affected must upgrade to a newer Docker version.

  • Terraform users on AWS may need to rename some resources in their state file in order to prepare for future Terraform 0.12 support. See Required Actions below.

  • Please see the notes in the 1.15 release about the apiGroup changing from kops to kops.k8s.io

  • Since 1.16, a controller is now used to apply labels to nodes. If you are not using AWS, GCE or OpenStack your (non-master) nodes may not have labels applied correctly.

Required Actions

  • Terraform users on AWS may need to rename resources in their terraform state file in order to prepare for future Terraform 0.12 support. Terraform 0.12 no longer supports resource names starting with digits. In kOps, both the default route and additional VPC CIDR associations are affected. See #7957 for more information.
  • The default route was named aws_route.0-0-0-0--0 and will now be named aws_route.route-0-0-0-0--0.
  • Additional CIDR blocks associated with a VPC were similarly named the hyphenated CIDR block with two hyphens for the /, for example aws_vpc_ipv4_cidr_block_association.10-1-0-0--16. These will now be prefixed with cidr-, for example aws_vpc_ipv4_cidr_block_association.cidr-10-1-0-0--16.

To prevent downtime, follow these steps with the new version of kOps:

  1. kops update cluster --target terraform ...
  2. terraform plan
  3. # Observe any aws_route or aws_vpc_ipv4_cidr_block_association resources being destroyed and recreated
  4. # Run these commands as necessary. The exact names may differ; use what is outputted by terraform plan
  5. terraform state mv aws_route.0-0-0-0--0 aws_route.route-0-0-0-0--0
  6. terraform state mv aws_vpc_ipv4_cidr_block_association.10-1-0-0--16 aws_vpc_ipv4_cidr_block_association.cidr-10-1-0-0--16
  7. terraform plan
  8. # Ensure these resources are no longer being destroyed and recreated
  9. terraform apply
  • Kubernetes 1.9 users will need to enable the PodPriority feature gate. This is required for newer versions of kOps.

To enable the Pod priority feature, follow these steps:

  1. kops edit cluster
  2. # Add the following section
  3. spec:
  4.   kubelet:
  5.     featureGates:
  6.       PodPriority: "true"
  • If either a kOps 1.17 alpha release or a custom kOps build was used on a cluster, a kops-controller Deployment may have been created that should get deleted because it has been replaced with a DaemonSet. Run kubectl -n kube-system delete deployment kops-controller after upgrading to kOps 1.17.0-alpha.2 or later.

Deprecations

  • Support for Kubernetes releases prior to 1.9 is deprecated and will be removed in kops 1.18.

  • The kops/v1alpha1 API is deprecated and will be removed in kops 1.18. Users of kops replace will need to supply v1alpha2 resources.

  • Support for Ubuntu 16.04 (Xenial) has been deprecated and will be removed in future versions of kOps.

  • Support for Debian 8 (Jessie) has been deprecated and will be removed in future versions of kOps.

  • Support for CoreOS has been deprecated and will be removed in future versions of kOps. Those affected should consider using Flatcar as a replacement.

  • Support for the “Legacy” etcd provider has been deprecated. It will not be supported for Kubernetes 1.18 or later. To migrate to the default “Manager” etcd provider see the etcd migration documentation.

  • The default StorageClass gp2 prior to kOps 1.17.0 is no longer the default, replaced by StorageClass kops-ssd-1-17.

Known Issues

  • kOps 1.17.0-beta.1 included an update for AWS IAM Authenticator to 0.5.0. This version fails to use the volume mounted ConfigMap causing API authentication issues for clients with aws-iam-authenticator credentials. Any cluster with spec.authentication.aws defined according to the docs without overriding the spec.authentication.aws.image is affected. The workaround is to specify the old 0.4.0 image with spec.authentication.aws.image=602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon/aws-iam-authenticator:v0.4.0. For the 1.17.0 release, this change was rolled back, and the AWS IAM authenticator defaults to version 0.4.0

  • kOps 1.17.0 includes a new StorageClass kops-ssd-1-17 which is set as the default via the annotation "storageclass.beta.kubernetes.io/is-default-class":"true". If you have modified the previous gp2 StorageClass, it could conflict with the defaulting behavior. To resolve, patch the gp2 StorageClass to have the annotation "storageclass.beta.kubernetes.io/is-default-class":"false", which aligns with a patch to kOps 1.17.1 as well. kubectl patch storageclass.storage.k8s.io/gp2 --patch '{"metadata": {"annotations": {"storageclass.beta.kubernetes.io/is-default-class": "false"}}}'

Full change list since 1.16.0 release

1.16.0-alpha.1 to 1.17.0-alpha.1

1.17.0-alpha.1 to 1.17.0-alpha.2

1.17.0-alpha.2 to 1.17.0-alpha.3

1.17.0-alpha.3 to 1.17.0-alpha.4

1.17.0-alpha.4 to 1.17.0-beta.1

1.17.0-beta.1 to 1.17.0-beta.2

1.17.0-beta.2 to 1.17.0

1.17.0 to 1.17.1

1.17.1 to 1.17.2