HNC v0.5.3
HNC v0.5.3 includes several critical bug fixes since HNC v0.5.2, including support for K8s 1.19. It also introduces the ability to install the kubectl-hns
plugin via Krew. See the changelog for the full release.
To install this release on your cluster, run the following commands:
HNC_VERSION=v0.5.3
kubectl apply -f https://github.com/kubernetes-sigs/multi-tenancy/releases/download/hnc-${HNC_VERSION}/hnc-manager.yaml
# Wait 30s if HNC has never been installed before for it to generate certs and reboot itself.
To install the kubectl plugin on your workstation, either use Krew or install manually:
-
Via Krew: Krew can only support one version of a plugin at a time, and it now supports v0.6.0, not v0.5.3. This is due to the introduction of the
v1alpha2
API in v0.6.0, which is not supported by the v0.5.x plugin. -
Manually: Switch to any directory in your
PATH
(e.g.~/bin
) and run the following commands:HNC_VERSION=v0.5.3 HNC_PLATFORM=linux_amd64 # also supported: darwin_amd64 curl -L https://github.com/kubernetes-sigs/multi-tenancy/releases/download/hnc-${HNC_VERSION}/kubectl-hns_${HNC_PLATFORM} -o ./kubectl-hns chmod +x ./kubectl-hns # Ensure the plugin is working kubectl hns # The help text should be displayed
For more instructions, see the user guide.
Known issues
These issues are being (or have been) fixed in a future release of HNC, but are considered to be sufficiently rare or low-impact that we are not currently planning on backporting them to HNC v0.5. Please contact aludwin@google.com if you are affected by these changes and require a backport.
- If you start propagating a new type (such as
Secret
), any object with the same type and name in a descendant namespace will be overwritten without warning (#1076)- If you simply attempt to create a conflicting object in an ancestor, or change the hierarchy in a way that could result in an object being overwritten in a descendant namespace, HNC will prevent you from doing this. It's only in the case where you're turning on propagation for the entire cluster that HNC is unable to warn you of the implications.
- This issue will be fixed in HNC v0.6.
- If a RoleBinding is quickly deleted and recreated with a new Role, HNC may fail to update it (#798)
- This issue will be fixed in HNC v0.6.
Changelog
Since HNC v0.5.2
Fixed:
- Subnamespaces with propagated objects cannot be deleted (#1130)
- Objects can be propagated inconsistently if descendant namespaces have conflicting objects (#1076)
- This is only partially fixed in this release; see "Known Issues," above.
- HNC cannot be installed on K8s 1.19 (#1100)
- Deleting an anchor in the "conflict" state can delete the related namespace (#1149)
- This makes it more dangerous to try to turn a subns into a full namespace
Since HNC v0.5.1
Fixed:
- HNC's timeout on the object validator is too long (#1023)
- Distribute the kubectl plugin for MacOS (#1029)
- HNC supports server-side dry-run (#1056)
Since HNC v0.5.0
Fixed:
- HNC does not prevent propagated objects from being deleted (#845)
Since HNC v0.4
Key new/changed features in this release include:
- You can delete a leaf subnamespace by deleting its anchor without first setting
allowCascadingDelete
. That is, you're allowed to delete any namespace or subnamespace as long as this will not trigger the deletion of any other subnamespaces (#716). - The behaviour of
allowCascadingDelete
has been simplified - it now takes effect if any ancestor has it set (#730). - HNC startup time has been reduced from >90s to ~15s when it is first installed (#765)
- All finalizers are removed from HNC resources if the CRDs are deleted, making uninstallation easier (#824).
In addition, the following known issues from HNC v0.4 were fixed in this release:
- If you managed to create a subnamespace anchor to an existing namespace (by bypassing the webhook, or due to an extremely unlucky race condition), and if that subnamespace had
allowCascadingDelete
set (which is not the default), then you could delete that namespace. In HNC v0.5, deleting a conflicting anchor does not affect the subnamespace (#797). - The object validators were set up correctly and did not respond to changes in
HNCConfiguration
. That is, if you overwrote or deleted an object managed by HNC, it would appear to succeed, but HNC would immediately overwrite it. In HNC v0.5, attempting to modify a propagated object will result in a validation error (#761).
Testing signoff
Target | Tests | By | Result |
---|---|---|---|
KIND 1.19 | make e2e-test |
@adrianludwin | passed Sep 29 (as RC2) |
GKE 1.17 (rapid channel) | " | @adrianludwin | passed Sep 29 (as RC2) |
GKE 1.16 (regular channel) | " | @adrianludwin | passed Sep 29 (as RC2) |
GKE 1.15 (stable channel) | " | @adrianludwin | passed Sep 29 (as RC2) |