Referensi

• 1: Glosarium
• 2: Kubeadm
• 3: Mengakses API
• 3.1: Menggunakan Otorisasi RBAC
• 4: Baris Perintah kubectl
• 4.1: Contekan kubectl
• 5: Referensi Jaringan
• 5.1: Protokol untuk Service
• 5.2: Port dan Protokol

1 - Glosarium

2 - Kubeadm

Kubeadm adalah fitur yang dibuat untuk menyediakan kubeadm init dan kubeadm join sebagai praktik terbaik dengan "jalur cepat" untuk membuat klaster Kubernetes.

kubeadm melakukan tindakan yang diperlukan untuk membuat klaster minimum yang layak untuk aktif dan berjalan. Secara desain, ini hanya memperdulikan tentang bootstrap, bukan tentang mesin provisioning. Demikian pula, dengan instalasi berbagai addon atau tambahan yang bagus untuk dimiliki, seperti Dasbor Kubernetes, solusi pemantauan, dan tambahan khusus cloud, tidak termasuk dalam cakupan.

Sebaliknya, kita mengharapkan perangkat dengan tingkat yang lebih tinggi dan lebih disesuaikan untuk dibangun di atas kubeadm, dan idealnya, menggunakan kubeadm sebagai dasar dari semua penerapan untuk mempermudah pembuatan klaster yang sesuai.

Cara Instalasi

Untuk menginstal kubeadm, silakan lihat Petunjuk Instalasi.

Selanjutnya

• kubeadm init untuk melakukan bootstrap pada node control-plane Kubernetes
• kubeadm join untuk melakukan bootstrap worker node Kubernetes worker dan menggabungkannya ke dalam klaster
• kubeadm upgrade untuk melakukan pembaruan klaster Kubernetes ke versi yang lebih baru
• kubeadm config untuk mengonfigurasi klaster kamu untuk kubeadm upgrade, jika kamu menggunakan kubeadm v1.7.x atau dibawahnya untuk menginisialisasi klaster kamu
• kubeadm token untuk mengatur token-token untuk kubeadm join
• kubeadm reset untuk mengembalikan semua perubahan yang dibuat untuk host dengan kubeadm init atau kubeadm join
• kubeadm version untuk mencetak versi kubeadm
• kubeadm alpha untuk melihat sekilas sekumpulan fitur yang ada untuk mengumpulkan feedback atau umpan balik dari komunitas

3 - Mengakses API

3.1 - Menggunakan Otorisasi RBAC

Role-based access control (RBAC) atau kontrol akses berbasis rol adalah metode pengaturan akses ke sumber daya komputer atau jaringan berdasarkan rol pengguna individu dalam organisasimu.

Otorisasi RBAC menggunakan grup API rbac.authorization.k8s.io untuk mengendalikan keputusan otorisasi. Hal ini memungkinkanmu untuk mengonfigurasi kebijakan secara dinamis melalui API Kubernetes.

Untuk mengaktifkan RBAC, jalankan server API dengan flag --authorization-mode diatur dengan daftar yang dipisahkan koma yang menyertakan RBAC; sebagai contoh:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

Objek API

API RBAC mendeklarasikan empat jenis objek Kubernetes: Role, ClusterRole, RoleBinding dan ClusterRoleBinding. kamu bisa mendeskripsikan beberapa objek, atau mengubahnya menggunakan alat seperti kubectl, seperti objek Kubernetes lain.

Role dan ClusterRole

Sebuah Role RBAC atau ClusterRole memuat aturan yang mewakili sekumpulan izin. Izin bersifat aditif (tidak ada aturan "tolak").

Sebuah Role selalu mengatur izin dalam Namespace tertentu; ketika kamu membuat Role, kamu harus menentukan Namespace tempat Role tersebut berada.

ClusterRole, sebaliknya, adalah sumber daya tanpa Namespace. Sumber daya tersebut memiliki nama yang berbeda (Role dan ClusterRole) karena objek Kubernetes selalu harus menggunakan Namespace atau tanpa Namespace; tidak mungkin keduanya.

ClusterRole memiliki beberapa kegunaan. Kamu bisa menggunakan ClusterRole untuk:

1. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam sebuah Namespace atau lebih
2. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam seluruh Namespace
3. mendefinisikan izin pada sumber daya dalam lingkup klaster

Jika kamu ingin mendefinisikan sebuah rol dalam Namespace, gunakan Role; jika kamu ingin mendefinisikan rol di level klaster, gunakan ClusterRole.

Contoh Role

Berikut adalah contoh Role dalam Namespace bawaan yang dapat digunakan untuk memberikan akses baca pada Pod:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" mengindikasikan grup API inti
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Contoh ClusterRole

ClusterRole dapat digunakan untuk memberikan izin yang sama dengan Role. Karena ClusterRole memiliki lingkup klaster, kamu juga dapat menggunakannya untuk memberikan akses ke:

• sumber daya lingkup klaster (seperti Node)
• berbagai endpoint non-sumber daya (seperti /healthz)
• sumber daya Namespace (seperti Pod), di semua Namespace Sebagai contoh: kamu bisa menggunakan ClusterRole untuk memungkinkan pengguna tertentu untuk menjalankan kubectl get pods --all-namespaces.

Berikut adalah contoh ClusterRole yang dapat digunakan untuk memberikan akses baca pada Secret di Namespace tertentu, atau di semua Namespace (tergantung bagaimana keterikatannya):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" dihilangkan karena ClusterRole tidak menggunakan Namespace
  name: secret-reader
rules:
- apiGroups: [""]
  #
  # di tingkat HTTP, nama sumber daya untuk mengakses objek Secret
  # adalah "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Nama objek Role dan ClusterRole harus menggunakan nama path segment yang valid.

RoleBinding dan ClusterRoleBinding

Sebuah RoleBinding memberikan izin yang ditentukan dalam sebuah Role kepada pengguna atau sekelompok pengguna. Ini menyimpan daftar subjek (pengguna, grup, atau ServiceAccount), dan referensi ke Role yang diberikan. RoleBinding memberikan izin dalam Namespace tertentu sedangkan ClusterRoleBinding memberikan akses tersebut pada lingkup klaster.

RoleBinding dapat merujuk Role apa pun di Namespace yang sama. Atau, RoleBinding dapat mereferensikan ClusterRole dan memasangkan ClusterRole tersebut ke Namespace dari RoleBinding. Jika kamu ingin memasangkan ClusterRole ke semua Namespace di dalam klastermu, kamu dapat menggunakan ClusterRoleBinding.

Nama objek RoleBinding atau ClusterRoleBinding harus valid menggunakan nama path segment yang valid.

Contoh RoleBinding

Berikut adalah contoh dari RoleBinding yang memberikan Role "pod-reader" kepada pengguna "jane" pada Namespace "default". Ini memungkinkan "jane" untuk membaca Pod di Namespace "default".

apiVersion: rbac.authorization.k8s.io/v1
# RoleBinding memungkinkan "jane" untuk membaca Pod di Namespace "default"
# Kamu harus sudah memiliki Role bernama "pod-reader" di Namespace tersebut.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# Kamu bisa mencantumkan lebih dari satu "subjek"
- kind: User
  name: jane # "name" peka huruf besar-kecil
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" menentukan pengikatan (binding) ke Role / ClusterRole
  kind: Role # ini harus Role atau ClusterRole
  name: pod-reader # ini harus sesuai dengan nama Role atau ClusterRole yang ingin kamu gunakan
  apiGroup: rbac.authorization.k8s.io

