🈚️ 👨🏽‍✈️ 💅🏾 10 alasan [tidak] menggunakan k8s ⚗️ 🧗🏾 👩🏿‍🤝‍👩🏻

Hari ini kita akan berbicara tentang Kubernetes, tentang rake yang dapat dikumpulkan dalam penggunaan praktisnya, dan tentang perkembangan yang membantu penulis dan yang seharusnya membantu Anda juga. Kami akan mencoba membuktikan bahwa tanpa k8 di dunia modern di mana saja. Untuk lawan k8, kami juga memberikan alasan yang sangat bagus mengapa Anda tidak harus beralih ke itu. Artinya, dalam cerita kita tidak hanya akan membela Kubernetes, tetapi juga memarahinya. Dari sinilah namanya datang [bukan] ini .

Artikel ini didasarkan pada presentasi oleh Ivan Glushkov ( gli ) pada konferensi DevOops 2017. Dua tempat kerja terakhir Ivan entah bagaimana terkait dengan Kubernetes: ia bekerja di infracommand di kedua Postmates dan Machine Zone, dan mereka memengaruhi Kubernetes dengan sangat erat. Plus, Ivan memimpin podcast DevZen . Presentasi lebih lanjut akan atas nama Ivan.

Pertama, saya akan membahas secara singkat area mengapa ini berguna dan penting bagi banyak orang, mengapa hype ini muncul. Maka saya akan bercerita tentang pengalaman kami dalam menggunakan teknologi. Nah, lalu kesimpulannya.

Dalam artikel ini, semua slide dimasukkan sebagai gambar, tetapi terkadang Anda ingin menyalin sesuatu. Sebagai contoh, akan ada contoh dengan konfigurasi. Slide PDF dapat diunduh di sini .

Saya tidak akan memberi tahu semua orang: pastikan untuk menggunakan Kubernetes. Ada pro dan kontra, jadi jika Anda datang untuk mencari kontra, Anda akan menemukannya. Anda punya pilihan, hanya melihat pro, hanya kontra dan umumnya melihat semuanya bersama-sama. Simon Cat akan membantu saya dengan pro, dan kucing hitam akan menyeberang jalan ketika ada minus.

Jadi, mengapa hype ini terjadi sama sekali, mengapa teknologi X lebih baik daripada Y. Kubernetes adalah sistem yang persis sama, dan ada banyak lebih dari satu. Ada Wayang, Koki, Ansible, Bash + SSH, Terraform. SSH favorit saya membantu saya sekarang, mengapa saya harus pergi ke suatu tempat. Saya percaya bahwa ada banyak kriteria, tetapi saya menyoroti yang paling penting.

Waktu dari komit hingga rilis adalah tanda yang sangat bagus, dan orang-orang dari Express 42 adalah pakar hebat dalam hal ini. Otomasi perakitan, otomasi seluruh pipa adalah hal yang sangat baik, Anda tidak bisa memuji itu, itu sebenarnya membantu. Integrasi Berkelanjutan, Penerapan Berkelanjutan. Dan, tentu saja, berapa banyak usaha yang akan Anda habiskan untuk melakukan semuanya. Semuanya dapat ditulis dalam Assembler, seperti yang saya katakan, sistem penempatan juga, tetapi tidak akan menambah kenyamanan.

Saya tidak akan memberi tahu Anda pengantar singkat tentang Kubernetes, Anda tahu apa itu. Saya akan menyentuh area ini sedikit lebih jauh.

Mengapa semua ini sangat penting bagi pengembang? Pengulangan sangat penting bagi mereka, yaitu, jika mereka menulis semacam aplikasi, menjalankan tes, itu akan berhasil untuk Anda, untuk tetangga Anda, dan untuk produksi.

