Pendahuluan

Pada metode kedua ini, proses deployment menggunakan Kubernetes K3s sebagai platform untuk menjalankan aplikasi. Berbeda dengan metode sebelumnya, yaitu Docker Compose yang mengelola container melalui file Compose, pada metode ini aplikasi dikelola menggunakan resource Kubernetes seperti Deployment, Service, Pod, dan Secret.

Proses build image dan deployment dipisahkan agar masing-masing proses memiliki tanggung jawab yang jelas. Proses build dilakukan menggunakan GitLab Runner dengan Docker executor, sedangkan deployment ke cluster K3s dilakukan menggunakan runner yang memiliki akses terhadap Kubernetes dan menjalankan perintah kubectl.

Alur deployment ini dimulai dari perubahan source code pada repository GitLab. Ketika developer membuat Git Tag, GitLab CI/CD menjalankan proses build Docker image dan memberikan tag versi sesuai dengan CI_COMMIT_TAG. Image tersebut kemudian dikirim ke GitLab Container Registry. Setelah image tersedia di registry, proses deployment menjalankan konfigurasi Kubernetes menggunakan kubectl sehingga aplikasi dapat diperbarui pada cluster K3s.

Tujuan

Metode K3s Kubectl bertujuan untuk menjalankan aplikasi pada Kubernetes K3s dengan proses deployment yang dikendalikan menggunakan kubectl. Pada implementasinya, proses build Docker image tetap dilakukan oleh runner runner-docker-rnd dengan tag docker-rnd. Sementara itu, proses deployment Kubernetes dilakukan menggunakan runner runner-k3s. Pemisahan runner ini membuat proses build image dan proses deployment Kubernetes memiliki fungsi yang berbeda dan tidak saling bergantung secara langsung.

Environment K3s

Cluster K3s yang digunakan pada implementasi ini berjalan pada server dengan hostname k3s-rnd-00. Server tersebut menggunakan Debian GNU/Linux 13 dan memiliki alamat IP 192.168.1.7. Versi K3s yang digunakan adalah v1.36.4+k3s1.

Informasi environment dapat diperiksa menggunakan perintah berikut:

hostname
hostname -I
kubectl version

Status node K3s dapat diperiksa menggunakan:

sudo kubectl get nodes

Node yang digunakan harus berada dalam kondisi Ready. Contoh hasil pemeriksaan:

NAME          STATUS   ROLES
k3s-rnd-00    Ready    control-plane

Status Ready menunjukkan bahwa node K3s dapat digunakan untuk menjalankan workload Kubernetes.

Pemeriksaan Pod

Setelah memastikan node dalam kondisi Ready, resource Pod yang berjalan pada cluster dapat diperiksa menggunakan:

sudo kubectl get pods -A

Perintah tersebut menampilkan Pod dari seluruh namespace yang tersedia pada cluster. Untuk melihat Pod pada namespace default, gunakan:

sudo kubectl get pods -n default

Pemeriksaan ini dilakukan untuk memastikan resource yang telah dideploy benar-benar dibuat oleh Kubernetes dan berada dalam kondisi yang sesuai.

GitLab Runner Docker

Proses build Docker image dilakukan menggunakan GitLab Runner runner-docker-rnd dengan tag docker-rnd. Runner ini bertugas menjalankan proses build berdasarkan Dockerfile yang terdapat pada repository. Image kemudian diberikan tag berdasarkan Git Tag yang digunakan pada proses CI/CD.

Contoh proses build:

docker build \
  -t "${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG}" .

Setelah proses build selesai, image dikirim ke GitLab Container Registry menggunakan:

docker push "${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG}"

Dengan menggunakan CI_COMMIT_TAG, setiap image yang dihasilkan memiliki versi yang mengikuti Git Tag. Contohnya, ketika repository menggunakan tag v0.1.6, image yang dihasilkan juga menggunakan tag v0.1.6.

GitLab Runner K3s

Proses deployment ke Kubernetes dilakukan menggunakan GitLab Runner runner-k3s. Runner ini digunakan untuk menjalankan perintah Kubernetes seperti kubectl apply, kubectl rollout status, dan perintah pemeriksaan resource lainnya.Pada implementasi ini, runner K3s menggunakan Kubernetes sebagai executor. Dengan demikian, runner tersebut memiliki lingkungan yang digunakan untuk menjalankan proses deployment ke cluster K3s. Pemisahan runner antara proses build dan deployment membuat proses CI/CD lebih terstruktur. Runner Docker berfokus pada pembuatan image, sedangkan runner K3s berfokus pada penerapan konfigurasi aplikasi ke Kubernetes.

