Kubernetes Deployment

This section describes how to deploy a project configuration created in nevisAdmin 4 to an infrastructure inventory. See Reference Deployment for information on how to install nevisAdmin 4 itself.

Overview

Required Elements to Deploy via Kubernetes

You need to set up the following main elements to be able to deploy via Kubernetes:

• A Kubernetes cluster.
• A Kubernetes inventory,containing credentials to connect to Kubernetes and Git.
• A nevisAdmin 4 installation. This installation can run within the cluster or outside of the cluster.
• A nevisOperator instance, which is deployed within the Kubernetes cluster.
• A Git deployment repository, which contains the generated configuration files.

For more detailed information, see Example Installation on Azure.

Deployment Process

Zero Downtime Deployment explains how nevisAdmin 4 performs seamless configuration changes and software updates without any service interruption.

In a nutshell, the deployment process is as follows:

1. nevisAdmin 4 combines configuration and infrastructure information to validate and generate the configuration files of the Nevis components.
2. nevisAdmin 4 publishes (pushes) the generated configuration files to the deployment repository.
3. nevisAdmin 4 connects to the Kubernetes cluster and creates or modifies the custom resources.
4. In the Kubernetes cluster, the nevisOperator will detect the respective changes and create the required actions for Kubernetes to start the deployment. The nevisOperator picks up the custom resources and creates child resources:

• The Nevis databases are initialized.
• Docker containers are started for each configured Nevis instance. Within the containers, the file-based configurations from the deployment repository are mounted.

5. During the deployment, Kubernetes will get the configuration files required for each Nevis component from the deployment repository.
6. Once the deployment in Kubernetes has finished, you will be informed by nevisAdmin 4.

Starting the Deployment

The deployment of a configuration project is executed with the Deployment Wizard. You can access the wizard from multiple places, as you can see in the next figure:

]

Accessing the Deployment WizardThe deployment can also be executed from the Deployment History as part of a rollback operation.

See Classic Deployment for information on how to rollback your project configuration.

Deployment Step 1: Select

In the first step of the deployment process, you select what you want to deploy:

]

1. Select a project in Select project on the left side of the wizard (no. 1 in the previous figure).
   1. Only the projects accessible by you are listed.
   2. Selection is mandatory.
   3. You can use the filter to search for a project.
2. Select an inventory in Select inventory in the middle of the wizard (no. 2).
   1. Only the inventories accessible by you are listed.
   2. The deployment wizard adopts the color of the selected inventory.
   3. Selection is mandatory.
   4. You can use the filter to search for an inventory.
3. Select how you want to deploy your services on the right side of the wizard (no. 3).
   1. If you have never deployed these services before, only the Primary option will be available.
   2. If these services have already been deployed at least once, you may choose to perform a Secondary (Canary, A/B) deployment instead. For more information, see Side-by-side deployment

All services are going to be deployed. Partial Kubernetes deployments are not possible.

Inventories marked with the warning icon can only be used with projects that are published. If your project is not published, you will not be able to proceed to Step 3 "Preview" after validation. For more information, see Publish Project and Inventory Required.

The next movie demonstrates the first deployment step:

Deployment Step 2: Validate

In this step, the Generation Engine generates the deployment artifacts such as the configurations files and service configurations. It then validates these artifacts against the selected inventory, showing the progress of the validation and providing you feedback immediately in case of any error.

If Validation Fails

If a setting is missing or something is wrongly configured, then this is visible in the wizard's Validation results list: All configuration elements with a problem are marked red. If you click these elements, the wizard shows the details of the problem, including links to the source of the problem. This gives you the opportunity to correct the missing or erroneous information and continue with the deployment process.

A general warning message appears when you try to deploy a project with an older version of the standard pattern libraries (see picture below).

You can correct this by navigating to the Project Settings, where you can edit theStandard libraries and select the Update to latest option.

Have a look at the previous figures as well as the following movie. Here, we validate the deployment of the project SIVEN-WEB-SHOP on the inventory TEST-STAGE-CLOUD.

The previously mentioned Validation results list shows the failed patterns (each representing a Nevis component instance) - see no. 1 in the [first figure].