Yang kedua adalah lingkungan standar: jika Anda telah mempelajari Kubernetes dan pergi ke perusahaan tetangga di mana Kubernetes berada, maka semuanya akan sama. Penyederhanaan prosedur pengujian dan Integrasi Berkelanjutan bukan merupakan hasil langsung dari menggunakan Kubernetes, tetapi masih menyederhanakan tugas, sehingga semuanya menjadi lebih nyaman.

Untuk pengembang rilis, ada banyak manfaat lainnya. Pertama, ini adalah infrastruktur yang tidak dapat diubah.

Kedua, infrastruktur seperti kode yang disimpan di suatu tempat. Ketiga, idempotensi, kemampuan menambahkan rilis dengan satu tombol. Pelepasan rollback terjadi cukup cepat, dan introspeksi sistem cukup nyaman. Tentu saja, semua ini dapat dilakukan pada sistem Anda, ditulis di atas lutut, tetapi Anda tidak selalu dapat melakukannya dengan benar, dan Kubernetes telah menerapkannya.

Apa yang tidak dimiliki Kubernet, dan apa yang tidak diizinkan untuk dilakukan? Ada banyak kesalahpahaman dalam hal ini. Mari kita mulai dengan wadahnya. Kubernet berjalan di atasnya. Kontainer bukan mesin virtual yang ringan, tetapi entitas yang sama sekali berbeda. Mereka mudah dijelaskan dengan bantuan konsep ini, tetapi ternyata itu salah. Konsepnya sangat berbeda, harus dipahami dan diterima.
Kedua, Kubernetes tidak membuat aplikasi lebih aman. Itu tidak membuatnya secara otomatis terukur.

Anda perlu berusaha keras untuk memulai Kubernetes, itu tidak akan jadi "menekan tombol, dan semuanya bekerja secara otomatis." Itu akan menyakitkan.

Pengalaman kami Kami ingin Anda dan orang lain tidak merusak apa pun. Untuk melakukan ini, Anda perlu melihat lebih jauh - dan inilah sisi kami.

Pertama, Kubernetes tidak pergi sendiri. Ketika Anda sedang membangun struktur yang akan sepenuhnya mengelola rilis dan penyebaran, Anda harus memahami bahwa Kubernetes adalah satu dadu, dan harus ada 100 dadu seperti itu. Untuk membangun semua ini, Anda harus mempelajarinya dengan keras. Pemula yang akan masuk ke sistem Anda juga akan mempelajari tumpukan ini, sejumlah besar informasi.

Kubernetes bukan satu-satunya blok penting, ada banyak blok penting lainnya, yang tanpanya sistem tidak akan berfungsi. Artinya, Anda perlu sangat khawatir tentang toleransi kesalahan.

Karena itu, Kubernetes bernilai minus. Sistemnya kompleks, Anda perlu banyak merawat.

Tapi ada plusnya. Jika seseorang mempelajari Kubernetes di satu perusahaan, di perusahaan lain rambutnya tidak akan tahan lama karena sistem pelepasannya. Seiring waktu, ketika Kubernetes mengambil alih lebih banyak ruang, transisi orang dan pelatihan akan lebih mudah. Dan untuk itu - plus.

Kami menggunakan Helm. Sistem ini, yang dibangun di atas Kubernetes, menyerupai manajer paket. Anda dapat mengklik tombol, katakan bahwa Anda ingin menginstal * Wine * di sistem Anda. Dapat diinstal di Kubernetes. Ini berfungsi, secara otomatis mengunduh, mulai, dan semuanya akan berfungsi. Ini memungkinkan Anda untuk bekerja dengan plug-in, arsitektur client-server. Jika Anda bekerja dengannya, kami sarankan Anda menjalankan satu Tiller di namespace. Ini mengisolasi namespace dari satu sama lain, dan melanggar satu tidak merusak yang lain.

Padahal, sistemnya sangat kompleks. Suatu sistem, yang seharusnya merupakan abstraksi dari tingkat yang lebih tinggi dan lebih sederhana dan lebih dapat dimengerti, tidak benar-benar membuatnya lebih mudah untuk dipahami. Untuk minus ini.

