Saat Anda mulai membuat lebih banyak layanan Kubernetes, tugas-tugas yang awalnya sederhana mulai menjadi lebih kompleks. Misalnya, tim pengembangan tidak dapat membuat layanan atau penerapan dengan nama yang sama. Jika Anda memiliki ribuan pod, membuat daftarnya akan memakan banyak waktu, apalagi mengelolanya dengan benar. Dan ini hanyalah puncak gunung es.
Mari kita lihat bagaimana namespace mempermudah pengelolaan sumber daya Kubernetes. Jadi apa itu namespace? Namespace dapat dianggap sebagai klaster virtual di dalam klaster Kubernetes Anda. Anda dapat mengisolasi beberapa namespace satu sama lain dalam satu cluster Kubernetes. Mereka benar-benar dapat membantu Anda dan tim Anda dalam hal organisasi, keamanan, dan bahkan kinerja sistem.
Pada sebagian besar distribusi Kubernetes, cluster hadir dengan namespace yang disebut "default". Sebenarnya ada tiga namespace yang ditangani Kubernetes: default, kube-system, dan kube-public. Saat ini Kube-publik jarang digunakan.
Membiarkan namespace kube saja adalah ide bagus, terutama pada sistem terkelola seperti Google Kubernetes Engine. Ia menggunakan namespace "default" sebagai tempat di mana layanan dan aplikasi Anda dibuat. Sama sekali tidak ada yang istimewa tentangnya, kecuali Kubernetes sudah dikonfigurasikan untuk menggunakannya, dan Anda tidak dapat menghapusnya. Ini bagus untuk memulai dan sistem berkinerja rendah, tetapi saya tidak akan merekomendasikan penggunaan namespace default pada sistem produk besar. Dalam kasus terakhir, satu tim pengembangan dapat dengan mudah menulis ulang kode orang lain dan merusak pekerjaan tim lain tanpa menyadarinya.
Oleh karena itu, Anda harus membuat beberapa namespace dan menggunakannya untuk mengelompokkan layanan Anda menjadi unit yang dapat dikelola. Namespace dapat dibuat dengan satu perintah. Jika Anda ingin membuat namespace bernama test, gunakan perintah $ kubectl create namespace test atau cukup buat file YAML dan gunakan seperti resource Kubernetes lainnya.
Anda dapat melihat semua namespace menggunakan perintah $ kubectl get namespace.
Setelah selesai, Anda akan melihat tiga namespace bawaan dan namespace baru yang disebut "test". Mari kita lihat file YAML sederhana untuk membuat pod. Anda akan melihat bahwa tidak ada penyebutan namespace.
Jika Anda menggunakan kubectl untuk menjalankan file ini, modul mypod akan dibuat di namespace yang sedang aktif. Ini akan menjadi namespace default sampai Anda mengubahnya. Ada 2 cara untuk memberi tahu Kubernetes di namespace mana Anda ingin membuat sumber daya. Cara pertama adalah dengan menggunakan tanda namespace saat membuat sumber daya.
Cara kedua adalah dengan menentukan namespace dalam deklarasi YAML.
Jika Anda menentukan namespace di YAML, sumber daya akan selalu dibuat di namespace tersebut. Jika Anda mencoba menggunakan namespace berbeda saat menggunakan flag namespace, perintah akan gagal. Sekarang jika Anda mencoba menemukan pod Anda, Anda tidak akan dapat melakukannya.
Hal ini terjadi karena semua perintah dijalankan di luar namespace yang sedang aktif. Untuk menemukan pod Anda, Anda perlu menggunakan flag namespace, tetapi ini akan cepat membosankan, terutama jika Anda seorang pengembang di tim yang menggunakan namespacenya sendiri dan tidak ingin menggunakan flag tersebut untuk setiap perintah. Mari kita lihat bagaimana kita dapat memperbaikinya.
Di luar kotak, namespace aktif Anda disebut default. Jika Anda tidak menentukan namespace di YAML sumber daya, maka semua perintah Kubernetes akan menggunakan namespace default aktif ini. Sayangnya, mencoba mengelola namespace aktif menggunakan kubectl bisa gagal. Namun, ada alat bagus bernama Kubens yang membuat proses ini lebih mudah. Saat Anda menjalankan perintah kubens, Anda akan melihat semua namespace dengan namespace aktif yang disorot.
Untuk mengalihkan namespace aktif ke namespace pengujian, cukup jalankan perintah $kubens test. Jika Anda kemudian menjalankan perintah $kubens lagi, Anda akan melihat bahwa namespace aktif baru sekarang dialokasikan - test.
Ini berarti Anda tidak memerlukan flag namespace untuk melihat pod di namespace pengujian.
Dengan cara ini namespace disembunyikan satu sama lain, namun tidak terisolasi satu sama lain. Sebuah layanan di satu namespace dapat berkomunikasi dengan mudah dengan layanan di namespace lain, yang seringkali sangat berguna. Kemampuan untuk berkomunikasi di namespace yang berbeda berarti layanan pengembang Anda dapat berkomunikasi dengan layanan tim pengembang lain di namespace yang berbeda.
Biasanya, ketika aplikasi Anda ingin mengakses layanan Kubernetes, Anda menggunakan layanan penemuan DNS bawaan dan cukup memberi nama layanan tersebut pada aplikasi Anda. Namun, dengan melakukan hal tersebut, Anda dapat membuat layanan dengan nama yang sama di beberapa namespace, hal ini tidak dapat diterima.
Untungnya, hal ini mudah diatasi dengan menggunakan bentuk alamat DNS yang diperluas. Layanan di Kubernetes mengekspos titik akhirnya menggunakan templat DNS umum. Ini terlihat seperti ini:
Biasanya, Anda hanya memerlukan nama layanan dan DNS akan secara otomatis menentukan alamat lengkapnya.
Namun, jika Anda perlu mengakses layanan dalam namespace yang berbeda, cukup gunakan nama layanan ditambah nama namespace:
Misalnya, jika Anda ingin menyambungkan ke database layanan di namespace pengujian, Anda dapat menggunakan database alamat database.test
Jika Anda ingin menyambung ke database layanan di namespace prod, Anda menggunakan database.prod.
Jika Anda benar-benar ingin mengisolasi dan membatasi akses namespace, Kubernetes mengizinkan Anda melakukan ini menggunakan Kebijakan Jaringan Kubernetes. Saya akan membicarakan hal ini di episode berikutnya.
Saya sering mendapat pertanyaan, berapa banyak namespace yang harus saya buat dan untuk tujuan apa? Apa yang dimaksud dengan data yang dikelola?
Jika Anda membuat terlalu banyak namespace, hal tersebut hanya akan menghalangi Anda. Jika jumlahnya terlalu sedikit, Anda akan kehilangan semua manfaat dari solusi tersebut. Menurut saya ada empat tahapan utama yang dilalui setiap perusahaan saat membuat struktur organisasinya. Bergantung pada tahap pengembangan proyek atau perusahaan Anda, Anda mungkin ingin mengadopsi strategi namespace yang sesuai.
Bayangkan Anda adalah bagian dari tim kecil yang berupaya mengembangkan 5-10 layanan mikro dan Anda dapat dengan mudah mengumpulkan semua pengembang dalam satu ruangan. Dalam situasi ini, masuk akal untuk menjalankan semua layanan prod di namespace default. Tentu saja, untuk fleksibilitas lebih, Anda dapat menggunakan 2 namespace - secara terpisah untuk prod dan dev. Dan kemungkinan besar, Anda menguji pengembangan Anda di komputer lokal menggunakan sesuatu seperti Minikube.
Katakanlah segalanya berubah dan Anda kini memiliki tim yang berkembang pesat yang mengerjakan lebih dari 10 layanan mikro sekaligus. Ada saatnya perlu menggunakan beberapa cluster atau namespace, secara terpisah untuk prod dan dev. Anda dapat membagi tim menjadi beberapa subtim sehingga masing-masing subtim memiliki layanan mikro sendiri dan masing-masing tim dapat memilih namespacenya sendiri untuk memfasilitasi proses pengelolaan pengembangan dan rilis perangkat lunak.
Ketika setiap anggota tim memperoleh wawasan tentang cara kerja sistem secara keseluruhan, semakin sulit untuk mengoordinasikan setiap perubahan dengan pengembang lainnya. Mencoba membuat tumpukan penuh di mesin lokal Anda semakin sulit setiap hari.
Di perusahaan besar, pengembang umumnya tidak mengetahui siapa sebenarnya yang mengerjakan apa. Tim berkomunikasi menggunakan kontrak layanan atau menggunakan teknologi mesh layanan, yang menambahkan lapisan abstraksi melalui jaringan, seperti alat konfigurasi Istio. Mencoba menjalankan seluruh tumpukan secara lokal tidak mungkin dilakukan. Saya sangat merekomendasikan menggunakan platform pengiriman berkelanjutan (CD) seperti Spinnaker di Kubernetes. Jadi, ada saatnya di mana setiap perintah pasti membutuhkan namespacenya sendiri. Setiap tim bahkan dapat memilih beberapa namespace untuk lingkungan pengembang dan lingkungan produksi.
Terakhir, ada perusahaan wirausaha besar yang salah satu kelompok pengembangnya bahkan tidak mengetahui keberadaan kelompok pengembang lainnya. Perusahaan semacam itu umumnya mempekerjakan pengembang pihak ketiga yang berinteraksi dengannya melalui API yang terdokumentasi dengan baik. Setiap grup tersebut berisi beberapa tim dan beberapa layanan mikro. Dalam hal ini, Anda perlu menggunakan semua alat yang saya bicarakan sebelumnya.
Pemrogram tidak boleh menyebarkan layanan secara manual dan tidak boleh memiliki akses ke namespace yang bukan urusan mereka. Pada tahap ini, disarankan untuk memiliki beberapa cluster untuk mengurangi βradius ledakanβ aplikasi yang dikonfigurasi dengan buruk, untuk menyederhanakan proses penagihan dan manajemen sumber daya.
Oleh karena itu, penggunaan namespace yang tepat oleh organisasi Anda memungkinkan Anda membuat Kubernetes lebih mudah dikelola, dikontrol, aman, dan fleksibel.
Beberapa iklan π
Terima kasih untuk tetap bersama kami. Apakah Anda menyukai artikel kami? Ingin melihat konten yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman, , analog unik dari server level awal, yang kami temukan untuk Anda: (tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2x lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai $99! Membaca tentang
Sumber: www.habr.com