Skip to content

Packaging an Application in a Helm Chart

This topic describes how to package a cloud-native application, tool, or service into a Helm chartHelm is an essential application package manager that describes the structure of an application in a packaging format called charts. A Helm chart contains a bundle of the YAML configuration files needed to run an application, including dependencies and libraries..

The application repositories contain a collection of popular prepackaged applications, but you can also create a Helm chart from scratch to bring your own containerA standard packaging and distribution format that contains the Helm chart in an image file. The Helm chart executes when the container runs. and application to the platform. The Helm chart packages the application, making it ready to publish and share.

An application must be packaged in a Helm chart before you add can it to the application repository.

Megaport ONE provides a straightforward template that guides you through chart creation, eliminating the need to create multiple YAML filesStands for YAML Ain’t Markup Language, a file format used to configure Kubernetes pods, Services, and Deployments, arranged in a specific layout.. Because the template eliminates YAML coding, you can quickly deploy and share scalable, secure, and highly-available production applications.

Note

Helm charts not only make it easy to deploy an application but also to adjust particular settings and variables after you share the application.

When new versions of the installed package are available, Helm makes it easy to upgrade (or roll back) the installed package.

Helm chart overview

The Helm chart template requires these resource definitions:

  • Chart details such as name, version, and description.

You can further customize the Helm chart using these optional add-on resources:

  • Storage allocations for CPU and memory (RAM).
  • Deployments for replicating pods to scale an application as needed.
  • Service and Ingress for exposing the application as a service on a network, including securing it with a TLS secret name.

Creating a Helm chart

To create a chart

  1. Log in to the Megaport ONE Portal.
  2. Choose Compute > Applications.

  3. Click Deploy New Application.

  4. Select Create a chart from the Options menu.

    Create Helm Chart

    A list of managed repositories appears.

  5. Select the managed repository to store the chart in and click Confirm.

    If you need to add a managed repository, see Adding a Repository.

    Add Helm Chart Details

  6. Provide these chart details:

    • Name – Enter a name for the chart with a length of 1 to 63 characters. Use lowercase letters, numbers, or hyphens. Start and end the name with an alphanumeric character. Don’t use dots, spaces, or underscores.
    • Version – Enter the target Helm chart version. Version numbers use semantic versioning 2 (SemVer2) notation in the form of 1.2.3, where the first number represents the major version number, the second the minor, and the third the patch number. Helm uses version numbers as release markers.
    • Description – Enter a chart description that helps identify the resources in the chart, up to 250 alphanumeric characters. The description can include spaces and any of these characters:
      a-z + A-Z
      0-9
      ! @ # . $ % ^ & * () - _

    • Icon URL – If you want to add an icon to the chart, enter a publicly available URL to an SVG or PNG image file. The URL must start with https. For example, https://icon.example.com/helm.svg

  7. Select the check box to collect common resources in values.yaml (the default), or clear the check box if you don’t need to collect the resource values.

    The Global Resource option moves common fields from the Deployments, Services, and Ingress resources to the values.yaml file. Extracting the values provides an easy and flexible way for an admin with a working knowledge of Helm to create a template for less knowledgeable administrators to customize and deploy.

    For details on resources, see Managing resources for pods and containers.

    For details on the values.yaml file, see Modifying an application.

  8. If you aren’t going to add any more resources, click Finish Creating Helm Chart.

  9. Review the chart summary and click Confirm.

    The next step is to deploy an application in the Helm chart and select a cluster.

  10. Click Deploy.

  11. Complete the procedure To configure an application to add an application to the Helm chart and select a cluster.

Managing resources for pods and containers

A chart can optionally include a related set of Kubernetes resources that you configure to meet the application requirements. The most common is the storage resource that specifies how much memory (RAM) and CPU to reserve for a container that holds the application.

The other resources provide ways to ensure podA pod represents a group of one or more containers. reliability and expose the containerized application as a service to the network.

Reserving storage resources

A persistent volume claim (PVC) is a request to reserve a storage resource for a pod in a persistent volume (PV). PVCs consume PV resources.

PVC claims are optional.

You create a PVC by requesting a specific amount of storage and an access mode. For example, a 10 Gibibyte(GiB) A unit of computer information consisting of 1,024 megabytes. volume of high-speed, read-write storage. Kubernetes then looks for an appropriate PV to accommodate the request. When it finds one, Kubernetes claims a chunk of persistent storage for the pod by provisioning and binding to it. If Kubernetes can’t find a matching volume or it can’t create one, the PVC remains unbound until a matching volume becomes available.

Both stateless and stateful applications can use PVs.

Pod Volume

To request a PVC

  1. On the Create Helm Chart page, click Add Persistent Claim Volume.

    Create PVC Resource

  2. Enter a name for the PVC from 1 to 253 characters. Use lowercase letters, numbers, dots, or hyphens. Start and end the name with an alphanumeric character. Don’t use spaces or underscores.

  3. Click the up/down arrows to request a storage capacity in Gibibytes (GiB).

  4. Select an access mode to define the read/write and mount permissions:

    • ReadWriteOnce – Mounts the storage volume as read-write by a single nodeThe worker machines that applications run on..
    • ReadOnlyMany – Mounts the storage volume as read-only by many nodes.
    • ReadWriteMany – Mounts the storage volume as read-write by many nodes.
    • ReadWriteOncePod – Mounts the storage volume as read-write by a single pod. Use ReadWriteOncePod access mode to ensure that only one pod across the whole cluster can read that PVC or write to it. This is only supported for CSI volumes and Kubernetes version 1.22 or later.

    For details, see the Kubernetes documentation on Persistent Volumes.

  5. If you want to use a predefined storage class, enter the custom storage class name.

    By default, the PVC requests the default storage class for the provider, but you can enter a custom storage class. Storage classes differentiate the classes of storage offered and vary by provider. For example, administrators can provide a custom storage class to describe quality-of-service (QoS) levels or a storage class that provisions a premium Azure disk backed by premium SSD.

    For details, see the Kubernetes documentation on Storage Classes.

Managing pods using a Deployment resource

A Deployment is responsible for managing pods and keeping a set of pods running. Deployment resources provide declarative updates for pods. You declare your ideal system by setting the resource expectations in a Deployment. If the Deployment detects that the actual state of the system doesn’t meet these expectations, it intervenes to fix the problem.

  • Deployments are optional.

  • Deployments can use a predefined PVC to reserve storage resources.

Pod Reliability

To add a Deployment resource

  1. On the Create Helm Chart page, click Add Deployment.

  2. Enter a name for the Deployment with a length of 1 to 63 characters. Use lowercase letters, numbers, or hyphens. Start and end the name with an alphanumeric character. Don’t use dots, spaces, or underscores. For example, demo-deployment.

  3. Enter how many copies, or replicas, of the pod that Kubernetes should run concurrently.

    Deployment replicas provide pods with the ability to recover after failures, improving their overall reliability. You declare how many replicas you want and the Deployment monitors the pod continuously to make sure that the actual state of the cluster matches by running that number of replicas. If there aren’t enough, it starts new replicas and if there are too many, it stops the extras to maintain the expected state.

    The default value is 1. We recommend at least 2 replicas, because if you have only 1, any pod failure could result in downtime.

  4. Select the container registry credential types authorized to access the Deployment.

    To remove a credential, click it again.

    For container registry credential details, see Container credentials.

  5. To add a predefined PVC to the Deployment, click Add Volume.

    Provide these details:

    • Volume Name – A a volume description with a length of 1 to 63 characters. Use lowercase letters, numbers, or hyphens. Start and end the name with an alphanumeric character. Don’t use dots, spaces, or underscores.
    • Persistent Volume Claim – Select a predefined PVC from the drop-down list. To add a PVC to the list, see Reserving storage resources.

Adding a container and image to a Deployment

A Deployment pod can include a container, a container image, environmental variables, and secrets.

To add a container and image

  1. On the Create Helm Chart page, click Add Deployment.

  2. Click Add Container and select the General tab.

  3. Enter a name for the container with a length of 1 to 63 characters. Use lowercase letters, numbers, or hyphens. Start and end the name with an alphanumeric character. Don’t use dots, spaces, or underscores.

  4. For containers that need to run and complete before the application containers, select the Init Container check box. Init containers can prepare a configuration or make necessary changes to the environment before regular containers run.

  5. Enter the container imageA container image represents binary data that encapsulates an application and includes everything it needs when it is executed by a container runtime.
    Bring your own application container image and add the pathname to the image repository here.
    name. For example, cloudnative.demo.example/imagename.

    When you deploy an application from a container image, Kubernetes pulls the image from a repository. However, you might not want to pull from a repository but instead use an existing copy of the image on the node to save bandwidth costs and avoid rate limits.

    Note

    You can pull a container image from a private registry after providing the credentials to authenticate to the registry.

  6. Select a pull policyA policy that determines when Kubernetes pulls the image from remote storage. for the image:

    • Always - Always pull the image from the repository, even if it already exists on the node.
    • Never - Never pull the image from the repository, even if it doesn’t already exist on the node.
    • IfNotPresent - Only pull the image if it doesn’t already exist on the node.
  7. Enter the port number to use for container communication with the application. For example, 8080.

    This port number must match the target port number for a Service resource.

  8. Specify how much of each resource the container needs.

    • The memory (RAM) and CPU capacity requirements range in size from Extra Small to Extra Large.

    • Select custom to add your own RAM and CPU requirements and limits.

  9. Select Enable GPU to enable graphics processing unit (GPU) capabilities.

  10. Click Add.