Mari kita bandingkan konfigurasi. Kemungkinan besar, Anda juga memiliki beberapa konfigurasi jika Anda menjalankan sistem Anda dalam produksi. Kami memiliki sistem kami sendiri yang disebut BOOMer. Saya tidak tahu mengapa kami memanggilnya begitu. Terdiri dari Boneka, Koki, Ansible, Terraform dan yang lainnya, ada botol besar.

Mari kita lihat cara kerjanya. Berikut adalah contoh konfigurasi nyata yang saat ini bekerja di produksi. Apa yang kita lihat di sini?

Pertama, kita melihat di mana harus meluncurkan aplikasi, kedua, apa yang perlu diluncurkan, dan ketiga, bagaimana harus disiapkan untuk peluncuran. Dalam satu botol konsep sudah dicampur.

Jika kita melihat lebih jauh, karena kita menambahkan warisan untuk membuat konfigurasi yang lebih kompleks, kita harus melihat apa yang ada dalam konfigurasi umum yang kita maksudkan. Plus, kami menambahkan konfigurasi jaringan, hak akses, perencanaan beban. Semua ini dalam satu konfigurasi yang kita perlukan untuk menjalankan aplikasi nyata dalam produksi, kita mencampur banyak konsep di satu tempat.

Ini sangat sulit, sangat salah, dan ini merupakan nilai tambah besar bagi Kubernetes, karena di dalamnya Anda cukup menentukan apa yang harus dijalankan. Pengaturan jaringan dilakukan selama instalasi Kubernetes, seluruh penyediaan diselesaikan dengan menggunakan buruh pelabuhan - Anda memiliki enkapsulasi, semua masalah entah bagaimana dipisahkan, dan dalam hal ini, konfigurasi hanya memiliki aplikasi Anda, dan ada nilai tambah untuk ini.

Mari kita lihat lebih dekat. Di sini kita hanya punya satu aplikasi. Agar penyebaran dapat bekerja, Anda membutuhkan lebih banyak untuk bekerja. Pertama, Anda perlu mendefinisikan layanan. Bagaimana rahasia, ConfigMap, akses ke Load Balancer datang kepada kami.

Jangan lupa bahwa Anda memiliki beberapa lingkungan. Ada Stage / Prod / Dev. Ini semua bersama-sama bukan bagian kecil yang saya perlihatkan, tetapi satu set besar konfigurasi, yang benar-benar sulit. Untuk minus ini.

Templat helm untuk perbandingan. Itu sepenuhnya mengulangi template Kubernetes, jika ada file di Kubernetes dengan definisi penyebaran, yang sama akan berada di Helm. Alih-alih nilai spesifik untuk lingkungan, Anda memiliki template yang diganti dari nilai.
Anda memiliki templat terpisah, nilai-nilai terpisah yang harus diganti dalam templat ini.

Tentu saja, Anda perlu mendefinisikan infrastruktur berbeda dari Helm itu sendiri, meskipun faktanya Anda memiliki banyak file konfigurasi di Kubernetes yang perlu Anda seret dan taruh ke Helm. Ini semua sangat sulit, untuk yang minus.

Sistem yang seharusnya menyederhanakan sebenarnya menyulitkan. Bagi saya, ini adalah minus yang jelas. Entah perlu menambahkan sesuatu yang lain, atau tidak menggunakan

Ayo masuk lebih dalam, kita tidak cukup dalam.

Pertama, bagaimana kita bekerja dengan kelompok. Saya membaca artikel Google "Borg, Omega, dan Kubernetes," yang sangat menganjurkan konsep bahwa Anda perlu memiliki satu cluster besar. Saya juga untuk ide ini, tetapi, pada akhirnya, kami meninggalkannya. Sebagai hasil dari perselisihan kami, kami menggunakan empat kelompok berbeda.