RoleBinding juga bisa mereferensikan ClusterRole untuk memberikan izin yang didefinisikan di dalam ClusterRole ke sumber daya di dalam Namespace RoleBinding. Referensi semacam ini memungkinkan kamu menentukan sekumpulan Role yang umum di seluruh klastermu, lalu menggunakannya kembali di dalam beberapa Namespace.

Sebagai contoh, meskipun RoleBinding berikut merujuk ke ClusterRole, "dave" (subjek, peka kapital) hanya akan dapat membaca Secret di dalam Namespace "development", karena Namespace RoleBinding (di dalam metadatanya) adalah "development".

apiVersion: rbac.authorization.k8s.io/v1
# RoleBinding memungkinkan "dave" untuk membaca Secret di Namespace "development".
# Kamu sudah harus memiliki ClusterRole bernama "secret-reader".
kind: RoleBinding
metadata:
  name: read-secrets
  #
  # Namespace dari RoleBinding menentukan di mana izin akan diberikan.  
  # Ini hanya memberikan izin di dalam Namespace "development".
  namespace: development
subjects:
- kind: User
  name: dave # Nama peka huruf besar-kecil
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Contoh ClusterRoleBinding

Untuk memberikan izin di seluruh klaster, kamu dapat menggunakan ClusterRoleBinding. ClusterRoleBinding berikut memungkinkan seluruh pengguna di dalam kelompok "manager" untuk membaca Secret di berbagai Namespace.

apiVersion: rbac.authorization.k8s.io/v1
# ClusterRoleBinding ini memungkinkan siapapun di dalam kelompok "manager" untuk membaca Secret di berbagai Namespace.
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Nama peka kapital
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Setelah kamu membuat ClusterRoleBinding, kamu tidak dapat mengganti Role atau ClusterRole yang dirujuk. Jika kamu mencoba mengganti roleRef dari sebuah ClusterRoleBinding, kamu akan mendapatkan galat validasi. Jika kamu tidak ingin mengganti roleRef untuk sebuah ClusterRoleBinding, kamu harus menghapus objek ClusterRoleBinding tersebut dan membuat sebuah pengganti.

Ada dua alasan untuk pembatasan tersebut:

1. Membuat roleRef menjadi tidak dapat diubah (immutable) memungkinkan pemberian izin update kepada seseorang pada objek ClusterRoleBinding yang ada, sehingga mereka dapat mengelola daftar subjek, tanpa bisa berubah Role yang diberikan kepada subjek tersebut.

2. ClusterRoleBinding dengan Role yang berbeda adalah ClusterRoleBinding yang berbeda secara fundamental. Mengharuskan sebuah ClusterRoleBinding untuk dihapus/diciptakan kembali untuk mengubah roleRef akan memastikan daftar lengkap subjek dalam ClusterRoleBinding akan diberikan Role baru (sebagai langkah untuk mencegah modifikasi secara tidak sengaja hanya pada roleRef tanpa memastikan semua subjek yang seharusnya diberikan izin pada Role baru).

Utilitas baris perintah kubectl auth reconcile membuat atau memperbarui berkas manifes yang mengandung objek RBAC, dan menangani penghapusan dan pembuatan objek ikatan jika dibutuhkan untuk mengganti Role yang dirujuk. Lihat penggunaan perintah dan contoh untuk informasi tambahan.

Mengacu pada sumber daya

Pada API Kubernetes, sebagian besar sumber daya diwakili dan diakses menggunakan representasi nama objek, seperti pods untuk Pod. RBAC mengacu pada sumber daya yang menggunakan nama yang persis sama dengan yang muncul di URL untuk berbagai endpoint API yang relevan. Beberapa Kubernetes APIs melibatkan subresource, seperti log untuk Pod. Permintaan untuk log Pod terlihat seperti:

GET /api/v1/namespaces/{namespace}/pods/{name}/log

Dalam hal ini, pods adalah sumber daya Namespace untuk sumber daya Pod, dan log adalah sebuah sub-sumber daya pods. Untuk mewakili ini dalam sebuah Role RBAC, gunakan garis miring (/) untuk membatasi sumber daya dan sub-sumber daya. Untuk memungkinkan subjek membaca pods dan juga mengakses sub-sumber daya log untuk masing-masing Pod tersebut, kamu dapat menulis:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

Kamu juga dapat merujuk ke sumber daya dengan nama untuk permintaan tertentu melalui daftar resourceNames. Ketika nama dicantumkan, permintaan dapat dibatasi untuk setiap objek sumber daya. Berikut adalah contoh yang membatasi subjeknya hanya untuk melakukan get atau update pada sebuah ConfigMap bernama my-configmap:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  #
  # pada level HTTP, nama sumber daya untuk mengakses objek ConfigMap
  # adalah "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

ClusterRole gabungan

Kamu dapat mengumpulkan beberapa ClusterRole menjadi satu ClusterRole gabungan. Pengontrol, yang berjalan sebagai bagian dari control plane klaster, mengamati objek ClusterRole dengan aggregationRule. AggregationRule mendefinisikan Selector label yang digunakan oleh pengontrol untuk mencocokkan objek ClusterRole lain yang harus digabungkan ke dalam rules.

Berikut adalah contoh ClusterRole gabungan:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # Control plane secara otomatis mengisi rules

Jika kamu membuat ClusterRole baru yang cocok dengan label Selector dari ClusterRole gabungan yang ada, maka perubahan itu akan memicu penambahan aturan baru ke dalam ClusterRole gabungan. Berikut adalah contoh yang menambahkan aturan ke ClusterRole "monitoring", dengan membuat sebuah ClusterRole lain berlabel rbac.example.com/aggregate-to-monitoring: true.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-endpoints
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
# ketika kamu membuat ClusterRole "monitoring-endpoints",
# aturan di bawah ini akan ditambahkan ke ClusterRole "monitoring".
rules:
- apiGroups: [""]
  resources: ["services", "endpoints", "pods"]
  verbs: ["get", "list", "watch"]

Role bawaan pengguna menggunakan agregasi ClusterRole. Ini memungkinkan kamu, sebagai administrator klaster, menambahkan aturan untuk sumber daya ubah suai, seperti yang dilayani oleh CustomResourceDefinitions atau server API gabungan, untuk memperluas Role bawaan.

Sebagai contoh: ClusterRole berikut mengizinkan Role bawaan "admin" dan "edit" mengelola sumber daya ubah suai bernama CronTab, sedangkan Role "view" hanya dapat membaca sumber daya CronTab. Kamu dapat mengasumsikan bahwa objek CronTab dinamai "crontab" dalam URL yang terlihat oleh server API.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aggregate-cron-tabs-edit
  labels:
    # Tambahkan izin berikut ke Role bawaan "admin" and "edit".
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: aggregate-cron-tabs-view
  labels:
    # Tambahkan izin berikut ke Role bawaan "view"    
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch"]

Contoh Role

Contoh berikut adalah potongan dari objek Role atau ClusterRole yang hanya menampilkan bagian rules.

Mengizinkan pembacaan sumber daya "pods" pada grup API inti:

rules:
- apiGroups: [""]
  #
  # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Pod
  # adalah "pods"
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Mengizinkan pembacaan/penulisan Deployment (pada tingkat HTTP: objek dengan "deployments" di bagian sumber daya dari URL) pada masing-masing grup API "extensions" dan "apps":

rules:
- apiGroups: ["extensions", "apps"]
  #
  # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Deployment
  # adalah "deployments"
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Mengizinkan pembacaan pada Pods pada grup API inti, dan juga serta pembacaan atau penulisan Job di grup API "batch" atau "extensions":

rules:
- apiGroups: [""]
  #
  # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Pod
  # adalah "pods"
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch", "extensions"]
  #
  # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Job
  # adalah "jobs"
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Mengizinkan pembacaan ConfigMap bernama "my-config" (harus terikat dengan suatu RoleBinding untuk membatasi ke satu ConfigMap di satu Namespace):

rules:
- apiGroups: [""]
  #
  # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek ConfigMap
  # adalah "configmaps"  
  resources: ["configmaps"]
  resourceNames: ["my-config"]
  verbs: ["get"]

Mengizinkan pembacaan sumber daya "nodes" pada grup API inti (karena sebuah node ada pada lingkup-klaster, ini harus berupa ClusterRole yang terikat dengan ClusterRoleBinding agar efektif):

rules:
- apiGroups: [""]
  #
  # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Node
  # adalah "nodes"
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

Mengizinkan permintaan GET dan POST kepada endpoint non-sumber daya /healthz dan seluruh subpath (harus berada di dalam ClusterRole yang terikat dengan ClusterRoleBinding agar efektif):

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' in a nonResourceURL is a suffix glob match
  verbs: ["get", "post"]

Mengacu pada subjek

RoleBinding atau ClusterRoleBinding mengikat sebuah Role ke subjek. Subjek dapat berupa kelompok, pengguna atau ServiceAccounts.

Kubernetes merepresentasikan username sebagai string. Ini bisa berupa: nama sederhana, seperti "alice"; email, seperti "bob@example.com"; atau ID pengguna numerik yang direpresentasikan sebagai string. Terserah kamu sebagai administrator klaster untuk mengonfigurasi modul otentikasi sehingga otentikasi menghasilkan username dalam format yang kamu inginkan.

Di Kubernetes, modul otentikasi menyediakan informasi grup. Grup, seperti halnya pengguna, direpresentasikan sebagai string, dan string tersebut tidak memiliki format tertentu, selain prefiks system: yang sudah direservasi.

ServiceAccount memiliki nama yang diawali dengan system:serviceaccount:, dan menjadi milik grup yang diawali dengan nama system:serviceaccounts:.

Contoh RoleBinding

Contoh-contoh berikut ini hanya potongan RoleBinding yang hanya memperlihatkan bagian subjects.

Untuk pengguna bernama alice@example.com:

subjects:
- kind: User
  name: "alice@example.com"
  apiGroup: rbac.authorization.k8s.io

Untuk grup bernama frontend-admins:

subjects:
- kind: Group
  name: "frontend-admins"
  apiGroup: rbac.authorization.k8s.io

Untuk ServiceAccount bawaan di Namespace "kube-system":

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

Untuk seluruh ServiceAccount di Namespace qa:

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroup: rbac.authorization.k8s.io

Untuk seluruh ServiceAccount di Namespace apapun:

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

Untuk seluruh pengguna yang terotentikasi:

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

Untuk seluruh pengguna yang tidak terotentikasi:

subjects:
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

Untuk seluruh pengguna:

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

Role dan RoleBinding bawaan

API membuat satu set objek ClusterRole dan ClusterRoleBinding bawaan. Sebagian besar dari objek dengan prefiks system: menunjukkan bahwa sumber daya tersebut secara langsung dikelola oleh control plane klaster. Seluruh ClusterRole dan ClusterRoleBinding dilabeli dengan kubernetes.io/bootstrapping=rbac-defaults.

Rekonsiliasi otomatis

Pada setiap penyalaan (start-up), server API memperbarui ClusterRole bawaan dengan berbagai izin yang hilang, dan memperbarui ClusterRoleBinding bawaan dengan subjek yang hilang. Ini memungkinkan klaster untuk memperbaiki modifikasi yang tidak disengaja, dan membantu menjaga Role dan RoleBinding selalu terkini karena izin dan subjek berubah pada rilis terbaru Kubernetes.

Untuk menonaktifkan rekonsiliasi ini, atur anotasi rbac.authorization.kubernetes.io/autoupdate pada ClusterRole bawaan atau RoleBinding bawaan menjadi false. Ingat bahwa hilangnya izin dan subjek bawaan dapat mengakibatkan malfungsi klaster.

Rekonsiliasi otomatis diaktifkan secara bawaan jika pemberi otorisasi RBAC aktif.

Role diskoveri API

RoleBinding bawaan memberi otorisasi kepada pengguna yang tidak terotentikasi untuk membaca informasi API yang dianggap aman untuk diakses publik (termasuk CustomResourceDefinitions). Untuk menonaktifkan akses anonim, tambahkan --anonymous-auth=false ke konfigurasi server API.

Untuk melihat konfigurasi Role ini melalui kubectl jalankan perintah:

kubectl get clusterroles system:discovery -o yaml

Role pengguna

Beberapa ClusterRole bawaan tidak diawali dengan system:. Ini dimaksudkan untuk Role pengguna. Ini termasuk Role super-user (cluster-admin), Role yang dimaksudkan untuk diberikan akses seluruh klaster dengan menggunakan ClusterRoleBinding, dan Role yang dimaksudkan untuk diberikan pada Namespace tertentu dengan menggunakan RoleBinding (admin, edit, view).

ClusterRole menggunakan ClusterRole gabungan untuk mengizinkan administrator untuk memasukan peraturan untuk sumber daya khusus pada ClusterRole ini. Untuk menambahkan aturan kepada Role admin, edit, atau view, buatlah sebuah CLusterRole dengan satu atau lebih label berikut:

metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"

Role komponen inti

Role komponen lainnya

Role untuk pengontrol bawaan

kube-controller-manager pada Kubernetes menjalankan pengontrol yang merupakan bawaan dari control plane Kubernetes. Ketika dijalankan dengan --use-service-account-credentials, kube-controller-manager memulai setiap pengontrol menggunakan ServiceAccount yang terpisah. Role yang sesuai tersedia untuk setiap pengontrol bawaan, dengan prefiks system:controller:. Jika manajer pengontrol tidak dimulai dengan --use-service-account-credentials, maka manajer pengontrol akan menjalankan semua kontrol tertutup (control loop) menggunakan kredensialnya sendiri, yang harus diberikan semua Role yang relevan. Role yang dimaksud termasuk:

• system:controller:attachdetach-controller
• system:controller:certificate-controller
• system:controller:clusterrole-aggregation-controller
• system:controller:cronjob-controller
• system:controller:daemon-set-controller
• system:controller:deployment-controller
• system:controller:disruption-controller
• system:controller:endpoint-controller
• system:controller:expand-controller
• system:controller:generic-garbage-collector
• system:controller:horizontal-pod-autoscaler
• system:controller:job-controller
• system:controller:namespace-controller
• system:controller:node-controller
• system:controller:persistent-volume-binder
• system:controller:pod-garbage-collector
• system:controller:pv-protection-controller
• system:controller:pvc-protection-controller
• system:controller:replicaset-controller
• system:controller:replication-controller
• system:controller:resourcequota-controller
• system:controller:root-ca-cert-publisher
• system:controller:route-controller
• system:controller:service-account-controller
• system:controller:service-controller
• system:controller:statefulset-controller
• system:controller:ttl-controller

Pencegahan eskalasi privilese dan bootstrapping

API RBAC mencegah pengguna dari mengeskalasikan privilese dengan mengubah Role atau RoleBinding. Karena hal ini diberlakukan pada level API, maka hal ini berlaku bahkan ketika pemberi otorisasi RBAC tidak digunakan.

Pembatasan pada pembuatan dan pembaruan Role

Kamu hanya bisa membuat/memperbaru suatu Role jika setidaknya satu dari beberapa hal di bawah ini terpenuhi:

1. Kamu telah mempunyai semua izin yang termuat dalam Role tersebut, pada lingkup yang sama dengan objek yang diubah (di seluruh klaster untuk sebuah ClusterRole, di dalam Namespace yang sama atau keseluruhan klaster untuk sebuah Role).
2. Kamu diberikan izin eksplisit untuk melakukan escalate pada sumber daya roles atau clusterroles di dalam grup API rbac.authorization.k8s.io.

Sebagai contoh, jika user-1 tidak memiliki kemampuan untuk mendaftar Secret di seluruh klaster, maka user-1 tidak akan bisa membuat suatu ClusterRole yang memuat izin tersebut. Agar pengguna bisa membuat/memperbaru Role:

1. Berikan sebuah Role yang memungkinkan mereka untuk membuat/memperbarui objek Role atau CLusterRole, sesuai keinginan.
2. Berikan mereka izin untuk menyertakan izin tertentu dalam Role yang mereka buat/perbarui:
   • secara implisit, dengan memberikan mereka izin tersebut (jika mereka mencoba untuk membuat atau mengubah sebuah Role atau ClusterRole dengan izin yang tidak mereka miliki, permintaan API akan dilarang)
   • atau secara eksplisit mengizinkan penentuan izin apa pun dalam sebuah Role atau ClusterRole dengan memberikan mereka izin untuk melakukan escalate pada sumber daya roles atau clusterroles di dalam grup API rbac.authorization.k8s.io

Pembatasan pada pembuatan dan pembaruan RoleBinding

Kamu hanya bisa membuat/memperbarui suatu RoleBinding jika kamu telah mempunyai semua izin yang terdapat pada Role yang diacu (di dalam lingkup yang sama dengan RoleBinding) atau jika kamu telah terotorisasi untuk melakukan bind pada role yang diacu. Sebagai contoh, jika user-1 tidak mempunyai kemampuan untuk mendaftar Secret di seluruh klaster, maka user-1 tidak akan bisa membuat sebuah ClusterRoleBinding dengan Role yang memberikan izin tersebut. Agar pengguna bisa membuat/memperbarui RoleBinding:

1. Berikan sebuah Role yang mengizinkan mereka untuk membuat/memperbarui objek RoleBinding atau ClusterRoleBinding, sesuai keinginan.
2. Berikan mereka izin yang dibutuhkan untuk RoleBinding tertentu:
   • secara implisit, dengan memberikan mereka izin yang yang termuat pada Role yang dimaksud
   • secara eksplisit, dengan memberikan mereka izin untuk melakukan bind pada Role (atau ClusterRole) tertentu

