Pavel Selivanov, arkitek penyelesaian Southbridge dan guru Slurm, memberikan pembentangan di DevOpsConf 2019. Ceramah ini merupakan sebahagian daripada salah satu topik kursus mendalam tentang Kubernetes “Slurm Mega”.
berlangsung di Moscow pada 18-20 November.
— Moscow, 22-24 November.
sentiasa ada.
Di bawah potongan adalah transkrip laporan.
Selamat petang, rakan sekerja dan mereka yang bersimpati dengan mereka. Hari ini saya akan bercakap tentang keselamatan.
Saya lihat ada ramai pengawal keselamatan di dalam dewan hari ini. Saya memohon maaf kepada anda terlebih dahulu jika saya menggunakan istilah dari dunia keselamatan yang tidak betul-betul seperti kebiasaan untuk anda.
Kebetulan kira-kira enam bulan lalu saya terjumpa satu kluster Kubernetes awam. Awam bermakna terdapat bilangan ke-n ruang nama; dalam ruang nama ini terdapat pengguna yang diasingkan dalam ruang nama mereka. Semua pengguna ini tergolong dalam syarikat yang berbeza. Nah, telah diandaikan bahawa kluster ini harus digunakan sebagai CDN. Iaitu, mereka memberi anda kluster, mereka memberi anda pengguna di sana, anda pergi ke sana ke ruang nama anda, gunakan bahagian hadapan anda.
Syarikat saya sebelum ini cuba menjual perkhidmatan sedemikian. Dan saya diminta mencucuk kluster untuk melihat sama ada penyelesaian ini sesuai atau tidak.
Saya datang ke kluster ini. Saya diberi hak terhad, ruang nama terhad. Lelaki di sana memahami apa itu keselamatan. Mereka membaca tentang Kawalan akses berasaskan Peranan (RBAC) dalam Kubernetes - dan mereka memutarkannya supaya saya tidak dapat melancarkan pod secara berasingan daripada penempatan. Saya tidak ingat masalah yang saya cuba selesaikan dengan melancarkan pod tanpa penempatan, tetapi saya benar-benar mahu melancarkan pod sahaja. Untuk nasib baik, saya memutuskan untuk melihat hak yang saya ada dalam kluster, perkara yang boleh saya lakukan, perkara yang tidak boleh saya lakukan dan perkara yang mereka telah kacau di sana. Pada masa yang sama, saya akan memberitahu anda perkara yang telah mereka konfigurasikan secara salah dalam RBAC.
Kebetulan dalam masa dua minit saya menerima pentadbir ke kluster mereka, melihat semua ruang nama jiran, melihat di sana bahagian pengeluaran syarikat yang telah membeli perkhidmatan dan digunakan. Saya hampir tidak dapat menahan diri daripada pergi ke hadapan seseorang dan meletakkan beberapa kata makian di halaman utama.
Saya akan memberitahu anda dengan contoh bagaimana saya melakukan ini dan bagaimana untuk melindungi diri anda daripada ini.
Tetapi pertama, izinkan saya memperkenalkan diri saya. Nama saya Pavel Selivanov. Saya seorang arkitek di Southbridge. Saya memahami Kubernetes, DevOps dan segala macam perkara mewah. Jurutera Southbridge dan saya sedang membina semua ini, dan saya sedang berunding.
Sebagai tambahan kepada aktiviti utama kami, baru-baru ini kami telah melancarkan projek yang dipanggil Slurms. Kami cuba membawa keupayaan kami untuk bekerja dengan Kubernetes kepada orang ramai, untuk mengajar orang lain untuk turut bekerja dengan K8.
Apa yang akan saya bincangkan hari ini? Topik laporan itu jelas - tentang keselamatan gugusan Kubernetes. Tetapi saya ingin segera mengatakan bahawa topik ini sangat besar - dan oleh itu saya ingin segera menjelaskan apa yang saya pasti tidak akan bercakap tentang. Saya tidak akan bercakap tentang istilah hackneyed yang telah digunakan seratus kali di Internet. Semua jenis RBAC dan sijil.
Saya akan bercakap tentang perkara yang menyakitkan saya dan rakan sekerja saya tentang keselamatan dalam kelompok Kubernetes. Kami melihat masalah ini dalam kalangan penyedia yang menyediakan kluster Kubernetes dan dalam kalangan pelanggan yang datang kepada kami. Dan juga daripada pelanggan yang datang kepada kami daripada syarikat pentadbir perunding lain. Maksudnya, skala tragedi itu sebenarnya sangat besar.
Terdapat tiga perkara yang akan saya bincangkan hari ini:
- Hak pengguna vs hak pod. Hak pengguna dan hak pod bukanlah perkara yang sama.
- Mengumpul maklumat tentang kluster. Saya akan menunjukkan bahawa anda boleh mengumpul semua maklumat yang anda perlukan daripada kluster tanpa mempunyai hak istimewa dalam kluster ini.
- Serangan DoS pada kluster. Jika kami tidak dapat mengumpul maklumat, kami akan dapat meletakkan kluster dalam apa jua keadaan. Saya akan bercakap tentang serangan DoS pada elemen kawalan kelompok.
Satu lagi perkara umum yang akan saya nyatakan ialah apa yang saya uji semua ini, yang mana saya pasti boleh mengatakan bahawa semuanya berfungsi.
Kami mengambil sebagai asas pemasangan gugusan Kubernetes menggunakan Kubespray. Jika ada yang tidak tahu, ini sebenarnya satu set peranan untuk Ansible. Kami menggunakannya secara berterusan dalam kerja kami. Perkara yang baik ialah anda boleh menggulungnya di mana-mana - anda boleh menggulungnya pada kepingan besi atau ke awan di suatu tempat. Satu kaedah pemasangan berfungsi pada dasarnya untuk segala-galanya.
Dalam kelompok ini saya akan mempunyai Kubernetes v1.14.5. Keseluruhan gugusan Cube, yang akan kami pertimbangkan, dibahagikan kepada ruang nama, setiap ruang nama dimiliki oleh pasukan yang berasingan, dan ahli pasukan ini mempunyai akses kepada setiap ruang nama. Mereka tidak boleh pergi ke ruang nama yang berbeza, hanya ke ruang nama mereka sendiri. Tetapi terdapat akaun pentadbir tertentu yang mempunyai hak ke atas keseluruhan kluster.
Saya berjanji bahawa perkara pertama yang akan kami lakukan ialah mendapatkan hak pentadbir kepada kluster. Kami memerlukan pod yang disediakan khas yang akan memecahkan gugusan Kubernetes. Apa yang perlu kita lakukan ialah menerapkannya pada kelompok Kubernetes.
kubectl apply -f pod.yamlPod ini akan sampai kepada salah seorang ahli gugusan Kubernetes. Dan selepas ini kluster dengan senang hati akan mengembalikan kepada kami fail bernama admin.conf. Dalam Cube, fail ini menyimpan semua sijil pentadbir dan pada masa yang sama mengkonfigurasi API kluster. Ini adalah betapa mudahnya untuk mendapatkan akses pentadbir, saya fikir, 98% daripada kelompok Kubernetes.
Saya ulangi, pod ini dibuat oleh seorang pembangun dalam kluster anda yang mempunyai akses untuk menggunakan cadangannya ke dalam satu ruang nama kecil, semuanya diapit oleh RBAC. Dia tidak mempunyai hak. Namun begitu sijil tersebut telah dikembalikan.
Dan sekarang tentang pod yang disediakan khas. Kami menjalankannya pada mana-mana imej. Mari kita ambil debian:jessie sebagai contoh.
Kami mempunyai perkara ini:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Apa itu toleransi? Sarjana dalam kelompok Kubernetes biasanya ditandakan dengan sesuatu yang dipanggil taint. Dan intipati "jangkitan" ini ialah ia mengatakan bahawa pod tidak boleh diberikan kepada nod induk. Tetapi tiada siapa yang peduli untuk menunjukkan dalam mana-mana pod bahawa ia bertolak ansur dengan "jangkitan". Bahagian Tolerasi hanya mengatakan bahawa jika sesetengah nod mempunyai NoSchedule, maka nod kami bertolak ansur dengan jangkitan sedemikian - dan tiada masalah.
Selanjutnya, kami mengatakan bahawa bawah kami bukan sahaja bertolak ansur, tetapi juga mahu menyasarkan tuan secara khusus. Kerana tuan mempunyai perkara yang paling lazat yang kami perlukan - semua sijil. Oleh itu, kami menyebut nodeSelector - dan kami mempunyai label standard pada induk, yang membolehkan anda memilih daripada semua nod dalam kluster dengan tepat nod yang menjadi induk.
Dengan dua bahagian ini dia pasti akan datang kepada tuannya. Dan dia akan dibenarkan tinggal di sana.
Tetapi hanya datang kepada tuan tidak mencukupi untuk kami. Ini tidak akan memberi kita apa-apa. Jadi seterusnya kita mempunyai dua perkara ini:
hostNetwork: true
hostPID: true Kami menentukan bahawa pod kami, yang kami lancarkan, akan hidup dalam ruang nama kernel, dalam ruang nama rangkaian dan dalam ruang nama PID. Sebaik sahaja pod dilancarkan pada induk, ia akan dapat melihat semua antara muka sebenar dan langsung nod ini, mendengar semua trafik dan melihat PID semua proses.
Kemudian ia adalah perkara kecil. Ambil etcd dan baca apa yang anda mahu.
Perkara yang paling menarik ialah ciri Kubernetes ini, yang terdapat di sana secara lalai.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Dan intipatinya ialah kita boleh mengatakan dalam pod yang kita lancarkan, walaupun tanpa hak untuk kluster ini, bahawa kita mahu mencipta volum jenis hostPath. Ini bermakna mengambil laluan daripada hos yang akan kami lancarkan - dan mengambilnya sebagai volum. Dan kemudian kami memanggilnya nama: hos. Kami memasang keseluruhan hostPath ini di dalam pod. Dalam contoh ini, ke direktori /host.
Saya akan mengulanginya lagi. Kami memberitahu pod untuk datang ke master, dapatkan hostNetwork dan hostPID di sana - dan lekapkan keseluruhan root master di dalam pod ini.
Anda faham bahawa dalam Debian kami menjalankan bash, dan bash ini berjalan di bawah root. Iaitu, kami baru sahaja menerima akar pada induk, tanpa mempunyai sebarang hak dalam gugusan Kubernetes.
Kemudian tugas keseluruhannya ialah pergi ke sub direktori /host /etc/kubernetes/pki, jika tidak silap saya, ambil semua sijil induk kluster di sana dan, dengan itu, menjadi pentadbir kluster.
Jika anda melihatnya dengan cara ini, ini ialah beberapa hak yang paling berbahaya dalam pod - tidak kira apa hak yang ada pada pengguna:
Jika saya mempunyai hak untuk menjalankan pod dalam beberapa ruang nama kluster, maka pod ini mempunyai hak ini secara lalai. Saya boleh menjalankan pod istimewa, dan ini secara amnya semua hak, boleh dikatakan akar pada nod.
Kegemaran saya ialah pengguna Root. Dan Kubernetes mempunyai pilihan Run As Non-Root ini. Ini adalah sejenis perlindungan daripada penggodam. Adakah anda tahu apa itu "virus Moldavia"? Jika anda tiba-tiba menjadi penggodam dan datang ke kluster Kubernetes saya, maka kami, pentadbir yang lemah, bertanya: “Sila nyatakan dalam pod anda yang anda akan menggodam kluster saya, jalankan sebagai bukan akar. Jika tidak, ia akan berlaku bahawa anda menjalankan proses dalam pod anda di bawah akar, dan ia akan menjadi sangat mudah untuk anda menggodam saya. Tolong lindungi diri anda daripada diri sendiri."
Jumlah laluan hos, pada pendapat saya, adalah cara terpantas untuk mendapatkan hasil yang diingini daripada gugusan Kubernetes.
Tetapi apa yang perlu dilakukan dengan semua ini?
Pemikiran yang harus datang kepada mana-mana pentadbir biasa yang menemui Kubernetes ialah: “Ya, saya beritahu anda, Kubernetes tidak berfungsi. Terdapat lubang di dalamnya. Dan keseluruhan Cube adalah omong kosong." Malah, terdapat perkara seperti dokumentasi, dan jika anda melihat di sana, terdapat bahagian .
Ini ialah objek yaml - kita boleh menciptanya dalam kelompok Kubernetes - yang mengawal aspek keselamatan secara khusus dalam perihalan pod. Iaitu, sebenarnya, ia mengawal hak untuk menggunakan mana-mana hostNetwork, hostPID, jenis volum tertentu yang ada dalam pod semasa permulaan. Dengan bantuan Dasar Keselamatan Pod, semua ini boleh diterangkan.
Perkara yang paling menarik tentang Dasar Keselamatan Pod ialah dalam kluster Kubernetes, semua pemasang PSP bukan sahaja tidak diterangkan dalam apa jua cara, ia hanya dilumpuhkan secara lalai. Dasar Keselamatan Pod didayakan menggunakan pemalam kemasukan.
Okey, mari kita gunakan Dasar Keselamatan Pod ke dalam kelompok, katakan bahawa kita mempunyai beberapa pod perkhidmatan dalam ruang nama, yang hanya pentadbir mempunyai akses. Katakan, dalam semua kes lain, pod mempunyai hak terhad. Kerana kemungkinan besar pembangun tidak perlu menjalankan pod istimewa dalam kelompok anda.
Dan semuanya kelihatan baik-baik saja dengan kami. Dan kelompok Kubernetes kami tidak boleh digodam dalam masa dua minit.
Ada masalah. Kemungkinan besar, jika anda mempunyai kluster Kubernetes, maka pemantauan dipasang pada kluster anda. Saya juga akan meramalkan bahawa jika kluster anda mempunyai pemantauan, ia akan dipanggil Prometheus.
Apa yang saya akan beritahu anda akan sah untuk kedua-dua pengendali Prometheus dan Prometheus yang dihantar dalam bentuk tulennya. Persoalannya ialah jika saya tidak dapat memasukkan pentadbir ke dalam kluster dengan begitu cepat, maka ini bermakna saya perlu melihat lebih banyak lagi. Dan saya boleh mencari dengan bantuan pemantauan anda.
Mungkin semua orang membaca artikel yang sama tentang Habré, dan pemantauan terletak di ruang nama pemantauan. Carta helm dipanggil lebih kurang sama untuk semua orang. Saya meneka bahawa jika anda melakukan pemasangan stable/prometheus, anda akan mendapat nama yang hampir sama. Dan kemungkinan besar saya tidak perlu meneka nama DNS dalam kelompok anda. Kerana ia standard.
Seterusnya kita mempunyai dev ns tertentu, di mana anda boleh menjalankan pod tertentu. Dan kemudian dari pod ini sangat mudah untuk melakukan sesuatu seperti ini:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics ialah salah satu pengeksport Prometheus yang mengumpul metrik daripada API Kubernetes itu sendiri. Terdapat banyak data di sana, apa yang berjalan dalam kluster anda, apa itu, apa masalah yang anda hadapi dengannya.
Sebagai contoh mudah:
kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=
"gcr.io/google-containers/kube-apiserver:v1.14.5"
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
Dengan membuat permintaan curl mudah daripada pod yang tidak mempunyai hak istimewa, anda boleh mendapatkan maklumat berikut. Jika anda tidak tahu versi Kubernetes yang anda jalankan, ia akan memberitahu anda dengan mudah.
Dan perkara yang paling menarik ialah selain daripada mengakses kube-state-metrics, anda boleh dengan mudah mengakses Prometheus sendiri secara langsung. Anda boleh mengumpul metrik dari sana. Anda juga boleh membina metrik dari sana. Malah secara teorinya, anda boleh membina pertanyaan sedemikian daripada gugusan dalam Prometheus, yang hanya akan mematikannya. Dan pemantauan anda akan berhenti berfungsi dari kluster sama sekali.
Dan di sini persoalan timbul sama ada mana-mana pemantauan luaran memantau pemantauan anda. Saya baru sahaja mendapat peluang untuk beroperasi dalam kelompok Kubernetes tanpa sebarang akibat untuk diri saya sendiri. Anda tidak akan tahu bahawa saya beroperasi di sana, kerana tiada lagi pemantauan.
Sama seperti PSP, rasanya seperti masalahnya ialah semua teknologi mewah ini - Kubernetes, Prometheus - mereka tidak berfungsi dan penuh dengan lubang. Tidak juga.
Terdapat perkara sedemikian - .
Jika anda seorang pentadbir biasa, kemungkinan besar anda tahu tentang Dasar Rangkaian bahawa ini hanyalah satu lagi yaml, yang mana sudah terdapat banyak yaml dalam kluster. Dan beberapa Polisi Rangkaian pastinya tidak diperlukan. Dan walaupun anda membaca Dasar Rangkaian, bahawa ia adalah tembok api yaml Kubernetes, ia membolehkan anda mengehadkan hak akses antara ruang nama, antara pod, maka anda pasti memutuskan bahawa tembok api dalam format yaml dalam Kubernetes adalah berdasarkan abstraksi seterusnya ... Tidak tidak . Ini pastinya tidak perlu.
Walaupun anda tidak memberitahu pakar keselamatan anda bahawa menggunakan Kubernetes anda, anda boleh membina tembok api yang sangat mudah dan ringkas, dan yang sangat terperinci. Jika mereka belum mengetahui perkara ini lagi dan tidak mengganggu anda: “Nah, berikan saya, berikan saya...” Kemudian dalam apa jua keadaan, anda memerlukan Dasar Rangkaian untuk menyekat akses kepada beberapa tempat perkhidmatan yang boleh ditarik dari kluster anda tanpa sebarang kebenaran.
Seperti dalam contoh yang saya berikan, anda boleh mengeluarkan metrik keadaan kube dari mana-mana ruang nama dalam kelompok Kubernetes tanpa mempunyai sebarang hak untuk berbuat demikian. Dasar rangkaian telah menutup akses dari semua ruang nama lain ke ruang nama pemantauan dan itu sahaja: tiada akses, tiada masalah. Dalam semua carta yang wujud, kedua-dua Prometheus standard dan Prometheus yang ada dalam pengendali, terdapat hanya pilihan dalam nilai teraju untuk membolehkan dasar rangkaian untuk mereka. Anda hanya perlu menghidupkannya dan ia akan berfungsi.
Terdapat satu masalah di sini. Sebagai pentadbir berjanggut biasa, anda berkemungkinan besar memutuskan bahawa dasar rangkaian tidak diperlukan. Dan selepas membaca pelbagai jenis artikel tentang sumber seperti Habr, anda memutuskan bahawa flanel, terutamanya dengan mod pintu masuk hos, adalah perkara terbaik yang boleh anda pilih.
Apa yang perlu dilakukan?
Anda boleh cuba menggunakan semula penyelesaian rangkaian yang anda ada dalam kelompok Kubernetes anda, cuba gantikannya dengan sesuatu yang lebih berfungsi. Untuk Calico yang sama, sebagai contoh. Tetapi saya ingin segera mengatakan bahawa tugas menukar penyelesaian rangkaian dalam kelompok kerja Kubernetes agak tidak penting. Saya menyelesaikannya dua kali (kedua-dua kali, bagaimanapun, secara teori), tetapi kami juga menunjukkan cara melakukannya di Slurms. Untuk pelajar kami, kami menunjukkan cara menukar penyelesaian rangkaian dalam kelompok Kubernetes. Pada dasarnya, anda boleh cuba memastikan bahawa tiada masa henti pada kelompok pengeluaran. Tetapi anda mungkin tidak akan berjaya.
Dan masalah itu sebenarnya diselesaikan dengan sangat mudah. Terdapat sijil dalam kluster dan anda tahu bahawa sijil anda akan tamat tempoh dalam setahun. Nah, dan biasanya penyelesaian biasa dengan sijil dalam gugusan - mengapa kami bimbang, kami akan menaikkan gugusan baharu berdekatan, membiarkan yang lama menjadi busuk dan mengatur semula segala-galanya. Benar, apabila ia menjadi busuk, kita perlu duduk selama sehari, tetapi inilah kluster baharu.
Apabila anda menaikkan gugusan baharu, pada masa yang sama masukkan Calico dan bukannya flanel.
Apa yang perlu dilakukan jika sijil anda dikeluarkan selama seratus tahun dan anda tidak akan menggunakan semula kluster? Terdapat perkara seperti Kube-RBAC-Proxy. Ini adalah perkembangan yang sangat hebat, ia membolehkan anda membenamkan dirinya sebagai bekas kereta sampingan kepada mana-mana pod dalam gugusan Kubernetes. Dan ia sebenarnya menambah kebenaran pada pod ini melalui RBAC Kubernetes sendiri.
Ada satu masalah. Sebelum ini, penyelesaian Kube-RBAC-Proxy ini telah dibina ke dalam Prometheus pengendali. Tetapi kemudian dia telah tiada. Kini versi moden bergantung pada fakta bahawa anda mempunyai dasar rangkaian dan menutupnya menggunakan dasar tersebut. Dan oleh itu kita perlu menulis semula carta itu sedikit. Malah, jika anda pergi ke , terdapat contoh cara menggunakan ini sebagai sidecar, dan carta perlu ditulis semula dengan minima.
Ada satu lagi masalah kecil. Prometheus bukan satu-satunya yang memberikan metriknya kepada sesiapa sahaja. Semua komponen kluster Kubernetes kami juga dapat mengembalikan metrik mereka sendiri.
Tetapi seperti yang saya telah katakan, jika anda tidak boleh mengakses kluster dan mengumpul maklumat, maka anda sekurang-kurangnya boleh melakukan sedikit kemudaratan.
Oleh itu, saya akan segera menunjukkan dua cara bagaimana kluster Kubernetes boleh dimusnahkan.
Anda akan ketawa apabila saya memberitahu anda ini, ini adalah dua kes kehidupan sebenar.
Kaedah satu. Kehabisan sumber.
Jom lancarkan satu lagi pod istimewa. Ia akan mempunyai bahagian seperti ini.
resources:
requests:
cpu: 4
memory: 4Gi Seperti yang anda ketahui, permintaan ialah jumlah CPU dan memori yang dikhaskan pada hos untuk pod tertentu dengan permintaan. Jika kami mempunyai hos empat teras dalam gugusan Kubernetes, dan empat pod CPU tiba di sana dengan permintaan, ini bermakna tiada lagi pod dengan permintaan akan dapat datang ke hos ini.
Jika saya menjalankan pod sedemikian, maka saya akan menjalankan arahan:
$ kubectl scale special-pod --replicas=...Kemudian tiada orang lain akan dapat menggunakan gugusan Kubernetes. Kerana semua nod akan kehabisan permintaan. Dan dengan itu saya akan menghentikan kluster Kubernetes anda. Jika saya melakukan ini pada waktu petang, saya boleh menghentikan penggunaan untuk masa yang agak lama.
Jika kita melihat semula dokumentasi Kubernetes, kita akan melihat perkara ini yang dipanggil Julat Had. Ia menetapkan sumber untuk objek kluster. Anda boleh menulis objek Julat Had dalam yaml, gunakannya pada ruang nama tertentu - dan kemudian dalam ruang nama ini anda boleh mengatakan bahawa anda mempunyai sumber lalai, maksimum dan minimum untuk pod.
Dengan bantuan perkara sedemikian, kami boleh mengehadkan pengguna dalam ruang nama produk tertentu pasukan dalam keupayaan untuk menunjukkan semua jenis perkara jahat pada pod mereka. Tetapi malangnya, walaupun anda memberitahu pengguna bahawa mereka tidak boleh melancarkan pod dengan permintaan untuk lebih daripada satu CPU, terdapat perintah skala yang begitu hebat, atau mereka boleh melakukan skala melalui papan pemuka.
Dan dari sinilah kaedah nombor dua berasal. Kami melancarkan 11 pod. Itu sebelas bilion. Ini bukan kerana saya menghasilkan nombor sedemikian, tetapi kerana saya melihatnya sendiri.
Cerita sebenar. Lewat petang saya hendak keluar dari pejabat. Saya melihat sekumpulan pembangun duduk di sudut, terkapai-kapai melakukan sesuatu dengan komputer riba mereka. Saya pergi ke lelaki itu dan bertanya: "Apa yang berlaku kepada anda?"
Sedikit lebih awal, sekitar jam sembilan malam, salah seorang pemaju sedang bersiap untuk pulang. Dan saya memutuskan: "Saya kini akan mengurangkan permohonan saya kepada satu." Saya menekan satu, tetapi Internet perlahan sedikit. Dia menekan yang satu lagi, dia menekan yang satu, dan mengklik Enter. Saya mencucuk semua yang saya boleh. Kemudian Internet menjadi hidup - dan segala-galanya mula diperkecilkan kepada nombor ini.
Benar, kisah ini tidak berlaku di Kubernetes; pada masa itu ia adalah Nomad. Ia berakhir dengan fakta bahawa selepas satu jam percubaan kami untuk menghentikan Nomad daripada percubaan berterusan untuk skala, Nomad menjawab bahawa dia tidak akan berhenti membuat skala dan tidak akan melakukan apa-apa lagi. "Saya penat, saya pergi." Dan dia meringkuk.
Sememangnya, saya cuba melakukan perkara yang sama pada Kubernetes. Kubernetes tidak berpuas hati dengan sebelas bilion pod, dia berkata: “Saya tidak boleh. Melebihi pelindung mulut dalaman." Tetapi 1 pod boleh.
Sebagai tindak balas kepada satu bilion, Cube tidak berundur ke dalam dirinya sendiri. Dia betul-betul mula skali. Semakin jauh proses itu, semakin banyak masa yang diambilnya untuk mencipta pod baharu. Tetapi proses itu tetap berjalan. Satu-satunya masalah ialah jika saya boleh melancarkan pod tanpa had dalam ruang nama saya, maka walaupun tanpa permintaan dan had saya boleh melancarkan begitu banyak pod dengan beberapa tugas yang dengan bantuan tugasan ini nod akan mula ditambah dalam memori, dalam CPU. Apabila saya melancarkan begitu banyak pod, maklumat daripadanya harus masuk ke dalam storan, iaitu, dsb. Dan apabila terlalu banyak maklumat tiba di sana, storan mula kembali terlalu perlahan - dan Kubernetes mula menjadi membosankan.
Dan satu lagi masalah... Seperti yang anda tahu, elemen kawalan Kubernetes bukanlah satu perkara utama, tetapi beberapa komponen. Khususnya, terdapat pengurus pengawal, penjadual, dan sebagainya. Semua lelaki ini akan mula melakukan kerja yang tidak perlu dan bodoh pada masa yang sama, yang dari masa ke masa akan mula mengambil lebih banyak masa. Pengurus pengawal akan membuat pod baharu. Penjadual akan cuba mencari nod baharu untuk mereka. Anda kemungkinan besar akan kehabisan nod baharu dalam kelompok anda tidak lama lagi. Kelompok Kubernetes akan mula berfungsi dengan lebih perlahan dan perlahan.
Tetapi saya memutuskan untuk pergi lebih jauh. Seperti yang anda ketahui, dalam Kubernetes terdapat perkara sedemikian yang dipanggil perkhidmatan. Nah, secara lalai dalam kelompok anda, kemungkinan besar, perkhidmatan ini berfungsi menggunakan jadual IP.
Jika anda menjalankan satu bilion pod, sebagai contoh, dan kemudian menggunakan skrip untuk memaksa Kubernetis membuat perkhidmatan baharu:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Pada semua nod kluster, semakin banyak peraturan iptables baharu akan dijana lebih kurang serentak. Selain itu, satu bilion peraturan iptables akan dihasilkan untuk setiap perkhidmatan.
Saya menyemak keseluruhan perkara ini pada beberapa ribu, sehingga sepuluh. Dan masalahnya ialah sudah pada ambang ini agak bermasalah untuk melakukan ssh ke nod. Kerana paket, melalui begitu banyak rantai, mula berasa tidak begitu baik.
Dan ini juga, semuanya diselesaikan dengan bantuan Kubernetes. Terdapat objek kuota Sumber sedemikian. Menetapkan bilangan sumber dan objek yang tersedia untuk ruang nama dalam kelompok. Kita boleh mencipta objek yaml dalam setiap ruang nama gugusan Kubernetes. Menggunakan objek ini, kita boleh mengatakan bahawa kita mempunyai bilangan permintaan dan had tertentu yang diperuntukkan untuk ruang nama ini, dan kemudian kita boleh mengatakan bahawa dalam ruang nama ini adalah mungkin untuk mencipta 10 perkhidmatan dan 10 pod. Dan pemaju tunggal sekurang-kurangnya boleh mencekik dirinya pada waktu petang. Kubernetes akan memberitahunya: "Anda tidak boleh menskalakan pod anda kepada jumlah itu, kerana sumber tersebut melebihi kuota." Itu sahaja, masalah selesai. .
Satu perkara yang bermasalah timbul dalam hal ini. Anda merasakan betapa sukarnya untuk mencipta ruang nama dalam Kubernetes. Untuk menciptanya, kita perlu mengambil kira banyak perkara.
Kuota sumber + Julat Had + RBAC
• Buat ruang nama
• Buat julat had di dalam
• Buat kuota sumber dalam
• Buat akaun perkhidmatan untuk CI
• Buat pengikatan peranan untuk CI dan pengguna
• Lancarkan pod perkhidmatan yang diperlukan secara pilihan
Oleh itu, saya ingin mengambil kesempatan ini untuk berkongsi perkembangan saya. Terdapat perkara sedemikian yang dipanggil pengendali SDK. Ini ialah cara untuk kluster Kubernetes menulis pengendali untuknya. Anda boleh menulis pernyataan menggunakan Ansible.
Pada mulanya ia ditulis dalam Ansible, dan kemudian saya melihat bahawa terdapat pengendali SDK dan menulis semula peranan Ansible menjadi pengendali. Pernyataan ini membolehkan anda mencipta objek dalam kelompok Kubernetes yang dipanggil arahan. Di dalam arahan, ia membolehkan anda menerangkan persekitaran untuk arahan ini dalam yaml. Dan dalam persekitaran pasukan, ia membolehkan kami menerangkan bahawa kami memperuntukkan begitu banyak sumber.
Little one .
Dan kesimpulannya. Apa yang perlu dilakukan dengan semua ini?
Pertama. Dasar Keselamatan Pod bagus. Dan walaupun pada hakikatnya tiada pemasang Kubernetes menggunakannya sehingga hari ini, anda masih perlu menggunakannya dalam kelompok anda.
Dasar Rangkaian bukan sekadar satu lagi ciri yang tidak diperlukan. Inilah yang sangat diperlukan dalam kelompok.
LimitRange/ResourceQuota - sudah tiba masanya untuk menggunakannya. Kami mula menggunakan ini sejak lama dahulu, dan untuk masa yang lama saya pasti bahawa semua orang menggunakannya. Ternyata ini jarang berlaku.
Sebagai tambahan kepada apa yang saya nyatakan semasa laporan, terdapat ciri tidak berdokumen yang membolehkan anda menyerang kluster. Dikeluarkan baru-baru ini .
Beberapa perkara sangat menyedihkan dan menyakitkan. Contohnya, dalam keadaan tertentu, cubelet dalam kelompok Kubernetes boleh memberikan kandungan direktori warlocks kepada pengguna yang tidak dibenarkan.
Terdapat arahan tentang cara untuk menghasilkan semula semua yang saya beritahu anda. Terdapat fail dengan contoh pengeluaran tentang rupa ResourceQuota dan Dasar Keselamatan Pod. Dan anda boleh menyentuh semua ini.
Terima kasih semua.
Sumber: www.habr.com