whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add Kubernetes Components in lang ID. (#13888)

Browse Source 
* Add Kubernetes Components in lang ID.

* Remove glossary since it's not translated yet.

* Add what is kubernetes? in ID lang

* Add kubernetes API in lang ID.

* Address id loc suggestions fo Kubernetes' overview.

* Remove uneeded lines of definitions.

* Add glossaries for Bahasa Indonesia.

* Add kubelet glossary for Bahasa Indonesia.

* Fix all italics due to missing period and false tag.
This commit is contained in:
Irvi Aini
2019-04-21 18:41:45 +07:00
committed by Kubernetes Prow Robot
parent 734eb9a086
commit f1a8462407
9 changed files with 592 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/id/docs/concepts/overview/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
title: "Ikhtisar"
weight: 20
---
content/id/docs/concepts/overview/components.md
+152
View File
@@ -0,0 +1,152 @@
---
title: Komponen-Komponen Kubernetes
content_template: templates/concept
weight: 20
card:
name: concepts
weight: 20
---
{{% capture overview %}}
Dokumen ini merupakan ikhtisar yang mencakup berbagai komponen
yang dibutuhkan agar kluster Kubernetes dapat berjalan secara fungsional.
{{% /capture %}}
{{% capture body %}}
## Komponen <i>Master</i>
Komponen <i>master</i> menyediakan <i>control plane</i> bagi kluster.
Komponen ini berperan dalam proses pengambilan secara global
pada kluster (contohnya, mekanisme <i>schedule</i>), serta berperan dalam proses
deteksi serta pemberian respons terhadap <i>events</i> yang berlangsung di dalam kluster
(contohnya, penjadwalan pod baru apabila jumlah replika yang ada pada
<i>replication controller</i> tidak terpenuhi).
Komponen master dapat dijalankan di mesin manapun yang ada di kluster. Meski begitu,
untuk memudahkan proses yang ada, <i>script</i> inisiasi awal yang dijalankan
biasanya memulai komponen master pada mesin yang sama, serta tidak menjalankan
kontainer bagi pengguna di mesin ini. Contoh konfigurasi <i>multi-master VM</i>
dapat dilihat di modul [Membangun Kluster HA] (/docs/admin/high-availability/).
### kube-apiserver
{{< glossary_definition term_id="kube-apiserver" length="all" >}}
### etcd
{{< glossary_definition term_id="etcd" length="all" >}}
### kube-scheduler
{{< glossary_definition term_id="kube-scheduler" length="all" >}}
### kube-controller-manager
{{< glossary_definition term_id="kube-controller-manager" length="all" >}}
Kontroler-kontroler ini meliputi:
* Kontroler <i>Node</i> : Bertanggung jawab untuk mengamati dan memberikan
respons apabila jumlah <i>node</i> berkurang.
* Kontroler Replikasi : Bertanggung jawab untuk menjaga jumlah <i>pod</i> agar
jumlahnya sesuai dengan kebutuhan setiap objek kontroler replikasi yang ada di sistem.
* Kontroler <i>Endpoints</i> : Menginisiasi objek <i>Endpoints</i>
(yang merupakan gabungan <i>Pods</i> dan <i>Services</i>).
* Kontroler <i>Service Account & Token</i>: Membuat akun dan
akses token API standar untuk setiap <i>namespaces</i> yang dibuat.
### cloud-controller-manager
[Cloud-controller-manager](/en/docs/tasks/administer-cluster/running-cloud-controller/) merupakan kontroler yang berinteraksi dengan penyedia layanan <i>cloud</i>.
Kontroler ini merupakat fitur alfa yang diperkenalkan pada Kubernetes versi 1.6.
<i>Cloud-controller-manager</i> hanya menjalankan iterasi kontroler <i>cloud-provider-specific</i> .
Kamu harus menonaktifkan iterasi kontroler ini pada <i>kube-controller-manager</i>.
Kamu dapat menonaktifka iterasi kontroler ini dengan mengubah nilai argumen `--cloud-provider` dengan `external`
ketika menginisiasi <i>kube-controller-manager</i>.
Adanya <i>cloud-controller-manager</i> memungkinkan kode yang dimiliki oleh penyedia layanan <i>cloud</i>
dan kode yang ada pada Kubernetes saling tidak bergantung selama masa <i>development</i>.
Pada versi sebelumnya, Kubernetes bergantung pada fungsionalitas spesifik yang disediakan oleh
penyedia layanan <i>cloud</i>. Di masa mendatang, kode yang secara spesifik dimiliki oleh
penyedia layanan <i>cloud</i> akan dipelihara oleh penyedia layanan <i>cloud</i> itu sendiri,
kode ini selanjutnya akan dihubungkan dengan <i>cloud-controller-manager</i> ketika Kubernetes dijalankan.
Kontroler berikut ini memiliki keterkaitan dengan penyedia layanan <i>cloud</i>:
* Kontroler Node : Melakukan pengecekan pada penyedia layanan <i>cloud</i> ketika menentukan apakah sebuah <i>node</i> telah dihapus pada <i>cloud</i> apabila <i>node</i> tersebut berhenti memberikan respons.
* Kontroler Route : Melakukan pengaturan awal <i>route</i> yang ada pada penyedia layanan <i>cloud</i>
* Kontroler Service : Untuk membuat, memperbaharui, menghapus <i>load balancer</i> yang disediakan oleh penyedia layanan <i>cloud</i>
* Kontroler Volume : Untuk membuat, meng-attach, dan melakukan <i>mount volume</i> serta melakukan inetraksi dengan penyedia layanan <i>cloud</i> untuk melakukan orkestrasi <i>volume</i>
## Komponen <i>Node</i>
Komponen ini ada pada setiap <i>node</i>, fungsinya adalah melakukan pemeliharaan terhadap <i>pod</i> serta menyediakan <i>environment runtime</i> bagi Kubernetes.
### kubelet
{{< glossary_definition term_id="kubelet" length="all" >}}
### kube-proxy
[kube-proxy](/docs/admin/kube-proxy/) membantu abstraksi service Kubernetes melakukan tugasnya. Hal ini terjadi dengan cara memelihara aturan-aturan jaringan (network rules) serta meneruskan koneksi yang ditujukan pada suatu host.
### <i>Container Runtime</i>
<i>Container runtime</i> adalah perangkat lunak yang bertanggung jawab dalam menjalankan kontainer.
Kubernetes mendukung beberapa <i>runtime</i>, diantaranya adalah: [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) dan semua implementasi [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
## <i>Addons</i>
<i>Addons</i> merupakan pod dan service yang mengimplementasikan fitur-fitur yang diperlukan kluster.
Beberapa <i>addons</i> akan dijelaskan selanjutnya.
### DNS
Meskipun tidak semua <i>addons</i> dibutuhkan, semua kluster Kubernetes hendaknya
memiliki DNS kluster. Komponen ini penting karena banyak dibutuhkan oleh komponen
lainnya.
[Kluster DNS](/en/docs/concepts/cluster-administration/addons/ ) adalah server DNS, selain beberapa server DNS lain yang sudah ada di
<i>environment</i> kamu, yang berfungsi sebagai catatan DNS bagi Kubernetes <i>services</i>
Kontainer yang dimulai oleh kubernetes secara otomatis akan memasukkan server DNS ini
ke dalam mekanisme pencarian DNS yang dimilikinya.
### <i>Web UI</i> (Dasbor)
[Dasbor](/en/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada kluster Kubernetes.
Dasbor ini memungkinkan user melakukan manajemen dan <i>troubleshooting</i> kluster maupun
aplikasi yang ada pada kluster itu sendiri.
### <i>Container Resource Monitoring</i>
[Container Resource Monitoring](/en/docs/tasks/debug-application-cluster/resource-usage-monitoring/) mencatat metrik <i>time-series</i> yang diperoleh
dari kontainer ke dalam basis data serta menyediakan antar muka yang dapat digunakan
untuk melakukan pencarian data yang dibutuhkan.
### <i>Cluster-level Logging</i>
[Cluster-level logging](/en/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat <i>log</i> kontainer pada
penyimpanan <i>log</i> terpusat dengan antar muka yang dapat digunakan untuk melakukan
pencarian.
{{% /capture %}}
content/id/docs/concepts/overview/kubernetes-api.md
+156
View File
@@ -0,0 +1,156 @@
---
title: API Kubernetes
content_template: templates/concept
weight: 30
card:
name: concepts
weight: 30
---
{{% capture overview %}}
Secara keseluruhan standar yang digunakan untuk API dijelaskan di dalam [dokumentasi API standar](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
<i>Endpoints API</i>, <i>resource types</i> serta contoh penggunaan dijelaskan di dalam [API Reference](/en/docs/reference).
Akses <i>remote</i> penggunaan API dijelaskan di dalam [dokumentasi akses API](/en/docs/reference/access-authn-authz/controlling-access/).
API Kubernetes juga berperan sebagai skema konfigurasi yang deklaratif di dalam sistem.. Sementara itu, [kubectl](/en/docs/reference/kubectl/overview/) merupakan <i>command-line</i> yang dapat digunakan untuk membuat, menmperbaharui, menghapus, dan mendapatkan obyek API.
Kubernetes menyimpan bentuk terserialisasi dari obyek API yang dimilikinya di dalam [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/).
Kubernetes sendiri dibagi menjadi beberapa komponen yang saling dapat saling interaksi melalui API.
{{% /capture %}}
{{% capture body %}}
## Perubahan API
Berdasarkan pengalaman kami, semua sistem yang berhasil memerlukan kebutuhan
untuk terus tumbuh dan berkembang seiring dengan bertambahnya kebutuhan
yang ada. Dengan demikian, kami berekspektasi bahwa API akan selalu berubah seiring dengan bertambahnya kebutuhan yang ada.
Meski begitu, perubahan yang ada akan selalu kompatibel dengan implementasi sebelumnya, untuk jangka waktu tertentu.
Secara umum, penambahan pada sebuah resource API atau field resource bisa sering terjadi.. Penghapusan <i>resource API</i> atau suatu <i>field</i>, di sisi lain,
diharapkan untuk dapat memenuhi [kaidah deprecation API](/docs/reference/using-api/deprecation-policy/).
Hal-hal apa saja yang perlu diperhatikan untuk menjamin kompatibilitas API
secara rinci dibahas di dalam [dokumentasi perubahan API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md).
## Swagger and OpenAPI Definition
Detail mengenai API didokumentasikan dengan menggunakan [OpenAPI](https://www.openapis.org/).
Semenjak Kubernetes versi 1.10, Kubernetes menghadirkan spesifikasi <i>OpenAPI</i> melalui <i>endpoint</i> `/openapi/v2`.
Format <i>request</i> dapat diterapkan dengan cara menambahkan <i>header HTTP</i>:
Header | Opsi
------ | ---------------
Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (<i>content-type</i> standar yang digunakan adalah `application/json` untuk `*/*`)
Accept-Encoding | `gzip`
Sebelum versi 1.14, terdapat 4 buah <i>endpoint</i> yang menyediakan spesifikasi <i>OpenAPI</i>
dalam format berbeda yang dapat digunakan (`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`).
<i>Endpoint</i> ini bersifat <i>deprecated</i> dan akan dihapus pada Kubernetes versi 1.14.
**Cara mendapatkan spesifikasi <i>OpenAPI</i>**:
Sebelum 1.10 | Mulai Kubernetes 1.10
----------- | -----------------------------
GET /swagger.json | GET /openapi/v2 **Accept**: application/json
GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf
GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip
Kubernetes juga menyediakan alternatif mekanisme serialisasi lain,
yaitu dengan menggunakan <i>Protobuf</i>, yang secara umum digunakan untuk mekanisme komunikasi
intra-kluster, hal ini didokumentasikan di dalam [proposal desain](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)
serta berkas IDL sebagai bentuk spesifikasi skema berada dalam <i>package</i> Go
Sebelum Kubernetes versi 1.14, <i>apiserver</i> Kubernetes juga mengekspos API
yang dapat digunakan untuk mendapatkan spesifikasi [Swagger v1.2](http://swagger.io/) pada <i>endpoint</i> `/swaggerapi`.
<i>Endpoint</i> ini akan sudah bersifat <i>deprecated</i> dan akan dihapus pada
Kubernetes versi 1.14.
## Pemberian Versi pada API
Untuk memudahkan restrukturisasi field dan resource yang ada,
Kubernetes menyediakan beberapa versi API yang berada pada <i>path</i> yang berbeda,
misalnya `/api/v1` atau `/apis/extensions/v1beta1`.
Kita dapat memilih versi yang akan digunakan pada tingkatan API
dan bukan pada tingkatan <i>field</i> atau <i>resource</i> untuk memastikan
API yang digunakan memperlihatkan gambaran yang jelas serta konsisten
mengenai <i>resoure</i> dan sifat sistem yang ada.
Perhatikan bahwa pemberian versi pada API dan pemberian versi pada API dan perangkat lunak memiliki keterkaitan secara tak langsung.
Proposal [API and release
versioning](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) memberikan deskripsi keterkaitan antara
pemberian versi pada API dan pemberian versi pada perangkat lunak.
API dengan versi yang berbeda menunjukan tingkatan kestabilan dan ketersediaan yang diberikan pada versi tersebut.
Kriteria untuk setiap tingkatan dideskripsikan secara lebih detail di dalam
[dokumentasi perubahan API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). They are summarized here:
- Tingkatan <i>Alpha</i>:
- Nama dari versi ini mengandung string `alpha` (misalnya, `v1alpha1`).
- Bisa jadi terdapat <i>bug</i>. Secara <i>default</i> fitur ini tidak diekspos.
- Ketersediaan untuk fitur yang ada bisa saja dihilangkan pada suatu waktu tanpa pemberitahuan sebelumnya.
- API yang ada mungkin saja berubah tanpa memperhatikan kompatibilitas dengan versi perangkat lunak sebelumnya.
- Hanya direkomendasikan untuk kluster yang digunakan untuk tujuan <i>testing</i>.
- Tingkatan <i>Beta</i>:
- Nama dari versi ini mengandung string `beta` (misalnya `v2beta3`).
- Kode yang ada sudah melalui mekanisme <i>testing</i> yang cukup baik. Menggunakan fitur ini dianggap cukup aman. Fitur ini diekspos secara <i>default</i>.
- Ketersediaan untuk fitur secara menyeluruh tidak akan dihapus, meskipun begitu detail untuk suatu fitur bisa saja berubah.
- Skema dan/atau semantik dari suatu obyek mungkin saja berubah tanpa memerhatikan kompatibilitas pada rilis <i>beta</i> selanjutnya.
Jika hal ini terjadi, kami akan menyediakan suatu instruksi untuk melakukan migrasi di versi rilis selanjutnya. hal ini bisa saja terdiri dari penghapusan, pengubahan, ataupun pembuatan
obyek API. Proses pengubahan mungkin saja membutuhkan pemikiran yang matang. Dampak proses ini bisa saja menyebabkan <i>downtime</i> aplikasi yang bergantung pada fitur ini.
- Disarankan hanya untuk digunakan untuk penggunaan yang untuk penggunaan yang tidak berdampak langsung pada bisnis kamu.
- **Kami mohon untuk mencoba versi <i>beta</i> yang kami sediakan dan berikan masukan terhadap fitur yang kamu pakai! Apabila fitur tersebut sudah tidak lagi berada di dalam tingkatan <i>beta</i> perubahan yang kami buat terhadap fitur tersebut bisa jadi tidak lagi dapat digunakan**
- Tingkatan stabil:
- Nama dari versi ini mengandung string `vX` dimana `X` merupakan bilangan bulat.
- Fitur yang ada pada tingkatan ini akan selalu muncul di rilis berikutnya.
## <i>API groups</i>
Untuk memudahkan proses ekstensi suatu API Kubernetes, kami mengimplementasikan [*API groups*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md).
<i>API group</i> ini dispesifikasikan di dalam <i>path</i> <i>REST</i> serta di dalam <i>field</i> `apiVersion` dari sebuah obyek yang sudah diserialisasi.
Saat ini, terdapat beberapa <i>API groups</i> yang digunakan:
1. Kelompok *core*, seringkali disebut sebagai *legacy group*, berada pada <i>path</i> <i>REST</i> `/api/v1` serta menggunakan `apiVersion: v1`.
1. <i>Named groups</i> berada pada <i>path</i> <i>REST</i> `/apis/$GROUP_NAME/$VERSION`, serta menggunakan `apiVersion: $GROUP_NAME/$VERSION`
(misalnya `apiVersion: batch/v1`). Daftar menyeluruh mengenai apa saja <i>API groups</i> dapat dilihat di [Kubernetes API reference](/docs/reference/).
Ekstensi API dengan custom resources dapat dilakukan melalui dua buah path:
1. [CustomResourceDefinition]()
digunakan jika memerlukan seluruh set semantik Kubernetes API, pengguna boleh implementasi apiserver sendiri dengan menggunakan aggregator.
1. Pengguna yang membutuhkan seperangkat semantik API Kubernetes API dapat mengimplementasikan <i>apiserver</i> mereka sendiri.
dengan menggunakan [aggregator]()
untuk membuat integrasi dengan klien menjadi lebih mudah.
## Mengaktifkan <i> API groups</i>
Beberapa <i>resources</i> dan <i>API groups</i> sudah diaktifkan secara <i>default</i>.
<i>Resource</i> dan <i>API groups</i> ini dapat diaktifkan dan dinonaktifkan dengan mengatur penanda `--runtime-config`
pada <i>apiserver</i>. `--runtime-config` menerima nilai yang dipisahkan oleh koma. Sebagai contoh: untuk menonaktifkan batch/v1, tetapkan
`--runtime-config=batch/v1=false`, untuk mengaktifkan batch/v2alpha1, tetapkan `--runtime-config=batch/v2alpha1`.
Penanda menerima nilai yang dipisahkan oleh pasangan `key=value` yang mendeskripsikan konfigurasi <i>runtime</i> pada <i>apiserver</i>.
PENTING: Melakukan proses mengaktifkan atau menonaktifkan <i>groups</i> atau <i>resources</i>
membutuhkan mekanisme <i>restart</i> <i>apiserver</i> dan <i>controller-manager</i>
agar <i>apiserver</i> dapat menerima perubahan `--runtime-config`.
## Mengaktifkan <i>resources</i> di dalam <i>groups</i>
<i>DaemonSets</i>, <i>Deployments</i>, <i>HorizontalPodAutoscalers</i>,
<i>Ingresses</i>, <i>Jobs</i>, dan <i>ReplicaSets</i> diaktifkan secara <i>default</i>.
Ekstensi lain dapat diaktifkan penanda `--runtime-config` pada <i>apiserver</i>. Penanda `--runtime-config` menerima nilai yang dipisahkan oleh koma.
Sebagai contoh untuk menonaktifkan <i>deployments</i> dan <i>ingress</i>, tetapkan.
`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`
{{% /capture %}}
content/id/docs/concepts/overview/what-is-kubernetes.md
+189
View File
@@ -0,0 +1,189 @@
---
title: Apa itu Kubernetes?
content_template: templates/concept
weight: 10
card:
name: concepts
weight: 10
---
{{% capture overview %}}
Laman ini merupakan ikhtisar Kubernetes.
{{% /capture %}}
{{% capture body %}}
Kubernetes merupakan <i>platform open-source</i> yang digunakan untuk melakukan
manajemen <i>workloads</i> aplikasi yang dikontainerisasi, serta menyediakan
konfigurasi dan otomatisasi secara deklaratif. Kubernetes berada di dalam ekosistem
yang besar dan berkembang cepat. <i>Service</i>, <i>support</i>, dan perkakas
Kubernetes tersedia secara meluas.
Google membuka Kubernetes sebagai proyek <i>open source</i> pada tahun 2014.
Kubernetes dibangun berdasarkan [pengalaman Google selama satu setengah dekade dalam menjalankan workloads](https://research.google.com/pubs/pub43438.html)
bersamaan dengan kontribusi berupa ide-ide terbaik yang diberikan oleh komunitas.
## Mengapa Kubernetes dan hal apa saja yang dapat dilakukan oleh Kubernetes?
Kubernetes memiliki sejumlah fitur yang dapat dijabarkan sebagai berikut:
- <i>platform</i> kontainer
- <i>platform microservices</i>
- <i>platform cloud</i> yang tidak mudah dipindahkan
Kubernetes menyediakan manajemen <i>environment</i> yang berpusat pada kontainer.
Kubernetes melakukan orkestrasi terhadap <i>computing</i>, <i>networking</i>,
dan inftrastruktur penyimpanan. Fitur inilah yang kemudian membuat konsep Platform as a Service (PaaS)
menjadi lebih sederhana dilengkapi dengan fleksibilitas yang dimiliki oleh Infrastructure as a Service (IaaS).
## Lalu apa yang menyebabkan Kubernetes disebut sebagai sebuah platform?
Meskipun Kubernetes menyediakan banyak fungsionalitas, selalu ada keadaan dimana
hal tersebut membutuhkan fitur baru. <i>Workflow</i> spesifik yang terkait dengan
proses pengembangan aplikasi dapat ditambahkan pada <i>streamline</i> untuk meningkatkan
produktivitas developer. Orkestrasi ad-hoc yang dapat diterima biasanya membutuhkan desain
otomatisasi yang kokoh agar bersifat <i>scalable</i>. Hal inilah yang membuat
Kubernetes juga didesain sebagai <i>platform</i> untuk membangun ekosistem komponen dan
dan perkakas untuk memudahkan proses <i>deployment</i>, <i>scale</i>, dan juga manajemen
aplikasi.
[Labels]() memudahkan pengguna mengkategorisasikan <i>resources</i> yang mereka miliki
sesuai dengan kebutuhan. [Annotations]() memungkinkan pengguna untuk menambahkan informasi
tambahan pada <i>resource</i> yang dimiliki.
Selain itu, [Kubernetes control plane]() dibuat berdasarkan
[API](/docs/reference/using-api/api-overview/) yang tersedia bagi pengguna dan developer. Pengguna
dapat mengimplementasikan kontroler sesuai dengan kebutuhan mereka, contohnya adalah
[schedulers](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md),
dengan [API kustom yang mereka miliki](), kontroler kustom ini kemudian dapat digunakan
pada [command-line
tool]() generik yang ada.
[Desain](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)
inilah yang memungkinkan beberapa sistem lain untuk dapat dibangun di atas Kubernetes.
## Lalu hal apakah yang tidak termasuk di dalam Kubernetes?
Kubernetes bukanlah sebuah <i>PaaS (Platform as a
Service)</i> yang biasanya. Meskipun Kubernetes dijalankan pada tingkatan kontainer
dan bukan pada tingkatan perangkat keras, Kubernetes menyediakan beberapa fitur
yang biasanya disediakan oleh Paas, seperti <i>deployment</i>, <i>scaling</i>,
<i>load balancing</i>, <i>logging</i>, dan <i>monitoring</i>. Akan tetapi,
Kubernetes bukanlah sistem monolitik, melainkan suatu sistem yang bersifat sebagai
<i>bulding block</i> dan <i>pluggable</i> yang dapat digunakan untuk membangun sebuah
platform yang dibutuhkan oleh developer dengan tetap mengutamakan konsep fleksibilitas.
Kubernetes:
* Tidak melakukan limitasi terhadap aplikasi yang di-support. Kubernetes bertujuan
untuk mendukung berbagai variasi <i>workloads</i>, termasuk
<i>stateless</i>, <i>stateful</i>, dan <i>data-processing</i>. Jika sebuah
aplikasi dapat dijalankan di atas kontainer, maka aplikasi tersebut juga dapat
dijalankan di atas Kubernetes.
* Tidak menyediakan mekanisme untuk melakukan <i>deploy</i> kode sumber
maupun mekanisme <i>build</i> sebuah aplikasi. <i>Continuous Integration, Delivery, and Deployment
(CI/CD) workflows</i> ditentukan oleh preferensi serta kebutuhan teknis organisasi.
* Tidak menyediakan <i>application-level services</i>, seperti <i>middleware
(e.g., message buses)</i>, <i>data-processing frameworks (for example,
Spark)</i>, <i>databases (e.g., mysql)</i>, <i>caches</i>, maupun <i>cluster storage systems (e.g.,
Ceph)</i> sebagai suatu <i>built-in services</i>. Komponen tersebut dapat dijalankan di atas Kubernetes, dan/atau
dapat diakses oleh aplikasi yang dijalankan di atas Kubernetes melalui sebuah mekanisme tidak mudah dipindahkan
misalnya saja <i>Open Service Broker</i>.
* Tidak membatasi penyedia layanan <i>logging</i>, <i>monitoring</i>, maupun <i>alerting</i> yang digunakan.
Kubernetes menyediakan <i>proof of concept</i> dan mekanisme integrasi yang dapat digunakan
untuk mengumpulkan serta mengekspor metriks yang ada.
* Tidak menyediakan atau mengharuskan penggunaan <i>configuration language/system (e.g.,
[jsonnet](https://github.com/google/jsonnet))</i>. Kubernetes menyediakan suatu API deklaratif
yang dapat digunakan oleh berbagai jenis spesifikasi deklaratif.
* Tidak menyediakan atau mengadaptasi sebuah konfigurasi, <i>maintenance</i>, manajemen, atau
<i>self-healing</i> mesin dengan spesifikasi khusus.
Sebagai tambahan, Kubernetes bukanlah sebuah *sitem orkestrasi biasa*. Bahkan pada kenyataannya,
Kubernetes menghilangkan kebutuhan untuk melakukan orkestrasi. Definisi teknis dari
*orkestrasi* merupakan eksekusi dari sebuah workflow yang sudah didefinisikan sebelumnya: pertama kerjakan A, kemudian B,
dan terakhir C. Sebaliknya, Kubernetes disusun oleh seperangkat
proses kontrol yang dapat idekomposisi yang selalu menjalankan <i>state</i> yang ada
saat ini hingga sesuai dengan <i>state</i> yang dinginkan.
Kita tidak perlu peduli proses apa saja yang perlu dilakukan untuk melakukan A hingga C.
Mekanisme kontrol yang tersentralisasi juga tidak dibutuhkan. Dengan demikian, sistem yang
dihasilkan lebih mudah digunakan lebih kokoh, serta lebih <i>extensible</i>.
## Mengapa kontainer?
Mencari alasan kenapa kita harus menggunakan kontainer?
![Mengapa kontainer?](/images/docs/why_containers.svg)
*Cara Lama* untuk melakukan mekanisme <i>deploy</i> suatu aplikasi
adalah dengan cara instalasi aplikasi tersebut pada sebuah mesin
dengan menggunakan <i>package manager</i> yang dimiliki oleh sistem operasi
mesin tersebut. Hal ini menciptakan suatu ketergantungan antara <i>executables</i>,
konfigurasi, serta ketergantungan lain yang dibutuhkan aplikasi dengan sistem operasi
yang digunakan oleh mesin. Untuk mengatasi hal ini, tentunya bisa saja kita melakukan
mekanisme <i>build</i> suatu <i>image</i> VM yang <i>immutable</i> untuk mendapatkan
mekanisme <i>rollouts</i> dan <i>rollback</i> yang dapat diprediksi.
Meskipun demikian, VM masih dianggap "berat" dan tidak tidak mudah dipindahkan.
*Cara Baru* adalah dengan melakukan mekanisme <i>deploy</i> kontainer pada tingkatan
virtualisasi di level sistem operasi (OS) bukan pada tingkatan virtualisasi perangkat keras.
Kontainer ini berada dalam lingkungan yang terisolasi satu sama lain serta terisolasi dengan
mesin dimana kontainer ini berada. Kontainer ini memiliki <i>filesystems</i> masing-masing.
Selain itu, setiap kontainer tidak dapat "melihat" <i>process</i> yang sedang dijalankan di
kontainer lain. Selain itu <i>resource</i> komputasi yang digunakan oleh kontainer
ini juga dapat dibatasi. Kontainer juga dapat dengan lebih mudah di-<i>build</i> jika
dibandingkan dengan VM, karena kontainer tidak bergantung pada <i>filesystem</i>
yang dimiliki mesin, serta dengan mudah dapat didistribusikan.
Karena kontainer ukurannya kecil dan lebih cepat, sebuah aplikasi dapat dibangun di setiap
<i>image</i> kontainer. Mekanisme pemetaan satu-satu antara kontainer dan aplikasi
inilah yang membuka keuntungan secara meyeluruh yang dapat diberikan oleh kontainer.
Dengan menggunakan kontainer, <i>image</i> kontainer dapat dibuat diwaktu rilis aplikasi.
Pembuatan <i>image</i> ini memungkinkan aplikasi secara konsisten dirilis pada
<i>environment</i> <i>development</i> maupun <i>production</i>. Selain itu,
kontainer juga memiliki transparasi yang lebih tinggi dibandingkan dengan VM. Maksudnya,
infrastruktur punya tugas untuk mengatur lifecycle seluruh process yang ada di dalam kontainer. Ini bukanlah lagi tugas sebuah supervisor process yang tersembunyi di dalam kontainer.
Secara garis besar, penggunaan kontainer memiliki keuntungan sebagai berikut:
* **Mekanisme pembuatan aplikasi serta proses deployment yang lebih efektif**:
Kontainer dapat meningkatkan kemudahan dan efisiensi jika dibandingkan dengan penggunaan VM.
* **Continuous development, integration, and deployment**:
Digunakan untuk melakukan proses <i>build</i> dan <i>deploy</i> yang sering dilakukan
serta kemudahan mekanisme <i>rollback</i> karena image yang ada sifatnya <i>immutable</i>.
* **Pemisahan kepentingan antara Dev dan Ops**:
Pembuatan <i>image</i> container dilakukan pada saat rilis dan bukan pada saat <i>deploy</i>
mengurangi ketergantungan aplikasi dan infrastruktur.
* **Observabilitas**
Tidak hanya informasi dan metriks pada level OS, tapi juga kesehatan aplikasi dan <i>signal</i> lain.
* **Konsistensi <i>environment</i> pada masa pengembangan , <i>testing</i>, dan <i>production</i>**:
Memiliki perilaku yang sama baik ketika dijalankan di mesin lokal maupun penyedia layanan <i>cloud</i>.
* **Portabilitas antar penyedia layanan <i>cloud</i> maupun distribusi OS**:
Dapat dijalankan pada Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine, dan dimanapun.
* **Manajemen yang bersifat Aplikasi sentris**:
Meningkatkan level abstraksi dari proses menjalankan OS pada perangkat keras virtual
ke proses menjalankan aplikasi pada sebuah OS dengan menggunakan <i>resource</i> logis.
* **[Mikroservis](https://martinfowler.com/articles/microservices.html) yang renggang (loosely coupled), terdistribusi, elastis, dan terliberasi**:
Aplikasi dapat dipecah menjadi komponen yang lebih kecil yang independen dan dapat
di-<i>deploy</i> dan diatur secara dinamis -- bukan sebuah sistem monolitik yang dijalankan pada
sebuah mesin yang hanya punya satu tujuan.
* **Isolasi <i>resource</i>**:
Performa aplikasi yang bisa diprediksi.
* **Utilisasi <i>resource</i>**:
Efisiensi yang tinggi
## Apakah arti Kubernetes? K8s?
Nama **Kubernetes** berasal dari Bahasa Yunani, yang berarti *juru mudi* atau
*pilot*, dan merupakan asal kata *gubernur* dan
[cybernetic](http://www.etymonline.com/index.php?term=cybernetics). *K8s*
merupakan sebuah singkatan yang didapat dengan mengganti 8 huruf "ubernete" dengan
"8".
{{% /capture %}}
{{% capture whatsnext %}}
* Siap untuk [memulai](/docs/setup/)?
* Untuk penjelasan lebih rinci, silahkan lihat [Dokumentasi Kubernetes](/docs/home/).
{{% /capture %}}
content/id/docs/reference/glossary/etcd.md
+19
View File
@@ -0,0 +1,19 @@
---
title: etcd
id: etcd
date: 2019-04-21
full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
short_description: >
Penyimpanan <i>key value</i> konsisten yang digunakan sebagai penyimpanan data kluster Kubernetes.
aka:
tags:
- architecture
- storage
---
Penyimpanan <i>key value</i> konsisten yang digunakan sebagai penyimpanan data kluster Kubernetes.
<!--more-->
Selalu perhatikan mekanisme untuk mem-<i>backup</i> data etcd pada kluster Kubernetes kamu. Untuk informasi lebih lanjut tentang etcd, lihat [dokumentasi etcd](https://github.com/coreos/etcd/blob/master/Documentation/docs.md).
content/id/docs/reference/glossary/kube-apiserver.md
+19
View File
@@ -0,0 +1,19 @@
---
title: kube-apiserver
id: kube-apiserver
date: 2019-04-21
full_link: /docs/reference/generated/kube-apiserver/
short_description: >
Komponen di master yang mengekspos API Kubernetes. Merupakan <i> front-end </i> dari <i> kontrol plane </i> Kubernetes.
aka:
tags:
- architecture
- fundamental
---
Komponen di master yang mengekspos API Kubernetes. Merupakan <i> front-end </i> dari <i> kontrol plane </i> Kubernetes.
<!--more-->
Komponen ini didesain agar dapat di-<i>scale</i> secara horizontal. Lihat [Membangun Kluster HA](/docs/admin/high-availability/).
content/id/docs/reference/glossary/kube-controller-manager.md
+19
View File
@@ -0,0 +1,19 @@
---
title: kube-controller-manager
id: kube-controller-manager
date: 2019-04-21
full_link: /docs/reference/generated/kube-controller-manager/
short_description: >
Komponen di master yang menjalankan kontroler.
aka:
tags:
- architecture
- fundamental
---
Komponen di master yang menjalankan kontroler.
<!--more-->
Secara logis, setiap kontroler adalah sebuah proses yang berbeda, tetapi untuk mengurangi kompleksitas, kontroler-kontroler ini dikompilasi menjadi sebuah <i> binary </i> yang dijalankan sebagai satu proses.
content/id/docs/reference/glossary/kube-scheduler.md
+18
View File
@@ -0,0 +1,18 @@
---
title: kube-scheduler
id: kube-scheduler
date: 2019-04-21
full_link: /docs/reference/generated/kube-scheduler/
short_description: >
Komponen di master yang bertugas mengamati pod yang baru dibuat dan belum di-<i>assign</i> ke suatu node dan kemudian akan memilih sebuah node dimana pod baru tersebut akan dijalankan.
aka:
tags:
- architecture
---
Komponen di master yang bertugas mengamati pod yang baru dibuat dan belum di-<i>assign</i> ke suatu node dan kemudian akan memilih sebuah node dimana pod baru tersebut akan dijalankan.
<!--more-->
Faktor-faktor yang diperhatikan dalam proses ini adalah kebutuhan <i>resource</i> secara individual dan kolektif, konstrain perangkat keras/perangkat lunak/peraturan, spesifikasi afinitas dan non-afinitas, lokalisasi data, interferensi <i>inter-workload</i> dan <i>deadlines</i>.
content/id/docs/reference/glossary/kubelet.md
+15
View File
@@ -0,0 +1,15 @@
---
title: Kubelet
id: kubelet
date: 2019-04-21
full_link: /docs/reference/generated/kubelet
short_description: >
Agen yang dijalankan pada setiap <i>node</i> di kluster dan bertugas memastikan kontainer dijalankan di dalam pod.
aka:
tags:
- fundamental
- core-object
---
Agen yang dijalankan pada setiap <i>node</i> di kluster dan bertugas memastikan kontainer dijalankan di dalam pod.