We are happy to announce a new versioning scheme for the Kubernetes Fury Distribution that will make choosing a KFD version much clearer and straightforward.
We are also announcing three new patch releases for the Distribution that will fix an issue affecting all Kubernetes releases >= 1.21.
New versioning scheme
Initially, Kubernetes Fury Distribution (KFD) had its own versioning following semantic versioning, but this approach showed some downsides and limitations. On the one hand, it was difficult to follow what Kubernetes versions were supported by a version of KFD. On the other hand, our principles are to be an undistribution and the closest to Kubernetes upstream as possible.
From KFD 1.21, Kubernetes Fury Distribution (KFD) will follow closely Kubernetes upstream versioning and releases, with the patches number referring to specific KFD patches.
Some practical examples:
- KFD 1.22.0 is compatible with Kubernetes 1.22.x with KFD release/patch
0 - KFD 1.22.5 is compatible with Kubernetes 1.22.x with KFD release/patch
5 - KFD 1.23.2 is compatible with Kubernetes 1.23.x with KFD release/patch
2
To see the full list of compatible versions and previous releases, please refer to the Compatibility Matrix in the Versioning section of the documentation.
You can find the documentation for each version by choosing it in the dropdown at the upper-right of the website.
Announcing new patch releases for KFD
Following the new versioning, we have released three patched versions of the Kubernetes Fury Distribution:
Kubernetes introduced in version 1.21 an expiration mechanism for Service Account Tokens that might result in applications using expired Service Account Tokens to contact the Kubernetes API. If you want to learn more about this issue, here is the link to the official documentation.
New KFD patched releases solve this problem by fully supporting transparent renewal mechanisms for expiring service account tokens.
We recommend you upgrade to the latest patch release of KFD available for the version of your Kubernetes cluster.
See the release notes in the linked releases for more information.
You can find applications using expired tokens by inspecting the Kubernetes Audit logs and searching for the stale-token string.
The API server will log all the service account names that are contacting it with tokens with more than 1 hour of life.