Selalu sulit untuk menghosting sejumlah besar pengguna dengan aman di satu cluster Kubernetes. Alasan utamanya adalah bahwa semua organisasi menggunakan Kubernetes secara berbeda, jadi model multi-pengguna tunggal kemungkinan tidak akan berfungsi untuk semua orang. Sebaliknya, Kubernetes menawarkan komponen untuk membuat solusi Anda sendiri, seperti Role Based Access Control (RBAC) dan NetworkPolicies; semakin baik komponen ini, semakin mudah untuk membangun cluster multi-pengguna yang aman.
Namespaces bergegas menyelamatkan
Sejauh ini yang paling penting dari komponen ini adalah ruang nama . Mereka adalah dasar dari hampir semua kebijakan berbagi bidang keamanan dan kontrol di Kubernetes. Misalnya, RBAC, NetworkPolicies, dan ResourceQuotas mendukung namespace secara default, sedangkan objek seperti Secret, ServiceAccount, dan Ingress tersedia secara bebas dalam satu ruang tetapi sepenuhnya terisolasi dari yang lain .
Namespaces memiliki beberapa fitur utama yang membuatnya ideal untuk penegakan kebijakan. Pertama, mereka dapat digunakan untuk merepresentasikan properti . Kebanyakan objek Kubernetes seharusnyaberada di namespace apa pun. Dengan menggunakan ruang nama untuk mewakili kepemilikan, Anda selalu dapat mengandalkan objek tersebut untuk memiliki pemilik.
Kedua, hanya pengguna dengan hak yang sesuai yang dapat membuat dan menggunakan ruang nama . Untuk membuat ruang nama, Anda memerlukan hak istimewa tambahan, dan pengguna lain memerlukan izin eksplisit untuk bekerja dengannya - yaitu, untuk membuat, melihat, atau memodifikasi objek di ruang nama ini. Jadi, namespace pertama dibuat dengan serangkaian kebijakan yang rumit, dan hanya setelah itu pengguna yang tidak memiliki hak istimewa dapat membuat objek "biasa" seperti pod dan layanan.
Pembatasan ruang nama
Sayangnya, dalam praktiknya, namespace tidak cukup fleksibel dan tidak cocok dalam beberapa kasus penggunaan umum. Misalnya, tim tertentu memiliki beberapa layanan mikro dengan rahasia dan kuota berbeda. Idealnya, mereka harus membagi layanan ini menjadi ruang nama terpisah untuk mengisolasinya satu sama lain, tetapi ini menghadirkan dua masalah.
Pertama, namespace ini tidak memiliki satu konsep kepemilikan, meskipun keduanya dimiliki oleh tim yang sama. Ini berarti bahwa tidak hanya Kubernetes yang tidak tahu apa-apa tentang fakta bahwa namespace ini memiliki satu pemilik, tetapi juga tidak memiliki kemampuan untuk menerapkan kebijakan global ke semua namespace yang dikontrol sekaligus.
Kedua, seperti yang Anda ketahui, otonomi adalah kunci kerja tim yang efektif. Karena pembuatan namespace memerlukan hak istimewa yang lebih tinggi, kecil kemungkinannya siapa pun di tim pengembangan akan memiliki hak istimewa ini. Dengan kata lain, setiap kali tim memutuskan untuk membuat namespace baru, mereka harus menghubungi administrator cluster. Ini mungkin bisa diterima dengan sempurna untuk perusahaan kecil, tetapi seiring pertumbuhannya, efek negatif dari organisasi semacam itu menjadi lebih jelas.
Memperkenalkan Hierarchical Namespaces
Namespace hierarki adalah konsep baru yang dikembangkan oleh kelompok kerja multi-tenancy Kubernetes ( wg-multitenancy ) untuk mengatasi masalah ini. Dalam bentuk yang disederhanakan, namespace hierarkis adalah namespace Kubernetes biasa dengan sumber daya kustom kecil yang disertakan yang mengarah ke satu namespace induk (opsional). Ini memperluas konsep kepemilikan ke ruang nama itu sendiri , bukan hanya objek di dalamnya.
Konsep kepemilikan juga menerapkan dua jenis hubungan tambahan:
- : namespace' . : subnamespaces, .
Ini menyelesaikan kedua masalah tim pengembang yang khas. Administrator cluster dapat membuat satu ruang "root" untuk itu bersama dengan kebijakan yang diperlukan dan mendelegasikan otoritas untuk membuat subruang kepada anggota tim. Dengan cara ini, pengembang dapat membuat subnamespace untuk digunakan sendiri tanpa melanggar kebijakan yang ditetapkan oleh administrator kluster.
Sedikit latihan
Namespace hierarki diimplementasikan menggunakan ekstensi Kubernetes yang disebut Hierarchical Namespace Controller atau HNC . HNC terdiri dari dua komponen:
- Manajer beroperasi dalam sebuah cluster, mengelola subnamespaces, mendistribusikan objek kebijakan, memastikan bahwa hierarki valid, dan mengelola titik ekstensi.
- Sebuah plugin kubectl menyebutnya
kubectl-hnsmemungkinkan pengguna untuk berinteraksi dengan manajer.
Panduan instalasi komponen dapat ditemukan pada halaman rilis di repositori proyek.
Mari kita lihat cara kerja HNC. Misalkan saya tidak memiliki hak istimewa untuk membuat namespace, tetapi saya dapat menelusuri namespace
team-adan membuat subnamespaces di dalamnya *. Plugin memungkinkan saya memasukkan perintah berikut:
$ kubectl hns create svc1-team-a -n team-a
* Secara teknis, Anda membuat objek kecil yang disebut "subnamespace jangkar" di ruang induk dan kemudian HNC membuat subnamespace.
Ini akan membuat namespace
svc1-team-a. Harap diperhatikan bahwa subnamespace tidak berbeda dengan namespace Kubernetes biasa, jadi namanya harus unik.
Anda dapat melihat struktur yang dihasilkan menggunakan perintah
tree:
$ kubectl hns tree team-a
# Output:
team-a
└── svc1-team-a
Jika ada kebijakan di ruang induk, mereka akan disalin ke anak *. Misalnya, Anda
team-amemiliki RBAC RoleBinding yang dipanggil sres. RoleBinding ini juga akan muncul di namespace terkait:
$ kubectl describe rolebinding sres -n svc1-team-a
# Output:
Name: sres
Labels: hnc.x-k8s.io/inheritedFrom=team-a # inserted by HNC
Annotations: <none>
Role:
Kind: ClusterRole
Name: admin
Subjects: …
* Secara default, hanya Roles dan RoleBindings di RBAC yang didistribusikan ulang, tetapi Anda dapat mengonfigurasi HNC untuk menyebarkan objek Kubernetes apa pun.
Terakhir, HNC menambahkan label ke ruang nama ini dengan informasi berguna tentang hierarki. Mereka dapat digunakan untuk menerapkan kebijakan lain. Misalnya, Anda dapat membuat NetworkPolicy berikut:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-team-a
namespace: team-a
spec:
ingress:
- from:
- namespaceSelector:
matchExpressions:
- key: 'team-a.tree.hnc.x-k8s.io/depth' # Label created by HNC
operator: Exists
Kebijakan ini akan disebarkan ke keturunan
team-adan juga akan memungkinkan lalu lintas masuk di antara semua ruang nama ini. Hanya HNC yang dapat memberikan label "pohon". Itu dijamin untuk mencerminkan hierarki saat ini.
Detail tentang fungsionalitas HNC dapat ditemukan di manual pengguna .
Langkah selanjutnya dan partisipasi dalam proses
Jika Anda merasa bahwa namespace'y hierarkis berguna di organisasi Anda, versi HNC v0.5.1 tersedia di GitHub (tersedia dari 28 Agustus hingga rilis v0.5.2 - ca. Perevi ..) . Kami ingin tahu pendapat Anda tentangnya, masalah apa yang Anda selesaikan, dan fitur apa yang ingin Anda tambahkan. Seperti halnya perangkat lunak apa pun di tahap awal pengembangan, kehati-hatian harus diberikan saat menggunakan HNC dalam produksi. Dan semakin banyak umpan balik yang kami terima, semakin cepat kami sampai di HNC 1.0.
Kami juga menerima kontribusi dari kontributor pihak ketiga, baik itu perbaikan bug / informasi tentang mereka atau membantu membuat prototipe fitur baru seperti pengecualian, pemantauan yang ditingkatkan, kutipan sumber daya hierarki, atau pengoptimalan konfigurasi.
Anda dapat menghubungi kami di repositori , buletin, atau Slack . Kami menantikan komentar Anda!
Pengumuman asli dibuat oleh Adrian Ludwin , Insinyur Perangkat Lunak dan Pimpinan Teknis untuk Hierarchical Namespace Controller.
Bonus! Peta jalan dan masalah
Silakan posting masalah - lebih banyak, lebih menyenangkan! Bug akan dianalisis terlebih dahulu, dan permintaan fitur akan diprioritaskan, setelah itu akan dimasukkan dalam rencana kerja atau backlog.
HNC belum mencapai status GA, jadi berhati-hatilah saat menggunakannya di cluster dengan objek konfigurasi yang tidak dapat Anda kehilangan (misalnya, yang tidak disimpan dalam repositori Git).
Semua masalah HNC disertakan dalam rencana kerja yang sesuai. Saat ini, tahapan utama dari rencana ini telah dilaksanakan atau direncanakan:
- v1.0: akhir I - awal kuartal II tahun 2021; HNC direkomendasikan untuk produksi.
- v0.8: awal 2021; fungsi kritis baru mungkin muncul.
- v0.7: akhir tahun 2020; kemungkinan besar v1beta1 API akan muncul.
- v0.6: 2020-; v1alpha2 API .
- v0.5: 2020-; , .
- v0.4: 2020-; API production-.
- v0.3: 2020-; UX subnamespace'.
- v0.2: 2019-; non-production.
- v0.1: 2019-; . , - .
- : .
PS dari penerjemah
Baca juga di blog kami: