ExamFinch.com My Study

Study guide

11.2 GitOps & Package Management (Helm, Kustomize, Argo CD & Flux)

Practice this exam

Kubernetes and Cloud Native Associate KCNA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Exam Overview

1.1 About the KCNA Exam & Certification Path 1.2 How to Use This Study Guide

2 Chapter 2: Kubernetes Fundamentals - Cluster Architecture & the API

2.1 Kubernetes Architecture & Control Plane Components 2.2 Worker Node Architecture & Node Components 2.3 Kubernetes API, Declarative Management & kubectl 2.4 Kubernetes Releases, API Versioning & Deprecation Policy

3 Chapter 3: Kubernetes Fundamentals - Workloads & Configuration

3.1 Core Workload Objects (Pods, Deployments & ReplicaSets) 3.2 Advanced Controllers (StatefulSets, DaemonSets, Jobs & CronJobs) 3.3 Namespaces, Labels, Selectors & Annotations 3.4 ConfigMaps, Secrets & Application Configuration 3.5 Pod & Container Lifecycle, Restart Policies & Graceful Termination

4 Chapter 4: Kubernetes Fundamentals - Scheduling & Autoscaling

4.1 Scheduling, Resource Management & Node Selection 4.2 Advanced Scheduling: Affinity, Topology Spread, Priority & Disruption Budgets 4.3 Autoscaling Workloads & Clusters (HPA, VPA, Cluster Autoscaler, KEDA)

5 Chapter 5: Kubernetes Fundamentals - Cluster Administration & Extensibility

5.1 Kubernetes Distributions, Installation Tools & Managed Services 5.2 Cluster Administration: Node Maintenance, Upgrades & etcd Backup 5.3 Extending Kubernetes: CRDs, Operators & the Controller Pattern

6 Chapter 6: Kubernetes Fundamentals - Containerization

6.1 Container Fundamentals, Runtimes & Registries 6.2 Container Image Anatomy: Layers, Tags, Digests & Pull Policy

7 Chapter 7: Container Orchestration - Networking & Service Discovery

7.1 Kubernetes Networking, Services & Ingress 7.2 Cluster DNS & Service Discovery with CoreDNS 7.3 NetworkPolicies, Zero-Trust Segmentation & the Gateway API

8 Chapter 8: Container Orchestration - Storage

8.1 Storage Concepts (PVs, PVCs, StorageClasses & CSI) 8.2 Volume Types, Snapshots & Stateful Storage Operations

9 Chapter 9: Container Orchestration - Security

9.1 Kubernetes Security & Access Control (RBAC & ServiceAccounts) 9.2 The 4C's of Cloud Native Security & Supply-Chain Trust 9.3 Service Mesh, mTLS & Zero-Trust Service Identity

10 Chapter 10: Container Orchestration - Troubleshooting

10.1 Container Troubleshooting & Health Probes 10.2 Cluster & Node-Level Troubleshooting

11 Chapter 11: Cloud Native Application Delivery

11.1 Cloud Native CI/CD Pipelines & Build Tooling 11.2 GitOps & Package Management (Helm, Kustomize, Argo CD & Flux) 11.3 Deployment Strategies & Release Management 11.4 Progressive Delivery Automation: Argo Rollouts, Flagger & Feature Flags 11.5 Application Debugging & Developer Workflows in Kubernetes 11.6 Platform Engineering & Developer Self-Service

12 Chapter 12: Cloud Native Architecture - Observability & Principles

12.1 Cloud Native Observability (Logging, Metrics & Tracing) 12.2 Cloud Native Principles & Architecture Patterns 12.3 Serverless, FaaS & Event-Driven Architecture

13 Chapter 13: Cloud Native Architecture - CNCF Ecosystem & Community

13.1 The CNCF Landscape, Governance & Project Lifecycle 13.2 Cloud Native Community, Collaboration & Contribution

11.2 GitOps & Package Management (Helm, Kustomize, Argo CD & Flux)

Key Takeaways Explain This Topic AI

Continuous Integration (CI) automates code building, testing, and container artifact creation, while Continuous Delivery/Deployment (CD) automates deploying verified artifacts into target Kubernetes environments.

GitOps relies on Git as the single source of truth for declaratively defined infrastructure and application manifests, utilizing automated pull-based reconciliation loops to synchronize live cluster state with Git commits.

