Kubernetes - Panduan Cepat

Kubernetes dalam alat pengelolaan container open source yang dihosting oleh Cloud Native Computing Foundation (CNCF). Ini juga dikenal sebagai versi Borg yang disempurnakan yang dikembangkan di Google untuk mengelola proses yang berjalan lama dan pekerjaan batch, yang sebelumnya ditangani oleh sistem terpisah.

Kubernetes hadir dengan kemampuan untuk mengotomatiskan penerapan, penskalaan aplikasi, dan operasi wadah aplikasi di seluruh kluster. Ia mampu menciptakan infrastruktur yang berpusat pada kontainer.

Fitur Kubernetes

Berikut adalah beberapa fitur penting dari Kubernetes.

• Melanjutkan pengembangan, integrasi, dan penyebaran

• Infrastruktur kemas

• Manajemen yang berpusat pada aplikasi

• Infrastruktur yang dapat diskalakan secara otomatis

• Konsistensi lingkungan di seluruh pengujian pengembangan dan produksi

• Infrastruktur yang digabungkan secara longgar, di mana setiap komponen dapat bertindak sebagai unit terpisah

• Kepadatan pemanfaatan sumber daya yang lebih tinggi

• Infrastruktur yang dapat diprediksi yang akan dibuat

Salah satu komponen utama Kubernetes adalah, ia dapat menjalankan aplikasi pada cluster infrastruktur mesin fisik dan virtual. Ia juga memiliki kemampuan untuk menjalankan aplikasi di cloud.It helps in moving from host-centric infrastructure to container-centric infrastructure.

Pada bab ini, kita akan membahas arsitektur dasar Kubernetes.

Kubernetes - Arsitektur Cluster

Seperti yang terlihat pada diagram berikut, Kubernetes mengikuti arsitektur client-server. Di mana, kami telah menginstal master pada satu mesin dan node pada mesin Linux terpisah.

Komponen kunci dari master dan node didefinisikan di bagian berikut.

Kubernetes - Komponen Mesin Master

Berikut adalah komponen Kubernetes Master Machine.

dll

Ini menyimpan informasi konfigurasi yang dapat digunakan oleh masing-masing node di cluster. Ini adalah penyimpanan nilai kunci ketersediaan tinggi yang dapat didistribusikan di antara beberapa node. Ini hanya dapat diakses oleh server Kubernetes API karena mungkin memiliki beberapa informasi sensitif. Ini adalah Toko nilai kunci terdistribusi yang dapat diakses oleh semua.

Server API

Kubernetes adalah server API yang menyediakan semua operasi pada cluster menggunakan API. Server API mengimplementasikan antarmuka, yang berarti alat dan pustaka yang berbeda dapat dengan mudah berkomunikasi dengannya.Kubeconfigadalah paket bersama dengan alat sisi server yang dapat digunakan untuk komunikasi. Ini mengekspos Kubernetes API.

Manajer Pengontrol

Komponen ini bertanggung jawab atas sebagian besar kolektor yang mengatur status cluster dan melakukan tugas. Secara umum, ini dapat dianggap sebagai daemon yang berjalan dalam loop nonterminating dan bertanggung jawab untuk mengumpulkan dan mengirim informasi ke server API. Ini berfungsi untuk mendapatkan status bersama dari cluster dan kemudian membuat perubahan untuk membawa status server saat ini ke status yang diinginkan. Pengontrol kunci adalah pengontrol replikasi, pengontrol titik akhir, pengontrol namespace, dan pengontrol akun layanan. Manajer pengontrol menjalankan berbagai jenis pengontrol untuk menangani node, titik akhir, dll.

Penjadwal

Ini adalah salah satu komponen kunci dari master Kubernetes. Ini adalah layanan di master yang bertanggung jawab untuk mendistribusikan beban kerja. Ini bertanggung jawab untuk melacak pemanfaatan beban kerja pada node cluster dan kemudian menempatkan beban kerja di sumber daya mana yang tersedia dan menerima beban kerja. Dengan kata lain, ini adalah mekanisme yang bertanggung jawab untuk mengalokasikan pod ke node yang tersedia. Penjadwal bertanggung jawab atas pemanfaatan beban kerja dan mengalokasikan pod ke node baru.

Kubernetes - Komponen Node

Berikut adalah komponen kunci dari server Node yang diperlukan untuk berkomunikasi dengan master Kubernetes.

Buruh pelabuhan

Persyaratan pertama dari setiap node adalah Docker yang membantu dalam menjalankan wadah aplikasi yang dienkapsulasi dalam lingkungan operasi yang relatif terisolasi tetapi ringan.

Layanan Kubelet

Ini adalah layanan kecil di setiap node yang bertanggung jawab untuk menyampaikan informasi ke dan dari layanan bidang kontrol. Ini berinteraksi denganetcdsimpan untuk membaca detail konfigurasi dan nilai wright. Ini berkomunikasi dengan komponen master untuk menerima perintah dan bekerja. ItukubeletProses kemudian mengambil tanggung jawab untuk memelihara status kerja dan server node. Ini mengelola aturan jaringan, penerusan port, dll.

Layanan Kubernetes Proxy

Ini adalah layanan proxy yang berjalan di setiap node dan membantu menyediakan layanan untuk host eksternal. Ini membantu dalam meneruskan permintaan ke container yang benar dan mampu melakukan load balancing primitif. Itu memastikan bahwa lingkungan jaringan dapat diprediksi dan diakses dan pada saat yang sama juga diisolasi. Ia mengelola pod pada node, volume, rahasia, membuat pemeriksaan kesehatan container baru, dll.

Kubernetes - Master dan Struktur Node

Ilustrasi berikut menunjukkan struktur Kubernetes Master dan Node.

Penting untuk menyiapkan Pusat Data Virtual (vDC) sebelum menyiapkan Kubernetes. Ini dapat dianggap sebagai sekumpulan mesin di mana mereka dapat berkomunikasi satu sama lain melalui jaringan. Untuk pendekatan langsung, Anda dapat menyiapkan vDCPROFITBRICKS jika Anda belum menyiapkan infrastruktur fisik atau cloud.

Setelah pengaturan IaaS di cloud apa pun selesai, Anda perlu mengkonfigurasi file Master dan Node.

Note- Setup ditampilkan untuk mesin Ubuntu. Hal yang sama dapat diatur di mesin Linux lainnya juga.

Prasyarat

Installing Docker- Docker diperlukan di semua instance Kubernetes. Berikut adalah langkah-langkah untuk menginstal Docker.

Step 1 - Masuk ke mesin dengan akun pengguna root.

Step 2- Perbarui informasi paket. Pastikan paket apt berfungsi.

Step 3 - Jalankan perintah berikut.

$ sudo apt-get update $ sudo apt-get install apt-transport-https ca-certificates

Step 4 - Tambahkan kunci GPG baru.

$ sudo apt-key adv \ --keyserver hkp://ha.pool.sks-keyservers.net:80 \ --recv-keys 58118E89F3A912897C070ADBF76221572C52609D $ echo "deb https://apt.dockerproject.org/repo ubuntu-trusty main" | sudo tee
/etc/apt/sources.list.d/docker.list

Step 5 - Perbarui gambar paket API.

$ sudo apt-get update

Setelah semua tugas di atas selesai, Anda dapat mulai dengan penginstalan aktual mesin Docker. Namun, sebelum ini Anda perlu memverifikasi bahwa versi kernel yang Anda gunakan sudah benar.

Instal Mesin Docker

Jalankan perintah berikut untuk menginstal mesin Docker.

Step 1 - Masuk ke mesin.

Step 2 - Perbarui indeks paket.

$ sudo apt-get update

Step 3 - Instal Mesin Docker menggunakan perintah berikut.

$ sudo apt-get install docker-engine

Step 4 - Jalankan daemon Docker.

$ sudo apt-get install docker-engine

Step 5 - Untuk sangat jika Docker diinstal, gunakan perintah berikut.

$ sudo docker run hello-world

Instal etcd 2.0

Ini perlu diinstal di Kubernetes Master Machine. Untuk menginstalnya, jalankan perintah berikut.

$ curl -L https://github.com/coreos/etcd/releases/download/v2.0.0/etcd
-v2.0.0-linux-amd64.tar.gz -o etcd-v2.0.0-linux-amd64.tar.gz ->1
$ tar xzvf etcd-v2.0.0-linux-amd64.tar.gz ------>2 $ cd etcd-v2.0.0-linux-amd64 ------------>3
$ mkdir /opt/bin ------------->4 $ cp etcd* /opt/bin ----------->5

Di set perintah di atas -

• Pertama, kami mengunduh etcd. Simpan ini dengan nama yang ditentukan.
• Kemudian, kita harus menghapus paket tar.
• Kami membuat dir. di dalam / opt bernama bin.
• Salin file yang diekstrak ke lokasi target.

Sekarang kami siap untuk membangun Kubernetes. Kita perlu menginstal Kubernetes di semua mesin di cluster.

$ git clone https://github.com/GoogleCloudPlatform/kubernetes.git $ cd kubernetes
$ make release

Perintah di atas akan membuat file _outputdir di root folder kubernetes. Selanjutnya, kita dapat mengekstrak direktori ke direktori mana pun yang kita pilih / opt / bin, dll.

Selanjutnya, datanglah bagian jaringan di mana kita harus benar-benar memulai dengan pengaturan master dan node Kubernetes. Untuk melakukan ini, kami akan membuat entri di file host yang dapat dilakukan di mesin node.

$ echo "<IP address of master machine> kube-master
< IP address of Node Machine>" >> /etc/hosts

Berikut akan menjadi output dari perintah di atas.

Sekarang, kita akan mulai dengan konfigurasi sebenarnya di Kubernetes Master.

Pertama, kami akan mulai menyalin semua file konfigurasi ke lokasi yang benar.

$ cp <Current dir. location>/kube-apiserver /opt/bin/ $ cp <Current dir. location>/kube-controller-manager /opt/bin/
$ cp <Current dir. location>/kube-kube-scheduler /opt/bin/ $ cp <Current dir. location>/kubecfg /opt/bin/
$ cp <Current dir. location>/kubectl /opt/bin/ $ cp <Current dir. location>/kubernetes /opt/bin/

Perintah di atas akan menyalin semua file konfigurasi ke lokasi yang diperlukan. Sekarang kita akan kembali ke direktori yang sama dimana kita telah membuat folder Kubernetes.

$ cp kubernetes/cluster/ubuntu/init_conf/kube-apiserver.conf /etc/init/ $ cp kubernetes/cluster/ubuntu/init_conf/kube-controller-manager.conf /etc/init/
$ cp kubernetes/cluster/ubuntu/init_conf/kube-kube-scheduler.conf /etc/init/ $ cp kubernetes/cluster/ubuntu/initd_scripts/kube-apiserver /etc/init.d/
$ cp kubernetes/cluster/ubuntu/initd_scripts/kube-controller-manager /etc/init.d/ $ cp kubernetes/cluster/ubuntu/initd_scripts/kube-kube-scheduler /etc/init.d/

$ cp kubernetes/cluster/ubuntu/default_scripts/kubelet /etc/default/ $ cp kubernetes/cluster/ubuntu/default_scripts/kube-proxy /etc/default/
$ cp kubernetes/cluster/ubuntu/default_scripts/kubelet /etc/default/

Langkah selanjutnya adalah memperbarui file konfigurasi yang disalin di bawah / etc. dir.

Konfigurasikan etcd pada master menggunakan perintah berikut.

$ ETCD_OPTS = "-listen-client-urls = http://kube-master:4001"

Konfigurasi kube-apiserver

Untuk ini di master, kita perlu mengedit file /etc/default/kube-apiserver file yang kami salin sebelumnya.

$ KUBE_APISERVER_OPTS = "--address = 0.0.0.0 \
--port = 8080 \
--etcd_servers = <The path that is configured in ETCD_OPTS> \
--portal_net = 11.1.1.0/24 \
--allow_privileged = false \
--kubelet_port = < Port you want to configure> \
--v = 0"

Konfigurasikan Manajer Pengontrol kube

Kita perlu menambahkan konten berikut di /etc/default/kube-controller-manager.

$ KUBE_CONTROLLER_MANAGER_OPTS = "--address = 0.0.0.0 \
--master = 127.0.0.1:8080 \
--machines = kube-minion \ -----> #this is the kubernatics node
--v = 0

Selanjutnya, konfigurasikan penjadwal kube di file yang sesuai.

$ KUBE_SCHEDULER_OPTS = "--address = 0.0.0.0 \
--master = 127.0.0.1:8080 \
--v = 0"

Setelah semua tugas di atas selesai, kami akan melanjutkan dengan membuka Kubernetes Master. Untuk melakukan ini, kami akan memulai ulang Docker.

$ service docker restart

Konfigurasi Kubernetes Node

Node Kubernetes akan menjalankan dua layanan yaitu kubelet and the kube-proxy. Sebelum melanjutkan, kita perlu menyalin binari yang kita unduh ke folder yang diperlukan tempat kita ingin mengkonfigurasi node kubernetes.

Gunakan metode yang sama untuk menyalin file yang kami lakukan untuk kubernetes master. Karena ini hanya akan menjalankan kubelet dan kube-proxy, kami akan mengkonfigurasinya.

$ cp <Path of the extracted file>/kubelet /opt/bin/ $ cp <Path of the extracted file>/kube-proxy /opt/bin/
$ cp <Path of the extracted file>/kubecfg /opt/bin/ $ cp <Path of the extracted file>/kubectl /opt/bin/
$ cp <Path of the extracted file>/kubernetes /opt/bin/

Sekarang, kita akan menyalin konten ke direktori yang sesuai.

$ cp kubernetes/cluster/ubuntu/init_conf/kubelet.conf /etc/init/
$ cp kubernetes/cluster/ubuntu/init_conf/kube-proxy.conf /etc/init/ $ cp kubernetes/cluster/ubuntu/initd_scripts/kubelet /etc/init.d/
$ cp kubernetes/cluster/ubuntu/initd_scripts/kube-proxy /etc/init.d/ $ cp kubernetes/cluster/ubuntu/default_scripts/kubelet /etc/default/
$ cp kubernetes/cluster/ubuntu/default_scripts/kube-proxy /etc/default/

Kami akan mengkonfigurasi kubelet dan kube-proxy conf file.

Kami akan mengkonfigurasi /etc/init/kubelet.conf.

$ KUBELET_OPTS = "--address = 0.0.0.0 \
--port = 10250 \
--hostname_override = kube-minion \
--etcd_servers = http://kube-master:4001 \
--enable_server = true
--v = 0"
/

Untuk kube-proxy, kami akan mengkonfigurasi menggunakan perintah berikut.

$ KUBE_PROXY_OPTS = "--etcd_servers = http://kube-master:4001 \
--v = 0"
/etc/init/kube-proxy.conf

Terakhir, kami akan memulai ulang layanan Docker.

$ service docker restart

Sekarang kita selesai dengan konfigurasi. Anda dapat memeriksa dengan menjalankan perintah berikut.

$ /opt/bin/kubectl get minions

Image Kubernetes (Docker) adalah blok bangunan utama dari Infrastruktur yang tertampung. Untuk saat ini, kami hanya mendukung Kubernetes untuk mendukung image Docker. Setiap container dalam pod memiliki image Docker yang berjalan di dalamnya.

Saat kita mengonfigurasi sebuah pod, properti image di file konfigurasi memiliki sintaks yang sama seperti perintah Docker. File konfigurasi memiliki kolom untuk menentukan nama gambar, yang akan kita tarik dari registri.

Berikut adalah struktur konfigurasi umum yang akan menarik image dari registry Docker dan diterapkan ke container Kubernetes.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> 1
   spec:
      containers:
         - name: neo4j-server ------------------------> 2
         image: <Name of the Docker image>----------> 3
         imagePullPolicy: Always ------------->4
         command: ["echo", "SUCCESS"] ------------------->

Dalam kode di atas, kami telah mendefinisikan -

• name: Tesing_for_Image_pull - Nama ini diberikan untuk mengidentifikasi dan memeriksa apa nama wadah yang akan dibuat setelah menarik gambar dari registri Docker.

• name: neo4j-server- Ini adalah nama yang diberikan ke penampung yang kami coba buat. Seperti yang kami berikan neo4j-server.

• image: <Name of the Docker image>- Ini adalah nama gambar yang kami coba tarik dari Docker atau registri internal gambar. Kita perlu menentukan jalur registri lengkap bersama dengan nama gambar yang coba kita tarik.

• imagePullPolicy - Selalu - Kebijakan penarikan gambar ini menetapkan bahwa setiap kali kita menjalankan file ini untuk membuat penampung, itu akan menarik nama yang sama lagi.

• command: [“echo”, “SUCCESS”] - Dengan ini, saat kita membuat container dan jika semuanya berjalan dengan baik, akan muncul pesan saat kita akan mengakses container tersebut.

Untuk menarik gambar dan membuat wadah, kami akan menjalankan perintah berikut.

$ kubectl create –f Tesing_for_Image_pull

Setelah kami mengambil log, kami akan mendapatkan hasilnya sebagai berhasil.

$ kubectl log Tesing_for_Image_pull

Perintah diatas akan menghasilkan keluaran yang berhasil atau kita akan mendapatkan keluaran berupa kegagalan.

Note - Anda disarankan untuk mencoba semua perintah itu sendiri.

Fungsi utama sebuah pekerjaan adalah untuk membuat satu atau lebih pod dan melacak keberhasilan dari sebuah pod. Mereka memastikan bahwa jumlah pod yang ditentukan berhasil diselesaikan. Jika sejumlah pod berhasil yang berhasil diselesaikan, tugas tersebut dianggap selesai.

Membuat Pekerjaan

Gunakan perintah berikut untuk membuat pekerjaan -

apiVersion: v1
kind: Job ------------------------> 1
metadata:
   name: py
   spec:
   template:
      metadata
      name: py -------> 2
      spec:
         containers:
            - name: py ------------------------> 3
            image: python----------> 4
            command: ["python", "SUCCESS"]
            restartPocliy: Never --------> 5

Dalam kode di atas, kami telah mendefinisikan -

• kind: Job → Kami telah mendefinisikan jenisnya sebagai Ayub yang akan memberi tahu kubectl bahwa yaml file yang digunakan adalah untuk membuat pod jenis pekerjaan.

• Name:py → Ini adalah nama template yang kita gunakan dan spesifikasi mendefinisikan template.

• name: py → kami telah memberi nama sebagai py di bawah spesifikasi container yang membantu mengidentifikasi Pod yang akan dibuat darinya.

• Image: python → gambar yang akan kita tarik untuk membuat wadah yang akan berjalan di dalam pod.

• restartPolicy: Never →Kondisi image restart ini diberikan sebagai never yang artinya jika container dimatikan atau jika salah maka tidak akan restart sendiri.

Kami akan membuat pekerjaan menggunakan perintah berikut dengan yaml yang disimpan dengan nama py.yaml.

$ kubectl create –f py.yaml

Perintah di atas akan membuat pekerjaan. Jika Anda ingin memeriksa status pekerjaan, gunakan perintah berikut.

$ kubectl describe jobs/py

Perintah di atas akan membuat pekerjaan. Jika Anda ingin memeriksa status pekerjaan, gunakan perintah berikut.

Pekerjaan Terjadwal

Pekerjaan terjadwal di Kubernetes menggunakan Cronetes, yang mengambil tugas Kubernetes dan meluncurkannya di cluster Kubernetes.

• Menjadwalkan pekerjaan akan menjalankan pod pada titik waktu tertentu.
• Pekerjaan parodi dibuat untuknya yang memanggil dirinya sendiri secara otomatis.

Note - Fitur pekerjaan terjadwal didukung oleh versi 1.4 dan API betch / v2alpha 1 dihidupkan dengan melewatkan –runtime-config=batch/v2alpha1 saat membuka server API.

Kami akan menggunakan yaml yang sama yang kami gunakan untuk membuat pekerjaan dan menjadikannya pekerjaan terjadwal.

apiVersion: v1
kind: Job
metadata:
   name: py
spec:
   schedule: h/30 * * * * ? -------------------> 1
   template:
      metadata
         name: py
      spec:
         containers:
         - name: py
         image: python
         args:
/bin/sh -------> 2
-c
ps –eaf ------------> 3
restartPocliy: OnFailure

Dalam kode di atas, kami telah mendefinisikan -

• schedule: h/30 * * * * ? → Untuk menjadwalkan pekerjaan agar dijalankan setiap 30 menit.

• /bin/sh: Ini akan masuk ke dalam wadah dengan / bin / sh

• ps –eaf → Akan menjalankan perintah ps -eaf pada mesin dan mencantumkan semua proses yang berjalan di dalam wadah.

Konsep pekerjaan terjadwal ini berguna saat kita mencoba membangun dan menjalankan serangkaian tugas pada titik waktu tertentu dan kemudian menyelesaikan prosesnya.

Label

Label adalah pasangan nilai kunci yang dilampirkan ke pod, pengontrol replikasi, dan layanan. Mereka digunakan sebagai pengidentifikasi atribut untuk objek seperti pod dan pengontrol replikasi. Mereka dapat ditambahkan ke sebuah objek pada waktu pembuatan dan dapat ditambahkan atau dimodifikasi pada saat berjalan.

Penyeleksi

Label tidak memberikan keunikan. Secara umum, kita dapat mengatakan banyak objek dapat memiliki label yang sama. Pemilih label adalah primitif pengelompokan inti di Kubernetes. Mereka digunakan oleh pengguna untuk memilih sekumpulan objek.

Kubernetes API saat ini mendukung dua jenis penyeleksi -

• Pemilih berbasis kesetaraan
• Selektor berbasis set

Penyeleksi Berbasis Kesetaraan

Mereka memungkinkan pemfilteran berdasarkan kunci dan nilai. Objek yang cocok harus memenuhi semua label yang ditentukan.

Penyeleksi Berbasis Set

Pemilih berbasis set memungkinkan pemfilteran kunci sesuai dengan sekumpulan nilai.

