Panduan ini berasal dari dokumentasi internal untuk tim engineering di Vidio, yang kami rasa mungkin berguna untuk dibagikan kepada komunitas yang lebih luas. Kami sadari ada background / context yang kurang lengkap yang kami masih belum sempat menambahkannya.

Skill yang dibutuhkan

Bagian ini hanya mendeskripsikan skill apa saja yang dibutuhkan. Kalau kamu tertarik untuk belajar lebih lanjut tentang skill-skill tersebut, kamu bisa klik link silabus ini: DevOps-team Training Syllabus

Docker

Docker digunakan untuk men-develop aplikasi di local environment menggunakan container. Aplikasi yang kamu develop nantinya akan dibungkus ke dalam container. Hal umum yang dilakukan biasanya membuat container image lalu menjalankannya. Adapun perintah-perintah  terkait yang bisa kamu pelajari lebih lanjut:

• Dockerfile
• docker build
• docker run
• docker-compose

Kubernetes

Kubernetes digunakan untuk menjalankan image container di non-local environment, seperti staging dan production. Kubernetes menyediakan orkestrasi, yaitu menangani container lifecycle mulai dari scheduling, scaling, rollout, networking, dan sebagainya.

Kubernetes memiliki banyak sekali fitur sehingga butuh waktu yang lama untuk menguasainya, tapi kamu bisa mulai mempelajari nya dari resource-resource yang sering digunakan, di antaranya yaitu:

• Namespace
• Configmap
• Secret
• Pod
• Deployment
• Service
• HPA
• PDB
• Network policy

Helm

Helm adalah package manager untuk Kubernetes, seperti apt/dpkg/.deb untuk Debian/Ubuntu. Package manager dibutuhkan karena manifest kubernetes berupa yaml, sehingga jika kita ingin menginstall aplikasi serupa di 2 cluster berbeda (staging dan prod), kita akan butuh 2 salinan files yaml dan akan perlu mengganti beberapa values-nya agar sesuai dengan masing-masing cluster. Sebagai contoh, vidio web di staging menggunakan DB staging dan vidio web di prod menggunakan DB prod, masing-masing DB tentunya memiliki hostname DB yang berbeda.

Helm mencoba memecahkan masalah ini dengan sebuah paket yang disebut Helm Chart. Helm Chart adalah sebuah package yang berisi templates dan default values. Chart ini bisa diinstal ke beberapa cluster dengan values yang berbeda-beda.

Untuk lebih lanjut tentang Helm bisa dipelajari disini:

• Templating syntax
• Values
• Functions

Getting access

Gitlab repository

Kubernetes cluster kita dikonfigurasi mengunakan git repo dibawah ini:

• Nakhoda
• Nakhoda-charts

Semua engineer harusnya sudah memiliki access ke repo-repo tersebut. Untuk memastikan, kamu bisa mencoba clone dan pull dari repo-repo tersebut.

Kubernetes cluster

Kubectl

Kubectl adalah command line tool yang dapat kamu gunakan untuk berinteraksi dengan Kubernetes cluster. Untuk menggunakan kubectl dengan GKE, kamu harus menginstall tool berikut ini dan mengkonfigurasinya supaya bisa berkomunikasi dengan cluster. Jika kamu menjalankan beberapa cluster di Google Cloud, kamu perlu mengkonfigurasi kubectl lebih lanjut:

Tutorial untuk install kubectl dan dependencies yang dibutuhkan.

Kubectl membaca file kubeconfig untuk mendapatkan konfigurasi cluster yang akan diakses. Secara default, kubectl mencari file dengan nama config pada direktori $HOME/.kube.

Kubeconfig berisi kumpulan parameter yang disebut contexts. Setiap contexts berisi cluster Kubernetes, user, juga default namespace (optional). Perintah kubectl mengacu ke contexts yang sedang dipilih.

Switch context

Kita memiliki beberapa cluster Kubernetes: tools-build, staging, prod, dll.
Untuk menggunakan kubectl pada cluster yang diinginkan, kita perlu mengambil credential dan mengatur contextnya di file kubeconfig.

Untuk mengecek context mana yang sedang digunakan untuk kubectl, jalankan:
kubectl config current-context

Untuk mengganti context ke cluster lain, jalankan:
gcloud container clusters get-credentials CLUSTER_NAME --region=COMPUTE_REGION --project=PROJECT_NAME

Kita memiliki script di nahkoda untuk mempersingkat perintah-perintah diatas, bisa kamu lihat di bin/switch-context.sh di dalam repo nakhoda.

Cara pemanggilan script nya seperti di bawah ini :

• ./bin/switch-context.sh tools-build
• ./bin/switch-context.sh staging

Kamu bisa mengacu ke dokumen ini untuk contoh lainnya

• https://repo.kmklabs.com/kmk-online/nakhoda#getting-kubectl-access-to-the-cluster

VPN

Control plane yang ada di cluster GKE kita dibatasi aksesnya dari network internal saja untuk keamanan. Agar kamu bisa terhubung ke control plane / menggunakan kubectl dari network luar, kamu perlu terhubung melalui VPN.

Pastikan kamu terhubung ke VPN yang sesuai berdasarkan project di cluster GKE

Jika kamu belum memiliki vpn di atas, kamu bisa mengacu ke dokumen ini untuk tutorial mendapatkan akses VPN-nya:

https://repo.kmklabs.com/kmk-online/kmk-access/-/wikis/HOWTO-OpenVPN-Access

Permission

Jika kamu belum memiliki akses untuk melakukan switch-context atau menjalankan perintah kubectl pada cluster tertentu, kamu bisa lihat https://repo.kmklabs.com/kmk-online/nakhoda#adding-people-access-to-gke

Pengenalan Nakhoda dan Nakhoda-charts

Objek-objek kubernetes bisa dibuat, diupdate dan dihapus dengan menyimpan beberapa file konfigurasi di sebuah direktori dan menjalankan kubectl apply pada directory tersebut secara recursive. File-file ini disebut dengan manifest dan disimpan dalam format YAML. Format YAML memungkinkan untuk mengkonfigurasi aplikasi Kubernetes secara deklaratif.

Nakhoda

Struktur direktori Nakhoda dan standarisasinya:

• bin/ : berisi file-file executables
• config/ : berisi config cluster yang digunakan untuk setup script
• gcp-resources/ : berisi resource-resource GCP yang di pakai oleh GKE project namun tidak di kelola oleh kubernetes
• jenkins: berisi file-file groovy untuk job jenkins yang berkaitan dengan GKE
• kubernetes/ : berisi manifest-manifest kubernetes

      └── {namespace}
          └── {name service}
              └── file-file manifest 

Agar penamaan file yang lebih jelas, kami menyarankan penamaannya mengikuti resource kind-nya, contohnya: deployment.yaml, service.yaml

Ada beberapa manifest konfigurasi yang secara khusus disimpan di nakhoda (bukan di dalam helm chart) untuk masing-masing servicesnya di GKE kita:

• Namespace
  Namespace secara eksklusif disimpan di nakhoda, sehingga setiap nama service harus menentukan nama namespace yang diinginkan.

• Helm Release
  HelmRelease adalah instalasi dari chart yang berjalan di cluster Kubernetes. Manifest ini akan menginstall chart yang ada di Helm repository, termasuk nakhoda-chart. File ini juga berisi helm values yang akan digunakan.

• Secret
  Secret adalah kubernetes object yang berisi data sensitive atau rahasia. Secret bisa digunakan oleh pod atau digunakan sebagai HelmRelease values.

• Limitrange
  Konfigurasi yang digunakan untuk membatasi alokasi resource (berupa limits dan requests) pada setiap jenis objek (seperti Pod atau PersistentVolumeClaim) di sebuah namespace.

• Resourcequota
  Konfigurasi yang digunakan untuk membatasi penggunaan keseluruhan sumber daya (resource) per namespace. Resource quota mampu membatasi jumlah objek yang dapat dibuat pada sebuah namespace menurut jenisnya, serta jumlah total sumber daya komputasi (compute resources) yang dapat dipakai oleh sumber daya (resources) di namespace tersebut.

  Hindari untuk membatasi satu jenis objek resource yang sama pada suatu namespace. Sebagai contoh, dua resource quota yang berbeda dalam sebuah namespace tidak boleh sama-sama membatasi jumlah maksimal pod yang diperbolehkan.

Flux

Flux merupakan sebuah tool yang bertugas untuk menjaga kubernetes cluster tetap sinkron dengan kode yang ada pada git repositories (GitOps), sekaligus juga melakukan otomatisasi pembaruan pada objek kubernetes saat ada kode baru yang ditambahkan. Ada beberapa manifest objek flux yang perlu dibuat di nakhoda agar sebuah layanan (service) dapat dikelola oleh flux itu. Manifest tersebut terletak pada path directory kubernetes/{cluster-name}/flux-system.

• Sources
• Kustomizations

Flux menerapkan GitOps dalam mengelola dan mensinkronisasi kubernetes cluster berdasarkan file konfigurasi yang berada di git repository. GitOps merupakan sebuah cara yang digunakan untuk mengelola infrastruktur dan aplikasi sehingga keseluruhan sistem ditulis secara deklaratif dalam source control (git) repository, dan memiliki proses otomatis yang memastikan bahwa cluster berjalan dalam kondisi yang telah ditentukan pada repository.

Dengan ini, setiap kali terdapat perubahan pada repository nakhoda, flux akan melakukan “git pull” perubahan tersebut dan menerapkannya pada kubernetes cluster.

Nakhoda-Charts

Nakhoda-charts merupakan repository tempat semua helm charts buatan sendiri ditempatkan.

Struktur direktori :

nama-chart/
├── Chart.yaml
├── Values.yaml
├── templates/

Helm charts

Helm charts merupakan kubernetes package yang berisi templates dan default values. Helm chart dapat diinstal ke beberapa cluster dengan values yang berbeda. Untuk service yang kita develop sendiri, kita juga membuat helm charts sendiri untuk menyesuaikan kebutuhan infrastruktur kita. Helm charts tersebut ditempatkan di repository nakhoda-charts.

Mengapa menggunakan charts?

• Manifest kubernetes bisa di-reuse di environments berbeda
• Menggunakan template
• Helm charts menyediakan fitur template dalam proses pembuatan konfigurasi, hal ini memfasilitasi kita membuat charts lebih kreatif sesuai dengan kebutuhan.
• Helm template yang sama dapat digunakan sekaligus di lingkungan staging dan production
• Karena charts menggunakan template, charts dapat digunakan kembali secara berulang pada lingkungan yang berbeda. Contohnya logging, karena kami memiliki logging di setiap environment (staging / production), kami cukup menyiapkan 1 helm chart saja untuk logging ini, selanjutnya chart ini dapat digunakan di setiap environment yang membutuhkan infrastruktur logging.
• Kita bisa menentukan default values dari variables dari di dalam helm chart.

Di artikel berikutnya kita akan membahas proses migrasi.