Skip to content
This repository has been archived by the owner on Jun 26, 2023. It is now read-only.

Releases: kubernetes-retired/multi-tenancy

HNC v0.8.0

30 Apr 13:35
@adrianludwin adrianludwin
hnc-v0.8.0
c794725
This commit was created on github.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
HNC v0.8.0 Latest
Latest

Note: HNC v0.9.0 and later are now available from our new repo. This repo will no longer be updated with the latest HNC releases.

HNC v0.8.0 fixes some minor issues with Exceptions, improves the stability of your cluster by protecting critical system namespaces, and adds support for the latest versions of Kubernetes.

Installing

WARNING: if your cluster already has HNC installed, please ensure you are using HNC v0.7.0 or later.

You can install or upgrade HNC on your cluster using the following commands (admin privileges required):

# Select the latest version of HNC
HNC_VERSION=v0.8.0

# Forbid HNC from modifying system namespaces
kubectl label ns kube-system hnc.x-k8s.io/excluded-namespace=true --overwrite
kubectl label ns kube-public hnc.x-k8s.io/excluded-namespace=true --overwrite
kubectl label ns kube-node-lease hnc.x-k8s.io/excluded-namespace=true --overwrite

# Install HNC. Afterwards, wait up to 30s for HNC to refresh the certificates on its webhooks.
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, either use Krew or install manually:

  • Via Krew: Install Krew if you don't have it already, then run the command kubectl krew install hns. Krew now installs HNC v0.9.0 or later

  • Manually: Switch to any directory in your PATH (e.g. ~/bin) and run the following commands:

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

Changelog