Cluster e2e pertama yang menguji Kubernetes itu sendiri dan menguji skrip yang menggunakan lingkungan, plug-in, dan sebagainya. Yang kedua, tentu saja, prod dan panggung. Ini adalah konsep standar. Ketiga, ini adalah admin, di mana segala sesuatu dimuat - khususnya, kami memiliki CI di sana, dan tampaknya karena itu cluster ini akan selalu menjadi yang terbesar.

Ada banyak tes: dengan komit, dengan menggabungkan, semua orang membuat banyak komitmen, jadi clusternya sangat besar.

Kami mencoba melihat CoreOS, tetapi tidak menggunakannya. Mereka memiliki TF atau CloudFormation di dalam, dan keduanya sangat buruk memungkinkan kami untuk memahami apa yang ada di dalam negara. Karena itu, ada masalah selama peningkatan. Saat Anda ingin memperbarui pengaturan Kubernetes Anda, misalnya, versinya, Anda mungkin menemukan fakta bahwa pembaruan tidak berfungsi seperti ini, dalam urutan yang salah. Ini adalah masalah stabilitas besar. Ini adalah minus.

Kedua, ketika Anda menggunakan Kubernetes, Anda perlu mengunduh gambar dari suatu tempat. Ini bisa menjadi sumber internal, repositori, atau eksternal. Jika internal, ada masalah. Saya merekomendasikan menggunakan Distribusi Docker karena stabil, itu dibuat oleh Docker. Namun harga dukungan masih tinggi. Agar dapat berfungsi, Anda harus membuatnya toleran terhadap kesalahan, karena ini adalah satu-satunya tempat aplikasi Anda mendapatkan data untuk bekerja.

Bayangkan bahwa pada saat genting, ketika Anda menemukan bug pada produksi, repositori Anda jatuh - Anda tidak dapat memperbarui aplikasi. Anda harus menjadikannya toleran terhadap kesalahan, dan dari semua kemungkinan masalah yang hanya bisa terjadi.

Kedua, jika massa tim, masing-masing memiliki citra sendiri, mereka menumpuk banyak dan sangat cepat. Anda dapat membunuh Distribusi Docker Anda. Anda perlu melakukan pembersihan, menghapus gambar, membuat informasi untuk pengguna, kapan dan apa yang akan Anda bersihkan.

Ketiga, dengan gambar besar, katakanlah, jika Anda memiliki monolit, ukuran gambar akan sangat besar. Bayangkan Anda perlu melepaskan 30 node. 2 gigabytes per 30 node - hitung aliran mana, seberapa cepat ia mengunduh ke semua node. Saya ingin menekan tombol, dan segera menjadi hijau. Tapi tidak, Anda harus menunggu dulu sampai diunduh. Sangat penting untuk mempercepat unduhan ini, dan semuanya berfungsi dari satu titik.

Dengan repositori eksternal, ada masalah yang sama dengan pengumpul sampah, tetapi paling sering ini dilakukan secara otomatis. Kami menggunakan Quay. Dalam hal repositori eksternal, ini adalah layanan pihak ketiga di mana sebagian besar gambar bersifat publik. Bahwa tidak ada gambar publik, perlu untuk menyediakan akses. Kami membutuhkan rahasia, hak akses ke gambar, semua ini dikonfigurasi secara khusus. Tentu saja, ini bisa otomatis, tetapi dalam kasus peluncuran lokal Kuba di sistem Anda, Anda masih harus mengkonfigurasinya.

Untuk menginstal Kubernet kami menggunakan kops. Ini adalah sistem yang sangat baik, kami adalah pengguna awal sejak saat mereka belum menulis ke blog. Itu tidak sepenuhnya mendukung CoreOS, bekerja dengan baik dengan Debian, tahu bagaimana mengkonfigurasi secara otomatis node master Kubernetes, bekerja dengan add-on, dan memiliki kemampuan untuk melakukan nol downtime selama pembaruan Kubernetes.
Semua fitur ini berada di luar kotak, yang plus besar dan berani. Sistem hebat!

