Certificate Hub runs on a Kubernetes system with the following requirements.

Kubernetes versions

Certificate Hub makes use of fairly generic Kubernetes capabilities. We endeavor to be as generic as possible in our deployment, and we do not require any special Operating System, Kubernetes, or Docker configuration that we are aware of.

• To our knowledge, Certificate Hub use of Kubernetes features is confined to open-source capabilities. Certificate Hub is supported on any active Kubernetes open-source version or commercial derivative.
• We officially support Certificate Hub operation on the current and prior two Kubernetes versions, consistent with generally accepted Kubernetes support policies. However, we have operated Certificate Hub on versions since 2018.

Kubernetes worker nodes

The number of Kubernetes worker nodes to use is a choice for our customers and depends on Certificate Hub and the other applications sharing the Kubernetes cluster. In our AWS environment, we run multiple instances of Certificate Hub, each in its namespace. Five nodes are sufficient for our roughly 20 development, quality assurance, and special-use instances. Not sure if these numbers are still valid. CertHub has grown, and we've had to scale back the number of environments we host.

Kubernetes pod instances

The Kubernetes deployment of Certificate Hub consists of the following pods.

In most deployments, one instance of each pod will be sufficient to handle the load. Certificate Hub load is proportional to the number of active users. Background tasks, such as discovery, source certificate retrieval, reporting, and renewal, do not constitute a heavy load.

The deployment scripts instantiate a single instance of each pod. You can modify this in the Kubernetes deployment by updating the replicas settings in the following file.

However, there are many other considerations for high availability.

Kubernetes Ingress

Certificate Hub assumes that your Kubernetes deployment includes an Ingress Controller. You must point this controller to the Entry Service, for example, by simply defining an Ingress. The Certificate Hub installation script will create an Ingress entry with the following name.

That should work in most cases. But, depending on your type of Ingress Controller, you may need to replace or modify this Ingress.

Certificate Hub expects all URL paths prefixed with a namespace. Traditionally this namespace is the Kubernetes Namespace of the Certificate Hub installation, but you can use any string that contains only letters and numbers. Certificate Hub will not function without this namespace prefix. The Ingress installed by the installation scripts defines a path with such a namespace prefix.

Kubernetes persistent volume

Set a persistent volume for the database where Certificate Hub saves the configuration, certificate data, and reports.

• In AWS deployments, you can generally resize this volume. Kubernetes provides volume expansion support, which we have verified to be effective in our Entrust AWS deployments of Certificate Hub.
• On Kubernetes platforms such as Azure, the storage setup templates may need to be modified.
• In other deployments, like on-premises deployments or deployments using stock PostgreSQL, set the volume size in advance because you cannot resize the database.

For example, a PersistentVolume for 1G is enough storage for 25,000 certs and a few weeks of reports.

To set the persistent volume

1. Define a persistent volume with enough storage size when Setting a local storage in Kubernetes.
2. Provide persistent volume claim size accordingly when Creating the Kubernetes environment.

Third-party command-line tools

Certificate Hub assumes the following third-party command-line tools are already installed.