Enhanced Kubernetes Features

As part of the 2.3.0 release, Nirmata has incorporated several features to provide enhanced Kubernetes cluster management.

Volume Claim Snapshot Overview

Volume Claim Snapshot creates a snapshot from an existing volume. This snapshot backs up the data on the volume which can then be used to create a different volume based on the same data. Use of this feature requires that a volume snapshot custom resource definition (CRD) is present on the cluster. The snapshot is vendor-specific and is not a Kubernetes Snapshot.

How to Add a Volume Claim Snapshot

To create a new Volume Claim Snapshot, select and open the Environment.

image

Click on the Storage & Configuration tab and select Create a Volume Snapshot. Complete the information in the Create Volume Snapshot wizard. Click Add.

image

Custom Resource Definition Support Overview

Custom Resource Definition (CRD) Support allows cluster customization within Nirmata. CRDs can be created and supported within Nirmata.

How to Add a New CRD

To create a new CRD, select Catalog from the sidebar menu.

Click the +Add CRD button and upload a CRD manifest. Note that the CRD manifest must be in YAML format.

image

Resource Quota & Limit Range Overview

In Kubernetes, Resource Quota provides constraints that limit aggregate resource consumption per namespace. It can limit the quantity of objects that can be created in a namespace by type, as well as the total amount of resources that may be consumed by resources in that namespace.

If a resource quota is configured, then it is required that every incoming pod/container makes an explicit request for the required resources. If a resource request is not configured, the pod creation request is rejected. A Limit Range can be used to force defaults for pods that don’t specify resource requirements.

Support of Resource Quota and Limit Range within Nirmata allows users to allocate the resources of a cluster to specific teams or applications.

Resource Quota and Limit Range enables cluster resources, including CPU, memory, PVCs, and a variety of other quantities, to be divided between multiple teams or applications.

Nirmata checks the quantities used at the specified level. If the quantity is found to be above the specified threshold for more than three minutes, an alarm is raised in Nirmata.

Admin or platform user can specify the Default Resource Quota for an environment. This will be applied to any application/namespace that does not specify one.

image

Resource Quotas set at the Environment level are not hard limits and will not prevent applications from running. Instead, when running an application exceeds the Resource Quota limits, an alarm is raised.

How to Set a Limit Range

Limit Range can be added to most Kubernetes resources but most often it is added to Container, Pod, PersistentVolumeClaim. Default values are required in the limit range for environments that use resource quotas so that any container that does not specify resource requests/limits can use the defaults.

To apply a new Limit Range, create an Environment in Nirmata by selecting Environments and then the +Add Environment button. Complete the Add Environment wizard.

Isolation Level Definitions
Shared NameSpace All applications deployed in the environment are in the same namespace; each application can only be deployed one time
Namespace per Application Each application can be deployed multiple times; deployment occurs within the application’s own Environment

image

After creating the Environment, open the Environment settings and select Add Limit Range.

image

Specify the appropriate Default Limits to be applied at the container level. Each Default Level is the quantity that the container is guaranteed to have at start-up.

Default Request values are the quantities applied to containers that do not specify a request quantity. A Default Request is the minimum value for the specified resource and is applied to containers deployed in the environment.

Click the Add button after completing each Limit Range quantity.

image

How to Set a Resource Quota at the Environment Level

After setting a Limit Range at the container level, Resource Quotas can be defined at the Application Level and the Environment Level.

To add a Resource Quota, select Add Resource Quota from within the Environment Settings. Kubernetes compares current application usage levels to the defined Resource Quotas.

image

image

image

How to Set a Resource Quota at the Application Level

To set a Resource Quota at the Application level, select the Application from the Catalog and then click on the Deployment.

image

Select the Containers to which the Resource Quota will apply.

image

Click Add Resource Requirements.

image

Understanding Resource Quota Errors

If the pod deployment fails when the resource quota is exceeded, the error details are displayed in Status.

For example, in a deployment, ReplicaFailure will display. View the details by clicking on the condition.