Dari tautan, Anda dapat menemukan banyak opsi untuk menyiapkan jaringan di Kubernetes. Sebenarnya ada banyak dari mereka, setiap orang memiliki kelebihan dan kekurangan mereka sendiri. Kops hanya mendukung sebagian dari opsi ini. Anda dapat, tentu saja, mengkonfigurasinya untuk bekerja melalui CNI, tetapi lebih baik menggunakan yang paling populer dan standar. Mereka diuji oleh masyarakat, dan kemungkinan besar stabil.

Kami memutuskan untuk menggunakan Calico. Ini bekerja dengan baik dari awal, tanpa banyak masalah, menggunakan BGP, enkapsulasi lebih cepat, mendukung IP-in-IP, memungkinkan Anda untuk bekerja dengan multi-cloud, bagi kami ini adalah nilai tambah yang besar.
Integrasi yang baik dengan Kubernetes, menggunakan label membatasi lalu lintas. Untuk ini merupakan nilai tambah.

Saya tidak berharap Calico untuk mencapai negara ketika dihidupkan, dan semuanya bekerja tanpa masalah.

Ketersediaan Tinggi, seperti yang saya katakan, kami lakukan melalui kops, Anda dapat menggunakan 5-7-9 node, kami menggunakan tiga. Kami duduk di etcd v2, karena bug mereka tidak diperbarui pada v3. Secara teoritis, ini akan mempercepat beberapa proses. Saya tidak tahu, saya ragu.

Saat yang sulit, kami memiliki gugus khusus untuk bereksperimen dengan skrip, otomatis bergulir melalui CI. Kami percaya bahwa kami memiliki perlindungan terhadap tindakan yang sepenuhnya salah, tetapi untuk beberapa rilis khusus dan kompleks, kalau-kalau kami membuat snapshot dari semua disk, kami tidak melakukan backup setiap hari.

Otorisasi adalah pertanyaan abadi. Kami di Kubernet menggunakan RBAC, akses berbasis peran. Ini jauh lebih baik daripada ABAC, dan jika Anda mengkonfigurasinya, maka Anda mengerti apa yang saya maksud. Lihatlah konfigurasi - terkejut.
Kami menggunakan Dex, penyedia OpenID yang memompa semua informasi dari beberapa sumber data.
Dan untuk masuk ke Kubernetes, ada dua cara. Penting untuk entah bagaimana mendaftar di .kube / config ke mana harus pergi dan apa yang bisa dilakukan. Penting untuk mendapatkan konfigurasi ini. Atau pengguna pergi ke UI, di mana ia login, menerima konfigurasi, menyalinnya ke / config dan bekerja. Ini sangat tidak nyaman. Kami secara bertahap pindah ke fakta bahwa seseorang masuk ke konsol, mengklik tombol, masuk, konfigurasi secara otomatis dihasilkan darinya dan ditumpuk di tempat yang tepat. Jauh lebih nyaman, kami memutuskan untuk bertindak dengan cara ini.

Sebagai sumber data kami menggunakan Active Directory. Kubernetes memungkinkan Anda untuk mendorong informasi tentang grup melalui seluruh struktur otorisasi, yang diterjemahkan ke dalam namespace dan peran. Jadi, kita segera membedakan antara ke mana seseorang bisa pergi, ke mana dia tidak punya hak untuk pergi, dan apa yang bisa dilepaskannya.

Paling sering, orang membutuhkan akses ke AWS. Jika Anda tidak memiliki Kubernetes, ada mesin yang menjalankan aplikasi. Tampaknya yang Anda butuhkan hanyalah untuk mendapatkan log, melihatnya dan hanya itu. Ini nyaman ketika seseorang dapat pergi ke mobilnya dan melihat bagaimana aplikasi bekerja. Dari sudut pandang Kubernetes, semuanya berfungsi dalam wadah. Ada perintah `kubectl exec` - masuk ke wadah dalam aplikasi dan lihat apa yang terjadi di sana. Oleh karena itu, tidak perlu pergi ke instance AWS. Kami telah menolak akses ke semua orang kecuali infrakommand.

Selain itu, kami telah melarang kunci admin yang sudah lama diputar, masuk melalui peran. Jika mungkin untuk menggunakan peran admin - saya admin. Ditambah lagi kami menambahkan rotasi tombol. Lebih mudah untuk mengkonfigurasinya melalui perintah awsudo, ini adalah proyek di github, saya sangat merekomendasikannya, ini memungkinkan Anda untuk bekerja dengan tim-sudo.

Kuota. Suatu hal yang sangat bagus di Kubernetes, bekerja langsung di luar kotak. Anda membatasi ruang nama apa pun, katakanlah, dengan jumlah objek, memori atau CPU yang dapat Anda konsumsi. Saya percaya bahwa ini penting dan bermanfaat bagi semua orang. Kami belum mencapai memori dan CPU, kami hanya menggunakan jumlah objek, tetapi kami akan menambahkan semua ini.

Besar dan gemuk plus, memungkinkan Anda untuk melakukan banyak hal rumit.

Scaling. Anda tidak dapat mencampur penskalaan di dalam Kubernetes dan di luar Kubernetes. Di dalam Kubernetes melakukan penskalaan sendiri. Itu dapat meningkatkan polong secara otomatis ketika ada beban besar.

Di sini saya berbicara tentang meningkatkan contoh Kubernetes sendiri. Ini dapat dilakukan dengan menggunakan AWS Autoscaler, ini adalah proyek github. Ketika Anda menambahkan pod baru dan itu tidak dapat dimulai karena kekurangan sumber daya pada semua instance, AWS Autoscaler dapat secara otomatis menambahkan node. Ini memungkinkan Anda untuk bekerja pada Spot-instance, kami belum menambahkannya, tetapi kami akan, memungkinkan kami untuk menghemat banyak.

Ketika Anda memiliki banyak pengguna dan aplikasi pengguna, Anda perlu memantaunya. Biasanya ini adalah telemetri, log, beberapa gambar yang indah.

Karena alasan historis, kami memiliki Sensu, itu tidak cocok untuk Kubernetes. Proyek yang lebih berorientasi metrik diperlukan. Kami melihat seluruh tumpukan TICK, terutama InfluxDB. UI yang bagus, bahasa seperti SQL, tetapi tidak cukup fitur. Kami beralih ke Prometheus.

Dia baik. Bahasa permintaan yang bagus, peringatan yang baik, dan semuanya ada di luar kotak.

Untuk mengirim telemetri, kami menggunakan Cernan. Ini adalah proyek kami sendiri yang ditulis dalam Rust. Ini adalah satu-satunya proyek pada Rust yang telah bekerja dalam produksi kami selama satu tahun sekarang. Ini memiliki beberapa konsep: ada konsep sumber data, Anda mengkonfigurasi beberapa sumber. Anda mengonfigurasi tempat data akan digabungkan. Kami memiliki konfigurasi filter, yaitu, data yang mengalir dapat diproses dengan beberapa cara. Anda dapat mengonversi log menjadi metrik, metrik menjadi log, apa pun yang Anda inginkan.
Terlepas dari kenyataan bahwa Anda memiliki beberapa input, beberapa kesimpulan, dan Anda menunjukkan bahwa kemana ia pergi, ada sesuatu seperti sistem grafik besar, ternyata cukup nyaman.

Kami sekarang bergerak mulus dari tumpukan Statsd / Cernan / Wavefront saat ini ke Kubernetes. Secara teoritis, Prometheus ingin mengambil data dari aplikasi dengan sendirinya, jadi Anda perlu menambahkan titik akhir ke semua aplikasi, yang darinya akan mengambil metrik. Cernan adalah tautan transmisi, ia harus bekerja di mana saja. Ada dua kemungkinan: Anda bisa menjalankan Kubernetes di setiap instance, menggunakan konsep Sidecar, ketika kontainer lain bekerja di bidang data Anda yang mengirim data. Kami melakukan ini dan itu.

