Learn GitOps with ArgoCD - Kubernetes & Manifest Management Recap

#Introduction

In episode 2 we dissected the ArgoCD architecture and understood that it's an operator that manages Kubernetes manifests. That means, before the hands-on part, we must be truly comfortable with the thing being managed: Kubernetes manifests, plus the two tools that turn plain manifests into flexible configuration — Helm and Kustomize. This episode is a recap that brings those three worlds together, and at the same time the technical preparation for episodes 4 through 8, which are entirely hands-on.

If you already know this material from other series, treat this episode as a quick reference. For those where it's still fuzzy, this is the right time to fill the gaps — because all the manifests here will be written and managed by you through ArgoCD.

#Review of Core Kubernetes Objects

These are the objects ArgoCD manages most often. The patterns you see here will repeat throughout the entire series.

#Deployment and Service

The most basic pair: a Deployment defines replicas and image; a Service opens a stable communication path:

Simple Deployment + Service

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: ghcr.io/arman/api:v1.2.0
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: api
  namespace: production
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 8080

#ConfigMap and Secret

Both separate configuration from the image. The main difference: Secret values are stored base64-encoded (not encrypted!) and have separate RBAC behavior:

apiVersion: v1
kind: ConfigMap
metadata:
  name: api-config
  namespace: production
data:
  LOG_LEVEL: "info"
  MAX_CONNECTIONS: "100"
---
apiVersion: v1
kind: Secret
metadata:
  name: api-secret
  namespace: production
type: Opaque
stringData:
  DB_PASSWORD: "s3cr3t-yang-harus-dikelola"

#Ingress and Namespace

An Ingress routes external traffic to a Service inside the cluster:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  namespace: production
spec:
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api
                port:
                  number: 80

A Namespace is a logical partition: production, staging, dev, or team-a. ArgoCD can be locked down to only deploy to specific namespaces via a Project (covered in episode 10).

#Helm Basics

Helm is the package manager for Kubernetes. It turns manifests into templates that can be parameterized.

The standard chart structure:

my-app/
├── Chart.yaml          # metadata chart (name, version, apiVersion)
├── values.yaml         # nilai default yang bisa di-override
├── values-prod.yaml    # nilai khusus environment
└── templates/
    ├── deployment.yaml # template Deployment
    ├── service.yaml
    └── _helpers.tpl    # named template helper

Inside templates/deployment.yaml, the parts that change are written as template expressions that read values.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Chart.Name }}
  namespace: {{ .Release.Namespace }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Chart.Name }}
  template:
    metadata:
      labels:
        app: {{ .Chart.Name }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

The default values in values.yaml can be overridden per environment with a -f values-prod.yaml file or --set image.tag=v1.3.0. Dependencies between charts are managed in Chart.yaml via dependencies:.

#Kustomize Basics

Where Helm uses templating, Kustomize uses overlays: the original definition (base) is never modified, other environments simply override parts via patches.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
namePrefix: prod-
patches:
  - target:
      kind: Deployment
      name: api
    patch: |
      - op: replace
        path: /spec/replicas
        value: 5
images:
  - name: ghcr.io/arman/api
    newTag: v1.3.0

Notice Kustomize's advantage: no template expressions are injected into the text; the end result is pure YAML that can be read directly. This preserves auditability — what's in Git is exactly what gets applied.

#Generators

Kustomize can also generate ConfigMaps and Secrets from files or literals:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configMapGenerator:
  - name: api-config
    literals:
      - LOG_LEVEL=info
      - MAX_CONNECTIONS=100

The advantage of generators: a small change produces a new hash suffix so the Deployment rolls automatically.

#Manifest Directory Organization

Without good organization, a manifest repository turns into garbage. Two patterns are common in the real world:

#Environment-Based

gitops/
├── base/                    # definisi netral semua aplikasi
│   ├── api/
│   │   ├── deployment.yaml
│   │   └── service.yaml
│   └── web/
│       └── deployment.yaml
└── overlays/                # kustomisasi per environment
    ├── dev/
    ├── staging/
    └── production/

#Application-Based per Environment

apps/
├── api/
│   ├── dev/
│   ├── staging/
│   └── production/
└── web/
    ├── dev/
    ├── staging/
    └── production/

#Closing

This episode refreshes three technical foundations:

• Core Kubernetes objects: Deployment, Service, ConfigMap, Secret, Ingress, Namespace.
• Helm: templating, per-environment values, and chart dependencies.
• Kustomize: base + overlays, patches, generators, and pure, auditable YAML.
• Directory organization patterns: environment-based or application-based.

With this technical foundation, we're ready to enter the installation phase. In episode 4 we'll install ArgoCD on your cluster: choosing the installation method, doing the initial setup, and opening its UI for the first time. See you there!