Skip to main content

Repository

Advance Feature

This is an advanced feature that requires understanding Kubernetes manifests. Test locally before deploying. For simple, stateless applications, use the source type, image.

Using a repository source type to store application manifests enables version control, collaboration, and seamless integration with CI/CD pipelines. However, it is specifically intended for private Helm repositories hosted on Git. Therefore, it is necessary to use the 'repository' source type only if the Helm chart in the Git repository is private. For public Helm charts, the 'helm' source type can be utilized.

Register Private Git Repository

Application manifests located in a private repository require credentials. Please ask the administrator to configure them before using this source type.

name: "k8s-operator"
profileName: "default-profile"
namespace: "foo-service"
source:
  type: "repository"
  repository:
    repo:
      path: "charts/k8s-operator"
      releaseName: "k8s-operator"
      targetBranch: "main"
    values:
      files:
        # relative to the path prefix
        - "../values/values.yaml"
      type: files
    # values: 
    #   object: {}
    #   type: object

Manifest​

The provided above YAML snippet is an application resource manifest to deploy a helm respository that resides in the Git repository.

  • name: The name of the application.
  • profileName: The profile used for the application.
  • namespace: The name of the namespace where the applicwill be deployed. This field is optional and may be required based on the application's network configuration.
  • source:
    • type: The source type, which is "repository".
    • respository: Specifies the Helm chart details.
      • repo: Repository details for the Helm chart.
        • path:** Specifies the directory name where the Helm charts reside in the repository pointed by repoURL`.
        • releaseName: (Optional) Specifies the release name for Helm deployment.
        • repoURL: Specifies the URL of the repository.
        • targetRevision: Specifies the git branch or tag to use.
      • values: Specifies the values to override for the Helm chart.
        • object: Specifies additional value overrides as a YAML blob.
        • files: Points to the values.yaml file in the repositoy
        • type: Specifies the type of values pded, either object or files.

Overrides Helm Values with files?​

In our repository manifest example, the Helm chart for the Kubernetes operator is located under the charts/k8s-operator directory. This organization is intentional to ensure clarity and accessibility of our Helm charts. Here is a detailed overview of the directory structure within our Git repository, including the location of the values/values.yaml file.

k8s-repo/
└── charts/
    ├── k8s-operator/
    └── values/
        └── values.yaml
  • k8s-repo/: This is the root directory of our Git repository, containing all assets and code necessary for our Kubernetes deployments.
  • charts/: This folder acts as a container for all our Helm charts
  • k8s-operator/: Dedicated to the Kubernetes operator's Helm chart, this directory contains all the essential files for the Helm chart, including templates and a Chart.yaml file that defines the chart.
  • values/: the values directory is located directly inside the charts folder. It houses the values.yaml file, which is crucial for configuring theelm chart. This file allows users to specify configuration values that override the chart's defaults, enabling customization of the deployment according to specific requirements.

Given this structure, the ../values/values.yaml path is relative to the charts/k8s-operator directory, allowing it to correctly point to the values.yaml file.

Overrides Helm Values with blob?​

For scenarios where file-based overrides are not preferred, you can utilize the object type. This approach enables you to directly inject a YAML blob into the configuration, allowing for the override of any fields present in the default values.yaml file. Below is an example demonstrating how to override the name field with a custom value.

values:
  type: "object"  
  object: 
     name: k8s-operator-test
     ...

Deploy​

To deploy this YAML manifest using the astroctl command-line tool, follow these steps:

Save the YAML manifest to a file, for example, application.yaml. Use the following command to apply the manifest:

astroctl apply -f application.yaml

Validate​

The platform provides standard debugging subcommands part of the astroctl.

  1. Access the cluster directly and perform the necessary validations via kubectl command

    How to get the kubeconfig of the remote cluster? - Follow Cluster Context

  2. Run the following commands:
Status 
astroctl app status k8s-operator

Events,CD: If availabile

astroctl app events k8s-operator

Events, K8s: If availabile

astroctl app events k8s-operator -k

Logs: This will provide logs of all the pods running

astroctl app logs k8s-operatork8s-repo

For more, please check the Application subcommand part of the CLI

Upgrade​

For applications deployed using helm-charts, upgrades involve modifying the helm-charts directly in the Git repository (best practice is to create a Git pull request on the branch configured via the targetRevision). This can include changing the application version, updating container image tags, or altering configuration settings. The platform watches the repoURL path for changes and applies them to the Kubernetes cluster. Please note that it may take some time for the changes to be reflected.

Sync time

The sync time is currently around 3-5 minutes. Configuration options to control the sync time will be available soon.

Not all changes trigger application upgrade

Not all helm-chart changes trigger application upgrades, such as configmap changes. Custom logic is needed to reload the configmap.

Rolling Application Updates

In this mode, the application rolling updates are dictated solely by the manifest files. The platform has no control over this process.