Kubernetes Deployment

Minimum hardware requirements to satisfy at least a High Availability (HA) deployment are as follows:

These requirements can either be backed by physical machines (i.e. on-premises Docker Enterprise deployment) or using virtual machines (i.e. managed Kubernetes instances on Azure, AWS, Openshift, etc).

This section describes environment setup. I.e., required Operating System and software version requirements.

To setup the environment the following requirements must be fulfilled:

If necessary, see corresponding upstream project documentation.

This section describes component scaling considerations, i.e. what should scale and when and expected loads for sizing.

In the context of a Kubernetes cluster deployment there are two kinds of scaling: host scaling and component scaling. Host scaling refers to the number of host nodes (or Virtual Machines) backing the cluster and Component scaling refers to component (or container) scaling.

Host scaling should be executed when the backing nodes start experiencing either CPU, memory or I/O pressure, in which case a scale up operation should be considered and, conversely, when the nodes are using very few resources of the cluster a scale down operation may be considered.

Component scaling should be executed, or configured to execute automatically, for scale up operations when there is enough available host capacity and an increase on demand is expected. On the other hand, on low demand situations a scale down operation can be executed to free up resources to allow a host scale down.

The components that should scale are usually the Application Layer. Other components, like the relational database scaling should be considered only according to use case specifications.

Helm is a command-line interface (CLI) package manager. Helm uses a packaging format called charts. Where a chart is a collection of YAML files that describe a related set of Kubernetes resources.

eSign docker images are stored in a private registry, in order to download this docker images in the kubernetes cluster a image pull secret is created with the respective configuration and respective user/password.

However, for security reasons some clients may choose to use their own private registry. If so, in order to configure eSign to use the custom private registry, it is necessary to update the following chart structure.

eSign helm chart per default install and embedded H2 database.
This must not be configured in real environments, so you must use other database of your choice, specially for production environments.

In order to connect to a custom database, it is necessary to provide to eSign the necessary hibernate configuration to connect to this database (Refer to the Hibernate configuration section).

Bellow it is presented an example of this user-supplied values.yaml file.

Kubernetes init containers run in the same Pod as the main application container, though with a separate life cycle. The pattern is often used to initialize a state or configuration for the application running in the main container.

The same is applied in this solution, eSign init container as the purpose to verify if a custom database is running as is accepting connections.

Since as seen above it is possible to change repository images and database configurations, init container is also configurable to follow applied customizations.

A Security Context defines privilege and access control settings for a Pod or Container.

In Kubernetes hosts where SELinux or AppArmor is installed it may be required to define the for each container what permissions and users needed.

In order to configure each container security context the following fields may be added to the user-supplied values file. Helm template will copy all key-value pairs bellow the securityContext and podSecurityContext and copy them to the respective deployment spec.

A node selector specifies a map of key-value pairs. For the pod to be eligible to run on a node, the pod must have the indicated key-value pairs as the label on the node.

In order to do this for each Product Catalogue application the nodeSelector must be enabled, and the respective key-value pairs should be added.

When Kubernetes schedules a Pod, containers require enough resources (CPU and RAM) to run. If no resources are defined Pods will consume all resources available to the node and may interfere with other running applications.

Resource requests and limits are used to control the resources used by the pod. Resource requests are what the container is guaranteed to get in order to execute, if the available resources are not available the pod is not scheduled. The resource limits, is applied in order to guarantee that a pod does not cross a certain threshold.

eSign implements two container probes, the liveness and readiness probes.

The LivenessProbe, iIndicates whether the Container is still running. If the liveness probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy. If a Container does not provide a liveness probe, the default state is always Success.

While the ReadinessProbe, indicates whether the Container is ready to service requests. If the readiness probe fails, the endpoints controller removes the Pod’s IP address from the endpoints of all Services that match the Pod. The default state of readiness before the initial delay is Failure. If a Container does not provide a readiness probe, the default state is Success.

The default configuration for the probes can be edited within the following helm structure

The next set of configurations are application base and exclusive of eSign Core chart. The following configurations can be achieved by manipulating the default configmap or by creating a custom configmap with custom configuration. It is however, mandatory that this configmaps exist on the cluster and are correctly associated with eSign Core chart in order to guarantee the proper functioning of the application.

eSign helm charts do not install any ingress out-of-the-box. Which means, in case esign should be exposed to the internet, that for each environment/cluster it will be necessary to a route (openshift) or ingress rules must be created.

This ingress/routes should point to client-esigncore service in port 8080.

Scaling the application can be achieved by updating the number of running replicas, either by updating the default value of the number of replicas.

Or by manually update the number of running instances.