Glossary

• Artifacts: Immutable outputs generated after a job, build, or deployment process. Examples include container images and Helm charts.

• Base Deployment Template: A pre-defined manifest that specifies the application's runtime behavior. It serves as a starting point for deployments, allowing you to customize values for specific environments.

• Build Context: The directory containing the Dockerfile and other files required for building a container image. By default, the root directory of the selected Git repository is used.

• Build Pipeline: A series of automated steps that transform source code into a deployable container image.

• Chart Store: A central repository for Helm charts used to deploy applications on Kubernetes.

• Cluster: A group of interconnected computers (nodes) that manage containerized applications using Kubernetes. Nodes provide resources and services to run, manage, and scale applications.

• Commit Hash: A unique identifier representing a specific version of source code in a Git repository.

• ConfigMaps: Kubernetes objects that store configuration data in key-value pairs. They separate configuration from application code, simplifying management and updates. Different ConfigMaps can be used for various environments.

• Container/OCI Registry: A repository for storing container images. It allows developers to share, store, and manage images used to deploy containers. OCI-compliant registries can also store artifacts like Helm charts. (OCI stands for Open Container Initiative, an industry standard for container formats and registries.)

• Cordoning: Temporarily marking a node as unscheduled, preventing new pods from being assigned to it.

• CronJob: A Kubernetes object used to create Jobs that run on a repeating schedule, commonly used for periodic tasks.

• DaemonSet: A Kubernetes object that ensures a specific pod runs on all or a designated set of nodes within a cluster, often used for tasks like logging or monitoring.

• Deployment Strategy: A defined approach for updating or changing applications. Devtron supports various deployment strategies like rolling updates, blue-green deployments, canary releases, and recreate strategies.

• Dockerfile: A script that defines how to build a Docker container image. It includes instructions to assemble the image's base, dependencies, and application code.

• Draining: Evacuating pods from a node before cordoning it, ensuring pods are gracefully rescheduled on other nodes.

• Environment: A deployment target, such as development, testing, or production. Applications can have different configurations for each environment, like the number of replicas or resource allocation.

• External Links: Links to external resources related to the application, such as Prometheus or Grafana, configured through Devtron's Global Configurations.

• GitOps: A methodology for managing and automating Kubernetes deployments using Git repositories as the source of truth. Changes to the desired cluster state are driven by Git commits.

• Helm Charts/Packages: Packages containing pre-configured Kubernetes resources and configurations used to define, install, and upgrade applications on Kubernetes clusters.

• Image: A packaged and standalone software containing the code and dependencies needed to run a containerized application. Devtron facilitates building container images, pushing them to registries, and deploying them on Kubernetes clusters. Images are platform-agnostic, eliminating the need for compiling applications for different systems.

• Job: A Kubernetes object used to create one or more pods to complete a specific task and then terminate.

• Load Balancer: Distributes incoming network traffic across multiple instances or nodes for efficient resource utilization and improved performance. In Kubernetes, a Load Balancer is a service type. The managed Kubernetes service connects to the cloud provider's load balancer service and creates a load balancer mapped to the Kubernetes service.

• Manifest: A YAML file describing Kubernetes objects and their desired state within the cluster. Applying a manifest instructs Kubernetes to create or modify resources to match the specified state.

• Material: The source code of your application in a specific Git commit.

• Namespace: A way to organize and isolate resources within a Kubernetes cluster, providing logical separation between applications or environments.

• Node Taint: A setting applied to a node that influences pod scheduling. Taints can restrict which pods are allowed to run on the node.

• NodePort: A Kubernetes service type that exposes a port on each node in the cluster, making a service accessible externally.

• Nodes: The physical or virtual machines that make up a Kubernetes cluster and where containers are scheduled to run.

• Pod: The smallest deployable unit in Kubernetes, consisting of one or more containers that share storage and network resources.

• Pre-build, Post-build, Pre-deployment, Post-deployment: Actions or processes performed before, during,