Apa itu Kubernetes? #

Ketika kita pertama kali mulai mendeploy aplikasi berbasis container, semuanya terasa sangat mudah. Kita cukup menulis sebuah Dockerfile, membuat container secara lokal, lalu menyebarkannya ke server produksi menggunakan perintah Docker sederhana atau modul Docker di Ansible. Namun, seiring dengan berkembangnya sistem dan skala aplikasi kita, tantangan operasional yang sesungguhnya mulai muncul. Docker saja tidak lagi cukup ketika kita harus mengelola puluhan hingga ratusan container yang berjalan secara dinamis di atas kluster server fisik atau virtual.

Bagaimana jika salah satu server fisik kita mengalami kerusakan perangkat keras di tengah malam? Bagaimana cara kita mendistribusikan lalu lintas jaringan secara merata ke puluhan replika aplikasi tanpa harus mengonfigurasi load balancer secara manual setiap kali ada container baru yang aktif? Bagaimana kita melakukan pembaruan aplikasi tanpa menimbulkan downtime bagi pengguna? Untuk menjawab tantangan-tantangan pengelolaan container dalam skala besar inilah Kubernetes (sering disingkat sebagai K8s) diciptakan.

Dalam artikel ini, kita akan menjelajahi konsep fundamental Kubernetes, arsitektur internal yang menggerakkannya, bagaimana ia memperlakukan infrastruktur sebagai sekumpulan API, serta di mana peran krusial Ansible dalam mempermudah siklus hidup pengelolaan kluster dan workload di Kubernetes.

Evolusi Infrastruktur: Dari Bare-Metal Hingga Orkestrasi #

Untuk memahami mengapa Kubernetes menjadi standar industri saat ini, kita harus melihat kembali bagaimana cara kita mengelola aplikasi berevolusi dari waktu ke waktu. Setiap era memiliki karakteristik operasional, keterbatasan, dan solusinya sendiri.

flowchart LR
    BM["Bare-Metal (Satu OS, Satu Hardware)"] --> VM["Virtual Machine (Hypervisor, Guest OS)"]
    VM --> CO["Container (Shared OS Kernel, Ringan)"]
    CO --> K8S["Kubernetes (Orkestrasi Cluster Otomatis)"]

Era Tradisional (Bare-Metal) #

Pada awalnya, kita menjalankan aplikasi langsung di atas server fisik (bare-metal). Keterbatasan terbesar dari era ini adalah alokasi sumber daya yang tidak efisien. Jika kita menjalankan satu aplikasi web di atas server fisik yang besar, aplikasi tersebut mungkin hanya menggunakan 5% dari kapasitas CPU dan memori. Namun, jika kita menjalankan beberapa aplikasi di server yang sama, kita akan menghadapi masalah konflik dependensi library dan risiko keamanan di mana satu aplikasi yang bermasalah dapat memengaruhi aplikasi lainnya di sistem operasi yang sama.

Era Virtualisasi (Virtual Machines) #

Untuk memecahkan masalah isolasi pada bare-metal, industri beralih ke teknologi Virtual Machine (VM). Dengan bantuan Hypervisor, kita dapat menjalankan beberapa sistem operasi tamu (guest OS) yang sepenuhnya terisolasi di atas satu perangkat keras fisik tunggal. VM memberikan batas keamanan yang kuat dan pembagian resource yang jelas. Namun, VM sangat boros resource karena setiap VM harus menjalankan salinan lengkap sistem operasi tersendiri, yang membutuhkan ruang penyimpanan giga-byte dan waktu booting yang relatif lama (beberapa menit).

Era Container (Containerization) #

Container memecahkan masalah pemborosan resource pada VM dengan cara berbagi kernel sistem operasi host. Alih-alih memvirtualisasikan seluruh hardware dan OS, container hanya mengisolasi ruang pengguna (user space). Hal ini membuat container menjadi sangat ringan (hanya berukuran mega-byte), efisien dalam konsumsi CPU dan memori, serta memiliki waktu booting yang hampir instan (dalam hitungan detik). Kita dapat mengemas aplikasi beserta seluruh dependensinya ke dalam satu image container yang portabel untuk dijalankan di mana saja.

Era Orkestrasi (Kubernetes) #

Meskipun container sangat bagus untuk portabilitas, mengelola ratusan container secara manual di berbagai server yang berbeda adalah mimpi buruk bagi tim operasional. Jika sebuah container mati, siapa yang akan menyadarinya dan menyalakan kembali container tersebut? Di sinilah orkestrasi container masuk. Kubernetes bertindak sebagai “konduktor orkestra” yang mengelola seluruh siklus hidup container secara otomatis, memastikan aplikasi kita selalu berjalan sesuai dengan status yang kita deklarasikan.

Mengapa Kita Butuh Orkestrasi Container? #

Mari kita bayangkan sebuah skenario nyata di lingkungan produksi tanpa menggunakan sistem orkestrasi. Kita memiliki aplikasi microservices yang dideploy ke dalam 30 container yang tersebar di 5 server yang berbeda. Tanpa sistem orkestrasi seperti Kubernetes, kita harus menghadapi tantangan operasional berikut secara manual:

Tantangan Tanpa Orkestrasi Container:
  - Deteksi Kegagalan: Container di server-3 mati mendadak → Kita harus memantau manual dan melakukan restart.
  - Alokasi Kapasitas: Server-2 kehabisan memori → Kita harus mencari tahu server mana yang masih longgar untuk mendeploy container baru.
  - Skalabilitas: Traffic melonjak pada hari raya → Kita harus login ke setiap server dan membuat replika container secara manual.
  - Update Aplikasi: Merilis versi baru → Kita harus menghentikan versi lama dan menyalakan versi baru satu per satu, menyebabkan downtime.
  - Jaringan: Menghubungkan antar-service → Kita harus melacak IP address container yang selalu berubah setiap kali di-restart.

Kubernetes menyelesaikan seluruh tantangan di atas secara otomatis dengan mengabstraksikan sekumpulan server fisik atau virtual menjadi satu kesatuan pool resource yang besar. Kita tidak perlu lagi peduli di server mana container kita berjalan. Kita cukup memberi tahu Kubernetes: “Tolong jalankan 5 replika dari aplikasi saya, pastikan ia selalu tersedia, dan ekspos ke port 80.” Kubernetes akan terus-menerus bekerja di latar belakang untuk menjaga agar kondisi nyata (actual state) kluster selalu sama dengan kondisi yang kita inginkan (desired state).

Solusi Otomatis Bersama Kubernetes:
  ✓ Self-Healing: Jika ada container yang crash, Kubernetes akan langsung mendeteksi dan membuat container baru.
  ✓ Auto-Scaling: Kubernetes dapat menambah atau mengurangi jumlah replika container secara otomatis berdasarkan utilisasi CPU.
  ✓ Service Discovery & Load Balancing: Kubernetes memberikan IP address dan nama DNS tunggal untuk sekelompok container.
  ✓ Automated Rollouts & Rollbacks: Kita bisa melakukan update aplikasi secara bertahap tanpa downtime sama sekali.
  ✓ Resource Bin-Packing: Kubernetes menempatkan container secara otomatis berdasarkan kebutuhan resource tanpa membuang kapasitas server.

Kapan Kita Harus Menggunakan Kubernetes? #

Penting bagi kita untuk memahami bahwa Kubernetes bukanlah peluru perak yang cocok untuk semua skenario. Kubernetes membawa kompleksitas operasional yang cukup tinggi, sehingga kita harus bijak dalam memutuskan kapan harus mengadopsinya.