Note that the validation results are shown per combination of Nevis component instance and service (that is, the Kubernetes service that will deploy the instances of the corresponding Nevis component). There are errors in the configurations of the nevisProxy instance Webshop WAF, the Authentication instance Webshop AUTH and the Logrend instance Webshop LOGREND. If you click on the pattern you can see the details of the error in the right part of the wizard (no. 2 in the first figure). In this case there are two errors:

• The Front End Path in the pattern Webshop WAF is empty, although it is required to set a value.
• The Front End Addresses in the pattern Webshop WAF is not defined in the inventory you are trying to deploy to.

Continue the Deployment with Warnings

It is possible to continue the deployment even if the validation of the configuration detected warnings. To continue deployment in this case, explicitly confirm that you want to deploy the instance patterns with warnings:

If Validation Succeeds

If nevisAdmin 4 did not find any issues and everything is fine, there are green check marks before each Nevis component instance/service combination. The following figure illustrates this:

At this point the project and inventory are validated successfully. The following options are available:

• If you want to move to the next step, click the Preview deployment button (no. 1 in the previous figure).
• If you want to see the details of the artifacts that were generated during the validation, click on the generation results here link (no. 2).
• If you want to repeat the validation, click the Repeat validation button (no. 3).
• If you want to change the project or inventory selection, click the Change selection button (no. 4).

Generation Results

If you want to view the generated deployment artifacts, click the link generation results here (see no. 2 in the previous figure). This opens the Generation results screen (see the next figure).

Additionally, you can view the details for each element in the list.

The Generation results screen consists of:

• The results tree (no. 1 in the previous figure):

• The selection details part (no. 2):

  The next figure shows the Details tab:

• The Expand files function (no. 3):

• The Download file function (no. 4):

• The Fullscreenfunction (no. 5):

If you are happy with the generated deployment artifacts and the validation has been successful, you can proceed to the next step in the deployment process.

Publish Project and Inventory Required

Some inventories can be restricted to allow deployment only if the selected project and inventory are published. See Restrict Deployment to Published Projects and Inventories Only to configure this setting.

Suppose you have set this restriction for the inventory you are trying to deploy to. If you also have local changes pending to be published, you will not be able to continue the deployment. The Preview deployment button will be disabled, and you will be requested to publish the local changes. Once you have done that, you can restart the deployment process. Deployment will be possible now.

The next movie demonstrates this process.

Deployment Step 3: Preview

During this step, nevisAdmin 4 compares the generated configuration files and service configurations with the currently valid files and service configurations on the Kubernetes cluster.

Deployment Preview

TheDeployment preview screen provides an overview of the deployment to be executed (see the next figure). It shows all the service configurations that will be created or modified on the Kubernetes cluster as well as the configuration files of each component.

The Deployment preview screen consists of the following elements:

• The deployment preview tree (no. 1 in the previous figure):

• Selection details on the right side of the screen (no. 2):

• The Expand files function (no. 3):

• The Show changes only function (no. 4):

  The next figure shows the Show changes only function:

**Show changes only function**

• The Download file function (no. 5):

• The Fullscreen function (no. 6):

  The next figure shows the Fullscreen function:

• The Repeat previewfunction (no. 7):

• The Force redeployment function (no. 8):

Preview of a Service Failed

If the preview generation for a service failed, you will be able to see the description of the failure in the Preview report screen:

The preview can fail due to:

• Issues connecting to the deployment repository. For example, the SSH connection failed.
• Issues connecting to the Kubernetes cluster. For example, the token in the inventory has expired.

Once you have solved the issue with the connection, you can click Repeat previewand continue the deployment.

If the preview generation of at least one service failed, you will not be able to continue with the deployment.

Deployment Step 4: Deploy

The final step in the deployment process is the actual execution of the deployment. Now, all generated configuration files are pushed to the deployment repository and the service configurations applied on the Kubernetes cluster.

In this step, the wizard has provided to the Kubernetes cluster all the data required to create all the Nevis instances that you configured in your project.

Once the deployment has finished, you see a report with the result of the deployment execution. This Deployment report lists both successful and failed deployments.

To view the deployment details, click the view log link in the figure above. The figure below shows an example of the log file: