Pod

Overview

In Puzl, each GitLab pipeline job runs as a distinct Kubernetes pod, encapsulating and executing the job in its own isolated environment. A pod is the smallest and simplest unit in the Kubernetes object model. In the context of Puzl, each pipeline job is represented by a single pod, ensuring a seamless and efficient execution of your CI/CD workflows.

Platform Specifics

Services in Pipeline Jobs

Within each pipeline job pod, services defined in your GitLab pipeline configuration run in separate containers. This means if your pipeline job has multiple services, each service will run in its own container inside the pod, ensuring they operate independently but can still communicate with each other as they reside in the same network namespace.

KVM Sandbox

In addition to containers, Puzl spawns a KVM virtual machine inside each pipeline job's pod. This VM provides an additional layer of isolation and security, ensuring that the job runs in a controlled and consistent environment.

Read-Only Nature

For security and consistency reasons, all pipeline job pods in Puzl are set to be read-only for the user. This means that once a job is initiated and its corresponding pod is created, you won't be able to modify its configuration, compute resources or the file system during its lifecycle.

Accessing Pods

While you cannot modify a pod directly, you can access your existing pods via API. Use this command to get information on your pipeline pods:

kubectl get pods -n <Your_pipelineNamespaceRef>

Replace <Your_pipelineNamespaceRef> with the value taken from spec.runner.pipelineNamespaceRef of the related GitLabRunnerClaim object.

Further Reading

While we've tailored the pod experience in Puzl for CI/CD workflows, the underlying principles and mechanisms are based on native Kubernetes functionalities. To dive deeper into the intricacies of pods, their lifecycle, and advanced configurations, refer to the official Kubernetes documentation on Pods.