HNC v0.5.3 RC1 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-rc1
kubectl apply -f https://github.com/kubernetes-sigs/multi-tenancy/releases/download/hnc-${HNC_VERSION}/hnc-manager.yaml

To install the kubectl plugin on your workstation, switch to any directory in your PATH (e.g. ~/bin) and run the following commands:

HNC_VERSION=v0.5.3-rc1
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

Or via Krew: INSTRUCTIONS TBD

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

• 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)

Full list of changes

Since HNC v0.5.1

• 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)

Full list of changes

Since HNC v0.5.0

This release fixes the following bugs:

• 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).

Full list of changes

Testing signoff