Saat ini, semua log dikirim ke stdout / stderr. Semua aplikasi dirancang untuk ini, jadi salah satu persyaratan penting adalah bahwa kita tidak meninggalkan sistem ini. Cernan mengirim data ke ElasticSearch, acara seluruh sistem Kubernetes dikirim ke sana menggunakan Heapster. Ini adalah sistem yang sangat bagus, saya sarankan.

Setelah itu, Anda dapat melihat semua log di satu tempat, misalnya, di konsol. Kami menggunakan Kibana. Ada produk Stern yang bagus, hanya untuk log. Hal ini memungkinkan Anda untuk menonton, mewarnai polong yang berbeda dalam warna yang berbeda, tahu cara melihat ketika satu di bawah telah mati dan yang lainnya telah dimulai kembali. Secara otomatis mengambil semua log. Proyek yang ideal, saya sangat merekomendasikannya, ini gemuk plus Kubernetes, semuanya baik-baik saja di sini.

Rahasia Kami menggunakan S3 dan KMS. Kami berpikir untuk beralih ke Vault atau rahasia di Kubernetes sendiri. Mereka berada di 1,7 dalam keadaan alfa, tetapi sesuatu harus dilakukan dengan ini.

Kita sampai pada bagian yang menarik. Pengembangan kubernet umumnya tidak banyak dipertimbangkan. : «Kubernetes — , , , ».
, Kubernetes — .

, , , - . Kubernetes : , , . , , — .

, , . -, Docker Way. , . , , SSH, : « - , ».

, Kubernetes , read only . , , , , , , , . Kubernetes , , , , -, .

: , - , , - , pipeline , : «, », . - , , , . , CI , - , CI . .

, , , , . , - . , . - Kubernetes. , , — , .
.

Kubernetes, , , - . , , Deis, . , , , Deis. , Deis .

, Helm Charts. , — . - How-to, - FAQ, , , , , . , . , , .

Minikube — , , , , , . Kubernetes , , SSH .

MacOS, Mac, , , . . virtualbox, xhyve. , , . xhyve, VirtualBox, , .

, , , - , . , , - , .

CI Kubernetes, , , Kubernetes, , . Concourse CI, , , , , , . Concourse . , . , , , - , .

CI, , , , Concourse. Drone.io — , , , , . , — , . , , .

pipeline -, Kubernetes. , , , CI, -, Kubernetes .
admin/stage-, - . .

Drone-. , pipeline, - : , . , Drone, , .

, : . , , - , Kubernetes. Google , , , - .

Google , Kubernetes. , , . , , . , . Service Mesh.

, , , Geodesic. , , . , . , , , .

, Kubernetes .

, . , , , . Kubernetes. , , .

.

, , — , , . : , , . — Kubernetes .

Kubernetes . , Kubernetes, . , , .

Kubernetes — . , Kubernetes . — .

, , .

Kubernetes, — . , , , .
, Minikube, , , . , , , Kubernetes . — , .

— . , , , , 1-2 , , , . Kubernetes .

-, Kubernetes , , . CI, CI , , , . .

— . , , , . Kubernetes , .
, , . , , , . , , .

, , Kubernetes , . . , .

. Kubernetes . -. , Kubernetes, , ( — , ) , .

, , pod, . , . , , , . , , Kubernetes, , .

Error Budget. : , . , , - . , , . — , . — . SLA «» — , , , . , , , , .

, . « », . , , . .

: @gliush .

, :

Menit periklanan. Jika Anda menyukai laporan ini dari konferensi DevOops - perhatikan bahwa pada 14 Oktober DevOops 2018 baru akan diadakan di St. Petersburg, akan ada banyak hal menarik dalam programnya. Situs ini sudah memiliki pembicara dan laporan pertama.

10 alasan [tidak] menggunakan k8s

More articles: