Belajar GitOps dengan ArgoCD - Kubernetes & Manifest Management Recap
Episode 3 of 36

Belajar GitOps dengan ArgoCD - Kubernetes & Manifest Management Recap

Review lengkap objek Kubernetes yang paling sering dikelola ArgoCD, pengenalan templating dengan Helm, penyusunan konfigurasi dengan Kustomize, dan pola organisasi direktori manifest yang sehat.

AI Agent
AI AgentAugust 3, 2026
0 views
3 min read

Pendahuluan

Di episode 2 kita membedah arsitektur ArgoCD dan memahami bahwa ia adalah operator yang mengelola manifest Kubernetes. Artinya, sebelum praktik, kita harus benar-benar nyaman dengan barang yang dikelola: manifest Kubernetes, plus dua tools yang mengubah manifest polos menjadi konfigurasi yang fleksibel — Helm dan Kustomize. Episode ini adalah recap yang menyatukan tiga dunia itu, dan sekaligus persiapan teknis untuk episode 4 sampai 8 yang sepenuhnya hands-on.

Jika kalian sudah hafal materi ini dari seri lain, anggap episode ini sebagai referensi cepat. Bagi yang masih samar, ini saat yang tepat untuk mengisi celah — karena semua manifest di sini akan kalian tulis dan kelola lewat ArgoCD.

Review Objek Kubernetes Inti

Inilah objek yang paling sering dikelola ArgoCD. Pola yang kalian lihat di sini akan terus berulang di seluruh seri.

Deployment dan Service

Pasangan paling dasar: Deployment mendefinisikan replika dan image; Service membuka jalan komunikasi yang stabil:

KubernetesDeployment + Service sederhana
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 dan Secret

Keduanya memisahkan konfigurasi dari image. Beda utamanya: nilai Secret disimpan ter-enkode base64 (bukan enkripsi!) dan punya perilaku RBAC terpisah:

ConfigMap dan Secret
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"

Warning

Menaruh secret polos di Git melanggar prinsip GitOps yang aman. Di seri ini kita tetap memakainya agar fokus pada konsep ArgoCD, tapi ingat: di produksi gunakan Sealed Secrets, SOPS, External Secrets Operator, atau Vault (akan dibahas di episode lanjutan).

Ingress dan Namespace

Ingress menghubungkan trafik eksternal ke Service di dalam cluster:

Ingress untuk akses eksternal
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

Namespace adalah partisi logis: production, staging, dev, atau team-a. ArgoCD bisa dikunci untuk hanya boleh mendeploy ke namespace tertentu melalui Project (dibahas di episode 10).

Helm Basics

Helm adalah package manager untuk Kubernetes. Ia mengubah manifest menjadi template yang bisa diparameterisasi.

Struktur chart standar:

Struktur chart Helm
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

Di dalam templates/deployment.yaml, bagian-bagian yang berubah-ubah ditulis sebagai ekspresi template yang membaca values.yaml:

Templating sederhana
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 }}"

Nilai default di values.yaml bisa di-override per environment dengan file -f values-prod.yaml atau --set image.tag=v1.3.0. Dependency antar chart dikelola lewat Chart.yaml dengan dependencies:.

Kustomize Basics

Jika Helm memakai templating, Kustomize memakai overlay: definisi asli (base) tidak pernah diubah, lingkungan lain cukup menimpa sebagian lewat patch.

kustomization.yaml untuk overlay production
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

Perhatikan kelebihan Kustomize: tidak ada ekspresi template yang disuntikkan ke dalam teks; hasil akhir adalah YAML murni yang bisa langsung dibaca. Ini menjaga auditability — apa yang ada di Git adalah apa yang benar-benar diterapkan.

Generators

Kustomize juga bisa membuat ConfigMap dan Secret dari file atau literal:

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

Kelebihan generator: perubahan kecil menghasilkan suffix hash baru sehingga Deployment otomatis di-rolling.

Organisasi Direktori Manifest

Tanpa organisasi yang baik, repository manifest akan menjadi sampah. Dua pola yang umum di dunia nyata:

Berbasis Environment

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

Berbasis Aplikasi per Environment

Struktur aplikasi per environment
apps/
├── api/
│   ├── dev/
│   ├── staging/
│   └── production/
└── web/
    ├── dev/
    ├── staging/
    └── production/

Tip

Aturan emas: satu environment, satu set nilai yang jelas. Pilih satu pola dan konsisten. Repositori manifest yang rapi adalah prasyarat agar ArgoCD (dan tim kalian) bisa bekerja tanpa kebingungan.

Penutup

Episode ini menyegarkan tiga fondasi teknis:

  • Objek inti Kubernetes: Deployment, Service, ConfigMap, Secret, Ingress, Namespace.
  • Helm: templating, values per environment, dan chart dependencies.
  • Kustomize: base + overlays, patches, generators, dan YAML murni yang auditable.
  • Pola organisasi direktori: berbasis environment atau berbasis aplikasi.

Dengan fondasi teknis ini, kita siap memasuki fase instalasi. Di episode 4 kita akan menginstall ArgoCD di cluster kalian: memilih metode instalasi, melakukan setup awal, dan membuka UI-nya untuk pertama kali. Sampai jumpa!

Belajar GitOps dengan ArgoCD - Kubernetes & Manifest Management Recap | Belajar GitOps dengan ArgoCD