KITA BUTUH KUBERNETES JIKA:
  ✓ Aplikasi kita dibangun dengan arsitektur microservices yang kompleks dan saling bergantung.
  ✓ Kita membutuhkan skalabilitas yang sangat dinamis untuk menangani fluktuasi lalu lintas yang ekstrem.
  ✓ Kita ingin memaksimalkan efisiensi biaya infrastruktur cloud dengan melakukan bin-packing container.
  ✓ Tim pengembang kita membutuhkan kemampuan untuk mendeploy aplikasi berkali-kali dalam sehari secara aman.
  ✓ Kita membutuhkan ketersediaan tinggi (high availability) dengan toleransi kegagalan tingkat server.

KITA TIDAK BUTUH KUBERNETES JIKA:
  ✗ Kita hanya menjalankan satu atau dua aplikasi monolithic sederhana yang jarang diupdate.
  ✗ Tim operasional kita belum memiliki keahlian dasar tentang container dan jaringan Linux.
  ✗ Kita tidak membutuhkan skalabilitas otomatis dan aplikasi kita bisa menerima downtime singkat saat maintenance.
  ✗ Anggaran infrastruktur kita sangat terbatas (menjalankan control plane Kubernetes membutuhkan overhead resource tersendiri).

Arsitektur Fundamental Cluster Kubernetes #

Kluster Kubernetes terdiri dari dua komponen utama: Control Plane (otak kluster yang membuat keputusan strategis) dan Worker Nodes (mesin pekerja tempat container aplikasi kita benar-benar berjalan). Memahami interaksi antar komponen ini sangat penting bagi kita sebelum mencoba mengotomasi siklus hidup kluster menggunakan Ansible.

flowchart TD
    subgraph ControlPlane["Control Plane (Otak Cluster)"]
        API["kube-apiserver (Pintu Masuk API)"]
        ETCD["(\"etcd (Database State Cluster)\")"]
        SCHED["kube-scheduler (Penjadwalan Pod)"]
        CTRL["kube-controller-manager (Reconciliation Loops)"]
        
        API <--> ETCD
        API <--> SCHED
        API <--> CTRL
    end

    subgraph WorkerNode["Worker Node (Node Pekerja)"]
        KLET["kubelet (Agen Node)"]
        PROXY["kube-proxy (Jaringan & Load Balancing)"]
        CRI["Container Runtime (containerd)"]
        
        KLET --> CRI
    end

    API <-->|"Komunikasi API"| KLET
    API <-->|"Komunikasi Network"| PROXY

1. Komponen Control Plane #

Control Plane bertanggung jawab untuk membuat keputusan global tentang kluster (seperti penjadwalan aplikasi), serta mendeteksi dan merespons peristiwa kluster. Komponen-komponen ini biasanya dijalankan pada server khusus yang tidak menjalankan container aplikasi pengguna demi menjaga keamanan dan performa.

• kube-apiserver: Ini adalah pintu masuk utama ke Control Plane. Semua komunikasi di dalam kluster, baik dari komponen internal maupun dari perintah luar (seperti kubectl atau playbook Ansible), harus melalui API Server. Ia bertindak sebagai validator dan pengatur lalu lintas data untuk objek-objek Kubernetes.
• etcd: Penyimpanan data key-value yang sangat konsisten dan andal. etcd adalah satu-satunya tempat penyimpanan data state kluster Kubernetes. Semua konfigurasi, status objek, dan data metadata disimpan di sini. Jika etcd kita hancur tanpa adanya backup, maka seluruh kluster kita juga akan hilang. Oleh karena itu, replikasi dan backup etcd menjadi prioritas utama.
• kube-scheduler: Komponen ini bertugas untuk memperhatikan Pod yang baru dibuat yang belum memiliki node yang ditugaskan, dan memilih node terbaik tempat Pod tersebut harus dijalankan. Keputusan penjadwalan ini dibuat berdasarkan kebutuhan resource (CPU/memori), kebijakan afinitas (affinity/anti-affinity), batasan hardware, dan beban kerja node saat itu.
• kube-controller-manager: Menjalankan proses pengontrol (controller) di latar belakang. Secara konseptual, setiap pengontrol adalah loop kontrol terpisah yang mengawasi keadaan kluster melalui API Server dan mencoba membawa keadaan saat ini menuju keadaan yang diinginkan. Contohnya termasuk Node Controller (mendeteksi jika node mati) dan Job Controller (menjalankan tugas batch).

2. Komponen Worker Node #

Worker Node bertugas untuk menjalankan Pod aplikasi kita dan menyediakan lingkungan runtime yang diperlukan agar container dapat saling berkomunikasi dengan aman.

• kubelet: Sebuah agen yang berjalan di setiap Worker Node di dalam kluster. Tugas utamanya adalah memastikan bahwa container yang didefinisikan dalam spesifikasi Pod berjalan dengan sehat dan sesuai target. Kubelet menerima instruksi dari API Server dan menerjemahkannya ke perintah kontainer runtime lokal.
• kube-proxy: Agen jaringan yang berjalan di setiap node untuk memelihara aturan jaringan (network rules) pada node tersebut. Aturan jaringan ini memungkinkan komunikasi jaringan ke Pod dari dalam atau luar kluster dengan memanfaatkan iptables atau IPVS di kernel Linux.
• Container Runtime: Perangkat lunak yang bertanggung jawab untuk menjalankan container. Kubernetes mendukung berbagai container runtime melalui Container Runtime Interface (CRI), seperti containerd, CRI-O, atau varian Docker lainnya.

Konsep Objek Dasar (Resources) di Kubernetes #

Sebelum kita mulai menulis manifest Kubernetes, kita harus memahami objek-objek dasar yang menjadi blok pembangun aplikasi di dalam kluster. Kubernetes mendefinisikan objek-objek ini secara deklaratif menggunakan format YAML.

1. Pod #

Pod adalah unit terkecil dan paling mendasar yang dapat kita buat dan kelola di Kubernetes. Sebuah Pod mewakili satu proses yang berjalan di kluster kita. Pod dapat berisi satu container (pola paling umum) atau beberapa container yang saling berbagi penyimpanan (storage) dan jaringan (network IP), serta instruksi tentang bagaimana container harus dijalankan.

# Contoh manifest Pod sederhana (pod-myapp.yaml)
apiVersion: v1
kind: Pod
metadata:
  name: webapp-pod
  namespace: production
  labels:
    app: webapp
spec:
  containers:
    - name: web-container
      image: nginx:1.25-alpine
      ports:
        - containerPort: 80

2. Deployment #

Kita hampir tidak pernah membuat Pod secara langsung di lingkungan produksi karena Pod tidak memiliki kemampuan self-healing bawaan jika node tempat ia berjalan mati. Sebagai gantinya, kita menggunakan Deployment. Deployment mengabstraksikan pembuatan Pod dan ReplicaSet, mengelola siklus hidup replikasi Pod, melakukan rolling update versi aplikasi tanpa downtime, serta memungkinkan kita melakukan rollback jika terjadi error pada versi baru.

# Contoh manifest Deployment (deployment-myapp.yaml)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-deployment
  namespace: production
spec:
  replicas: 3 # Menjamin selalu ada 3 replika Pod yang berjalan
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
        - name: web-container
          image: nginx:1.25-alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              memory: "64Mi"
              cpu: "100m"
            limits:
              memory: "128Mi"
              cpu: "200m"

3. Service #

Pod di Kubernetes bersifat fana (ephemeral). Ketika sebuah Pod mati atau di-reschedule ke node lain, ia akan mendapatkan IP address baru yang berbeda. Untuk menjembatani komunikasi antar Pod tanpa harus kehilangan jejak IP address, kita menggunakan Service. Service bertindak sebagai abstraksi untuk mengekspos sekelompok Pod sebagai satu endpoint jaringan yang stabil dan melakukan load balancing internal secara otomatis.

