Praktik terbaik Kubernetes. Organisasi Kubernet dengan namespace

Praktik terbaik Kubernetes. Membuat Kontainer Kecil

Saat Anda mulai membuat lebih banyak layanan Kubernetes, tugas yang mudah untuk memulai menjadi lebih rumit. Misalnya, tim pengembangan tidak dapat membuat layanan atau penyebaran dengan nama yang sama. Jika Anda memiliki ribuan perapian, daftar sederhana dari mereka akan memakan banyak waktu, belum lagi menyediakan manajemen normal. Dan ini hanyalah puncak gunung es.

Mari kita lihat bagaimana namespace namespace membuat manajemen sumber daya Kubernet lebih mudah. Jadi apa sebenarnya namespace itu? Namespace dapat dianggap sebagai cluster virtual di dalam cluster Kubernetes Anda. Anda dapat memiliki beberapa ruang nama yang terisolasi satu sama lain di dalam kelompok Kubernet yang sama. Mereka benar-benar dapat membantu Anda dan tim Anda dengan organisasi, keamanan, dan bahkan kinerja sistem.



Pada sebagian besar distribusi Kubernetes, cluster ini “out of the box” dengan namespace yang disebut “default”. Sebenarnya ada tiga ruang nama yang ditangani Kubernetes: default, kube-system, dan kube-public. Saat ini, Kube-publik tidak sering digunakan.



Tidak menyentuh namespace kubus adalah ide yang bagus, terutama pada sistem yang dikelola seperti Google Kubernetes Engine. Ini menggunakan namespace default sebagai tempat di mana layanan dan aplikasi Anda dibuat. Sama sekali tidak ada yang istimewa tentang itu, kecuali bahwa Kubernetes berada di luar kotak yang dikonfigurasi untuk menggunakannya, dan Anda tidak dapat menghapusnya. Ini bagus untuk memulai dan sistem dengan sedikit kinerja, tetapi saya tidak akan merekomendasikan menggunakan namespace default di sistem prod besar. Dalam kasus terakhir, satu tim pengembangan dapat dengan mudah menulis ulang kode orang lain dan mengganggu pekerjaan tim lain tanpa menyadarinya.

Karenanya, Anda harus membuat beberapa ruang nama dan menggunakannya untuk mengelompokkan layanan Anda menjadi tautan yang dapat dikelola. Namespace dapat dibuat dengan satu perintah. Jika Anda ingin membuat namespace bernama test, maka gunakan $ kubectl create namespace test test atau cukup buat file YAML dan gunakan seperti sumber daya Kubernet lainnya.



Anda dapat melihat semua ruang nama menggunakan perintah $ kubectl get namespace.



Setelah eksekusi, Anda akan melihat tiga ruang nama bawaan dan ruang nama baru bernama "test". Mari kita lihat file YAML sederhana untuk membuat pod. Anda mungkin memperhatikan bahwa tidak ada menyebutkan namespace di dalamnya.



Jika Anda menggunakan kubectl untuk menjalankan file ini, itu akan membuat modul mypod di namespace aktif saat ini. Ini akan menjadi namespace default sampai Anda mengubahnya. Ada 2 cara untuk memberi tahu Kubernet di mana namespace yang ingin Anda buat sumber daya Anda. Cara pertama adalah menggunakan flag namespace saat membuat sumber daya.



Cara kedua adalah menentukan namespace dalam deklarasi YAML.



Jika Anda menentukan namespace di YAML, maka sumber daya akan selalu dibuat di ruang ini. Jika Anda mencoba menggunakan namespace yang berbeda saat menggunakan flag namespace, perintahnya akan gagal. Sekarang, jika Anda mencoba menemukan pod Anda, Anda tidak dapat melakukannya.



Ini karena semua perintah dijalankan di luar namespace aktif saat ini. Untuk menemukan pod Anda, Anda perlu menggunakan flag namespace, tetapi ini cepat membosankan, terutama jika Anda bekerja sebagai pengembang dalam grup yang menggunakan namespace sendiri dan tidak ingin menggunakan flag seperti itu untuk setiap perintah individu. Mari kita lihat bagaimana ini bisa diperbaiki.



Di luar kotak, namespace aktif Anda disebut default. Jika Anda tidak menentukan namespace di YAML dari sumber daya, maka semua perintah Kubernetes akan menggunakan namespace default aktif ini. Sayangnya, upaya untuk mengelola namespace aktif menggunakan kubectl mungkin gagal. Namun, ada alat yang sangat bagus yang disebut Kubens, yang sangat menyederhanakan proses ini. Ketika Anda menjalankan perintah kubens, Anda melihat semua ruang nama dengan namespace aktif yang disorot.



Untuk mengalihkan namespace aktif ke namespace tes, Anda cukup menjalankan perintah tes $ kubens. Jika setelah ini, Anda memasukkan lagi perintah $ kubens, Anda dapat melihat bahwa namespace aktif baru sekarang dialokasikan - tes.



Ini berarti Anda tidak perlu flag namespace untuk melihat pod di namespace pengujian.



Oleh karena itu, ruang nama disembunyikan satu sama lain, tetapi tidak terisolasi satu sama lain. Layanan dari satu namespace dapat dengan mudah berkomunikasi dengan layanan di namespace lain, yang seringkali sangat berguna. Kemampuan untuk berkomunikasi antara ruang nama yang berbeda berarti bahwa layanan pengembang Anda dapat berinteraksi dengan layanan dev-command lain di ruang nama yang berbeda.

Biasanya, ketika aplikasi Anda ingin mengakses layanan Kubernetes, Anda menggunakan layanan penemuan DNS bawaan dan hanya memberikan aplikasi Anda nama layanan tersebut. Namun, Anda dapat membuat layanan dengan nama yang sama di beberapa ruang nama, yang tidak valid.



Untungnya, ini mudah dielakkan dengan menggunakan bentuk alamat DNS yang diperluas. Layanan di Kubernetes mengekspos titik akhir mereka menggunakan pola DNS umum. Kelihatannya seperti ini:



Sebagai aturan, Anda hanya perlu nama layanan, dan DNS akan secara otomatis menentukan alamat lengkap.



Namun, jika Anda perlu mengakses layanan di namespace yang berbeda, cukup gunakan nama layanan plus nama namespace:



Misalnya, jika Anda ingin terhubung ke database layanan di namespace tes, Anda dapat menggunakan database alamat database.test



Jika Anda ingin menghubungkan ke database layanan di namespace prod, Anda menggunakan database.prod.



Jika Anda benar-benar ingin mengisolasi dan membatasi akses ke namespace, Kubernetes memungkinkan Anda untuk melakukan ini menggunakan Kebijakan Jaringan Kubernetes. Saya akan membicarakan ini di seri berikutnya.

Saya sering ditanya berapa banyak ruang nama yang harus dibuat dan untuk tujuan apa? Apa itu data yang dikelola?

Jika Anda membuat terlalu banyak ruang nama, itu hanya menghalangi Anda. Jika jumlahnya terlalu sedikit, Anda akan kehilangan semua kelebihan dari solusi semacam itu. Saya pikir ada empat tahap utama yang dilalui setiap perusahaan dalam proses menciptakan struktur organisasinya sendiri. Bergantung pada tahap pengembangan di mana proyek atau perusahaan Anda berada, Anda dapat mengadopsi strategi yang tepat untuk membuat namespace.

Bayangkan Anda adalah bagian dari tim kecil yang bekerja untuk pengembangan 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 lingkup tindakan yang lebih besar, Anda dapat menggunakan 2 ruang nama - secara terpisah untuk prod dan dev. Dan kemungkinan besar, Anda menguji perkembangan Anda di komputer lokal menggunakan sesuatu seperti Minikube.

Misalkan kondisinya telah berubah dan sekarang Anda memiliki tim yang berkembang pesat yang secara bersamaan bekerja pada lebih dari 10 layanan mikro. Ada saatnya ketika Anda perlu menggunakan beberapa cluster atau ruang nama, secara terpisah untuk prod dan dev. Anda dapat membagi tim menjadi beberapa subkelompok sehingga masing-masing dari mereka memiliki layanan microser sendiri dan masing-masing tim ini dapat memilih namespace sendiri untuk memfasilitasi proses mengelola pengembangan dan pelepasan perangkat lunak.



Karena setiap anggota tim mendapat ide tentang bagaimana sistem secara keseluruhan bekerja, mengoordinasikan setiap perubahan dengan semua pengembang lainnya menjadi semakin sulit. Mencoba memutar tumpukan penuh di komputer lokal Anda semakin sulit setiap hari.

Di perusahaan besar, pengembang tidak tahu sama sekali siapa sebenarnya yang mengerjakan apa. Tim berkomunikasi menggunakan kontrak layanan atau menggunakan teknologi Service mesh, 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, saatnya tiba ketika masing-masing tim pasti membutuhkan namespace sendiri. Setiap perintah bahkan dapat memilih beberapa ruang nama untuk lingkungan dev dan lingkungan prod.

Akhirnya, ada perusahaan wirausaha besar di mana satu kelompok pengembangan bahkan tidak menyadari keberadaan kelompok lain. Perusahaan seperti itu umumnya dapat mempekerjakan pengembang pihak ketiga yang berinteraksi dengan melalui API yang terdokumentasi dengan baik. Di setiap kelompok tersebut ada beberapa tim dan beberapa layanan mikro. Dalam hal ini, Anda harus menggunakan semua alat yang saya sebutkan sebelumnya.



Pemrogram tidak boleh menggunakan layanan secara manual dan seharusnya tidak memiliki akses ke ruang nama yang tidak menjadi perhatian mereka. Pada tahap ini, disarankan untuk memiliki beberapa kluster untuk mengurangi "radius ledakan" dari aplikasi yang dikonfigurasi dengan buruk, untuk menyederhanakan proses penagihan dan manajemen sumber daya.

Dengan demikian, menggunakan ruang nama organisasi Anda dengan benar membuat Kubernet lebih mudah dikelola, dikelola, aman, dan fleksibel.

Praktik terbaik Kubernetes. Tes viabilitas Kubernetes dengan uji Readiness and Liveness

Sedikit iklan :)

Terima kasih untuk tetap bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman Anda, cloud VPS untuk pengembang dari $ 4,99 , analog unik dari server entry-level yang diciptakan oleh kami untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps mulai dari $ 19 atau cara membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).

Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya kami yang memiliki 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV dari $ 199 di Belanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai dari $ 99! Baca tentang Cara Membangun Infrastruktur Bldg. kelas c menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?