Overriding container settings with environmental variables

One important feature of Helm is the ability to override configuration settings using variables. You can add environmental variables to change or override the settings in the values.yaml. You can always change the settings in the YAML file, but it can be easier to set a value for a variable on the Env Variables tab.

You can also add environment variables that reference a secret’s values.

  1. On the Create Helm Chart page, under Deployment, click the container name and select the Env Variables tab.

  2. Define the variable name and optionally assign it a value. For example, environment staging.

  3. Click Add.

Adding a secret to a container

To add a secret to a container

  1. On the Create Helm Chart page, under Deployment, click the container name and select the Secrets tab.

  2. Enter the environmental variable, secret key reference name, and the secret key reference key value as a plain text string.

    Note

    The system encodes the secret using a base64 representation.

    You can enter more than one key and value pair to a secret. For example:

    redis-password: aquest

    certificate-key: pjystn

    certificate-crt: abcdfg

Adding an annotation to a Deployment

An annotation is a key-value pair that provides metadata about a resource. Annotations let you tag Deployment resources with helpful information. For example, you can provide a contact name. Suppose you want to clean up resources that aren’t in use, but need to check with their owners first. Annotations provide a way to track down the resource owners to verify before deleting.

You can use annotations in many ways. For details, see the Kubernetes documentation on Annotations.

To add an annotation to a Deployment

  • On the Create Helm Chart page, enter an annotation name and value. For example, Name: FE-eng-team.com/owner Value: Front-end-app-dev-team

Tip

The difference between annotations and labels is that labels use metadata to identify resources and are used to group related resources. Annotations are for arbitrary, non-identifying metadata.

Adding a label to a Deployment

A label is a key-value pair that tags metadata to a resource. Labels identify resources, such as what application is running in a pod. A label on its own doesn’t mean anything to Kubernetes. The strength of a label comes when you use it with a Deployment selector to group and select resources by their labels. For example, a Service resource has a Deployment selector that identifies the pods it sends requests to. The Service targets the pods based on their labels.

For details, see the Kubernetes documentation on Labels.

To add a label to a Deployment

  • On the Create Helm Chart page, enter a label name and value. For example, Name: tier Value: frontend

  • Add as many labels as you need.

Exposing an application as a service on a network

You can expose an application as a service on a network so that other users can access it. To expose an application as a service, you define a Service resource. The Service resource determines how Kubernetes establishes communication between the service and the network.

  • A Service resource can forward traffic from any port to another port.

  • A Service resource can expose multiple HTTP services through a single ingress by tracking IP address changes and DNS names, and providing a single IP address or DNS name as an entry point for all requests to the pods in a Deployment.

  • Service resources are optional.

  • You need to create a Deployment resource before creating a Service resource.

To add a Service resource

  1. On the Create Helm Chart Page, click Add Service.

    Create Service Resource

  2. Enter a name for the Service with a length of 1 to 63 characters. Use lowercase letters, numbers, or hyphens. Start and end the name with an alphanumeric character. Don’t use dots, spaces, or underscores.

  3. Choose a Deployment Selector.

    The Deployment selector connects the Service to a Deployment, and the Deployment tells the Service what pods belong to it and how to route requests to particular pods.

  4. Select a Service type.

    • ClusterIP – Use for interservice communication within the cluster. This is the default setting.

      • Assigns a cluster-internal IP address to ClusterIP service. This makes the Service only reachable by components within the same cluster.

      • This is the most commonly used service type.

    • NodePort – Use to enable external connectivity to your Service.

      • This service type extends ClusterIP by automatically creating the ClusterIP service to route the NodePort Service to.

      • NodePort exposes the Service outside of the cluster by adding a cluster-wide port on top of ClusterIP. NodePort exposes the service on the IP address for each cluster node through a static port. Each node proxies that port into your service, so external traffic has access to a fixed port on each node. Any request to your cluster on that port gets forwarded to the service.

      • If you don’t include a port, Kubernetes assigns one automatically.

      • You can only use ports 30000 through 32767.

      • Before you specify a port, make sure that it isn’t already in use by another service.

    • LoadBalancer – Use when a cloud service provider (CSP) is hosting the cluster. This resource spins up a network load balancer that provides a single IP address that forwards all traffic to your service.

      • LoadBalancer extends NodePort and ClusterIP by automatically creating the ClusterIP service to route the NodePort Service to, enabling NodePort for external connectivity, and exposing the service externally using the CSP’s load balancer.

      • Each service you expose gets its own IP address.

      • The LoadBalancer Service type is dependent on the cloud service provider. Some CSPs provide their own load balancers in the environment your cluster is running.

    • ExternalName – Use to create a Service within Kubernetes to represent an external datastore, such as a database that runs externally to Kubernetes.

