Restrictions in Kubernetes Setups

This page describes restrictions when deploying to Kubernetes.

Inventory

• Inventory secret file attachments cannot exceed 1 MB in size. In Kubernetes deployments, it is not possible to transfer files larger than 1 MB to the cluster as Kubernetes secrets. As a workaround, you can upload files that do not contain sensitive information via the Attach files feature. Alternatively, if you do not need to deploy to Kubernetes, you can increase the value of the property nevisadmin.secret.max-file-size.
• If you update the value of a secret, secret file, or non-secret file, subsequent rollback deployments to Kubernetes will use the updated value.

Zero Downtime Deployment

• Users of the nevisAdmin Administration GUI will lose their sessions after redeployment.
• If using automatic key management, during redeployment, automatic certificate renewal occurs. As a result, some users may experience errors until all pods are updated to the newest certificate configuration.
• If you deploy changes that are not backward compatible, some users may experience errors because during zero downtime deployment, old and new instances (pods) communicate freely.
• To make sure ongoing connections are not interrupted, the old instances are kept alive until all connections are closed, which results in higher resource usage during the redeployment process. The time during which the components are kept alive will be shortened in the future.
• Automatic nevisIDM DB schema upgrades are only supported for MariaDB, not for Oracle. Zero downtime deployment is supported in combination with manual Oracle database schema upgrades as described in the nevisIDM technical documentation, section General Upgrade Instructions.

Side-by-Side Deployment

• The first redeployment of a project after promotion from side-by-side deployment causes a restart of nevisProxy instances, even if there is no configuration change related to the nevisProxy instances.
• Do not change the namespace after the first deployment. This is because the primary and secondary deployments must be in the same namespace.
• Do not use the same namespace for multiple inventories. This is because the promotion and rollback of the secondary deployment affects the whole namespace.
• Avoid deleting the related inventory. This is because the deployment history is based on the inventory, and the side-by-side deployment depends on the deployment history. If the inventory is deleted, the history information will be lost.
• Only Import as Existing inventory is supported. This is because the deployment history is based on the existing inventory, and not saved in the exported inventory.

Nevis components

nevisProxy

• As TLS termination is done by the Ingress, the following limitations apply to client certificate authentication:
  • Clients have to support SNI.
  • Client certificate authentication is done by the NGINX Ingress controller, for more information, see the NGINX Ingress Settings pattern.
  • As NGINX propagates the client certificate in the ssl-client-cert header, the used nevisAuth states which validate the client certificate have to be adjusted to use this as a source for verification. The nevisIDM Client Certificate Authentication pattern does this automatically.
  • NGINX client certificate authentication options, such as whether a certificate is required or optional, can only be configured per Virtual Host, which means different paths on the same domain cannot have different settings. This does not affect further verification such as the X509 states.
• Multiple virtual hosts per nevisProxy instance (Kubernetes service) is supported through SNI. Custom bind addresses are not supported.

nevisIDM

• Outgoing port 25 is blocked on Azure. Thus, a different port has to be used for SMTP.
• Only remote JMS Message queue is supported.