apiVersion: v1
kind: Service
metadata:
   name: sp-neo4j-standalone
spec:
   ports:
      - port: 7474
      name: neo4j
   type: NodePort
   selector:
      app: salesplatform ---------> 1
      component: neo4j -----------> 2

Pada kode di atas, kami menggunakan selektor label sebagai app: salesplatform dan komponen sebagai component: neo4j.

Setelah kami menjalankan file menggunakan kubectl perintah, itu akan membuat layanan dengan nama sp-neo4j-standalone yang akan berkomunikasi pada port 7474. YPE adalah NodePort dengan pemilih label baru sebagai app: salesplatform dan component: neo4j.

Namespace memberikan kualifikasi tambahan untuk nama sumber daya. Ini berguna saat beberapa tim menggunakan cluster yang sama dan ada potensi benturan nama. Ini bisa sebagai dinding virtual antara beberapa cluster.

Fungsi Namespace

Berikut adalah beberapa fungsi penting dari Namespace di Kubernetes -

• Namespaces membantu komunikasi pod-to-pod menggunakan namespace yang sama.

• Namespaces adalah cluster virtual yang dapat berada di atas cluster fisik yang sama.

• Mereka memberikan pemisahan logis antara tim dan lingkungan mereka.

Buat Namespace

Perintah berikut digunakan untuk membuat namespace.

apiVersion: v1
kind: Namespce
metadata
   name: elk

Kontrol Namespace

Perintah berikut digunakan untuk mengontrol namespace.

$ kubectl create –f namespace.yml ---------> 1
$ kubectl get namespace -----------------> 2 $ kubectl get namespace <Namespace name> ------->3
$ kubectl describe namespace <Namespace name> ---->4 $ kubectl delete namespace <Namespace name>

Pada kode di atas,

• Kami menggunakan perintah untuk membuat namespace.
• Ini akan mencantumkan semua namespace yang tersedia.
• Ini akan mendapatkan namespace tertentu yang namanya ditentukan dalam perintah.
• Ini akan menjelaskan detail lengkap tentang layanan tersebut.
• Ini akan menghapus namespace tertentu yang ada di cluster.

Menggunakan Namespace dalam Layanan - Contoh

Berikut adalah contoh file contoh untuk menggunakan namespace dalam layanan.

apiVersion: v1
kind: Service
metadata:
   name: elasticsearch
   namespace: elk
   labels:
      component: elasticsearch
spec:
   type: LoadBalancer
   selector:
      component: elasticsearch
   ports:
   - name: http
      port: 9200
      protocol: TCP
   - name: transport
      port: 9300
      protocol: TCP

Pada kode di atas, kami menggunakan namespace yang sama di bawah metadata layanan dengan nama elk.

Node adalah mesin yang berfungsi di cluster Kubernetes yang juga dikenal sebagai minion. Mereka adalah unit kerja yang dapat berupa fisik, VM, atau instance cloud.

Setiap node memiliki semua konfigurasi yang diperlukan untuk menjalankan pod di dalamnya seperti layanan proxy dan layanan kubelet bersama dengan Docker, yang digunakan untuk menjalankan container Docker pada pod yang dibuat di node.

Mereka tidak dibuat oleh Kubernetes tetapi dibuat secara eksternal baik oleh penyedia layanan cloud atau manajer cluster Kubernetes di mesin fisik atau VM.

Komponen kunci Kubernetes untuk menangani banyak node adalah manajer pengontrol, yang menjalankan berbagai jenis pengontrol untuk mengelola node. Untuk mengelola node, Kubernetes membuat objek node jenis yang akan memvalidasi bahwa objek yang dibuat adalah node yang valid.

Layanan dengan Selector

apiVersion: v1
kind: node
metadata:
   name: < ip address of the node>
   labels:
      name: <lable name>

Dalam format JSON, objek sebenarnya dibuat yang terlihat sebagai berikut -

{
   Kind: node
   apiVersion: v1
   "metadata": 
   {
      "name": "10.01.1.10",
      "labels"
      {
         "name": "cluster 1 node"
      }
   }
}

Pengontrol Node

Mereka adalah kumpulan layanan yang berjalan di master Kubernetes dan terus memantau node di cluster berdasarkan metadata.name. Jika semua layanan yang dibutuhkan berjalan, maka node divalidasi dan pod yang baru dibuat akan diberikan ke node tersebut oleh pengontrol. Jika tidak valid, maka master tidak akan menetapkan pod apapun ke dalamnya dan akan menunggu sampai menjadi valid.

Kubernetes master mendaftarkan node secara otomatis, jika –register-node bendera benar.

–register-node = true

Namun, jika administrator cluster ingin mengelolanya secara manual maka hal itu dapat dilakukan dengan membalik -

–register-node = false

Sebuah layanan dapat didefinisikan sebagai kumpulan logis dari pod. Ia dapat didefinisikan sebagai abstraksi di bagian atas pod yang menyediakan satu alamat IP dan nama DNS di mana pod dapat diakses. Dengan Layanan, sangat mudah untuk mengelola konfigurasi teknik penyeimbang beban. Ini membantu pod untuk menskalakan dengan sangat mudah.

Layanan adalah objek REST di Kubernetes yang definisinya dapat diposting ke Kubernetes apiServer di master Kubernetes untuk membuat instance baru.

Layanan tanpa Pemilih

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
   - port: 8080
   targetPort: 31999

Konfigurasi di atas akan membuat layanan dengan nama Tutorial_point_service.

File Konfigurasi Layanan dengan Selector

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   selector:
      application: "My Application" -------------------> (Selector)
   ports:
   - port: 8080
   targetPort: 31999

Dalam contoh ini, kami memiliki selektor; jadi untuk mentransfer lalu lintas, kita perlu membuat titik akhir secara manual.

apiVersion: v1
kind: Endpoints
metadata:
   name: Tutorial_point_service
subnets:
   address:
      "ip": "192.168.168.40" -------------------> (Selector)
   ports:
      - port: 8080

Dalam kode di atas, kita telah membuat titik akhir yang akan mengarahkan lalu lintas ke titik akhir yang didefinisikan sebagai "192.168.168.40:8080".

Pembuatan Layanan Multi-Port

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   selector:
      application: “My Application” -------------------> (Selector)
   ClusterIP: 10.3.0.12
   ports:
      -name: http
      protocol: TCP
      port: 80
      targetPort: 31999
   -name:https
      Protocol: TCP
      Port: 443
      targetPort: 31998

Jenis Layanan

ClusterIP- Ini membantu dalam membatasi layanan di dalam cluster. Ini mengekspos layanan dalam cluster Kubernetes yang ditentukan.

spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: NodeportService

NodePort- Ini akan mengekspos layanan pada port statis pada node yang diterapkan. SEBUAHClusterIP layanan, ke mana NodePortlayanan akan merutekan, secara otomatis dibuat. Layanan dapat diakses dari luar cluster menggunakanNodeIP:nodePort.

spec:
   ports:
   - port: 8080
      nodePort: 31999
      name: NodeportService
      clusterIP: 10.20.30.40

Load Balancer - Menggunakan penyeimbang beban penyedia cloud. NodePort dan ClusterIP layanan dibuat secara otomatis ke mana penyeimbang beban eksternal akan merutekan.

Sebuah layanan penuh yamlfile dengan jenis layanan sebagai Node Port. Coba buat sendiri.

apiVersion: v1
kind: Service
metadata:
   name: appname
   labels:
      k8s-app: appname
spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: omninginx
   selector:
      k8s-app: appname
      component: nginx
      env: env_name

Pod adalah kumpulan container dan penyimpanannya di dalam node cluster Kubernetes. Dimungkinkan untuk membuat sebuah pod dengan banyak kontainer di dalamnya. Misalnya, menyimpan container database dan container data di pod yang sama.

Jenis Pod

Ada dua jenis Pod -

• Pod wadah tunggal
• Pod multi wadah

Pod Kontainer Tunggal

Mereka dapat dengan mudah dibuat dengan perintah kubctl run, di mana Anda memiliki image yang telah ditentukan pada registry Docker yang akan kita tarik saat membuat sebuah pod.

$ kubectl run <name of pod> --image=<name of the image from registry>

Example - Kami akan membuat pod dengan gambar tomcat yang tersedia di hub Docker.

$ kubectl run tomcat --image = tomcat:8.0

Ini juga dapat dilakukan dengan membuat file yaml file dan kemudian menjalankan kubectl create perintah.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
    image: tomcat: 8.0
    ports:
containerPort: 7500
   imagePullPolicy: Always

Begitu di atas yaml file dibuat, kami akan menyimpan file dengan nama tomcat.yml dan jalankan perintah create untuk menjalankan dokumen.

$ kubectl create –f tomcat.yml

Ini akan membuat pod dengan nama tomcat. Kita bisa menggunakan perintah gambarkan bersama dengankubectl untuk mendeskripsikan pod.

Pod Multi Kontainer

Pod multi container dibuat menggunakan yaml mail dengan definisi wadah.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
    image: tomcat: 8.0
    ports:
containerPort: 7500
   imagePullPolicy: Always
   -name: Database
   Image: mongoDB
   Ports:
containerPort: 7501
   imagePullPolicy: Always

Pada kode di atas, kita telah membuat satu pod dengan dua container di dalamnya, satu untuk tomcat dan yang lainnya untuk MongoDB.

Replikasi Controller adalah salah satu fitur utama Kubernetes, yang bertanggung jawab untuk mengelola siklus hidup pod. Ia bertanggung jawab untuk memastikan bahwa jumlah replika pod yang ditentukan berjalan kapan saja. Ini digunakan pada saat seseorang ingin memastikan bahwa jumlah pod yang ditentukan atau setidaknya satu pod sedang berjalan. Ia memiliki kemampuan untuk memunculkan atau menurunkan no dari pod yang ditentukan.

Merupakan praktik terbaik untuk menggunakan pengontrol replikasi untuk mengelola siklus hidup pod daripada membuat pod berulang kali.

apiVersion: v1
kind: ReplicationController --------------------------> 1
metadata:
   name: Tomcat-ReplicationController --------------------------> 2
spec:
   replicas: 3 ------------------------> 3
   template:
      metadata:
         name: Tomcat-ReplicationController
      labels:
         app: App
         component: neo4j
      spec:
         containers:
         - name: Tomcat- -----------------------> 4
         image: tomcat: 8.0
         ports:
            - containerPort: 7474 ------------------------> 5

Detail Pengaturan

• Kind: ReplicationController → Dalam kode di atas, kita telah mendefinisikan jenis sebagai pengontrol replikasi yang memberi tahu kubectl bahwa yaml File akan digunakan untuk membuat pengontrol replikasi.

• name: Tomcat-ReplicationController→ Ini membantu dalam mengidentifikasi nama yang pengontrol replikasi akan dibuat. Jika kita menjalankan kubctl, getrc < Tomcat-ReplicationController > itu akan menampilkan detail pengontrol replikasi.

• replicas: 3 → Ini membantu pengontrol replikasi untuk memahami bahwa ia perlu mempertahankan tiga replika dari sebuah pod pada titik waktu mana pun dalam siklus hidup pod.

• name: Tomcat → Di bagian spesifikasi, kita telah mendefinisikan namanya sebagai tomcat yang akan memberi tahu pengontrol replikasi bahwa container yang ada di dalam pod adalah tomcat.

• containerPort: 7474 → Ini membantu dalam memastikan bahwa semua node di cluster tempat pod menjalankan container di dalam pod akan diekspos di port 7474 yang sama.

Di sini, layanan Kubernetes berfungsi sebagai penyeimbang beban untuk tiga replika kucing jantan.

Replica Set memastikan berapa banyak replika pod yang harus dijalankan. Ini dapat dianggap sebagai pengganti pengontrol replikasi. Perbedaan utama antara set replika dan pengontrol replikasi adalah, pengontrol replikasi hanya mendukung pemilih berbasis kesetaraan sedangkan set replika mendukung pemilih berbasis set.

apiVersion: extensions/v1beta1 --------------------->1
kind: ReplicaSet --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   selector:
      matchLables:
         tier: Backend ------------------> 3
      matchExpression:
{ key: tier, operation: In, values: [Backend]} --------------> 4
template:
   metadata:
      lables:
         app: Tomcat-ReplicaSet
         tier: Backend
      labels:
         app: App
         component: neo4j
   spec:
      containers:
      - name: Tomcat
      image: tomcat: 8.0
      ports:
      - containerPort: 7474

Detail Pengaturan

• apiVersion: extensions/v1beta1 → Pada kode di atas, versi API adalah versi beta lanjutan dari Kubernetes yang mendukung konsep kumpulan replika.

• kind: ReplicaSet → Kita telah mendefinisikan jenis sebagai set replika yang membantu kubectl memahami bahwa file tersebut digunakan untuk membuat set replika.

• tier: Backend → Kami telah mendefinisikan tingkat label sebagai backend yang membuat pemilih yang cocok.

• {key: tier, operation: In, values: [Backend]} → Ini akan membantu matchExpression untuk memahami kondisi pencocokan yang telah kami tentukan dan dalam operasi yang digunakan oleh matchlabel untuk menemukan detailnya.

Jalankan file di atas menggunakan kubectl dan membuat set replika backend dengan definisi yang disediakan di yaml mengajukan.

Deployment ditingkatkan dan versi pengontrol replikasi yang lebih tinggi. Mereka mengelola penyebaran kumpulan replika yang juga merupakan versi pengontrol replikasi yang ditingkatkan. Mereka memiliki kemampuan untuk memperbarui kumpulan replika dan juga mampu untuk kembali ke versi sebelumnya.

Mereka menyediakan banyak fitur yang diperbarui matchLabels dan selectors. Kami mendapatkan pengontrol baru di master Kubernetes yang disebut pengontrol penerapan yang mewujudkannya. Ini memiliki kemampuan untuk mengubah penyebaran di tengah jalan.

Mengubah Penerapan

Updating- Pengguna dapat memperbarui penerapan yang sedang berlangsung sebelum selesai. Dalam hal ini, penerapan yang ada akan diselesaikan dan penerapan baru akan dibuat.

Deleting- Pengguna dapat menjeda / membatalkan penerapan dengan menghapusnya sebelum selesai. Membuat ulang penerapan yang sama akan melanjutkannya.

Rollback- Kami dapat membatalkan penerapan atau penerapan yang sedang berlangsung. Pengguna dapat membuat atau memperbarui penyebaran dengan menggunakanDeploymentSpec.PodTemplateSpec = oldRC.PodTemplateSpec.

Strategi Penerapan

Strategi penyebaran membantu dalam menentukan bagaimana RC baru harus menggantikan RC yang ada.

Recreate- Fitur ini akan mematikan semua RC yang ada dan kemudian memunculkan RC baru. Ini menghasilkan penerapan yang cepat, namun akan mengakibatkan waktu henti saat pod lama tidak aktif dan pod baru belum muncul.

Rolling Update- Fitur ini secara bertahap menurunkan RC lama dan menampilkan RC baru. Ini menghasilkan penerapan yang lambat, namun tidak ada penerapan. Setiap saat, beberapa pod lama dan beberapa pod baru tersedia dalam proses ini.

File konfigurasi Deployment terlihat seperti ini.

apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   template:
      metadata:
         lables:
            app: Tomcat-ReplicaSet
            tier: Backend
   spec:
      containers:
         - name: Tomcatimage:
            tomcat: 8.0
            ports:
               - containerPort: 7474

Dalam kode di atas, satu-satunya hal yang berbeda dari set replika adalah kita telah mendefinisikan jenisnya sebagai penerapan.

Buat Penerapan

$ kubectl create –f Deployment.yaml -–record
deployment "Deployment" created Successfully.

Ambil Deployment

$ kubectl get deployments
NAME           DESIRED     CURRENT     UP-TO-DATE     AVILABLE    AGE
Deployment        3           3           3              3        20s

Periksa Status Penerapan

$ kubectl rollout status deployment/Deployment

Memperbarui Deployment

$ kubectl set image deployment/Deployment tomcat=tomcat:6.0

Mengembalikan ke Penerapan Sebelumnya

$ kubectl rollout undo deployment/Deployment –to-revision=2

Di Kubernetes, volume dapat dianggap sebagai direktori yang dapat diakses oleh container di dalam pod. Kami memiliki tipe volume yang berbeda di Kubernetes dan tipe tersebut menentukan bagaimana volume dibuat dan isinya.

Konsep volume hadir dengan Docker, namun satu-satunya masalah adalah bahwa volume sangat terbatas pada pod tertentu. Begitu umur pod berakhir, volumenya juga hilang.

Di sisi lain, volume yang dibuat melalui Kubernetes tidak terbatas pada container apa pun. Ini mendukung salah satu atau semua kontainer yang ditempatkan di dalam pod Kubernetes. Keuntungan utama volume Kubernetes adalah, ia mendukung berbagai jenis penyimpanan di mana pod dapat menggunakan beberapa di antaranya pada saat yang bersamaan.

Jenis Volume Kubernetes

Berikut adalah daftar dari beberapa Volume Kubernetes yang populer -

• emptyDir- Ini adalah jenis volume yang dibuat saat Pod pertama kali ditetapkan ke sebuah Node. Ia tetap aktif selama Pod tersebut berjalan di node tersebut. Volume awalnya kosong dan container di dalam pod dapat membaca dan menulis file di volume emptyDir. Setelah Pod dihapus dari node, data di emptyDir akan dihapus.

• hostPath - Jenis volume ini memasang file atau direktori dari filesystem node host ke pod Anda.

• gcePersistentDisk- Jenis volume ini memasang Persistent Disk Google Compute Engine (GCE) ke dalam Pod Anda. Data dalam filegcePersistentDisk tetap utuh saat Pod dihapus dari node.

• awsElasticBlockStore- Jenis volume ini memasang Penyimpanan Blok Elastis Amazon Web Services (AWS) ke dalam Pod Anda. SepertigcePersistentDisk, data di file awsElasticBlockStore tetap utuh saat Pod dihapus dari node.

• nfs - An nfsvolume memungkinkan NFS (Sistem File Jaringan) yang ada untuk dipasang ke dalam pod Anda. Data di filenfsvolume tidak terhapus saat Pod dihapus dari node. Volume hanya dilepas.

• iscsi - An iscsi volume memungkinkan volume iSCSI (SCSI over IP) yang sudah ada untuk dipasang ke dalam pod Anda.

• flocker- Ini adalah manajer volume data kontainer berkerumun sumber terbuka. Ini digunakan untuk mengelola volume data. SEBUAHflockervolume memungkinkan set data Flocker dipasang ke dalam pod. Jika dataset tidak ada di Flocker, maka Anda harus membuatnya terlebih dahulu dengan menggunakan Flocker API.

• glusterfs- Glusterfs adalah sistem file jaringan sumber terbuka. Volume glusterfs memungkinkan volume glusterfs dipasang ke pod Anda.

• rbd- RBD adalah singkatan dari Rados Block Device. Sebuahrbdvolume memungkinkan volume Perangkat Blok Rados dipasang ke dalam pod Anda. Data tetap dipertahankan setelah Pod dihapus dari node.

• cephfs - A cephfsvolume memungkinkan volume CephFS yang ada untuk dipasang ke dalam pod Anda. Data tetap utuh setelah Pod dihapus dari node.

• gitRepo - A gitRepo volume me-mount direktori kosong dan mengkloning a git repositori ke dalamnya untuk digunakan pod Anda.

• secret - A secret volume digunakan untuk menyampaikan informasi sensitif, seperti kata sandi, ke pod.

• persistentVolumeClaim - A persistentVolumeClaimvolume digunakan untuk memasang PersistentVolume ke dalam pod. PersistentVolumes adalah cara bagi pengguna untuk "mengklaim" penyimpanan yang tahan lama (seperti GCE PersistentDisk atau volume iSCSI) tanpa mengetahui detail lingkungan cloud tertentu.

• downwardAPI - A downwardAPIvolume digunakan untuk membuat data API ke bawah tersedia untuk aplikasi. Ini memasang direktori dan menulis data yang diminta dalam file teks biasa.

• azureDiskVolume - An AzureDiskVolume digunakan untuk memasang Disk Data Microsoft Azure ke dalam Pod.

Volume Persisten dan Klaim Volume Persisten

Persistent Volume (PV)- Ini adalah bagian dari penyimpanan jaringan yang telah disediakan oleh administrator. Ini adalah sumber daya dalam kluster yang tidak bergantung pada masing-masing pod yang menggunakan PV.

Persistent Volume Claim (PVC)- Penyimpanan yang diminta oleh Kubernetes untuk podnya disebut PVC. Pengguna tidak perlu mengetahui penyediaan yang mendasarinya. Klaim harus dibuat di namespace yang sama tempat pod dibuat.

Membuat Persistent Volume

kind: PersistentVolume ---------> 1
apiVersion: v1
metadata:
   name: pv0001 ------------------> 2
   labels:
      type: local
spec:
   capacity: -----------------------> 3
      storage: 10Gi ----------------------> 4
   accessModes:
      - ReadWriteOnce -------------------> 5
      hostPath:
         path: "/tmp/data01" --------------------------> 6

Dalam kode di atas, kami telah mendefinisikan -

• kind: PersistentVolume → Kita telah mendefinisikan jenisnya sebagai PersistentVolume yang memberi tahu kubernetes bahwa file yaml yang digunakan adalah untuk membuat Persistent Volume.

• name: pv0001 → Nama PersistentVolume yang sedang kita buat.

• capacity: → Spesifikasi ini akan menentukan kapasitas PV yang kita coba buat.

• storage: 10Gi → Ini memberi tahu infrastruktur yang mendasari bahwa kami mencoba mengklaim ruang 10Gi di jalur yang ditentukan.

• ReadWriteOnce → Ini memberitahu hak akses volume yang kita buat.

• path: "/tmp/data01" → Definisi ini memberi tahu mesin bahwa kami mencoba membuat volume di bawah jalur ini pada infrastruktur yang mendasarinya.

Membuat PV

$ kubectl create –f local-01.yaml
persistentvolume "pv0001" created