GitOps controllers like Argo CD and Flux continuously detect and correct drift between desired state in Git repositories and actual state inside Kubernetes clusters.

Helm serves as the package manager for Kubernetes, structuring applications into reusable Charts consisting of templates, values.yaml configuration files, and Chart.yaml metadata.

Kustomize provides template-free declarative configuration management built directly into kubectl (-k flag), allowing developers to customize base Kubernetes manifests using overlays without variable substitution files.

Last updated: August 2026

11.2 GitOps & Package Management (Helm, Kustomize, Argo CD & Flux)

Quick Answer: Modern cloud-native delivery pipelines combine Continuous Integration (CI) and Continuous Delivery (CD) to automate code building, container scanning, and manifest deployment. GitOps establishes Git as the single source of truth for declarative infrastructure and application manifests, utilizing in-cluster controllers like Argo CD or Flux to maintain automated pull-based reconciliation loops. Package management in Kubernetes is dominated by Helm, which packages resource templates into reusable Charts configured via values.yaml . Alternatively, Kustomize provides template-free manifest customization using declarative overlays directly integrated into kubectl .

Automating application delivery across multi-tenant Kubernetes clusters requires robust continuous delivery mechanisms, standardized package management, and declarative configuration tools. By shifting from manual imperative deployment scripts to declarative GitOps pipelines and modular Helm charts, cloud-native engineering teams achieve consistent, audit-compliant release automation.

Cloud-Native CI/CD Pipelines

Traditional Continuous Integration and Continuous Delivery (CI/CD) pipelines have evolved significantly to support microservices and containerized Kubernetes workloads. ┌─────────────────────────────────────────────────────────────────────────────┐

  • │ Cloud Native CI/CD & GitOps Pipeline │
  • ├─────────────────────────────────────────────────────────────────────────────┤
  • │ [1. Developer] ──► Push Code Commit to Application Git Repo │
  • │ │
  • │ [2. CI Pipeline] (GitHub Actions / GitLab CI / Jenkins) │
  • │ ├── Run Unit Tests & Code Linting │
  • │ ├── Execute Multi-Stage Container Build │
  • │ ├── Scan Image for CVEs (Trivy) │
  • │ └── Push OCI Image to Registry (Harbor / ECR) & Update Config Repo │
  • │ │
  • │ [3. GitOps Repo] ──► Declarative YAML / Helm Charts / Kustomize Overlays │
  • │ │
  • │ [4. In-Cluster Controller] (Argo CD / Flux) │
  • │ └── Continuous Reconciliation Loop (Pull Git State ──► Sync K8s Cluster) │
  • └─────────────────────────────────────────────────────────────────────────────┘
  • Where CI Stops and GitOps Starts

Section 11.1 covers the continuous integration half of this pipeline in detail — testing stages, Kubernetes-native pipeline engines, daemonless image builders, and pipeline security. The handover point is step 4 above: CI's final act is to commit an updated image reference into the configuration repository . Everything after that commit is this section's subject.

Continuous Delivery (CD): Push vs. Pull Model

Traditional CD pipelines operated on an imperative Push model , where the CI runner held administrative cluster credentials and executed kubectl apply commands directly against target Kubernetes API servers. In cloud-native architectures, this approach is largely superseded by the declarative Pull-based GitOps model .

GitOps Principles & Architecture

Coined by Weaveworks in 2017, GitOps is an operational framework that applies DevOps best practices—such as version control, collaboration, compliance, and CI/CD—to infrastructure automation and application lifecycle management.

The Four Core GitOps Principles

Declarative System Description: The entire desired state of the Kubernetes cluster (workloads, networking, RBAC, storage) must be specified declaratively using YAML, Helm, or Kustomize.

Git as Single Source of Truth: Desired system state is stored in version-controlled Git repositories. Any change to production must occur via Git commits or Pull Requests (PRs).

Automated State Pulling: Software agents running inside the cluster continuously pull the desired state from Git, eliminating external admin credential exposure.

Continuous Reconciliation Loop: In-cluster GitOps controllers continuously monitor cluster state. If the actual state diverges from the desired state in Git (known as drift ), the controller automatically reconciles the cluster to match Git (self-healing) or alerts operators.

  • Leading CNCF GitOps Tools
  • Argo CD (CNCF Graduated)

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. It runs as an in-cluster controller that monitors Git repositories and synchronizes applications across multiple clusters. Argo CD features a powerful web interface, visualizes drift, supports multi-tenancy, and handles Helm charts, Kustomize overlays, and plain YAML manifests.