Registry Authentication

Karena Docker image disimpan pada GitLab Container Registry yang bersifat private, K3s membutuhkan credential untuk mengambil image tersebut. Credential registry disimpan dalam Kubernetes Secret dengan nama:

gitlab-registry

Secret dapat diperiksa menggunakan:

sudo kubectl -n default get secret gitlab-registry

Untuk melihat tipe Secret:

sudo kubectl -n default get secret gitlab-registry \
  -o jsonpath="{.type}"

Tipe Secret yang digunakan adalah:

kubernetes.io/dockerconfigjson

Secret tersebut kemudian digunakan oleh Pod melalui konfigurasi imagePullSecrets. Dengan metode ini, Kubernetes dapat melakukan autentikasi ke GitLab Container Registry ketika melakukan proses image pull.

Deployment YAML

Konfigurasi aplikasi pada Kubernetes disimpan dalam file YAML. Salah satu file yang digunakan adalah:

yaml/deployment.yaml

Contoh konfigurasi Deployment untuk aplikasi FrankenPHP adalah:

apiVersion: apps/v1
kind: Deployment

metadata:
  name: franken-php

spec:
  replicas: 1

  selector:
    matchLabels:
      app: franken-php

  template:
    metadata:
      labels:
        app: franken-php

    spec:
      imagePullSecrets:
        - name: gitlab-registry

      containers:
        - name: franken-php
          image: registry.gitlab.com/klikto/.../franken-php:{{VERSION}}

Pada konfigurasi tersebut terdapat placeholder {{VERSION}}. Placeholder digunakan agar versi Docker image dapat ditentukan secara dinamis oleh pipeline CI/CD. Dengan pendekatan ini, file Deployment tidak perlu diubah secara manual setiap kali terdapat versi image baru karena nilai versi akan otomatis diganti oleh pipeline.

Mengisi Versi Image

Pada saat pipeline berjalan, placeholder {{VERSION}} diganti dengan nilai dari CI_COMMIT_TAG. Proses tersebut dapat dilakukan menggunakan perintah:

sed -e "s|{{VERSION}}|${CI_COMMIT_TAG}|g" \
  yaml/deployment.yaml | \
  kubectl apply -n default -f -

Sebagai contoh, apabila Git Tag yang digunakan adalah:

v0.1.6

Maka nilai:

{{VERSION}}

akan diganti menjadi:

v0.1.6

Dengan demikian, Kubernetes akan menggunakan image:

registry.gitlab.com/klikto/.../franken-php:v0.1.6

Pendekatan ini memungkinkan satu file YAML digunakan untuk berbagai versi image tanpa harus membuat file Deployment baru untuk setiap versi yang akan digunakan.

Kubectl Apply

Setelah konfigurasi Deployment memiliki versi image yang sesuai, konfigurasi tersebut diterapkan ke cluster menggunakan kubectl. Jika file YAML sudah berisi versi image yang sesuai, perintah yang digunakan adalah:

sudo kubectl apply -n default -f yaml/deployment.yaml

Perintah kubectl apply membaca konfigurasi YAML dan membuat resource baru atau memperbarui resource yang sudah ada. Jika Deployment sebelumnya sudah berjalan dan image diubah ke versi yang lebih baru, Kubernetes akan melakukan proses pembaruan berdasarkan konfigurasi terbaru.

Rollout Deployment

Setelah proses apply berjalan, status Deployment perlu diperiksa untuk memastikan proses pembaruan berhasil. Gunakan perintah:

sudo kubectl rollout status deployment/franken-php \
  -n default \
  --timeout=120s

Perintah tersebut akan menunggu proses rollout sampai selesai atau sampai batas waktu yang ditentukan tercapai. Jika rollout berhasil, Deployment telah menggunakan konfigurasi terbaru dan Pod baru dapat digunakan untuk menjalankan aplikasi.

Verifikasi Deployment

Status Deployment dapat diperiksa menggunakan:

sudo kubectl get deployments -n default

Contoh hasil:

NAME          READY   UP-TO-DATE   AVAILABLE
franken-php   1/1     1            1

Nilai READY, UP-TO-DATE, dan AVAILABLE digunakan untuk melihat apakah jumlah Pod yang diinginkan sudah tersedia dan menggunakan konfigurasi terbaru.

Verifikasi Pod

Setelah Deployment berhasil, Pod aplikasi diperiksa menggunakan:

sudo kubectl get pods -n default -o wide

Pod aplikasi harus berada dalam kondisi:

Running

Informasi tambahan seperti IP Pod dan node tempat Pod berjalan juga dapat dilihat melalui opsi -o wide. Pemeriksaan ini penting karena Deployment yang berhasil dibuat belum tentu berarti aplikasi sudah berjalan dengan baik. Oleh karena itu, kondisi Pod tetap perlu diperiksa untuk memastikan container dapat dijalankan.

Verifikasi Service

Selain Deployment dan Pod, aplikasi Kubernetes biasanya membutuhkan Service sebagai endpoint untuk komunikasi antar-resource. Service dapat diperiksa menggunakan:

sudo kubectl get services -n default

Service memberikan endpoint jaringan yang dapat digunakan oleh aplikasi lain di dalam cluster untuk berkomunikasi dengan Pod. Dengan menggunakan Service, aplikasi tidak perlu bergantung langsung pada alamat IP Pod karena alamat IP Pod dapat berubah ketika Pod dibuat ulang.

Verifikasi Image

Image yang digunakan oleh Pod dapat diperiksa menggunakan:

sudo kubectl get pods \
  -n default \
  -o jsonpath="{.items[*].spec.containers[*].image}"

Perintah tersebut digunakan untuk menampilkan image yang sedang digunakan oleh container pada Pod. Pemeriksaan ini digunakan untuk memastikan bahwa Deployment telah menggunakan versi image yang sesuai dengan Git Tag yang digunakan pada pipeline.

Sebagai contoh, jika pipeline dijalankan menggunakan Git Tag v0.1.6, hasil pemeriksaan seharusnya menunjukkan image dengan tag:

franken-php:v0.1.6

Pengujian Rollout

Image versioning juga digunakan ketika aplikasi mengalami pembaruan versi. Sebagai contoh, aplikasi sebelumnya menggunakan:

v0.1.5

Kemudian source code diperbarui dan dibuat Git Tag:

v0.1.6

Pipeline akan membangun Docker image baru dengan tag v0.1.6 dan mengirimkannya ke GitLab Container Registry. Setelah image tersedia, proses deployment menjalankan konfigurasi Kubernetes dengan versi baru tersebut. Kubernetes kemudian melakukan rollout untuk mengganti Pod yang menggunakan image lama dengan Pod yang menggunakan image terbaru.

Status rollout dapat dipantau menggunakan:

sudo kubectl rollout status deployment/franken-php \
  -n default \
  --timeout=120s

Dengan mekanisme ini, perubahan versi aplikasi dapat dilakukan secara terkontrol melalui pipeline CI/CD.

Hasil Implementasi K3s Kubectl

Implementasi K3s Kubectl berhasil menghubungkan proses versioning pada GitLab dengan deployment aplikasi pada Kubernetes. Proses dimulai dari source code yang berada pada repository GitLab. Ketika Git Tag dibuat, GitLab CI/CD menggunakan nilai CI_COMMIT_TAG sebagai versi Docker image. Image kemudian dibangun menggunakan Docker Runner dan dikirim ke GitLab Container Registry.

Setelah image tersedia, proses deployment menggunakan runner K3s untuk menjalankan kubectl. File Deployment Kubernetes kemudian diterapkan ke cluster menggunakan versi image yang sesuai. Kubernetes selanjutnya membuat atau memperbarui Deployment dan Pod. Status resource dapat diperiksa menggunakan kubectl get deployments, kubectl get pods, dan kubectl get services. Dengan proses tersebut, perubahan versi aplikasi dapat dilakukan tanpa mengubah file Deployment secara manual setiap kali image mengalami pembaruan.

Kesimpulan K3s Kubectl

Metode K3s Kubectl berhasil menerapkan deployment aplikasi menggunakan Kubernetes K3s dan GitLab CI/CD. Proses build Docker image dilakukan menggunakan runner-docker-rnd, sedangkan proses deployment ke Kubernetes dilakukan menggunakan runner-k3s dengan perintah kubectl. Image versioning diterapkan melalui CI_COMMIT_TAG, sehingga setiap Git Tag dapat menghasilkan Docker image dengan versi yang sesuai. Versi tersebut kemudian digunakan oleh Deployment Kubernetes untuk menentukan image yang harus dijalankan.

GitLab Container Registry digunakan sebagai tempat penyimpanan Docker image, sedangkan Kubernetes Secret gitlab-registry digunakan agar K3s dapat melakukan autentikasi ketika mengambil private image dari registry. Dibandingkan dengan Docker Compose, metode ini memberikan pengelolaan aplikasi melalui resource Kubernetes seperti Deployment, Pod, Service, dan Secret. Proses pembaruan aplikasi juga dapat dikontrol melalui mekanisme rollout Kubernetes sehingga perubahan versi dapat dipantau setelah deployment dilakukan.