# Contoh manifest Service (service-myapp.yaml)
apiVersion: v1
kind: Service
metadata:
  name: webapp-service
  namespace: production
spec:
  selector:
    app: webapp # Mengarahkan traffic ke Pod dengan label app=webapp
  ports:
    - protocol: TCP
      port: 80 # Port yang diekspos oleh Service
      targetPort: 80 # Port kontainer tujuan
  type: ClusterIP # Default, hanya dapat diakses dari dalam kluster

4. ConfigMap dan Secret #

Kubernetes memisahkan kode aplikasi dari konfigurasi dan data sensitif menggunakan ConfigMap dan Secret. Hal ini memungkinkan kita untuk menggunakan image container yang sama di lingkungan Development, Staging, dan Produksi tanpa harus mengubah kode di dalamnya.

• ConfigMap: Digunakan untuk menyimpan data konfigurasi non-sensensial (seperti variabel lingkungan atau file konfigurasi aplikasi).
• Secret: Digunakan untuk menyimpan data sensitif seperti kata sandi, token API, dan private key SSH dengan enkripsi base64.

Arsitektur API-Driven Kubernetes #

Salah satu kekuatan utama Kubernetes yang membuatnya sangat cocok dipadukan dengan Ansible adalah filosofi API-Driven Architecture. Di Kubernetes, segala sesuatu diperlakukan sebagai API Object. Kluster Kubernetes dikendalikan sepenuhnya melalui API RESTful yang diekspos oleh kube-apiserver.

Ketika kita menjalankan perintah kubectl apply -f manifest.yaml, yang sebenarnya terjadi adalah kubectl membaca file YAML tersebut, mengubahnya menjadi format JSON, lalu mengirimkan request HTTP POST/PUT ke API Server Kubernetes. API Server kemudian melakukan validasi skema, menyimpannya ke database etcd, dan memicu siklus rekonsiliasi (reconciliation loop).

flowchart TD
    DS["desired state (YAML)"] --> APIS["kube-apiserver"]
    APIS --> ETCD["etcd (State Storage)"]
    APIS --> RL["reconciliation loop (Control Manager)"]
    RL --> KUBELET["kubelet & CRI"]
    KUBELET --> AS["actual state (Worker)"]

Loop rekonsiliasi ini adalah inti dari sifat deklaratif Kubernetes. Komponen pengontrol akan terus-menerus membandingkan keadaan nyata di lapangan (actual state) dengan keadaan yang dideklarasikan di etcd (desired state). Jika terjadi perbedaan (misalnya, salah satu Pod mati), pengontrol akan segera mengambil tindakan perbaikan (mendeploy Pod baru di node lain) tanpa perlu intervensi manual dari kita. Sifat API-driven inilah yang dimanfaatkan oleh modul-modul Ansible untuk mengelola infrastruktur kluster secara terstruktur dan idempoten.

Peran Ansible dalam Ekosistem Kubernetes #

Saat pertama kali belajar Kubernetes, banyak dari kita berpikir bahwa Ansible dan Kubernetes adalah dua alat yang saling bersaing. Ini adalah kesalahpahaman yang besar. Pada kenyataannya, Ansible dan Kubernetes saling melengkapi dengan sangat baik.

Ansible sangat unggul dalam mengelola konfigurasi berbasis host tradisional (sistem operasi, paket, file konfigurasi, jaringan host), sedangkan Kubernetes sangat unggul dalam mengelola container skala besar di tingkat aplikasi. Kita dapat membagi peran Ansible di ekosistem Kubernetes menjadi dua tahapan besar:

1. Day 0 & Day 1: Provisioning dan Bootstrapping Cluster #

Sebelum kita bisa mendeploy aplikasi ke Kubernetes, kita harus membuat klusternya terlebih dahulu. Proses inisialisasi kluster dari awal sangatlah rumit dan melelahkan jika dilakukan secara manual. Ansible bertindak sebagai alat otomatisasi utama untuk menyiapkan sistem operasi dasar pada node kontrol dan pekerja, menginstal dependencies sistem seperti container runtime (containerd), menyiapkan modul kernel Linux, hingga melakukan inisialisasi kluster pertama kali menggunakan kubeadm.

2. Day 2: Workload Management dan Integrasi Hybrid #

Setelah kluster aktif, kita dapat menggunakan Ansible untuk mengelola objek-objek di dalam Kubernetes. Menggunakan Ansible untuk mendeploy manifest aplikasi memungkinkan kita untuk menggabungkan deployment Kubernetes dengan alur kerja infrastruktur eksternal. Misalnya, playbook Ansible kita dapat membuat database cloud managed (RDS) di AWS, mendaftarkan DNS record di Cloudflare, lalu mendeploy manifest aplikasi kita ke Kubernetes yang mengambil kredensial database tersebut dari Ansible Vault.

Perbandingan Alat Pengelola: kubectl vs kubernetes.core Module #

Ketika kita ingin mendeploy manifest ke Kubernetes, kita dihadapkan pada pilihan: menggunakan perintah CLI kubectl murni, atau menggunakan modul kubernetes.core.k8s yang disediakan oleh Ansible. Mari kita bandingkan keduanya secara mendalam untuk melihat mengapa Ansible memberikan keuntungan yang jauh lebih besar di lingkungan produksi.

Pendekatan Menggunakan kubectl (Anti-Pattern):
  ✗ Sulit dikelola secara terpusat jika harus mendeploy ke beberapa kluster berbeda.
  ✗ Tidak memiliki validasi idempotency bawaan untuk alur logika yang kompleks.
  ✗ Secret management sering kali bocor karena kita harus membuat file manifest Secret secara lokal.
  ✗ Sulit diintegrasikan dengan langkah-langkah non-Kubernetes (seperti migrasi database eksternal).
  ✗ Sintaks skrip pembungkus shell untuk kubectl cepat menjadi rumit dan sulit didebug.

Pendekatan Menggunakan kubernetes.core (Solusi Benar):
  ✓ Terintegrasi penuh dengan Ansible Inventory untuk deployment multi-environment.
  ✓ Idempoten secara bawaan — Ansible hanya mengirimkan perubahan jika ada perbedaan state.
  ✓ Integrasi erat dengan Ansible Vault untuk enkripsi secret yang aman tanpa meninggalkan jejak teks biasa.
  ✓ Alur kerja hybrid: Ansible dapat mengelola resource cloud eksternal dan Kubernetes secara berurutan.
  ✓ Dukungan template Jinja2 untuk menghasilkan manifest Kubernetes yang dinamis dan modular.

Perbandingan Kode: Deployment Manual vs Declarative Playbook #

Mari kita bandingkan secara visual bagaimana perbedaan mendeploy aplikasi menggunakan skrip shell pembungkus kubectl (yang rawan kesalahan) dengan playbook Ansible yang rawan kegagalan digantikan dengan pendekatan deklaratif yang bersih.

# ANTI-PATTERN: Menggunakan shell module untuk menjalankan perintah kubectl secara manual
# Hal ini tidak idempoten, sulit menangani error, dan rawan kebocoran variabel sensitif di log terminal
- name: Deploy aplikasi menggunakan kubectl shell (Sangat Tidak Direkomendasikan)
  shell: |
    kubectl apply -f /opt/app/namespace.yaml
    kubectl apply -f /opt/app/secret.yaml
    kubectl apply -f /opt/app/deployment.yaml    
  environment:
    KUBECONFIG: /home/admin/.kube/config