Memeriksa PV

$ kubectl get pv
NAME        CAPACITY      ACCESSMODES       STATUS       CLAIM      REASON     AGE
pv0001        10Gi            RWO         Available                            14s

Menjelaskan PV

$ kubectl describe pv pv0001

Membuat Klaim Volume Persisten

kind: PersistentVolumeClaim --------------> 1
apiVersion: v1
metadata:
   name: myclaim-1 --------------------> 2
spec:
   accessModes:
      - ReadWriteOnce ------------------------> 3
   resources:
      requests:
         storage: 3Gi ---------------------> 4

Dalam kode di atas, kami telah mendefinisikan -

• kind: PersistentVolumeClaim → Ini menginstruksikan infrastruktur yang mendasari bahwa kami mencoba untuk mengklaim jumlah ruang tertentu.

• name: myclaim-1 → Nama klaim yang kami coba buat.

• ReadWriteOnce → Ini menentukan mode klaim yang kami coba buat.

• storage: 3Gi → Ini akan memberi tahu kubernetes tentang jumlah ruang yang ingin kami klaim.

Membuat PVC

$ kubectl create –f myclaim-1
persistentvolumeclaim "myclaim-1" created

Mendapatkan Detail Tentang PVC

$ kubectl get pvc
NAME        STATUS   VOLUME   CAPACITY   ACCESSMODES   AGE
myclaim-1   Bound    pv0001     10Gi         RWO       7s

Jelaskan PVC

$ kubectl describe pv pv0001

Menggunakan PV dan PVC dengan POD

kind: Pod
apiVersion: v1
metadata:
   name: mypod
   labels:
      name: frontendhttp
spec:
   containers:
   - name: myfrontend
      image: nginx
      ports:
      - containerPort: 80
         name: "http-server"
      volumeMounts: ----------------------------> 1
      - mountPath: "/usr/share/tomcat/html"
         name: mypd
   volumes: -----------------------> 2
      - name: mypd
         persistentVolumeClaim: ------------------------->3
         claimName: myclaim-1

Dalam kode di atas, kami telah mendefinisikan -

• volumeMounts: → Ini adalah jalur dalam wadah tempat pemasangan akan dilakukan.

• Volume: → Definisi ini mendefinisikan definisi volume yang akan kami klaim.

• persistentVolumeClaim: → Di bawah ini, kami mendefinisikan nama volume yang akan kami gunakan di pod yang ditentukan.

Rahasia dapat didefinisikan sebagai objek Kubernetes yang digunakan untuk menyimpan data sensitif seperti nama pengguna dan kata sandi dengan enkripsi.

Ada banyak cara untuk membuat rahasia di Kubernetes.

• Membuat dari file txt.
• Membuat dari file yaml.

Membuat Dari File Teks

Untuk membuat rahasia dari file teks seperti nama pengguna dan kata sandi, pertama-tama kita perlu menyimpannya dalam file txt dan menggunakan perintah berikut.

$ kubectl create secret generic tomcat-passwd –-from-file = ./username.txt –fromfile = ./.
password.txt

Membuat Dari File Yaml

apiVersion: v1
kind: Secret
metadata:
name: tomcat-pass
type: Opaque
data:
   password: <User Password>
   username: <User Name>

Menciptakan Rahasia

$ kubectl create –f Secret.yaml
secrets/tomcat-pass

Menggunakan Rahasia

Setelah kami membuat rahasia, itu dapat dikonsumsi di dalam pod atau pengontrol replikasi sebagai -

• Variabel Lingkungan
• Volume

Sebagai Variabel Lingkungan

Untuk menggunakan rahasia sebagai variabel lingkungan, kita akan menggunakan env di bawah bagian spesifikasi file pod yaml.

env:
- name: SECRET_USERNAME
   valueFrom:
      secretKeyRef:
         name: mysecret
         key: tomcat-pass

Sebagai Volume

spec:
   volumes:
      - name: "secretstest"
         secret:
            secretName: tomcat-pass
   containers:
      - image: tomcat:7.0
         name: awebserver
         volumeMounts:
            - mountPath: "/tmp/mysec"
            name: "secretstest"

Konfigurasi Rahasia Sebagai Variabel Lingkungan

apiVersion: v1
kind: ReplicationController
metadata:
   name: appname
spec:
replicas: replica_count
template:
   metadata:
      name: appname
   spec:
      nodeSelector:
         resource-group:
      containers:
         - name: appname
            image:
            imagePullPolicy: Always
            ports:
            - containerPort: 3000
            env: -----------------------------> 1
               - name: ENV
                  valueFrom:
                     configMapKeyRef:
                        name: appname
                        key: tomcat-secrets

Pada kode di atas, di bawah env definisi, kami menggunakan rahasia sebagai variabel lingkungan di pengontrol replikasi.

Rahasia Sebagai Mount Volume

apiVersion: v1
kind: pod
metadata:
   name: appname
spec:
   metadata:
      name: appname
   spec:
   volumes:
      - name: "secretstest"
         secret:
            secretName: tomcat-pass
   containers:
      - image: tomcat: 8.0
         name: awebserver
         volumeMounts:
            - mountPath: "/tmp/mysec"
            name: "secretstest"

Kebijakan Jaringan menentukan cara pod dalam namespace yang sama akan berkomunikasi satu sama lain dan titik akhir jaringan. Itu membutuhkanextensions/v1beta1/networkpoliciesuntuk diaktifkan dalam konfigurasi waktu proses di server API. Sumber dayanya menggunakan label untuk memilih pod dan menetapkan aturan untuk mengizinkan traffic ke pod tertentu selain yang ditentukan di namespace.

Pertama, kita perlu mengkonfigurasi Kebijakan Isolasi Namespace. Pada dasarnya, kebijakan jaringan semacam ini diperlukan pada penyeimbang beban.

kind: Namespace
apiVersion: v1
metadata:
   annotations:
      net.beta.kubernetes.io/network-policy: |
      {
         "ingress": 
         {
            "isolation": "DefaultDeny"
         }
      }