Sebagai contoh, ClusterRole dan RoleBinding berikut akan memungkinkan user-1 untuk memberikan Role admin, edit, dan view kepada pengguna lain di dalam Namespace user-1-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: role-grantor
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings"]
  verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["bind"]
  resourceNames: ["admin","edit","view"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: role-grantor-binding
  namespace: user-1-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: role-grantor
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: user-1

Ketika melakukan bootstrapping Role dan RoleBinding yang pertama, pengguna awal perlu memberikan izin yang belum mereka miliki. Untuk melakukan bootstrapping Role dan RoleBinding awal:

• Gunakan kredensial dengan grup "system:masters" yang terikat ke Role super-user "cluster-admin" oleh RoleBinding bawaan.
• Jika server API dijalankan dengan porta tidak aman diaktifkan (--insecure-port), kamu juga bisa membuat panggilan API via porta tersebut, yang tidak memberlakukan otentikasi atau otorisasi.

Utilitas baris perintah

kubectl create role

Membuat sebuah objek Role yang mendefinisikan izin di dalam sebuah Namespace. Contoh:

• Membuat sebuah Role bernama "pod-reader" yang memungkinkan pengguna untuk melakukan get, watch dan list pada Pod:

  kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
  

• Membuat sebuah Role bernama "pod-reader" dengan resourceNames yang ditentukan:

  kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
  

• Membuat sebuah Role bernama "foo" dengan apiGroups yang ditentukan:

  kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
  

• Membuat sebuah Role bernama "foo" dengan izin sub-sumber daya:

  kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
  

• Membuat sebuah Role bernama "my-component-lease-holder" dengan izin untuk mendapatkan/memperbarui suatu sumber daya dengan nama tertentu:

  kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
  

kubectl create clusterrole

Membuat sebuah ClusterRole. Contoh:

• Membuat sebuah ClusterRole bernama "pod-reader" yang memungkinkan pengguna untuk merlakukan get, watch dan list pada Pod:

  kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
  

• Membuat sebuah ClusterRole bernama "pod-reader" dengan recourceNames yang ditentukan:

  kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
  

• Membuat sebuah ClusterRole bernama "foo" dengan apiGroups yang ditentukan:

  kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
  

• Membuat sebuah ClusterRole bernama "foo" dengan izin sub-sumber daya:

  kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
  

• Membuat sebuah ClusterRole bernama "foo" dengan nonResourceURL yang ditentukan:

  kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
  

• Membuat sebuah ClusterRole bernama "monitoring" dengan aggregationRule yang ditentukan:

  kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
  

kubectl create rolebinding

Memberikan sebuah Role atau ClusterRole di dalam Namespace tertentu. Contoh:

• Di dalam Namespace "acme", memberikan izin dalam ClusterRole "admin" kepada pengguna bernama "bob":

  kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
  

• Di dalam Namespace "acme", memberikan izin dalam ClusterRole "view" ke ServiceAccount di dalam Namespace "acme" yang bernama "myapp":

  kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
  

• Di dalam Namespace "acme", memberikan izin dalam ClusterRole "view" ke ServiceAccount di dalam Namespace "myappnamespace" yang bernama "myapp":

  kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
  

kubectl create clusterrolebinding

Memberikan sebuah ClusterRole di seluruh klaster (semua Namespace). Contoh:

• Di seluruh klaster, memberikan izin dalam ClusterRole "cluster-admin" kepada pengguna bernama "root":

  kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
  

• Di seluruh klaster, memberikan izin dalam ClusterRole "system:node-proxier" kepada user bernama "system:kube-proxy":

  kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
  

• Di seluruh klaster, memberikan izin dalam ClusterRole "view" ke ServiceAccount bernama "myapp" di dalam Namespace "acme":

  kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
  

kubectl auth reconcile

Membuat atau memperbarui objek API rbac.authorization.k8s.io/v1 dari suatu berkas manifes.

Objek yang hilang dibuat, dan Namespace dibuat untuk objek dengan Namespace jika diperlukan.

Role yang sudah ada diperbarui untuk menyertakan izin pada objek masukan, dan menghilangkan izin tambahan jika --remove-extra-permissions ditetapkan.

RoleBinding yang sudah ada diperbarui untuk menyertakan subjek pada objek masukan, dan menghapus subjek tambahan jika --remove-extra-subjects ditetapkan.

Contoh:

• Mencoba menerapkan sebuah berkas manifes dari objek RBAC, menampilkan perubahan yang akan dibuat:

  kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client
  

• Menerapkan sebuah berkas manifes dari objek RBAC, mempertahankan izin tambahan (dalam Role) dan subjek tambahan (dalam RoleBinding):

  kubectl auth reconcile -f my-rbac-rules.yaml
  

• Menerapkan sebuah berkas manifes dari objek RBAC, menghapus izin tambahan (dalam Role) dan subjek tambahan (dalam RoleBinding):

  kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions
  

Izin ServiceAccount

Kebijakan RBAC bawaan memberikan izin terbatas ke komponen control plane, Node, dan pengontrol, akan tetapi tidak memberikan izin ke ServiceAccount di luar Namespace kube-system (di luar izin diskoveri yang diberikan kepada semua pengguna terotentikasi).

Hal ini memungkinkan kamu untuk memberika Role tertentu ke ServiceAccount tertentu sesuai kebutuhan. RoleBinding yang sangat detail memberikan keamanan yang lebih baik, akan tetapi membutuhkan lebih banyak usaha untuk pengaturannya. Pemberian izin yang lebih luas dapat memberikan akses API yang tidak perlu (dan berpotensi tereskalasi) ke ServiceAccount, akan tetapi pengaturannya lebih mudah.

Dalam urutan dari yang paling aman ke yang paling tidak aman, pendekatannya adalah:

1. Memberikan sebuah Role ke ServiceAccount aplikasi tertentu (praktik terbaik)

   Hal ini membutuhkan aplikasi untuk menentukan sebuah serviceAccountName di dalam spesifikasi Pod-nya, dan untuk ServiceAccount yang akan dibuat (via API, manifes aplikasi, kubectl create serviceaccount, dan lain-lain).

   Sebagai contoh, untuk memberikan izin hanya baca (read-only) di dalam "my-namespace" ke ServiceAccount "my-sa":

   kubectl create rolebinding my-sa-view \
     --clusterrole=view \
     --serviceaccount=my-namespace:my-sa \
     --namespace=my-namespace
   

2. Memberikan sebuah Role ke ServiceAccount "default" di dalam suatu Namespace

   Jika sebuah aplikasi tidak menetapkan serviceAccountName, aplikasi tersebut akan menggunakan ServiceAccount "default".

   Catatan:

   Izin yang diberikan ke ServiceAccount "default" tersedia ke Pod apa pun di dalam
   Namespace yang tidak menetapkan `serviceAccountName`.
   

   Sebagai contoh, untuk memberikan izin hanya baca di dalam "my-namespace" ke ServiceAccount "default":

   kubectl create rolebinding default-view \
     --clusterrole=view \
     --serviceaccount=my-namespace:default \
     --namespace=my-namespace
   

   Banyak pugasan berjalan sebagai ServiceAccount "default" di dalam Namespace kube-system. Untuk mengizinkan pugasan tersebut berjalan dengan akses super-user, berikan izin cluster-admin kepada ServiceAccount "default" di dalam Namespace kube-system.

   Perhatian:

   Mengaktifkan ini berarti Namespace `kube-system` memuat Secret yang
   memberikan akses _super-user_ ke API klastermu.
   

   kubectl create clusterrolebinding add-on-cluster-admin \
     --clusterrole=cluster-admin \
     --serviceaccount=kube-system:default
   

3. Memberikan Role ke semua ServiceAccount dalam suatu Namespace

   Jika kamu ingin semua aplikasi di dalam satu Namespace untuk memiliki Role, apa pun ServiceAccount yang digunakan, maka kamu dapat memberikan Role ke grup ServiceAccount untuk Namespace tersebut.

   Sebagai contoh, untuk memberikan izin hanya baca di dalam "my-namespace" ke semua ServiceAccount di dalam Namespace tersebut:

   kubectl create rolebinding serviceaccounts-view \
     --clusterrole=view \
     --group=system:serviceaccounts:my-namespace \
     --namespace=my-namespace
   

4. Memberikan Role terbatas ke semua ServiceAccount di seluruh klaster (tidak disarankan)

   Jika kamu tidak ingin untuk mengelola izin per Namespace, kamu bisa memberikan Role yang berlaku di seluruh klaster kepada semua ServiceAccount.

   Sebagai contoh, untuk memberikan akses hanya baca di semua Namespace untuk semua ServiceAccount yang ada di klaster:

   kubectl create clusterrolebinding serviceaccounts-view \
     --clusterrole=view \
    --group=system:serviceaccounts
   

5. Memberikan akses super-user ke semua ServiceAccount di seluruh klaster (sangat tidak disarankan)

   Jika kamu tidak peduli untuk melakukan partisi terhadap izin sama sekali, maka kamu bisa memberikan akses super-user ke semua ServiceAccount.

   Peringatan:

   Hal ini akan memberikan akses penuh untuk aplikasi apapun ke klastermu, dan juga
   memberikan pengguna manapun dengan akses baca ke Secret (atau kemampuan untuk membuat
   Pod apa pun) akses penuh ke klastermu.
   

   kubectl create clusterrolebinding serviceaccounts-cluster-admin \
     --clusterrole=cluster-admin \
     --group=system:serviceaccounts
   

Melakukan peningkatan dari ABAC

Klaster yang awalnya menjalankan versi Kubernetes lawas sering kali menggunakan kebijakan ABAC yang permisif, termasuk memberikan akses API penuh ke semua ServiceAccount.

Kebijakan RBAC bawaan memberikan izin yang terbatas ke komponen control plane, Node, dan pengontrol, akan tetapi tidak memberikan izin ke ServiceAccount di luar Namespace kube-system (di luar izin diskoveri yang diberikan kepada semua pengguna terotentikasi).

Meskipun jauh lebih aman, hal ini dapat mengganggu beban kerja yang sudah ada yang mengharapkan untuk menerima izin API secara otomatis. Berikut adalah dua pendekatan untuk mengelola transisi ini:

Pemberi otorisasi paralel

Jalankan pemberi otorisasi RBAC dan ABAC bersamaan, dan tentukan berkas kebijakan yang memuat kebijakan ABAC lama:

--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json

Untuk menjelaskan opsi baris perintah yang pertama secara detail: jika pemberi otorisasi sebelumnya, seperti Node, menolak permintaan, maka pemberi otorisasi RBAC mencoba untuk mengotorisasi permintaan API tersebut. Jika RBAC juga menolak permintaan API tersebut, maka pemberi otorisasi ABAC akan dijalankan. Hal ini berarti permintaan apa pun yang diizinkan oleh salah satu kebijakan RBAC atau ABAC akan diizinkan.

Ketika kube-apiserver dijalankan dengan level log 5 atau lebih tinggi untuk komponen RBAC (--vmodule=rbac*=5 atau --v=5), kamu dapat melihat penolakan RBAC di log server API (dengan prefiks RBAC). Kamu dapat menggunakan informasi tersebut untuk menentukan Role mana yang perlu diberikan ke pengguna, grup, atau ServiceAccount yang mana.

Jika kamu telah memberikan Role ke ServiceAccount dan beban kerja sedang berjalan tanpa pesan penolakan RBAC dalam log server, maka kamu dapat menghapus pemberi otorisasi ABAC.

Izin RBAC permisif

Kamu dapat mereplikasi kebijakan ABAC yang permisif dengan menggunakan RoleBinding RBAC.

kubectl create clusterrolebinding permissive-binding \
  --clusterrole=cluster-admin \
  --user=admin \
  --user=kubelet \
  --group=system:serviceaccounts

Setelah kamu beralih menggunakan RBAC, kamu harus menyesuaikan kontrol akses untuk klastermu untuk memastikan bahwa kesemuanya memenuhi kebutuhanmu terkait keamanan informasi.

4 - Baris Perintah kubectl

4.1 - Contekan kubectl

Lihat juga: Ikhitsar Kubectl dan Panduan JsonPath.

Laman ini merupakan ikhitisar dari perintah kubectl.

kubectl - Contekan

Autocomplete Kubectl

BASH

source <(kubectl completion bash) # menyiapkan autocomplete untuk bash ke dalam shell saat ini, paket bash-completion harus diinstal terlebih dahulu.
echo "source <(kubectl completion bash)" >> ~/.bashrc # menambahkan autocomplete secara permanen ke dalam bash shell kamu.

Kamu juga dapat menggunakan alias singkatan untuk kubectl yang juga bisa berfungsi dengan completion:

alias k=kubectl
complete -F __start_kubectl k

ZSH

source <(kubectl completion zsh)  # menyiapkan autocomplete untuk zsh ke dalam shell saat ini.
echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # menambahkan autocomplete secara permanen ke dalam zsh shell kamu.

Konteks Kubectl dan Konfigurasinya

Memilih klaster Kubernetes yang mana yang ditembak oleh kubectl untuk berkomunikasi dan diubah konfigurasinya. Lihat dokumentasi Otentikasi ke berbagai Klaster dengan kubeconfig untuk mengetahui informasi tentang berkas konfigurasi ini secara detail.

kubectl config view # memperlihatkan setelan kubeconfig yang sudah digabung (merged)

# menggunakan beberapa berkas kubeconfig sekaligus dan melihat semua konfigurasinya sekaligus (merged)
KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 

kubectl config view

# mendapatkan kata sandi untuk pengguna e2e
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

kubectl config view -o jsonpath='{.users[].name}'    # memperlihatkan pengguna pertama
kubectl config view -o jsonpath='{.users[*].name}'   # mendapatkan daftar pengguna
kubectl config get-contexts                          # memperlihatkan daftar konteks
kubectl config current-context                       # memperlihatkan konteks saat ini
kubectl config use-context my-cluster-name           # menyetel konteks bawaan menjadi my-cluster-name

# menambahkan seorang pengguna baru ke dalam kubeconf kamu yang mendukung basic auth
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword

# menyimpan Namespace secara permanen untuk semua perintah kubectl pada konteks tersebut
kubectl config set-context --current --namespace=ggckad-s2

# menyetel konteks yang menggunakan pengguna dan namespace yang spesifik
kubectl config set-context gce --user=cluster-admin --namespace=foo \
  && kubectl config use-context gce
 
kubectl config unset users.foo                       # menghapus pengguna foo

Menerapkan

apply (menerapkan) mengelola aplikasi melalui berkas-berkas yang berisi definisi tentang sumber daya Kubernetes. Perintah ini membuat dan memperbarui sumber daya di dalam sebuah klaster dengan menjalankan kubectl apply. Ini merupakan cara yang disarankan untuk mengelola aplikasi di dalam production. Lihat Buku Kubectl.

Membuat Objek

Manifes Kubernetes dapat didefinisikan ke dalam YAML atau JSON. Gunakan berkas dengan ekstensi .yaml, .yml, dan .json.

kubectl apply -f ./my-manifest.yaml            # membuat sumber daya
kubectl apply -f ./my1.yaml -f ./my2.yaml      # membuat sumber daya dari beberapa berkas
kubectl apply -f ./dir                         # membuat sumber daya dari berbagai berkas manifes yang ada di dalam direktori
kubectl apply -f https://git.io/vPieo          # membuat sumber daya dari sebuah tautan
kubectl create deployment nginx --image=nginx  # memulai sebuah instans tunggal nginx
kubectl explain pods                           # mendapatkan dokumentasi untuk manifes Pod

# membuat beberapa objek YAML dari masukan (stdin)
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep-less
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000"
EOF

# membuat sebuah Secret dengan beberapa kunci (key)
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: $(echo -n "s33msi4" | base64 -w0)
  username: $(echo -n "jane" | base64 -w0)
EOF

Melihat, Mencari Sumber Daya

# mendapatkan berbagai perintah dengan keluaran dasar
kubectl get services                          # mendapatkan semua Service di dalam Namespace saat ini
kubectl get pods --all-namespaces             # mendapatkan semua Pod di dalam semua Namespace
kubectl get pods -o wide                      # mendapatkan semua Pod di dalam Namespace saat ini, dengan informasi tambahan
kubectl get deployment my-dep                 # mendapatkan Deployment tertentu
kubectl get pods                              # mendapatkan semua Pod di dalam Namespace saat ini
kubectl get pod my-pod -o yaml                # mendapatkan spesifikasi YAML dari Pod tertentu

# menggambarkan berbagai perintah dengan keluaran yang lengkap (verbose)
kubectl describe nodes my-node
kubectl describe pods my-pod

# mendapatkan semua Service yang diurutkan berdasar nama
kubectl get services --sort-by=.metadata.name

# mendapatkan semua Pod yang diurut berdasarkan jumlah restart
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

# mendapatkan PersistentVolume yang diurut berdasarkan kapasitas
kubectl get pv --sort-by=.spec.capacity.storage

# mendapatkan label versi dari semua Pod dengan label app=cassandra
kubectl get pods --selector=app=cassandra -o \
  jsonpath='{.items[*].metadata.labels.version}'

# mendapatkan semua Node pekerja (worker) (selektor digunakan untuk tidak memasukkan
# Node yang memiliki label 'node-role.kubernetes.io/master' ke dalam keluaran)
kubectl get node --selector='!node-role.kubernetes.io/master'

# mendapatkan semua Pod yang sedang berjalan di dalam Namespace saat ini
kubectl get pods --field-selector=status.phase=Running

# mendapatkan ExternalIP dari semua Node
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'

# mendapatkan nama dari semua Pod yang termasuk ke dalam RC tertentu
# perintah "jq" berguna untuk mentransformasi keluaran yang terlalu rumit untuk diproses oleh jsonpath, lihat https://stedolan.github.io/jq/
sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})

# memperlihatkan label yang dimiliki semua Pod (atau objek Kubernetes lainnya yang mendukung label)
kubectl get pods --show-labels

# memeriksa Node mana yang sudah dalam kondisi siap (ready)
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
 && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"

# mendapatkan semua Secret yang sedang digunakan oleh Pod
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq

# mendapatkan semua containerID dari initContainer yang ada di semua Pod,
# berguna untuk membersihkan kontainer yang telah berhenti, tetapi menghindari terhapusnya initContainer
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3

# mendapatkan Event yang diurut berdasarkan cap waktu (timestamp)
kubectl get events --sort-by=.metadata.creationTimestamp

# membandingkan antara keadaan saat ini dengan keadaan yang diinginkan pada klaster, jika manifes diterpakan
kubectl diff -f ./my-manifest.yaml

Memperbarui Sumber Daya

kubectl set image deployment/frontend www=image:v2               # memperbarui kontainer "www" secara bergilir dari sebuah Deployment "frontend", memperbarui image-nya
kubectl rollout history deployment/frontend                      # memeriksa sejarah (history) Deployment, termasuk revisinya
kubectl rollout undo deployment/frontend                         # mengembalikan (rollback) ke Deployment sebelumnya
kubectl rollout undo deployment/frontend --to-revision=2         # mengembalikan (rollback) ke revisi tertentu
kubectl rollout status -w deployment/frontend                    # melakukan watch terhadap status pembaruan bergilir dari Deployment "frontend" sampai selesai
kubectl rollout restart deployment/frontend                      # melakukan restart secara bergilir untuk Deployment "frontend"