Flux (CNCF Graduated)

Flux is a set of open-source continuous delivery solutions for Kubernetes powered by the GitOps Toolkit. Flux automates manifest reconciliation, monitors OCI registries for new container image tags, and updates Git manifests automatically.

Package Management with Helm

Managing raw, un-templated Kubernetes YAML manifests across multiple environments (development, staging, production) leads to code duplication and configuration sprawl. Helm is the official CNCF Graduated package manager for Kubernetes, providing application templating, versioning, and release management.

Helm Core Architecture & Concepts

Helm Chart: A packaged directory of pre-configured Kubernetes resource templates and metadata.

Chart.yaml : Manifest file containing chart metadata (chart name, description, version, appVersion).

values.yaml : Default configuration values injected into the chart's templates during rendering.

Templates ( templates/ ): Kubernetes YAML manifests containing Go template syntax (e.g., {{ .Values.replicaCount }} ).

Release: A specific running instance of a Helm Chart deployed into a Kubernetes cluster with configured values.

Helm Repository: An HTTP server storing packaged chart archives ( .tgz ) and a searchable index.yaml catalog. My-Chart/

  • ├── Chart.yaml # Chart metadata & versioning
  • ├── values.yaml # Default configuration parameters
  • ├── templates/ # Templated K8s manifests
  • │ ├── deployment.yaml # {{ .Values.image.repository }}
  • │ ├── service.yaml # {{ .Values.service.port }}
  • │ └── _helpers.tpl # Reusable template partials
  • └── charts/ # Chart sub-dependencies
  • Essential Helm CLI Commands
  • Chart Search & Repository Management # Add a public Helm repository
  • helm repo add bitnami https://charts.bitnami.com/bitnami
  • helm repo update
  • # Search repositories for charts
  • helm search repo nginx
  • Installing & Upgrading Releases # Install a chart release with default values
  • helm install my-web bitnami/nginx --namespace web --create-namespace
  • # Install/Upgrade using a custom values file
  • helm upgrade --install my-web bitnami/nginx -f custom-values.yaml --set replicaCount=3 -n web
  • Release Inspection & Rollbacks # List active releases in a namespace
  • helm list -n web
  • # Display revision history of a release
  • helm history my-web -n web
  • # Roll back a release to a previous revision
  • helm rollback my-web 1 -n web
  • # Uninstall a release and delete associated resources
  • helm uninstall my-web -n web
  • Kustomize: Template-Free Manifest Management

While Helm relies on variable substitution and Go templates, Kustomize provides a template-free mechanism to customize raw Kubernetes manifests using declarative overlay transformations. Kustomize is natively integrated directly into kubectl via the -k flag.

Kustomize Base & Overlay Pattern

Kustomize organizes application manifests into two layers:

Bases: Pure, un-templated Kubernetes YAML manifests containing common baseline configurations shared across environments.

Overlays: Environment-specific directories ( overlays/dev , overlays/prod ) containing kustomization.yaml files that patch, modify, or extend base manifests (e.g., changing replica counts, adding environment variables, or appending name prefixes). kustomize-app/

  • ├── base/
  • │ ├── kustomization.yaml
  • │ ├── deployment.yaml
  • │ └── service.yaml
  • └── overlays/
  • ├── development/
  • │ ├── kustomization.yaml # Patches replicas: 1, dev labels
  • │ └── dev-patch.yaml
  • └── production/
  • ├── kustomization.yaml # Patches replicas: 5, prod labels
  • └── prod-patch.yaml
  • Executing Kustomize with kubectl
  • To build and apply an overlay environment directly: # Apply the production overlay manifests directly
  • kubectl apply -k overlays/production/
  • # Render the compiled YAML output to stdout for inspection
  • kubectl kustomize overlays/production/
  • Helm vs. Kustomize Comparison

Use Helm when: Packaging third-party off-the-shelf software, publishing reusable packages to public registries, or requiring complex conditional template logic.

Use Kustomize when: Customizing first-party microservices across internal cluster environments without writing complex template syntax or maintaining separate value files.