Hopefully many readers will have seen yesterdays announcement around Tanzu Community Edition, or TCE for short. I mentioned the fact that there are numerous community packages available in this new, free, open sourced version of Tanzu Kubernetes. Package management in TCE is achieved through a suite of tools bundled under the Carvel brand. In this post, I am going to describe some of the nuances around the deployment of these packages in a TCE cluster. There are 3 package components that need to considered when dealing with packages in TCE. There are (1) the repository, (2) the package install resources and (3) the actual package objects themselves (pods, replicas, services, etc). While there are a number of package deployment guides in the official TCE documentation, these are typically deployed using the default settings for the package package repository, the package install resources as well as for the deployed package objects. However, all of these can be changed as needed. Let’s look at how to do that.
1. Installing repository to the default namespace
Before being able to access the community packages, the repository needs to be added to the cluster. Here is sample command which demonstrates how to do this, but which does not specify any namespace. Thus the repository is installed in the default namespace.
In this case, the repository is installed in the default namespace. If querying the repository, there is no need to provide a namespace on the command line since the repository query is run against the default namespace. The following conditions now apply when the repository is installed in the default namespace:
- The namespace where the package install resources are placed must also be the default namespace.
- The namespace where the package objects are installed may be specified in a values manifest provided via the command line.
In the example below, the certificate manager community package is getting installed. Note that the default namespace is specified on the command line, but this is not necessary. I am also not specifying any package object namespace target through a values file, so certificate manager objects are getting installed in their automatically selected namespace which is tanzu-certificates.
If you wished to deploy the certificate manager objects to different target namespace other than tanzu-certificates, then the target namespace can be specified in a values file that is passed to the installer on the command line. In the command below, the package install resources namespace is changed to my-certificates via the values file provided on the command line. Note that the package install resources are still being deployed to the default namespace, as this is where the repository has been installed.
The key point to make here is that the repository and the package install resources must be in the same namespace, whilst the package objects target namespace may be controlled via a namespace attribute specified in the values.yaml file.
Note: The same is true if the repository is installed in a non-default namespace. The package install resources must also be installed in the same non-default namespace. Again, the package objects deployment namespace can be controlled via the values.yaml file. But if you try to install the package install resources to a namespace that is different to where the repository is installed, you will observe the following “not found” failure:
% tanzu package install certmgr -p cert-manager.community.tanzu.vmware.com -v 1.5.1 -n my-pkgs / Installing package 'cert-manager.community.tanzu.vmware.com' | Getting namespace 'my-pkgs' | Getting package metadata for 'cert-manager.community.tanzu.vmware.com' Error: failed to find a package with name 'cert-manager.community.tanzu.vmware.com' in namespace 'my-pkgs': \ internalpackagemetadatas.internal.packaging.carvel.dev "cert-manager.community.tanzu.vmware.com" not found
The only time that the package repository and the package install resources can be in different namespaces is if the repository is installed in the tanzu-package-repo-global namespace. Let’s look at that next.
2. Install repository to the tanzu-package-repo-global namespace
Now I can place the package install resources in a completely different namespace to the repository, if I so wish. In this example, I am creating a new namespace called my-pkgs and I am placing the certificate manager package install resources in that namespace.
- The namespace where the package install resources are installed does not need to be the same as the repository.
- The namespace where the package objects are installed may be changed in values manifest.
The key point to make here is that the repository and the package install resources do not need to be in the same namespace if the repository is installed in the tanzu-pkg-repo-global namespace , whilst the package objects target namespace may be controlled via a namespace attribute specified in the values.yaml file. As a final example, here is the certificate manager package install resources being deployed to the my-pkgs namespace while the certificate manager objects themselves are being deployed to their own namespace, called my-certificates.
To conclude this post, please keep in mind that in this initial release of Tanzu Community Edition, you can only deploy package install resources to a namespace that is different to the repository namespace when the namespace that holds the package repository is tanzu-package-repo-global. Otherwise package install resources are always deployed to the same namespace as the repository. Lastly, package objects can be deployed to different namespaces by modifying the values file in either case.