cat pod.json | kubectl replace -f -                              # menggantikan sebuah Pod berdasarkan JSON yang dilewatkan melalui std

# menggantikan, menghapus, dan membuat ulang sumber daya secara paksa, dapat menyebabkan gagalnya layanan
kubectl replace --force -f ./pod.json

# membuat sebuah Service untuk nginx yang terreplikasi, melayani pada porta 80 dan menghubungkan kontainer pada porta 8000
kubectl expose rc nginx --port=80 --target-port=8000

# memperbarui versi image (tag) yang dimiliki kontainer Pod menjadi versi v4
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -

kubectl label pods my-pod new-label=awesome                      # menambahkan sebuah label
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq       # menambahkan sebuah anotasi
kubectl autoscale deployment foo --min=2 --max=10                # menskalakan sebuah Deployment "foo" secara otomatis

Menambal (Patch) Sumber Daya

# memperbarui sebuah Node secara parsial
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'

# memperbarui image dari kontainer; spec.containers[*].name diperlukan karena menggunakan kunci merge
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'

# memperbarui image dari kontainer menggunakan patch json dengan array posisi
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'

# menonaktifkan sebuah Deployment livenessProbe menggunakan patch json dengan array posisi
kubectl patch deployment valid-deployment  --type json   -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'

# menambahkan elemen baru ke dalam array posisi
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'

Menyunting Sumber Daya

Menyunting sumber daya API menggunakan penyunting (editor) yang biasa kamu gunakan.

kubectl edit svc/docker-registry                      # menyunting Service yang bernama docker-registry
KUBE_EDITOR="nano" kubectl edit svc/docker-registry   # menggunakan penyunting alternatif

Menskalakan Sumber Daya

kubectl scale --replicas=3 rs/foo                                 # menskalakan ReplicaSet bernama 'foo' menjadi 3
kubectl scale --replicas=3 -f foo.yaml                            # menskalakan sebuah sumber daya yang dispesifikasikan di dalam "foo.yaml" menjadi 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql  # jika Deployment bernama mysql saat ini memiliki ukuran 2, skalakan mysql menjadi 3
kubectl scale --replicas=5 rc/foo rc/bar rc/baz                   # menskalakan beberapa ReplicationController sekaligus

Menghapus Sumber Daya

kubectl delete -f ./pod.json                                              # menghapus Pod menggunakan tipe dan nama yang dispesifikan di dalam pod.json
kubectl delete pod,service baz foo                                        # menghapus Pod dan Service dengan nama yang sama, yaitu "baz" dan "foo"
kubectl delete pods,services -l name=myLabel                              # menghapus semua Pod dan Service yang memiliki label name=myLabel
kubectl -n my-ns delete pod,svc --all                                     # menghapus semua Pod dan Service di dalam Namespace my-ns
# menghapus semua Pod yang sesuai dengan pattern1 atau pattern2 dari awk
kubectl get pods  -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs  kubectl delete -n mynamespace pod

Berinteraksi dengan Pod yang sedang berjalan

kubectl logs my-pod                                 # memperlihatkan log dari Pod (keluaran stdout)
kubectl logs -l name=myLabel                        # memperlihatkan log dari Pod dengan label name=myLabel (keluaran stdout)
kubectl logs my-pod --previous                      # memperlihatkan log dari Pod (keluaran stdout) untuk kontainer yang dijalankan sebelumnya
kubectl logs my-pod -c my-container                 # memperlihatkan log dari kontainer di dalam Pod (keluaran stdout, kasus banyak kontainer)
kubectl logs -l name=myLabel -c my-container        # memperlihatkan log dari Pod, dengan label name=myLabel (keluaran stdout)
kubectl logs my-pod -c my-container --previous      # memperlihatkan log dari kontainer di dalam Pod (keluaran stdout, kasus banyak kontainer) untuk kontainer yang dijalankan sebelumnya
kubectl logs -f my-pod                              # memperlihatkan aliran log dari Pod (keluaran stdout)
kubectl logs -f my-pod -c my-container              # memperlihatkan aliran log dari kontainer di dalam Pod (keluaran stdout, kasus banyak kontainer)
kubectl logs -f -l name=myLabel --all-containers    # memperlihatkan aliran log dari Pod dengan label name=myLabel (keluaran stdout)
kubectl run -i --tty busybox --image=busybox -- sh  # menjalankan Pod sebagai shell interaktif
kubectl run nginx --image=nginx --restart=Never -n 
mynamespace                                         # menjalankan Pod nginx ke dalam Namespace tertentu
kubectl run nginx --image=nginx --restart=Never     # menjalankan Pod nginx dan menulis spesifikasinya ke dalam sebuah berkas bernama pod.yaml
--dry-run -o yaml > pod.yaml

kubectl attach my-pod -i                            # melekatkan (meng-attach) ke dalam kontainer yang sedang berjalan
kubectl port-forward my-pod 5000:6000               # mendengar (listen) pada porta 5000 di mesin lokal dan meneruskan ke porta 6000 di Pod my-pod
kubectl exec my-pod -- ls /                         # menjalankan perintah pada Pod my-pod (kasus 1 kontainer)
kubectl exec my-pod -c my-container -- ls /         # menjalankan peirntah pada Pod my-pod (kasus banyak kontainer)
kubectl top pod POD_NAME --containers               # memperlihatkan metrik yang dimiliki Pod bersama kontainernya

Berinteraksi dengan Node dan Klaster

kubectl cordon my-node                                                # menandai my-node supaya tidak bisa dijadwalkan dengan Pod (unschedulable)
kubectl drain my-node                                                 # mengeringkan (drain) my-node sebagai bagian dari persiapan untuk pemeliharaan
kubectl uncordon my-node                                              # menandai my-node supaya bisa dijadwalkan dengan Pod (schedulable)
kubectl top node my-node                                              # memperlihatkan metrik dari Node my-node
kubectl cluster-info                                                  # memperlihatkan alamaat dari master dan layanan
kubectl cluster-info dump                                             # memperlihatkan state klaster saat ini pada keluaran stdout
kubectl cluster-info dump --output-directory=/path/to/cluster-state   # memperlihatkan state klaster saat ini pada /path/to/cluster-state

# jika sebuah taint dengan sebuah kunci dan efek di bawah pernah diterapkan, maka nilainya akan tergantikan dengan yang baru
kubectl taint nodes foo dedicated=special-user:NoSchedule

Berbagai Tipe Sumber Daya

Mendapatkan seluruh daftar tipe sumber daya yang didukung lengkap dengan singkatan pendeknya, grup API, apakah sumber daya merupakan sumber daya yang berada di dalam Namespace atau tidak, serta Kind:

kubectl api-resources

Operasi lainnya yang berkaitan dengan sumber daya API (api-resources):

kubectl api-resources --namespaced=true      # semua sumber daya yang berada di dalam Namespace
kubectl api-resources --namespaced=false     # semua sumber daya yang tidak berada di dalam Namespace
kubectl api-resources -o name                # semua sumber daya dengan keluaran sederhana (hanya nama sumber daya)
kubectl api-resources -o wide                # semua sumber daya dengan keluaran tambahan ("wide")
kubectl api-resources --verbs=list,get       # semua sumber daya yang mendukung verb permintaan "list" dan "get"
kubectl api-resources --api-group=extensions # semua sumber daya di dalam grup API "extensions"

Memformat Keluaran

