k8s YAML

Kubernetes YAML is a human-readable text-based format for specifying configuration-type information. Using YAML for K8s definitions provides a number of benefits to users.

1. Convenience: Users no longer have to add all of their parameters to the command line.
2. Maintenance: YAML files can be added to source control, so that changes can be tracked.
3. Flexibility: Users can create much more complex structures using YAML relative to command line.

You can manage the lifecycle of K8s YAML based workloads using the Web Console or RCTL CLI or REST APIs. We strongly recommend that customers automate this either

• By integrating RCTL with your existing CI system based automation pipeline, OR
• By leveraging the integrated GitOps capability.

Create Workload ¶

You can create Kubernetes YAML based workloads using the Web Console or the RCTL CLI or REST APIs.

• Login into the Web Console
• Click on New Workload
• For K8s YAML:
  • Upload files manually: Upload YAML files directly from your local system.
  • Pull files from repository: Allow the controller to pull YAML artifacts from a Git Repository.
  • Pull file from URL: Provide a direct URL from which the controller can automatically fetch the YAML artifact.
• Select the namespace where you wish to deploy the workload

Option A: Pull from Repository ¶

This approach requires the user to first select the type of the Git repository. Then, in the next step

• Select the repository from the dropdown list
• Select the branch/revision in the Git repo (in this example, master)
• Specify the path for the YAML file (in this example, nginxyaml/nginx.yaml)

Option B: Upload K8s YAML ¶

For this approach, the user needs to upload the "K8s yaml" file to the Controller. After uploading the file, users are allowed to "download" the configured K8s yaml file if they wish to view it.

Option C: Pulling File From URL ¶

• In the URL field, provide the complete URL of the remote YAML file.
• The system will automatically fetch the artifact from the provided URL and associate it with this version.

In the example below, the workload named wl-weburl uses the K8s YAML package type and Pull file from URL artifact sync option. The YAML file is fetched directly from the specified GitHub raw content URL, and the workload will be deployed in the namespace ns-528327659.

Publish Workload ¶

• Selecting the placement policy for the workload
• Publish the workload

Once the workloads are published, the list of workloads can be viewed as shown below.

Unpublish ¶

To unpublish the workload, click on the "unpublish button". The deployed resources on the remote clusters will be automatically removed.

Important

If the remote cluster was offline when the unpublish operation was initiated, the Controller will send this instruction to the cluster when it reconnects.

Pod Metrics ¶

To have the managed prometheus addon scrape pod metrics, add the following annotations to the pods with these parameters

metadata:
  annotations:
    prometheus.io/scrape: "true"
    prometheus.io/path: /metrics
    prometheus.io/port: "8080"
spec:

Adjust the prometheus.io/path based on the URL from where the pod serves metrics. Set prometheus.io/port to the port from where the pod serves metrics. The values for prometheus.io/scrape and prometheus.io/port must be enclosed within double quotes.

Important

The collected metrics in Prometheus will be retained for 3 hours.

Actions ¶

Edit or delete one (or) more workload(s) using the respective icons from the main workloads list page. Follow the prompts to delete a workload.

Note: When modifying a published workload, republish it.

Debug ¶

At anytime during or after deployment, users can view the status and other information about their workload's K8s resources by clicking on Debug.