Environments Menu
Kubernetes

Templates (Kubernetes)

8min

Save valuable time and reduce the risk of errors from one centralized place. Templates enable you to customize everything needed to fit your pipeline needs. Define it once and use it multiple times!

Overview

Collaboration, communication, and integration play a vital role in achieving success in the DevOps landscape. By focusing on these elements, teams can enhance their performance and ensure the quality of their processes and pipeline. These aspects are critical for achieving high performance and quality assurance, and by optimizing them, teams can experience a positive impact on their overall efficiency and effectiveness.

With this in mind, Kubeark makes use of Templates. Templates in Kubeark are pre-constructed configurations that include all the resources necessary to run a specific workload or application. They are designed to save time and reduce errors when scaling, by providing all the necessary infrastructure, platform, and software components. They are easy for users to implement and get started with.

The Templates page within the Kubeark Platform offers an intuitive, easy-to-use interface for defining and managing templates. There are two types of templates that Kubeark uses to enable a smooth experience with your projects. Going further, let's see what these are:

Manifests

A Kubernetes manifests represents the specification of an API object in JSON or YAML format. In a manifest you can specify a desired state of an object that Kubernetes will create and maintain when the manifest is applied to the specific Kubernetes cluster.



Charts

A chart represents a collection of files that describe a related set of Kubernetes API objects or resources. The template language of a chart is implemented in typed Go programming language


Document image



How does it work?

In order to define a template in Kubeark, there are a few important object types that we need to consider:

The main arguments section

These are mandatory inputs that need to be provided in order to define a functional deployment. Arguments will enable you to define what values can be passed along to your pipeline.

Argument

Description

Name

This is the unique name of the defined template

Template group

The template group to which the new template will belong

Cluster group

The cluster group to which the new template will belong

environment_action

This argument allows adding business logic for the environments lifecycle, and can be defined through: -> terminate - This is when the environment is terminated when the default_time, additional_time and grace_time reach 0 seconds

-> Manual 

-> Stop

-> Terminate - This downscales to 0 all the resources that can be scaled to 0 (e.g. DeploymentsStatefulSetsReplicaSets, etc)

Status

The template status is an unique value from an allowed list of values. These can be:

->Active - Production ready 

->Disabled - In development

Scope

This is a boolean value which defines the type of template based on your collaboration preferences or needs:

-> public - the endpoint is exposed in the public templates list

-> private - templates are exposed internal only

Owner

This field defines the user which created the template

Tags

Option to add a custom tag to your template for easy reference

Description

Add a custom description about the template

default_time

Represents the default time until an environment_action is triggered. The logic behind this parameters is that we want on-demand disposable containers triggered by external or internal actions like paying an invoice, closing or opening a contract, etc

additional_time

Represents an additional time when the default time is reached. This is used as a failsafe mechanism before triggering the environment_action

grace_time

Represents the grace period before the environment is deleted or terminated







Extra-Arguments

These are additional arguments that can be added which offer you more control over the values that can be passed to your pipeline. They are designed to encapsulate dynamic or specific template arguments.

Form composer - When creating a template, you have the option to provide additional details using a form composer. The form composer can be used from the main template creation page by selecting the "Insert Field" button.

Document image


Here are some of the fields you can include:

  • Key: A unique identifier or name for the field.
  • Id: An identifier that helps uniquely identify the field within the form.
  • Name: The name or label of the field as it will appear in the form.
  • Title: A title or description that provides further information about the field's purpose.
  • Input Type: Specifies the type of input expected in the field, such as "text" for plain text input.
  • Min Length and Max Length: Define the minimum and maximum lengths allowed for the input in characters.
  • Label: A descriptive label for the field, providing context or guidance to the user.
  • Pattern: If applicable, a regular expression pattern that defines the expected format for the input.
  • Value: An initial or default value for the field, if needed.
  • Disabled: A boolean (true/false) value indicating whether the field is initially disabled or not editable.
  • Required: A boolean value specifying whether the field must be filled out by the user

Example: Let's consider a web service solution with an ingress where a different ingress endpoint for each deployment is required. Here you will define an argument with a default value which can be overridden at the deployment step.

Chart information - this section includes essential details related to charts and repositories in the context of Kubeark template creation

Document image


The arguments you can include:

  • Chart Information Name: A user-defined name or identifier for the chart. It helps users easily recognize and reference the specific chart associated with the template.
  • Repository Name: The name of the repository or source where the chart is hosted.
  • Repository URL: The repository URL specifies the web address or location where the chart repository can be accessed.
  • Path: The path field defines the directory or subdirectory within the repository where the specific chart files are located.

Additional parameters - Variables are used to generate random data. You can use them in the values field of the additional parametewrs section. You can combine them with any other values.

For example, {{set_string}}-test the result will be a random string followed by the word test. You can also use them in a payload from a value of extra arguments, combined with other values or predefined variables.

The following predefined variable categories are available:

->Infra

->User

->Function

Additional parameters can also be added, the platform supporting various formats such as string, numeric, JSON, Code, List or Boolean

Updated 25 Mar 2024
Doc contributor
Did this page help you?