$ kubectl annotate ns <namespace> "net.beta.kubernetes.io/network-policy = 
{\"ingress\": {\"isolation\": \"DefaultDeny\"}}"

Setelah namespace dibuat, kita perlu membuat Kebijakan Jaringan.

Kebijakan Jaringan Yaml

kind: NetworkPolicy
apiVersion: extensions/v1beta1
metadata:
   name: allow-frontend
   namespace: myns
spec:
   podSelector:
      matchLabels:
         role: backend
   ingress:
   - from:
      - podSelector:
         matchLabels:
            role: frontend
   ports:
      - protocol: TCP
         port: 6379

Kubernetes API berfungsi sebagai fondasi untuk skema konfigurasi deklaratif untuk sistem. Kubectlalat baris perintah dapat digunakan untuk membuat, memperbarui, menghapus, dan mendapatkan objek API. Kubernetes API bertindak sebagai komunikator di antara berbagai komponen Kubernetes.

Menambahkan API ke Kubernetes

Menambahkan API baru ke Kubernetes akan menambahkan fitur baru ke Kubernetes, yang akan meningkatkan fungsionalitas Kubernetes. Namun, di samping itu juga akan meningkatkan biaya dan pemeliharaan sistem. Untuk menciptakan keseimbangan antara biaya dan kompleksitas, ada beberapa set yang ditentukan untuknya.

API yang ditambahkan harus berguna bagi lebih dari 50% pengguna. Tidak ada cara lain untuk mengimplementasikan fungsionalitas di Kubernetes. Keadaan luar biasa dibahas dalam pertemuan komunitas Kubernetes, dan kemudian API ditambahkan.

Perubahan API

Untuk meningkatkan kapabilitas Kubernetes, perubahan terus-menerus diperkenalkan ke sistem. Hal ini dilakukan oleh tim Kubernetes untuk menambahkan fungsionalitas ke Kubernetes tanpa menghapus atau memengaruhi fungsionalitas sistem yang ada.

Untuk mendemonstrasikan proses umum, berikut adalah contoh (hipotetis) -

• Seorang pengguna mengeposkan objek Pod ke /api/v7beta1/...

• JSON tidak diatur menjadi v7beta1.Pod struktur

• Nilai default diterapkan ke v7beta1.Pod

• Itu v7beta1.Pod diubah menjadi api.Pod struktur

• Itu api.Pod divalidasi, dan setiap kesalahan dikembalikan ke pengguna

• Itu api.Pod diubah menjadi v6.Pod (karena v6 adalah versi stabil terbaru)

• Itu v6.Pod disusun menjadi JSON dan ditulis ke etcd

Sekarang setelah kita menyimpan objek Pod, pengguna bisa MENDAPATKAN objek itu dalam versi API yang didukung. Misalnya -

• Seorang pengguna MENDAPATKAN Pod dari /api/v5/...

• JSON dibaca etcd dan unmarshalled menjadi v6.Pod struktur

• Nilai default diterapkan ke v6.Pod

• Itu v6.Pod diubah menjadi struktur api.Pod

• Itu api.Pod diubah menjadi v5.Pod struktur

• Itu v5.Pod diatur ke dalam JSON dan dikirim ke pengguna

Implikasi dari proses ini adalah bahwa perubahan API harus dilakukan dengan hati-hati dan kompatibel ke belakang.

Pembuatan Versi API

Untuk mempermudah dalam mendukung banyak struktur, Kubernetes mendukung beberapa versi API, masing-masing di jalur API yang berbeda seperti /api/v1 atau /apsi/extensions/v1beta1

Standar pembuatan versi di Kubernetes didefinisikan dalam beberapa standar.

Tingkat Alfa

• Versi ini mengandung alfa (misalnya v1alpha1)

• Versi ini mungkin bermasalah; versi yang diaktifkan mungkin memiliki bug

• Dukungan untuk bug dapat dihentikan kapan saja.

• Direkomendasikan untuk digunakan dalam pengujian jangka pendek hanya karena dukungan mungkin tidak selalu ada.

Tingkat Beta

• Nama versi mengandung beta (mis. V2beta3)

• Kode sepenuhnya diuji dan versi yang diaktifkan seharusnya stabil.

• Dukungan fitur tidak akan hilang; mungkin ada beberapa perubahan kecil.

• Direkomendasikan hanya untuk penggunaan yang tidak penting bagi bisnis karena potensi perubahan yang tidak kompatibel dalam rilis berikutnya.

Tingkat Stabil

• Nama versinya adalah vX dimana X adalah bilangan bulat.

• Versi fitur yang stabil akan muncul di perangkat lunak yang dirilis untuk banyak versi berikutnya.

Kubectl adalah utilitas baris perintah untuk berinteraksi dengan Kubernetes API. Ini adalah antarmuka yang digunakan untuk berkomunikasi dan mengelola pod di cluster Kubernetes.

Seseorang perlu mengatur kubectl ke lokal untuk berinteraksi dengan cluster Kubernetes.

Mengatur Kubectl

Unduh file yang dapat dieksekusi ke workstation lokal menggunakan perintah curl.

Di Linux

$ curl -O https://storage.googleapis.com/kubernetesrelease/
release/v1.5.2/bin/linux/amd64/kubectl

Di workstation OS X.

$ curl -O https://storage.googleapis.com/kubernetesrelease/
release/v1.5.2/bin/darwin/amd64/kubectl

Setelah pengunduhan selesai, pindahkan biner di jalur sistem.

$ chmod +x kubectl
$ mv kubectl /usr/local/bin/kubectl

Mengonfigurasi Kubectl

Berikut adalah langkah-langkah untuk melakukan operasi konfigurasi.

$ kubectl config set-cluster default-cluster --server = https://${MASTER_HOST} -- certificate-authority = ${CA_CERT}

$ kubectl config set-credentials default-admin --certificateauthority = ${
CA_CERT} --client-key = ${ADMIN_KEY} --clientcertificate = ${
ADMIN_CERT}

$ kubectl config set-context default-system --cluster = default-cluster -- user = default-admin $ kubectl config use-context default-system

• Menggantikan ${MASTER_HOST} dengan alamat atau nama node master yang digunakan pada langkah sebelumnya.

• Menggantikan ${CA_CERT} dengan jalur absolut ke ca.pem dibuat pada langkah sebelumnya.

• Menggantikan ${ADMIN_KEY} dengan jalur absolut ke admin-key.pem dibuat pada langkah sebelumnya.

• Menggantikan ${ADMIN_CERT} dengan jalur absolut ke admin.pem dibuat pada langkah sebelumnya.

Memverifikasi Setup

Untuk memverifikasi apakah kubectl berfungsi dengan baik atau tidak, periksa apakah klien Kubernetes sudah disiapkan dengan benar.

$ kubectl get nodes

NAME       LABELS                                     STATUS
Vipin.com  Kubernetes.io/hostname = vipin.mishra.com    Ready

Kubectlmengontrol Cluster Kubernetes. Ini adalah salah satu komponen kunci Kubernetes yang berjalan di workstation di mesin mana pun saat penyiapan selesai. Ia memiliki kemampuan untuk mengelola node di cluster.

Kubectlperintah digunakan untuk berinteraksi dan mengelola objek Kubernetes dan cluster. Pada bab ini, kita akan membahas beberapa perintah yang digunakan di Kubernetes melalui kubectl.

kubectl annotate - Ini memperbarui anotasi pada sumber daya.

$kubectl annotate [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ...
KEY_N = VAL_N [--resource-version = version]

Sebagai contoh,

kubectl annotate pods tomcat description = 'my frontend'

kubectl api-versions - Ini mencetak versi API yang didukung di cluster.

$ kubectl api-version;

kubectl apply - Memiliki kemampuan untuk mengkonfigurasi sumber daya dengan file atau stdin.

$ kubectl apply –f <filename>

kubectl attach - Ini menempelkan sesuatu ke wadah yang sedang berjalan.

$ kubectl attach <pod> –c <container> $ kubectl attach 123456-7890 -c tomcat-conatiner

kubectl autoscale - Ini digunakan untuk menskalakan pod secara otomatis yang ditentukan seperti Deployment, kumpulan replika, Pengontrol Replikasi.

$ kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min = MINPODS] -- max = MAXPODS [--cpu-percent = CPU] [flags] $ kubectl autoscale deployment foo --min = 2 --max = 10

kubectl cluster-info - Ini menampilkan Info cluster.

$ kubectl cluster-info

kubectl cluster-info dump - Ini membuang informasi yang relevan mengenai cluster untuk debugging dan diagnosis.

$ kubectl cluster-info dump
$ kubectl cluster-info dump --output-directory = /path/to/cluster-state

kubectl config - Mengubah file kubeconfig.

$ kubectl config <SUBCOMMAD>
$ kubectl config –-kubeconfig <String of File name>

kubectl config current-context - Ini menampilkan konteks saat ini.

$ kubectl config current-context
#deploys the current context

kubectl config delete-cluster - Menghapus cluster yang ditentukan dari kubeconfig.

$ kubectl config delete-cluster <Cluster Name>

kubectl config delete-context - Menghapus konteks tertentu dari kubeconfig.

$ kubectl config delete-context <Context Name>

kubectl config get-clusters - Menampilkan cluster yang ditentukan di kubeconfig.

$ kubectl config get-cluster $ kubectl config get-cluster <Cluser Name>

kubectl config get-contexts - Menjelaskan satu atau banyak konteks.

$ kubectl config get-context <Context Name>

kubectl config set-cluster - Mengatur entri cluster di Kubernetes.

$ kubectl config set-cluster NAME [--server = server] [--certificateauthority =
path/to/certificate/authority] [--insecure-skip-tls-verify = true]

kubectl config set-context - Mengatur entri konteks di titik masuk kubernetes.

$ kubectl config set-context NAME [--cluster = cluster_nickname] [-- user = user_nickname] [--namespace = namespace] $ kubectl config set-context prod –user = vipin-mishra

kubectl config set-credentials - Mengatur entri pengguna di kubeconfig.

$ kubectl config set-credentials cluster-admin --username = vipin --
password = uXFGweU9l35qcif

kubectl config set - Menetapkan nilai individu dalam file kubeconfig.

$ kubectl config set PROPERTY_NAME PROPERTY_VALUE

kubectl config unset - Ini membatalkan set komponen tertentu di kubectl.

$ kubectl config unset PROPERTY_NAME PROPERTY_VALUE

kubectl config use-context - Mengatur konteks saat ini dalam file kubectl.

$ kubectl config use-context <Context Name>

kubectl config view

$ kubectl config view $ kubectl config view –o jsonpath='{.users[?(@.name == "e2e")].user.password}'

kubectl cp - Salin file dan direktori ke dan dari kontainer.

$ kubectl cp <Files from source> <Files to Destinatiion> $ kubectl cp /tmp/foo <some-pod>:/tmp/bar -c <specific-container>

kubectl create- Untuk membuat sumber daya dengan nama file atau stdin. Untuk melakukan ini, format JSON atau YAML diterima.

$ kubectl create –f <File Name> $ cat <file name> | kubectl create –f -

Dengan cara yang sama, kita dapat membuat banyak hal seperti yang terdaftar menggunakan create perintah bersama kubectl.

• deployment
• namespace
• quota
• buruh pelabuhan rahasia
• secret
• generik rahasia
• tls rahasia
• serviceaccount
• clusterip layanan
• layanan loadbalancer
• layanan nodeport

kubectl delete - Menghapus sumber daya dengan nama file, stdin, sumber daya dan nama.

$ kubectl delete –f ([-f FILENAME] | TYPE [(NAME | -l label | --all)])

kubectl describe- Menjelaskan sumber daya tertentu di kubernetes. Menunjukkan detail sumber daya atau sekelompok sumber daya.

$ kubectl describe <type> <type name>
$ kubectl describe pod tomcat

kubectl drain- Ini digunakan untuk mengeringkan node untuk tujuan pemeliharaan. Ini mempersiapkan node untuk pemeliharaan. Ini akan menandai node sebagai tidak tersedia sehingga tidak boleh ditugaskan dengan penampung baru yang akan dibuat.

$ kubectl drain tomcat –force

kubectl edit- Ini digunakan untuk mengakhiri sumber daya di server. Hal ini memungkinkan untuk langsung mengedit sumber daya yang dapat diterima melalui alat baris perintah.

$ kubectl edit <Resource/Name | File Name) Ex. $ kubectl edit rc/tomcat

kubectl exec - Ini membantu untuk menjalankan perintah dalam wadah.

$ kubectl exec POD <-c CONTAINER > -- COMMAND < args...> $ kubectl exec tomcat 123-5-456 date

kubectl expose- Ini digunakan untuk mengekspos objek Kubernetes seperti pod, pengontrol replikasi, dan layanan sebagai layanan Kubernetes baru. Ini memiliki kemampuan untuk mengeksposnya melalui wadah yang sedang berjalan atau dari ayaml mengajukan.

$ kubectl expose (-f FILENAME | TYPE NAME) [--port=port] [--protocol = TCP|UDP] [--target-port = number-or-name] [--name = name] [--external-ip = external-ip-ofservice] [--type = type] $ kubectl expose rc tomcat –-port=80 –target-port = 30000
$ kubectl expose –f tomcat.yaml –port = 80 –target-port =

kubectl get - Perintah ini mampu mengambil data di cluster tentang resource Kubernetes.

$ kubectl get [(-o|--output=)json|yaml|wide|custom-columns=...|custom-columnsfile=...|
go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...]
(TYPE [NAME | -l label] | TYPE/NAME ...) [flags]

Sebagai contoh,

$ kubectl get pod <pod name> $ kubectl get service <Service name>

kubectl logs- Mereka digunakan untuk mendapatkan log dari container di dalam pod. Mencetak log dapat menentukan nama kontainer di dalam pod. Jika POD hanya memiliki satu wadah, tidak perlu menentukan namanya.

$ kubectl logs [-f] [-p] POD [-c CONTAINER] Example $ kubectl logs tomcat.
$ kubectl logs –p –c tomcat.8

kubectl port-forward - Mereka digunakan untuk meneruskan satu atau lebih port lokal ke pod.

$ kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT
[...[LOCAL_PORT_N:]REMOTE_PORT_N]
$ kubectl port-forward tomcat 3000 4000 $ kubectl port-forward tomcat 3000:5000

kubectl replace - Mampu mengganti sumber daya dengan nama file atau stdin.

$ kubectl replace -f FILENAME $ kubectl replace –f tomcat.yml
$ cat tomcat.yml | kubectl replace –f -

kubectl rolling-update- Melakukan pembaruan berkelanjutan pada pengontrol replikasi. Mengganti pengontrol replikasi yang ditentukan dengan pengontrol replikasi baru dengan memperbarui POD dalam satu waktu.

$ kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --
image = NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC)
$ kubectl rolling-update frontend-v1 –f freontend-v2.yaml

kubectl rollout - Mampu mengelola peluncuran penerapan.

$ Kubectl rollout <Sub Command>
$ kubectl rollout undo deployment/tomcat

Selain yang di atas, kami dapat melakukan banyak tugas menggunakan peluncuran seperti -

• riwayat peluncuran
• peluncuran jeda
• peluncuran resume
• status peluncuran
• peluncuran urungkan

kubectl run - Perintah Run memiliki kemampuan untuk menjalankan image di cluster Kubernetes.

$ kubectl run NAME --image = image [--env = "key = value"] [--port = port] [--
replicas = replicas] [--dry-run = bool] [--overrides = inline-json] [--command] --
[COMMAND] [args...]
$ kubectl run tomcat --image = tomcat:7.0 $ kubectl run tomcat –-image = tomcat:7.0 –port = 5000

kubectl scale - Ini akan menskalakan ukuran Kubernetes Deployments, ReplicaSet, Replikasi Controller, atau pekerjaan.

$ kubectl scale [--resource-version = version] [--current-replicas = count] -- replicas = COUNT (-f FILENAME | TYPE NAME ) $ kubectl scale –-replica = 3 rs/tomcat
$ kubectl scale –replica = 3 tomcat.yaml

kubectl set image - Ini memperbarui gambar templat pod.