image

Understanding Resource Quota Alarms

Nirmata generates the following alarms when resource quotas exceed the configured thresholds:

  1. Resource Quota CPU Usage: This alarm is triggered when the allocated CPU request is greater than the threshold.

  2. Resource Quota Limits CPU Usage: This alarm is triggered when the allocated CPU limit is greater than the threshold.

  3. Resource Quota Limits Memory Usage: This alarm is triggered when the allocated memory limit is greater than the threshold.

  4. Resource Quota Memory Usage: This alarm is triggered when the allocated memory request is greater than the threshold.

Compute Resource Quotas

Compute Resource Quotas
cpu Across all pods in a non-terminal state, the sum of CPU requests cannot exceed this value.
limits.cpu Across all pods in a non-terminal state, the sum of CPU limits cannot exceed this value.
limits.memory Across all pods in a non-terminal state, the sum of memory limits cannot exceed this value.
memory Across all pods in a non-terminal state, the sum of memory requests cannot exceed this value.
requests.cpu Across all pods in a non-terminal state, the sum of CPU requests cannot exceed this value.
requests.memory Across all pods in a non-terminal state, the sum of memory requests cannot exceed this value.

Storage Resource Quotas

Storage Resource Quotas
requests.storage Across all persistent volume claims, the sum of storage requests cannot exceed this value.
persistentvolumeclaims The total number of persistent volume claims that can exist in the namespace.
.storageclass.storage.k8s.io/requests.storage Across all persistent volume claims associated with the storage-class-name, the sum of storage requests cannot exceed this value.
.storageclass.storage.k8s.io/persistentvolumeclaims Across all pods in a non-terminal state, the sum of memory requests cannot exceed this value.

Object Count Quota

Resource Quota can be added for any namespaced resource using the syntax:

count/<resource>.<group>

Following resources are supported:

Supported Resources
configmaps The total number of config maps that can exist in the namespace.
pods The total number of pods in a non-terminal state that can exist in the namespace. A pod is in a terminal state if is in Failed, Succeeded phase.
persistentvolumeclaims The total number of persistent volume claims that can exist in the namespace.
replicationcontrollers The total number of replication controllers that can exist in the namespace.
resourcequotas The total number of resource quotas that can exist in a namespace.
services The total number of services that can exist in the namespace.
services.loadbalancers The total number of services of type load balancer that can exist in the namespace.
services.nodeports The total number of services of type node port that can exist in the namespace.
secrets The total number of secrets that can exist in the namespace.

Jobs are actions created and added to an application to run once.

Most commonly, Jobs are used to cleanup after an application runs, to run security before deploying an application, or to perform one-time setup operations.

It is possible to add multiple jobs to a single application.

CronJobs in Nirmata are equivalent to CronJobs in Linux. Using CronJobs, users can schedule jobs to be performed at predetermined intervals. CronJobs are most commonly used to create current snapshots and to backup snapshots.

How to Create a Job in an Application

To add a Job to an application, open the application and select Add a Job.

image

Complete each tab of the Add a Job wizard.

image

image

image

How to Create a CronJob in an Application

To add a CronJob to an application, open the application and select Add a CronJob.

image

Complete each tab of the Add a CronJob wizard.

image

image

image

API Versioning

Nirmata supports the current release of Kubernetes plus three prior releases. The current default Kubernetes version in Nirmata is 1.12. Users can install and deploy unsupported versions; however, Nirmata has only tested and validated those versions listed below.

Kubernetes 1.11 Kubernetes 1.12 Kubernetes 1.13
Nirmata 2.2.0 Yes Yes No
Nirmata 2.3.0 Yes Yes No
How to Use Other Kubernetes Versions

Other versions of Kubernetes may be deployed with Nirmata. However, it is recommended that non-supported versions be deployed only outside of production environments.

Change Management

Nirmata automatically synchronizes data for every resource cluster.

image

#### HashiCorp Vault Integration