Untuk mengeluarkan detail ke dalam jendela terminal kamu dengan format tertentu, tambahkan flag -o (atau --output) dengan perintah kubectl yang didukung.

Contoh-contoh yang menggunakan -o=custom-columns:

# All images running in a cluster
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'

 # All images excluding "registry.k8s.io/coredns:1.6.2"
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="registry.k8s.io/coredns:1.6.2")].image'

# All fields under metadata regardless of name
kubectl get pods -A -o=custom-columns='DATA:metadata.*'

More examples in the kubectl reference documentation.

Tingkat Kelengkapan Keluaran dan Debugging Kubectl

Tingkat kelengkapan keluaran (verbosity) dari kubectl dikendalikan oleh flag -v atau --v diikuti dengan bilangan bulat yang merepresentasikan tingkatan log. Ketentuan logging Kubernetes secara umum dan keterkaitannya dengan tingkatan log dijelaskan di sini.

Selanjutnya

• Pelajari lebih lanjut tentang Ikhitsar kubectl.

• Lihat berbagai pilihan opsi dari kubectl.

• Pelajari juga Ketentuan Penggunaan kubectl untuk mengetahui bagaimana cara memakainya di dalam skrip yang bisa dipergunakan berulangkali (reusable).

• Pelajari contekan kubectl dari komunitas.

5 - Referensi Jaringan

Bagian dari dokumentasi Kubernetes ini menyediakan referensi detail tentang jaringan Kubernetes.

5.1 - Protokol untuk Service

Jika Anda mengonfigurasi Service, Anda dapat memilih protokol jaringan manapun selama didukung oleh Kubernetes.

Berikut ini adalah protokol yang didukung Kubernetes untuk digunakan oleh Service:

• SCTP
• TCP (protokol bawaan)
• UDP

Ketika Anda mendefinisikan Service, Anda juga dapat menggunakan protokol aplikasi untuk Service.

Halaman ini menjelaskan beberapa kasus khusus, dimana kebanyakan kasus yang terjadi adalah saat penggunaan TCP sebagai protokol transport:

• HTTP dan HTTPS
• protokol PROXY
• terminasi TLS di load balancer

Protokol yang didukung

Ada 3 protokol valid yang dapat digunakan port suatu Service:

SCTP

Ketika menggunakan plugin jaringan yang mendukung SCTP, Anda dapat menggunakan SCTP untuk sebagian besar Service. Untuk Service dengan type: LoadBalancer , dukungan SCTP tersedia apabila penyedia cloud menyediakan protokol ini. (Kebanyakan dari mereka tidak menyediakan dukungan untuk protokol ini).

SCTP tidak tersedia untuk node yang menjalankan Windows.

Dukungan untuk asosiasi multihomed SCTP

Dukungan untuk asosiasi multihomed SCTP memerlukan plugin CNI agar mendukung penempatan banyak interface dan alamat IP ke sebuah Pod.

NAT untuk asosiasi multihomed SCTP memerlukan logika khusus di modul Kernel terkait.

TCP

Anda dapat menggunakan TCP untuk berbagai macam Service, dan ini adalah protokol jaringan bawaan.

UDP

Anda dapat menggunakan UDP untuk sebagian besar Service. Untuk Service dengan type: LoadBalancer, dukungan UDP tersedia apabila penyedia cloud menyediakan protokol ini

Kasus Khusus

HTTP

Jika penyedia cloud mendukung protokol ini, Anda dapat menggunakan Service dengan mode LoadBalancer untuk mengonfigurasi load balancer yang berada di luar klaster Kubernetes, dengan menggunakan mode khusus dimana load balancer yang disediakan penyedia cloud telah mengimplementasi HTTP / HTTPS proxying, dimana lalu lintas paket diteruskan ke backend endpoint untuk Service tersebut.

Biasanya, Anda mengatur protokol untuk Service dengan TCP dan menambahkan annotation (biasanya tergantung ke penyedia cloud) yang mengonfigurasi load balancer untuk menangani lalu lintas paket di tingkat HTTP. Konfigurasi ini menyediakan juga HTTPS (HTTP di atas TLS) dan reverse-proxying HTTP sederhana untuk workload Anda.

Anda juga mungkin ingin mengatur protokol aplikasi suatu koneksi dengan http atau https. Gunakan http jika session dari load balancer untuk workload Anda adalah HTTP tanpa TLS. Dan gunakan https jika session dari load balancer untuk workload Anda menggunakan enkripsi TLS.

protokol PROXY

Jika penyedia cloud Anda mendukung protokol ini, Anda dapat menggunakan Service dengan type: LoadBalancer untuk mengonfigurasi load balancer diluar klaster Kubernetes sendiri, yang akan meneruskan koneksi yang dibungkus oleh protokol PROXY.

Kemudian Load balancer mengirim rangkaian oktet awal yang menggambarkan koneksi kedatangan, mirip dengan contoh dibawah ini (protokol PROXY v1):

PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n

Data yang masuk setelah pembukaan protokol PROXY adalah data asli dari klien. Ketika kedua sisi menutup koneksi, load balancer juga memicu penutupan koneksi dan mengirim sisa data ketika memungkinkan.

Biasanya, Anda mendefinisikan Service dengan protokol TCP. Anda juga dapat menambahkan annotation, yang khusus untuk penyedia cloud Anda, yang mengonfigurasi load balancer dengan membungkus setiap koneksi yang datang dengan protokol PROXY.

TLS

Jika penyedia cloud Anda mendukung protokol ini, Anda dapat menggunakan protokol ini pada Service sebagai cara untuk membangun reverse proxying eksternal, dimana koneksi yang datang dari klien ke load balancer terenkripsi dengan TLS dan load balancer adalah TLS server peer. Koneksi dari load balancer yang menuju workload Anda dapat juga berupa TLS, atau teks biasa. Pilihan yang tersedia untuk Anda tergantung dari penyedia cloud atau implementasi kustom suatu Service.

Biasanya, Anda mengatur protokol ke TCP dan menambahkan annotation (biasanya khusus untuk penyedia cloud Anda) yang mengonfigurasi load balancer untuk berjalan sebagai server TLS. Anda juga dapat mengonfigurasi identitas TLS (sebagai server, dan mungkin juga sebagai klien yang terhubung ke workload Anda) dengan menggunakan mekanisme yang tersedia khusus untuk penyedia cloud Anda.

5.2 - Port dan Protokol

Ketika menjalankan Kubernetes di lingkungan dengan jaringan yang terbatas dan ketat, seperti pada on-premises data center dengan firewall fisik pada jaringan tersebut atau jaringan virtual di public cloud, akan sangat berguna apabila kita mengetahui port dan protokol yang digunakan oleh komponen Kubernetes

Panel Kontrol

Meskipun port Etcd termasuk dalam bagian panel kontrol diatas (sebagai bawaan dari instalasi klaster Kubernetes itu sendiri), Anda dapat membangun klaster Etcd Anda sendiri di luar Kubernetes atau melalui port kustom.

Worker node(s)

† Rentang port bawaan untuk Service berbasis NodePort.

Semua nomor port bawaan dapat ditimpa dengan nomor lainnya. Ketika port kustom dipilih, port tersebut harus dibuka dan dapat diakses oleh komponen Kubernetes lainnya.

Salah satu contoh yang umum adalah port API server yang terkadang diganti ke 443. Sebagai alternatif, port bawaan tetap digunakan dan API server tersebut ditempatkan di belakang load balancer yang dapat diakses melalui port 443. Kemudian, request yang diterima diteruskan ke API server melalui port bawaannya.