$ kubectl set image (-f FILENAME | TYPE NAME)
CONTAINER_NAME_1 = CONTAINER_IMAGE_1 ... CONTAINER_NAME_N = CONTAINER_IMAGE_N
$ kubectl set image deployment/tomcat busybox = busybox ngnix = ngnix:1.9.1 $ kubectl set image deployments, rc tomcat = tomcat6.0 --all

kubectl set resources- Digunakan untuk mengatur konten sumber daya. Ini memperbarui sumber daya / batas pada objek dengan templat pod.

$ kubectl set resources (-f FILENAME | TYPE NAME) ([--limits = LIMITS & -- requests = REQUESTS] $ kubectl set resources deployment tomcat -c = tomcat --
limits = cpu = 200m,memory = 512Mi

kubectl top node- Ini menampilkan penggunaan CPU / Memori / Penyimpanan. Perintah atas memungkinkan Anda melihat konsumsi sumber daya untuk node.

$ kubectl top node [node Name]

Perintah yang sama juga dapat digunakan dengan pod.

Untuk membuat aplikasi untuk penerapan Kubernetes, pertama-tama kita perlu membuat aplikasi di Docker. Ini dapat dilakukan dengan dua cara -

• Dengan mengunduh
• Dari file Docker

Dengan Mengunduh

Image yang ada dapat diunduh dari hub Docker dan dapat disimpan di registri Docker lokal.

Untuk melakukan itu, jalankan Docker pull perintah.

$ docker pull --help
Usage: docker pull [OPTIONS] NAME[:TAG|@DIGEST]
Pull an image or a repository from the registry
   -a, --all-tags = false     Download all tagged images in the repository
   --help = false             Print usage

Berikut akan menjadi output dari kode di atas.

Tangkapan layar di atas menunjukkan serangkaian gambar yang disimpan di registri Docker lokal kami.

Jika kita ingin membangun container dari image yang terdiri dari aplikasi yang akan diuji, kita bisa melakukannya dengan menggunakan perintah run Docker.

$ docker run –i –t unbunt /bin/bash

Dari File Docker

Untuk membuat aplikasi dari file Docker, kita perlu membuat file Docker terlebih dahulu.

Berikut adalah contoh file Jenkins Docker.

FROM ubuntu:14.04
MAINTAINER [email protected]
ENV REFRESHED_AT 2017-01-15
RUN apt-get update -qq && apt-get install -qqy curl
RUN curl https://get.docker.io/gpg | apt-key add -
RUN echo deb http://get.docker.io/ubuntu docker main > /etc/apt/↩
sources.list.d/docker.list
RUN apt-get update -qq && apt-get install -qqy iptables ca-↩
certificates lxc openjdk-6-jdk git-core lxc-docker
ENV JENKINS_HOME /opt/jenkins/data
ENV JENKINS_MIRROR http://mirrors.jenkins-ci.org
RUN mkdir -p $JENKINS_HOME/plugins
RUN curl -sf -o /opt/jenkins/jenkins.war -L $JENKINS_MIRROR/war-↩ stable/latest/jenkins.war RUN for plugin in chucknorris greenballs scm-api git-client git ↩ ws-cleanup ;\ do curl -sf -o $JENKINS_HOME/plugins/${plugin}.hpi \ -L $JENKINS_MIRROR/plugins/${plugin}/latest/${plugin}.hpi ↩
; done
ADD ./dockerjenkins.sh /usr/local/bin/dockerjenkins.sh
RUN chmod +x /usr/local/bin/dockerjenkins.sh
VOLUME /var/lib/docker
EXPOSE 8080
ENTRYPOINT [ "/usr/local/bin/dockerjenkins.sh" ]

Setelah file di atas dibuat, simpan dengan nama Dockerfile dan cd ke path file. Kemudian, jalankan perintah berikut.

$ sudo docker build -t jamtur01/Jenkins .

Setelah gambar dibuat, kami dapat menguji apakah gambar berfungsi dengan baik dan dapat diubah ke wadah.

$ docker run –i –t jamtur01/Jenkins /bin/bash

Deployment adalah metode untuk mengonversi gambar ke container dan kemudian mengalokasikan gambar tersebut ke pod di cluster Kubernetes. Ini juga membantu dalam menyiapkan cluster aplikasi yang mencakup penerapan layanan, pod, pengontrol replikasi, dan kumpulan replika. Kluster dapat diatur sedemikian rupa sehingga aplikasi yang di-deploy di pod dapat saling berkomunikasi.

Dalam penyiapan ini, kita dapat memiliki setelan penyeimbang beban di atas satu aplikasi yang mengalihkan lalu lintas ke sekumpulan pod dan kemudian mereka berkomunikasi ke pod backend. Komunikasi antar pod terjadi melalui objek layanan yang dibangun di Kubernetes.

File Yaml Load Balancer Ngnix

apiVersion: v1
kind: Service
metadata:
   name: oppv-dev-nginx
      labels:
         k8s-app: omni-ppv-api
spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: omninginx
   selector:
      k8s-app: appname
      component: nginx
      env: dev

Yaml Pengontrol Replikasi Ngnix

apiVersion: v1
kind: ReplicationController
metadata:
   name: appname
spec:
   replicas: replica_count
   template:
      metadata:
         name: appname
         labels:
            k8s-app: appname
            component: nginx
               env: env_name
spec:
   nodeSelector:
      resource-group: oppv
   containers:
      - name: appname
      image: IMAGE_TEMPLATE
      imagePullPolicy: Always
      ports:
         - containerPort: 8080
         resources:
            requests:
               memory: "request_mem"
               cpu: "request_cpu"
            limits:
               memory: "limit_mem"
               cpu: "limit_cpu"
            env:
            - name: BACKEND_HOST
               value: oppv-env_name-node:3000

File Yaml Layanan Frontend

apiVersion: v1
kind: Service
metadata:
   name: appname
   labels:
      k8s-app: appname
spec:
   type: NodePort
   ports:
   - name: http
      port: 3000
      protocol: TCP
      targetPort: 3000
   selector:
      k8s-app: appname
      component: nodejs
      env: dev

File Yaml Pengontrol Replikasi Bagian Depan

apiVersion: v1
kind: ReplicationController
metadata:
   name: Frontend
spec:
   replicas: 3
   template:
      metadata:
         name: frontend
         labels:
            k8s-app: Frontend
            component: nodejs
            env: Dev
spec:
   nodeSelector:
      resource-group: oppv
   containers:
      - name: appname
         image: IMAGE_TEMPLATE
         imagePullPolicy: Always
         ports:
            - containerPort: 3000
            resources:
               requests:
                  memory: "request_mem"
                  cpu: "limit_cpu"
                  limits:
                  memory: "limit_mem"
                  cpu: "limit_cpu"
            env:
               - name: ENV
               valueFrom:
               configMapKeyRef:
               name: appname
               key: config-env

File Yaml Layanan Backend

apiVersion: v1
kind: Service
metadata:
   name: backend
   labels:
      k8s-app: backend
spec:
   type: NodePort
   ports:
   - name: http
      port: 9010
      protocol: TCP
      targetPort: 9000
   selector:
      k8s-app: appname
      component: play
      env: dev

File Yaml Pengontrol Replikasi yang Didukung

apiVersion: v1
kind: ReplicationController
metadata:
   name: backend
spec:
   replicas: 3
   template:
      metadata:
         name: backend
      labels:
         k8s-app: beckend
         component: play
         env: dev
spec:
   nodeSelector:
      resource-group: oppv
      containers:
         - name: appname
            image: IMAGE_TEMPLATE
            imagePullPolicy: Always
            ports:
            - containerPort: 9000
            command: [ "./docker-entrypoint.sh" ]
            resources:
               requests:
                  memory: "request_mem"
                  cpu: "request_cpu"
               limits:
                  memory: "limit_mem"
                  cpu: "limit_cpu"
            volumeMounts:
               - name: config-volume
               mountPath: /app/vipin/play/conf
         volumes:
            - name: config-volume
            configMap:
            name: appname

Autoscalingadalah salah satu fitur utama dalam cluster Kubernetes. Ini adalah fitur di mana cluster mampu meningkatkan jumlah node karena permintaan untuk respons layanan meningkat dan mengurangi jumlah node saat kebutuhan menurun. Fitur penskalaan otomatis ini sekarang didukung di Google Cloud Engine (GCE) dan Google Container Engine (GKE) dan akan segera dimulai dengan AWS.

Untuk menyiapkan infrastruktur skalabel di GCE, pertama-tama kita harus memiliki project GCE aktif dengan fitur pemantauan cloud Google, logging cloud google, dan stackdriver aktif.

Pertama, kita akan menyiapkan cluster dengan beberapa node yang berjalan di dalamnya. Setelah selesai, kita perlu menyiapkan variabel lingkungan berikut.

Variabel Lingkungan

export NUM_NODES = 2
export KUBE_AUTOSCALER_MIN_NODES = 2
export KUBE_AUTOSCALER_MAX_NODES = 5
export KUBE_ENABLE_CLUSTER_AUTOSCALER = true

Setelah selesai, kita akan memulai cluster dengan menjalankan kube-up.sh. Ini akan membuat cluster bersama dengan cluster auto-scalar add on.

./cluster/kube-up.sh

Saat membuat cluster, kita dapat memeriksa cluster kita menggunakan perintah kubectl berikut.

$ kubectl get nodes
NAME                             STATUS                       AGE
kubernetes-master                Ready,SchedulingDisabled     10m
kubernetes-minion-group-de5q     Ready                        10m
kubernetes-minion-group-yhdx     Ready                        8m

Sekarang, kita dapat menerapkan aplikasi pada cluster lalu mengaktifkan autoscaler pod horizontal. Ini dapat dilakukan dengan menggunakan perintah berikut.

$ kubectl autoscale deployment <Application Name> --cpu-percent = 50 --min = 1 --
max = 10

Perintah di atas menunjukkan bahwa kami akan mempertahankan setidaknya satu dan maksimum 10 replika POD saat beban aplikasi meningkat.

Kami dapat memeriksa status penskala otomatis dengan menjalankan $kubclt get hpaperintah. Kami akan meningkatkan beban pada pod menggunakan perintah berikut.

$ kubectl run -i --tty load-generator --image = busybox /bin/sh
$ while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done

Kami dapat memeriksa hpa dengan berlari $ kubectl get hpa perintah.

$ kubectl get hpa NAME REFERENCE TARGET CURRENT php-apache Deployment/php-apache/scale 50% 310% MINPODS MAXPODS AGE 1 20 2m $ kubectl get deployment php-apache
NAME         DESIRED    CURRENT    UP-TO-DATE    AVAILABLE   AGE
php-apache      7          7           7            3        4m

Kami dapat memeriksa jumlah pod yang berjalan menggunakan perintah berikut.

jsz@jsz-desk2:~/k8s-src$ kubectl get pods
php-apache-2046965998-3ewo6 0/1        Pending 0         1m
php-apache-2046965998-8m03k 1/1        Running 0         1m
php-apache-2046965998-ddpgp 1/1        Running 0         5m
php-apache-2046965998-lrik6 1/1        Running 0         1m
php-apache-2046965998-nj465 0/1        Pending 0         1m
php-apache-2046965998-tmwg1 1/1        Running 0         1m
php-apache-2046965998-xkbw1 0/1        Pending 0         1m

Dan terakhir, kita bisa mendapatkan status node.

$ kubectl get nodes
NAME                             STATUS                        AGE
kubernetes-master                Ready,SchedulingDisabled      9m
kubernetes-minion-group-6z5i     Ready                         43s
kubernetes-minion-group-de5q     Ready                         9m
kubernetes-minion-group-yhdx     Ready                         9m

Menyiapkan dasbor Kubernetes melibatkan beberapa langkah dengan seperangkat alat yang diperlukan sebagai prasyarat untuk menyiapkannya.

• Docker (1.3+)
• pergi (1.5+)
• nodejs (4.2.2+)
• npm (1,3+)
• java (7+)
• teguk (3,9+)
• Kubernetes (1.1.2+)

Menyiapkan Dasbor

$ sudo apt-get update && sudo apt-get upgrade Installing Python $ sudo apt-get install python
$ sudo apt-get install python3 Installing GCC $ sudo apt-get install gcc-4.8 g++-4.8

Installing make
$ sudo apt-get install make Installing Java $ sudo apt-get install openjdk-7-jdk

Installing Node.js
$ wget https://nodejs.org/dist/v4.2.2/node-v4.2.2.tar.gz $ tar -xzf node-v4.2.2.tar.gz
$ cd node-v4.2.2 $ ./configure
$ make $ sudo make install

Installing gulp
$ npm install -g gulp $ npm install gulp

Memverifikasi Versi

Java Version
$ java –version java version "1.7.0_91" OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-1~deb8u1+rpi1) OpenJDK Zero VM (build 24.91-b01, mixed mode) $ node –v
V4.2.2