# BENAR: Menggunakan modul kubernetes.core.k8s secara deklaratif
# Ansible menangani koneksi API secara langsung, idempoten, dan kita bisa menggunakan Ansible Vault untuk Secret
- name: Deploy namespace dan resources secara deklaratif (Sistem Rekomendasi)
  kubernetes.core.k8s:
    kubeconfig: "{{ playbook_dir }}/kubeconfig/admin.conf"
    state: present
    definition:
      apiVersion: v1
      kind: Namespace
      metadata:
        name: "{{ app_namespace }}"
        labels:
          managed-by: ansible
          environment: "{{ env_name }}"

- name: Deploy database secret menggunakan data terenkripsi dari Ansible Vault
  kubernetes.core.k8s:
    kubeconfig: "{{ playbook_dir }}/kubeconfig/admin.conf"
    state: present
    definition:
      apiVersion: v1
      kind: Secret
      metadata:
        name: db-credentials
        namespace: "{{ app_namespace }}"
      type: Opaque
      stringData:
        database-url: "postgresql://{{ db_user }}:{{ vault_db_password }}@{{ db_host }}/{{ db_name }}"
    no_log: true # Mencegah password bocor ke stdout log Ansible

Dengan beralih menggunakan modul kubernetes.core.k8s, kita tidak perlu lagi memikirkan apakah file manifes sudah ada di server target atau apakah kita harus menjalankan perintah replace atau apply. Ansible akan menganalisis state objek saat ini langsung dari API Server Kubernetes dan mengambil tindakan minimal yang diperlukan untuk menyamakan keadaan riil dengan konfigurasi yang kita inginkan.

Decision Tree: Memilih Alur Orkestrasi yang Tepat #

Untuk mempermudah kita dalam menentukan kapan harus menggunakan Docker biasa, Kubernetes murni, atau kombinasi Ansible di atasnya, kita dapat mengikuti diagram keputusan berikut:

flowchart TD
    A{"Apakah Butuh Skalabilitas Dinamis?"} --|"Ya"| B{"Jumlah Container > 10?"}
    A --|"Tidak"| C["Cukup Gunakan Docker Compose"]
    B --|"Ya"| D["Kubernetes + Ansible"]
    B --|"Tidak"| E["Ansible + Docker Module"]

Jika aplikasi kita masih berskala kecil dan tidak memerlukan ketersediaan tinggi di berbagai server fisik, menggunakan modul Docker biasa di Ansible adalah pilihan yang lebih hemat biaya dan efisien. Namun, ketika kompleksitas menuntut orkestrasi kluster multipath, menggunakan Kubernetes yang dikendalikan oleh Ansible adalah standar emas yang harus kita terapkan.

Ringkasan #

• Kubernetes (K8s) adalah platform orkestrasi container open-source yang bertugas untuk mengotomasi deployment, scaling, management, dan self-healing container di atas kluster server.
• Arsitektur Kubernetes dibagi menjadi dua bagian: Control Plane (otak pengambil keputusan yang terdiri dari API Server, etcd, Scheduler, dan Controller Manager) dan Worker Node (tempat kontainer berjalan yang dikelola oleh kubelet, kube-proxy, dan container runtime).
• Sifat API-Driven pada Kubernetes memungkinkan semua resource diwakili sebagai objek RESTful yang dapat dimanipulasi secara deklaratif menggunakan format YAML.
• Objek fundamental Kubernetes meliputi Pod (unit terkecil), Deployment (mengelola replika dan pembaruan pod), Service (menjaga kestabilan alamat IP dan load balancing), serta ConfigMap & Secret (memisahkan data konfigurasi dari image kontainer).
• Ansible tidak bersaing dengan Kubernetes, melainkan saling melengkapi. Ansible unggul dalam bootstrapping awal kluster (Day 0/1) dan mengelola integrasi eksternal hibrida (Day 2).
• Menggunakan modul kubernetes.core.k8s jauh lebih baik daripada menjalankan kubectl di shell Ansible karena memberikan jaminan idempotensi, integrasi variabel dinamis Jinja2, dan keamanan secret menggunakan Ansible Vault.

← Sebelumnya: Image Build   Berikutnya: Provision Cluster →