Since HNC v0.7

  • Exceptions were not correctly reapplied if the labels were changed on a namespace (#1448)
  • Updated all dependencies to use v1 CRD and v1 webhooks to support newer version of Kubernetes (#1270, #1371)
  • Exclude HNC from critical system namespaces (#1023)
  • Built-in admin clusterrole now includes permissions to modify all HNC objects, including subnamespace anchors and hierarchy configs (#1341)
  • HNC can now propagate cluster-admin rolebindings in namespaces (#1311)

See full list of changes

Testing signoff

Target Tests By When Result
KIND 1.20 make test-e2e @adrianludwin apr 29 passed (as RC1)
GKE 1.19 (rapid channel) " @adrianludwin apr 30 passed
GKE 1.18 (regular channel) " @adrianludwin apr 29 passed (as RC1)
GKE 1.17 (stable channel) " @adrianludwin apr 29 passed (as RC1)
GKE 1.19 (rapid channel) Upgrade from v0.7.0 @adrianludwin apr 29 subns creation worked before and after; verified admin cluster role includes HNC permissions (as RC1)

Contributors

adrianludwin
Assets 7
Loading

HNC v0.8.0 RC1

29 Apr 19:52
@adrianludwin adrianludwin
hnc-v0.8.0-rc1
3964a2f
This commit was created on github.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
HNC v0.8.0 RC1 Pre-release
Pre-release

HNC v0.8.0 fixes some minor issues with Exceptions, improves the stability of your cluster by protecting critical system namespaces, and adds support for the latest versions of Kubernetes.

Installing

WARNING: if your cluster already has HNC installed, please ensure you are using HNC v0.7.0 or later.

You can install or upgrade HNC on your cluster using the following commands (admin privileges required):

# Select the latest version of HNC
HNC_VERSION=v0.8.0-rc1

# Forbid HNC from modifying system namespaces
kubectl label ns kube-system hnc.x-k8s.io/excluded-namespace=true --overwrite
kubectl label ns kube-public hnc.x-k8s.io/excluded-namespace=true --overwrite
kubectl label ns kube-node-lease hnc.x-k8s.io/excluded-namespace=true --overwrite

# Install HNC. Afterwards, wait up to 30s for HNC to refresh the certificates on its webhooks.
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, either use Krew or install manually:

  • Via Krew (NOT APPLICABLE FOR RELEASE CANDIDATES): Install Krew if you don't have it already, then run the command kubectl krew install hns.

  • Manually: Switch to any directory in your PATH (e.g. ~/bin) and run the following commands:

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

For more instructions, see the user guide.

Known issues

  • Tree labels can be briefly modified before HNC resets them (#1494)
  • Annotations can be added to propagated objects (#1500)

Changelog

Since HNC v0.7

  • Exceptions were not correctly reapplied if the labels were changed on a namespace (#1448)
  • Updated all dependencies to use v1 CRD and v1 webhooks to support newer version of Kubernetes (#1270, #1371)
  • Exclude HNC from critical system namespaces (#1023)
  • Built-in admin clusterrole now includes permissions to modify all HNC objects, including subnamespace anchors and hierarchy configs (#1341)
  • HNC can now propagate cluster-admin rolebindings in namespaces (#1311)

See full list of changes

Testing signoff

Target Tests By When Result
KIND 1.20 make test-e2e @adrianludwin apr 29 passed
GKE 1.19 (rapid channel) " @adrianludwin apr 29 passed
GKE 1.18 (regular channel) " @adrianludwin apr 29 passed
GKE 1.17 (stable channel) " @adrianludwin apr 29 passed
GKE 1.19 (rapid channel) Upgrade from v0.7.0 @adrianludwin apr 29 subns creation worked before and after; verified admin cluster role includes HNC permissions
Assets 7
Loading

HNC v0.7.0

14 Dec 22:04
@adrianludwin adrianludwin
hnc-v0.7.0
e3321bf
This commit was created on github.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
HNC v0.7.0

HNC v0.7.0 introduces Exceptions, which gives you fine-grained control of where objects are propagated, instead of always copying objects to all descendant namespaces.

Installing

WARNING: you cannot upgrade from HNC v0.5.x directly to HNC v0.7.x, since the use different APIs (v1alpha1 vs v1alpha2). Instead, upgrade to HNC v0.6.0 first, and then from v0.6.x to v0.7.x. Be sure to carefully follow the upgrading instructions from v0.5 to v0.6 to avoid losing data.

You can install or upgrade HNC on your cluster using the following commands (admin privileges required):

HNC_VERSION=v0.7.0
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 (APR 30 2021: Krew replaced by HNC v0.8.0): Install Krew if you don't have it already, then run the command kubectl krew install hns.

    • The HNC v0.8.0 plugin may work with HNC v0.7.0, but for best results, download the plugin manually, or upgrade to the latest version of HNC.

  • Manually: Switch to any directory in your PATH (e.g. ~/bin) and run the following commands:

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

  • Exceptions are not correctly reapplied if the labels are changed on a namespace (#1448)
  • CRDs and webhooks use the v1beta1 API versions, which are deprecated in K8s 1.16 and removed in 1.22 (#1247)

Changelog

Since HNC v0.6

  • Introduced Exceptions
  • When uninstalling HNC CRDs, subnamespaces could sometimes be erased by mistake; this is now fixed (#1285)
  • Default RAM requests/limits are raised from 50MB/100MB to 150MB/300MB as a result of scalability tests (#1306)
  • You can no longer create subnamespaces in kube-node-lease, similar to other system namespaces such as kube-system (#1229)

See full list of changes

Testing signoff

Target Tests By When Result
KIND 1.19 make test-e2e @adrianludwin dec 13 passed (as rc1)
GKE 1.18 (rapid channel) " @adrianludwin dec 14 passed
GKE 1.17 (regular channel) " @adrianludwin dec 13 passed (as rc1)
GKE 1.16 (stable channel) " @adrianludwin dec 13 passed (as rc1)
Assets 7
Loading

HNC v0.7.0 RC1

13 Dec 04:02
@adrianludwin adrianludwin
hnc-v0.7.0-rc1
083c78c
This commit was created on github.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
HNC v0.7.0 RC1 Pre-release
Pre-release

HNC v0.7.0 introduces Exceptions, which gives you fine-grained control of where objects are propagated, instead of always copying objects to all descendant namespaces.

Installing

WARNING: you cannot upgrade from HNC v0.5.x directly to HNC v0.7.x, since the use different APIs (v1alpha1 vs v1alpha2). Instead, upgrade to HNC v0.6.0 first, and then from v0.6.x to v0.7.x. Be sure to carefully follow the upgrading instructions from v0.5 to v0.6 to avoid losing data.

You can install or upgrade HNC on your cluster using the following commands (admin privileges required):

HNC_VERSION=v0.7.0-rc1
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 will be supported when HNC v0.7.0 is released, but is not available for v0.7.0 RC1 Install Krew if you don't have it already, then run the command kubectl krew install hns.

  • Manually: Switch to any directory in your PATH (e.g. ~/bin) and run the following commands:

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

For more instructions, see the user guide.

Known issues

No critical issues known at this time.

Changelog

Since HNC v0.6

  • Introduced Exceptions
  • When uninstalling HNC CRDs, subnamespaces could sometimes be erased by mistake; this is now fixed (#1285)
  • Default RAM requests/limits are raised from 50MB/100MB to 150MB/300MB as a result of scalability tests (#1306)
  • You can no longer create subnamespaces in kube-node-lease, similar to other system namespaces such as kube-system (#1229)

See full list of changes

Testing signoff

Target Tests By When Result
KIND 1.19 make test-e2e @adrianludwin dec 13 passed
GKE 1.18 (rapid channel) " @adrianludwin dec 13 passed
GKE 1.17 (regular channel) " @adrianludwin dec 13 passed
GKE 1.16 (stable channel) " @adrianludwin dec 13 passed
Assets 7
Loading

HNC v0.6.0

28 Oct 17:48
@adrianludwin adrianludwin
hnc-v0.6.0
0b3dc49
This commit was created on github.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
HNC v0.6.0

HNC v0.6.0 introduces the new v1alpha2 API that is more standards-compliant than the prior API. It also includes an alpha-level preview of exceptions and a variety of smaller fixes. See the changelog for more details.

Installing on a cluster without HNC

If you do not have HNC v0.5 installed on your cluster, you can install HNC v0.6 by running the following commands:

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

Otherwise, see below for upgrade instructions.

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.6.0
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

NB: As of December 14th 2020, you can no longer install the v0.6.0 version of the plugin via Krew; Krew now serves a newer version, which may not be compatible with HNC v0.6.0.

For more instructions, see the user guide.

Upgrading from HNC v0.5.x

If you do have HNC v0.5 installed on your cluster, be aware that installing HNC v0.6 will automatically and immediately update all your HNC objects (HierarchyConfiguration, HNCConfiguration and SubnamespaceAnchor) from v1alpha1 to v1alpha2. We have tested this process extensively but there is always the possibility that some bugs have slipped through and that you could lose data while upgrading from v0.5 to v0.6.

Once you have upgraded to HNC v0.6, you cannot automatically revert to HNC v0.5. To minimize or eliminate the chance of data loss, follow these steps:

  1. Ensure you have the latest version of HNC v0.5 installed before attempting to upgrade (v0.5.3)
  2. Ensure you don't have any objects with the hnc.x-k8s.io/inheritedFrom label, unless those objects have the propagate sync mode. That is, ensure you didn't change any type configs from propagate to ignore without cleaning up, because after HNC is upgraded, it will no longer respected the inheritedFrom label and will not be able to clean up these objects.
  3. Use kubectl hns config describe and ensure that there are no conditions in your cluster, and that all configs are healthy.
  4. Back up all existing HNC objects and manually confirm that all namespaces are accounted for.
  5. For the rest of this process, do not delete any object types that are propagated by HNC, and do not change the contents of any HNC objects. For example, do not delete any RBAC Roles or RoleBindings until you've confirmed that HNC v0.6 is in a good state.
  6. Install HNC v0.6 as described in the prior section, "Installing on a cluster without HNC." That is, first apply the manifest to your cluster, and then upgrade the kubectl-hns plugin on your workstation. Wait at least 30s for HNC to finish upgrading all v1alpha1 objects; once you can call kubectl hns tree -A and see your full hierarchy, you should be in good shape (during the upgrade process, the tree command may simply list namespaces without showing the hierarchical relationships).
  7. Run kubectl hns config describe to ensure that your cluster-wide configuration looks correct and there are no other problems across your cluster. The new API uses plural resource names instead of singular kind names (e.g. secrets and networkpolicies instead of Secret and NetworkPolicy), and HNC v0.6 uses a simple pluralization algorithm on your existing cluster-wide config (e.g. replace trailing "y" with "ies," otherwise append an "s"). If this is incorrect, you can simply fix the HNC config after the upgrade is finished.

If you do encounter problems, please contact us on Slack and we'll help you out. For more information about how v1alpha2 has changed, see the design doc.

To downgrade to HNC v0.5, you must completely uninstall HNC, including the CRDs. You may then reinstall HNC v0.5.x and reapply the configs you saved earlier.

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.

  • When uninstalling HNC CRDs, subnamespaces could sometimes be erased by mistake. This is fixed in v0.7.0 (#1285)

Changelog

Since HNC v0.5

  • The new v1alpha2 API is introduced with the following major changes from v1alpha1 (see full list):
    • Namespace conditions are now reported using the standard Kubernetes conditions schema.
    • Object "conditions" have been converted to Kubernetes Events and are no longer reported in the HierarchyConfiguration objects (though they are reported by kubectl hns describe NAMESPACE.
    • When configuring object propagation, instead of providing the group, version and kind (e.g. "networking.k8s.io/v1/NetworkPolicy"), you now provide the group and resource (e.g. "networking.k8s.io/networkpolicies"), similar to RBAC.
    • Enum values are now properly capitalized (e.g. Propagate, not propagate)
    • Annotations and labels are now properly hyphenated (e.g. inherited-from, not inheritedFrom)
  • If you start propagating a new type (such as Secret), we now warn you that existing objects could be overridden and provide ways to ensure this doesn't happen (#1076)
  • If a RoleBinding is quickly deleted and recreated with a new Role, HNC will no longer fail to update it (#798)

Full list of changes

Testing signoff

Target Tests By Result
KIND 1.19 make test-e2e @adrianludwin Passed (as RC1)
GKE 1.18 (rapid channel) " @adrianludwin Passed
GKE 1.17 (regular channel) " @adrianludwin Passed (as RC1)
GKE 1.16 (stable channel) " @adrianludwin Passed (as RC1)
Assets 7
Loading

HNC v0.6.0 RC1

27 Oct 19:42
@adrianludwin adrianludwin
hnc-v0.6.0-rc1
639dcd6
This commit was created on github.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
HNC v0.6.0 RC1 Pre-release
Pre-release

HNC v0.6.0 RC1 introduces the new v1alpha2 API that is more standards-compliant than the prior API. It also includes an alpha-level preview of exceptions and a variety of smaller fixes. See the changelog for more details.

Installing on a cluster without HNC

If you do not have HNC v0.5 installed on your cluster, you can install HNC v0.6 by running the following commands:

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

Otherwise, see below for upgrade instructions.

Krew is not supported by HNC v0.6.0 RC1, but will be supported in the final v0.6.0 release. To install the plugin manually, switch to any directory in your PATH (e.g. ~/bin) and run the following commands:

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

For more instructions, see the user guide.

Upgrading from HNC v0.5.x

If you do have HNC v0.5 installed on your cluster, be aware that installing HNC v0.6 will automatically and immediately update all your HNC objects (HierarchyConfiguration, HNCConfiguration and SubnamespaceAnchor) from v1alpha1 to v1alpha2. We have tested this process extensively but there is always the possibility that some bugs have slipped through and that you could lose data while upgrading from v0.5 to v0.6.

Once you have upgraded to HNC v0.6, you cannot automatically revert to HNC v0.5. To minimize or eliminate the chance of data loss, follow these steps:

  1. Ensure you have the latest version of HNC v0.5 installed before attempting to upgrade (v0.5.3)
  2. Ensure you don't have any objects with the hnc.x-k8s.io/inheritedFrom label, unless those objects have the propagate sync mode. That is, ensure you didn't change any type configs from propagate to ignore without cleaning up, because after HNC is upgraded, it will no longer respected the inheritedFrom label and will not be able to clean up these objects.
  3. Use kubectl hns config describe and ensure that there are no conditions in your cluster, and that all configs are healthy.
  4. Back up all existing HNC objects and manually confirm that all namespaces are accounted for.
  5. For the rest of this process, do not delete any object types that are propagated by HNC, and do not change the contents of any HNC objects. For example, do not delete any RBAC Roles or RoleBindings until you've confirmed that HNC v0.6 is in a good state.
  6. Install HNC v0.6 as described in the prior section, "Installing on a cluster without HNC." That is, first apply the manifest to your cluster, and then upgrade the kubectl-hns plugin on your workstation. Wait at least 30s for HNC to finish upgrading all v1alpha1 objects; once you can call kubectl hns tree -A and see your full hierarchy, you should be in good shape (during the upgrade process, the tree command may simply list namespaces without showing the hierarchical relationships).
  7. Run kubectl hns config describe to ensure that your cluster-wide configuration looks correct and there are no other problems across your cluster. The new API uses plural resource names instead of singular kind names (e.g. secrets and networkpolicies instead of Secret and NetworkPolicy), and HNC v0.6 uses a simple pluralization algorithm on your existing cluster-wide config (e.g. replace trailing "y" with "ies," otherwise append an "s"). If this is incorrect, you can simply fix the HNC config after the upgrade is finished.

If you do encounter problems, please contact us on Slack and we'll help you out. For more information about how v1alpha2 has changed, see the design doc.

To downgrade to HNC v0.5, you must completely uninstall HNC, including the CRDs. You may then reinstall HNC v0.5.x and reapply the configs you saved earlier.

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.

tbd

Changelog

Since HNC v0.5

  • The new v1alpha2 API is introduced with the following major changes from v1alpha1 (see full list):
    • Namespace conditions are now reported using the standard Kubernetes conditions schema.
    • Object "conditions" have been converted to Kubernetes Events and are no longer reported in the HierarchyConfiguration objects (though they are reported by kubectl hns describe NAMESPACE.
    • When configuring object propagation, instead of providing the group, version and kind (e.g. "networking.k8s.io/v1/NetworkPolicy"), you now provide the group and resource (e.g. "networking.k8s.io/networkpolicies"), similar to RBAC.
    • Enum values are now properly capitalized (e.g. Propagate, not propagate)
    • Annotations and labels are now properly hyphenated (e.g. inherited-from, not inheritedFrom)
  • If you start propagating a new type (such as Secret), we now warn you that existing objects could be overridden and provide ways to ensure this doesn't happen (#1076)
  • If a RoleBinding is quickly deleted and recreated with a new Role, HNC will no longer fail to update it (#798)

Full list of changes

Testing signoff

Target Tests By Result
KIND 1.19 make test-e2e1 @adrianludwin Passed
GKE 1.18 (rapid channel) " @adrianludwin Passed
GKE 1.17 (regular channel) " @adrianludwin Passed
GKE 1.16 (stable channel) " @adrianludwin Passed

Testing notes:

  1. After fix to network policy test (#1244)
Assets 7
Loading

HNC v0.5.3

29 Sep 12:27
@adrianludwin adrianludwin
hnc-v0.5.3
4b8e7a2
This commit was created on github.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
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

Full list of changes

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)

Full list of changes

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

Full list of changes

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)
Assets 6
Loading

HNC v0.5.3 RC2

29 Sep 09:55
@adrianludwin adrianludwin
hnc-v0.5.3-rc2
4b8e7a2
This commit was created on github.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
HNC v0.5.3 RC2 Pre-release
Pre-release

HNC v0.5.3 RC2 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-rc2
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: Install Krew if you don't have it already, then run the command kubectl krew install hns.

    • NB: Since Krew can only support one version of a plugin at a time, Krew will only support the v0.5.x plugins until v0.6 is released. These instructions will be removed when that happens, like in mid-late October.

  • Manually: Switch to any directory in your PATH (e.g. ~/bin) and run the following commands:

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

Full list of changes

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)

Full list of changes

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

Full list of changes

Testing signoff

Target Tests By Result
KIND 1.19 make e2e-test @adrianludwin passed Sep 29
GKE 1.17 (rapid channel) " @adrianludwin passed Sep 29
GKE 1.16 (regular channel) " @adrianludwin passed Sep 29
GKE 1.15 (stable channel) " @adrianludwin passed Sep 29
Assets 6
Loading

HNC v0.5.3 RC1

24 Sep 03:17
@adrianludwin adrianludwin
hnc-v0.5.3-rc1
6f44c1c
This commit was created on github.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
HNC v0.5.3 RC1 Pre-release
Pre-release

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

Target Tests By Result
KIND 1.19 make e2e-test @adrianludwin Passed
GKE 1.17 (rapid channel) " @adrianludwin Passed
GKE 1.16 (regular channel) " @adrianludwin Passed
GKE 1.15 (stable channel) " @adrianludwin Passed
Assets 6
Loading

HNC v0.5.2

27 Aug 19:08
@adrianludwin adrianludwin
hnc-v0.5.2
4df7070
This commit was created on github.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
HNC v0.5.2

HNC v0.5.2 includes several usability simplifications for subnamespaces relative to HNC v0.4, and maintains full backwards compatibility with the v1alpha1 API.

To install this release on your cluster, run the following commands:

HNC_VERSION=v0.5.2
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.2
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.

Changelog

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

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 a RoleBinding is quickly deleted and recreated with a new Role, HNC may fail to update it (#798)

Testing signoff

Target Tests By Result
GKE 1.17 (rapid channel) make e2e-test @adrianludwin Passed
GKE 1.16 (regular channel) " @adrianludwin Passed
GKE 1.15 (stable channel) " @adrianludwin Passed
Assets 5
Loading