Skip to main content

YAML

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.

YAML files offer a straightforward way to specify Kubernetes resources, granting detailed control over the configuration of applications. This method shines in situations where:

  • The creation of Helm charts is either impractical or unnecessary.
  • Modifications to Helm charts are needed after their initial setup.
  • There's a requirement to keep YAML files, which may be outputs from Helm templates, under version control in a Git repository.

The use of YAML files necessitates rigorous testing and deployment strategies to maintain both reliability and precision within your Kubernetes setup. Such configurations are invaluable for deploying applications with Kubernetes resources defined in YAML files and stored in a Git repository. They support the dynamic inclusion of resource definitions, enhancing flexibility across various deployment scenarios. The capability to selectively ignore certain files (e.g., Markdown files) while including others (e.g., all YAML files) offers meticulous control over the components that make up the application's infrastructure.

name: "my-yaml-application"
profileName: "default-profile"
source:
  type: "yaml"
  yaml:
    exclude: "*.md"
    include: "*.yaml"
    recursive: true
    repo:
      path: "path/to/yaml/files"
      repoURL: "https://github.com/my-org/k8s-manifests"
      targetRevision: "main"
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.

Manifest​

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

  • name: Specifies the name of the application, "my-yaml-application" in this case.
  • profileName: Indicates the profile to be used, here it's "default-profile". Profiles can dictate specific configurations or environments.
  • source: Defines the source of the Kubernetes resource definitions.
    • type: Set to "yaml", indicating that the source is YAML files.
    • yaml: Contains parameters for managing the inclusion and exclusion of files, as well as specifying the repository details.
      • exclude: A pattern for files to exclude, *.md in this example, meaning all Markdown files are ignored.
      • include: A pattern for files to include, *.yaml here, meaning all YAML files are considered.
      • recursive: A boolean indicating whether the search for YAML files should be recursive within the directory structure. true means it will search subdirectories.
      • repo: Specifies the repository containing the YAML files.
        • path: The directory path within the repository where the YAML files are located, "path/to/yaml/files" in this case.
        • repoURL: The URL of the repository, "https://github.com/my-org/k8s-manifests" here.
        • targetBranch: The branch, tag, or commit to use from the repository, with "main" specified in this example.

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

Not supported yet!

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

Upgrade​

For applications deployed using YAML files, upgrades involve modifying the YAML files 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.

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.