To add a port to a Service resource

  1. Click Add Port.

  2. Enter a port name using lowercase alphanumeric characters or -. Start and end the name with an alphanumeric character.

  3. Select an application protocol for a service port from the drop-down list:

    • TCPTransmission Control Protocol – You can use for any type of Service. This is the default setting.
    • UDPUser Datagram Protocol – You can use for most Services. For a LoadBalancer Service, you can use UDP if your cloud provider supports it.
    • SCTPStream Control Transmission Protocol – You can use for many Services, but check before enabling when a CSP is hosting the cluster. Most cloud providers do not support SCTP with a LoadBalancer Service.
  4. Enter the port number the Service is running on. For example, 80.

  5. Enter a target port for the Service to use to forward requests. For example, 8080. The target port must match the container port.

    In this example, once the container is running, any requests to port 80 are automatically forwarded to port 8080 on the container.

Ingress Deployment

Ingress resource

By default, Kubernetes isolates pods from the outside world. To communicate with a service running in a pod, you need to open an Ingress resource.

Ingress provides a powerful way to expose and handle many services outside of a cluster using an externally reachable HTTP or HTTPs URL. Ingress resources map HTTP or HTTP traffic routes outside of a cluster to different backend services, based on rules. The rules define which inbound connections reach which services. This resource consolidates your routing rules to a single resource.

Ingress works in combination with the Service resource to provide access to the pods, but runs as an independent resource to your service. Before setting up an ingress, you need to create a Service resource.

Ingress controllers, such as Nginix, work with the Ingress resource to accept traffic from the internet and load balance it to applications (usually in the form of running pods).

Note

An Ingress resource can also terminate Transport Layer Security (TLS) and route traffic to multiple hostnames at the same IP address.

Ingress resources are optional.

Ingress doesn’t support TCP or UDP.

For more details, see the Kubernetes documentation on Ingress.

To add an Ingress resource

  1. From the Create Helm Chart Page, click Add Ingress.

    Create Ingress Resource

  2. Enter a name for the Ingress resource, with a length of 1 to 63 characters. Start and end the name with an alphanumeric character. Don’t use dots, spaces, hyphens, or underscores. Use lowercase letters and numbers.

  3. Select an Ingress class to reference an IngressClass resource that contains additional configuration, including the name of the third-party controller that implements the class. For example, nginix.

    The Ingress controller evaluates and processes ingress rules and manages redirections. The controller provides an entry point to a cluster for all requests to the domain.

  4. If you want to use host-based routing, click Add Host.

    If you don’t provide a host, the rule applies to all inbound HTTP traffic through the IP address specified.

    Add Ingress Host

  5. Provide these details:

    • Host – Enter a specific hostname URL using lowercase alphanumeric characters and these characters: - . *

      For example, host.example.com

      The hostname must be a valid domain address.

    • Path – Enter a specific path to access your web server starting with /, alphanumeric characters, and these characters: - /

      Note

      The host and path must match the content of an incoming request before the load balancer directs traffic to the referenced Service.

    • Path Type – Enter a path type to specify how the system interprets an Ingress Object’s path.

      You must provide a path type as there is no default setting, and the validation fails without one.

      • ImplementationSpecific – Delegates the path prefix matching to the Ingress controller. For example, Nginx performs the HTTP(S) traffic routing.
      • Exact – Matches the URL path exactly (case-sensitive).
      • Prefix – Matches based on a URL path prefix split by /. Matching is case-sensitive and done on a path element-by-element basis.
    • Service – Select a predefined Service resource from the drop-down list.

    • Service Port – Enter a service port.
    • TLS Ingress Secret Name – If you want to use a a TLS private key and certificate to apply TLS termination, add a TLS secret name. When you add a secret, the Ingress controller secures the channel from the client to the load balancer using TLS. For details, see the Kubernetes documentation Ingress TLS.
  6. Click Add.

Adding an annotation to an Ingress

An annotation is a key-value pair that provides metadata about a resource. Annotations let you tag Deployment resources with helpful information. For example, you can provide a contact name.

You can use annotations in many ways. For details, see Annotations.

To add an annotation

  • On the Create Helm Chart page, enter an annotation name and value. For example, BE-eng-team.com/owner: "Back-end app development team"

Adding a label to an Ingress

A label is a key-value pair that tags metadata to a resource. Labels identify resources, such as what application is running in a pod. By itself, a label doesn’t mean anything to Kubernetes. The power of a label comes when you use it with a Deployment selector to group and select resources by their labels. For example, a Service resource has a selector that identifies the Pods it sends requests to.

For details, see the Kubernetes documentation on Labels.

To add a label

  • On the Create Helm Chart page, enter a label name and value. For example, Name: tier Value: frontend

  • Add as many labels as you need.

To finish the chart

  1. When the Helm chart is complete, click Finish Creating Helm Chart.

  2. Click Confirm.


Last update: 2023-04-25