$ npn -v 2.14.7 $ gulp -v
[09:51:28] CLI version 3.9.0

$ sudo gcc --version
gcc (Raspbian 4.8.4-1) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc. This is free software; 
see the source for copying conditions. There is NO warranty; not even for 
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Menginstal GO

$ git clone https://go.googlesource.com/go
$ cd go $ git checkout go1.4.3
$ cd src Building GO $ ./all.bash
$ vi /root/.bashrc In the .bashrc export GOROOT = $HOME/go
   export PATH = $PATH:$GOROOT/bin
   
$ go version
go version go1.4.3 linux/arm

Menginstal Dasbor Kubernetes

$ git clone https://github.com/kubernetes/dashboard.git
$ cd dashboard $ npm install -g bower

Menjalankan Dashboard

$ git clone https://github.com/kubernetes/dashboard.git $ cd dashboard
$ npm install -g bower $ gulp serve
[11:19:12] Requiring external module babel-core/register
[11:20:50] Using gulpfile ~/dashboard/gulpfile.babel.js
[11:20:50] Starting 'package-backend-source'...
[11:20:50] Starting 'kill-backend'...
[11:20:50] Finished 'kill-backend' after 1.39 ms
[11:20:50] Starting 'scripts'...
[11:20:53] Starting 'styles'...
[11:21:41] Finished 'scripts' after 50 s
[11:21:42] Finished 'package-backend-source' after 52 s
[11:21:42] Starting 'backend'...
[11:21:43] Finished 'styles' after 49 s
[11:21:43] Starting 'index'...
[11:21:44] Finished 'index' after 1.43 s
[11:21:44] Starting 'watch'...
[11:21:45] Finished 'watch' after 1.41 s
[11:23:27] Finished 'backend' after 1.73 min
[11:23:27] Starting 'spawn-backend'...
[11:23:27] Finished 'spawn-backend' after 88 ms
[11:23:27] Starting 'serve'...
2016/02/01 11:23:27 Starting HTTP server on port 9091
2016/02/01 11:23:27 Creating API client for
2016/02/01 11:23:27 Creating Heapster REST client for http://localhost:8082
[11:23:27] Finished 'serve' after 312 ms
[BS] [BrowserSync SPA] Running...
[BS] Access URLs:
--------------------------------------
Local: http://localhost:9090/
External: http://192.168.1.21:9090/
--------------------------------------
UI: http://localhost:3001
UI External: http://192.168.1.21:3001
--------------------------------------
[BS] Serving files from: /root/dashboard/.tmp/serve
[BS] Serving files from: /root/dashboard/src/app/frontend
[BS] Serving files from: /root/dashboard/src/app

Dasbor Kubernetes

Pemantauan adalah salah satu komponen kunci untuk mengelola cluster besar. Untuk ini, kami memiliki sejumlah alat.

Pemantauan dengan Prometheus

Ini adalah sistem pemantauan dan peringatan. Itu dibangun di SoundCloud dan bersumber terbuka pada tahun 2012. Ini menangani data multi-dimensi dengan sangat baik.

Prometheus memiliki banyak komponen untuk berpartisipasi dalam pemantauan -

• Prometheus - Ini adalah komponen inti yang membuang dan menyimpan data.

• Prometheus node explore - Mendapatkan matriks level host dan memaparkannya ke Prometheus.

• Ranch-eye - adalah sebuah haproxy dan mengekspos cAdvisor statistik untuk Prometheus.

• Grafana - Visualisasi data.

• InfuxDB - Database time series khusus digunakan untuk menyimpan data dari peternak.

• Prom-ranch-exporter - Ini adalah aplikasi node.js sederhana, yang membantu dalam menanyakan server Rancher untuk status tumpukan layanan.

Agen Docker Sematext

Ini adalah metrik, peristiwa, dan agen pengumpulan log yang sadar-Docker modern. Ini berjalan sebagai wadah kecil di setiap host Docker dan mengumpulkan log, metrik, dan acara untuk semua node cluster dan kontainer. Ia menemukan semua container (satu pod mungkin berisi beberapa container) termasuk container untuk layanan inti Kubernetes, jika layanan inti di-deploy di container Docker. Setelah penerapannya, semua log dan metrik segera tersedia di luar kotak.

Menerapkan Agen ke Node

Kubernetes menyediakan DeamonSets yang memastikan pod ditambahkan ke cluster.

Mengonfigurasi Agen Docker SemaText

Ini dikonfigurasi melalui variabel lingkungan.

• Dapatkan akun gratis di apps.sematext.com , jika Anda belum memilikinya.

• Buat Aplikasi SPM jenis "Docker" untuk mendapatkan Token Aplikasi SPM. Aplikasi SPM akan menyimpan metrik dan acara kinerja Kubernetes Anda.

• Buat Aplikasi Logsene untuk mendapatkan Token Aplikasi Logsene. Aplikasi Logsene akan menyimpan log Kubernetes Anda.

• Edit nilai LOGSENE_TOKEN dan SPM_TOKEN dalam definisi DaemonSet seperti yang ditunjukkan di bawah ini.

• Dapatkan templat sematext-agent-daemonset.yml (teks biasa mentah) terbaru (juga ditampilkan di bawah).

• Simpan di suatu tempat di disk.

• Ganti placeholder SPM_TOKEN dan LOGSENE_TOKEN dengan token SPM dan Aplikasi Logsene Anda.

Buat Objek DaemonSet

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
   name: sematext-agent
spec:
   template:
      metadata:
         labels:
            app: sematext-agent
      spec:
         selector: {}
         dnsPolicy: "ClusterFirst"
         restartPolicy: "Always"
         containers:
         - name: sematext-agent
            image: sematext/sematext-agent-docker:latest
            imagePullPolicy: "Always"
            env:
            - name: SPM_TOKEN
               value: "REPLACE THIS WITH YOUR SPM TOKEN"
            - name: LOGSENE_TOKEN
               value: "REPLACE THIS WITH YOUR LOGSENE TOKEN"
            - name: KUBERNETES
               value: "1"
            volumeMounts:
               - mountPath: /var/run/docker.sock
                  name: docker-sock
               - mountPath: /etc/localtime
                  name: localtime
            volumes:
               - name: docker-sock
                  hostPath:
                     path: /var/run/docker.sock
               - name: localtime
                  hostPath:
                     path: /etc/localtime

Menjalankan Sematext Agent Docker dengan kubectl

$ kubectl create -f sematext-agent-daemonset.yml
daemonset "sematext-agent-daemonset" created

Kubernetes Log

Log kontainer Kubernetes tidak jauh berbeda dengan log kontainer Docker. Namun, pengguna Kubernetes perlu melihat log untuk pod yang di-deploy. Oleh karena itu, sangat berguna untuk menyediakan informasi khusus Kubernetes untuk pencarian log, seperti -

• Namespace Kubernetes
• Nama pod Kubernetes
• Nama container Kubernetes
• Nama gambar Docker
• Kubernetes UID

Menggunakan ELK Stack dan LogSpout

Tumpukan ELK termasuk Elasticsearch, Logstash, dan Kibana. Untuk mengumpulkan dan meneruskan log ke platform logging, kami akan menggunakan LogSpout (meskipun ada opsi lain seperti FluentD).

Kode berikut menunjukkan bagaimana menyiapkan ELK cluster di Kubernetes dan membuat layanan untuk ElasticSearch -

apiVersion: v1
kind: Service
metadata:
   name: elasticsearch
   namespace: elk
   labels:
      component: elasticsearch
spec:
   type: LoadBalancer
   selector:
      component: elasticsearch
   ports:
   - name: http
      port: 9200
      protocol: TCP
   - name: transport
      port: 9300
      protocol: TCP

Membuat Pengontrol Replikasi

apiVersion: v1
kind: ReplicationController
metadata:
   name: es
   namespace: elk
   labels:
      component: elasticsearch
spec:
   replicas: 1
   template:
      metadata:
         labels:
            component: elasticsearch
spec:
serviceAccount: elasticsearch
containers:
   - name: es
      securityContext:
      capabilities:
      add:
      - IPC_LOCK
   image: quay.io/pires/docker-elasticsearch-kubernetes:1.7.1-4
   env:
   - name: KUBERNETES_CA_CERTIFICATE_FILE
   value: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
   - name: NAMESPACE
   valueFrom:
      fieldRef:
         fieldPath: metadata.namespace
   - name: "CLUSTER_NAME"
      value: "myesdb"
   - name: "DISCOVERY_SERVICE"
      value: "elasticsearch"
   - name: NODE_MASTER
      value: "true"
   - name: NODE_DATA
      value: "true"
   - name: HTTP_ENABLE
      value: "true"
ports:
- containerPort: 9200
   name: http
   protocol: TCP
- containerPort: 9300
volumeMounts:
- mountPath: /data
   name: storage
volumes:
   - name: storage
      emptyDir: {}

URL Kibana

Untuk Kibana, kami menyediakan URL Elasticsearch sebagai variabel lingkungan.

- name: KIBANA_ES_URL
value: "http://elasticsearch.elk.svc.cluster.local:9200"
- name: KUBERNETES_TRUST_CERT
value: "true"

Kibana UI akan dapat dijangkau di port kontainer 5601 dan kombinasi host / Node Port yang sesuai. Saat Anda mulai, tidak akan ada data apa pun di Kibana (yang diharapkan karena Anda belum memasukkan data apa pun).