Apa yang menanti Anda sebelum, setelah dan selama transisi ke Kubernetes - catatan bisnis

Halo semuanya!

Pada artikel ini, kami memutuskan untuk berspekulasi sedikit tentang kapan dan mengapa bisnis membutuhkan Kubernetes. Betapa sulitnya teknologi untuk masuk, seberapa cepat dan bagaimana hasilnya. Apakah itu layak dan apa yang semuanya mengancam. Kami tidak mengatur sendiri tugas untuk menulis tinjauan teknis mendalam, yang jumlahnya banyak, tetapi dalam materi berikut kami pasti akan berbagi praktik terbaik kami dalam hal arsitektur aplikasi dan stabilitas di bawah Kubernetes. Sekarang kita fokus pada apakah game itu sepadan dengan lilin dan apa yang kita dapatkan di jalan keluar.



Waktu ke pasar - kecepatan memperbarui pembaruan ke pasar - hari ini menjadi faktor kunci dalam efektivitas solusi TI. Produk perlu ditingkatkan setiap hari: tambahkan fungsi dan modul baru ke dalamnya, simpan dokumentasi dan skrip dalam kondisi sempurna. Pada saat yang sama, sistem online harus berjalan dengan lancar dan diperbarui tanpa mempengaruhi pengguna.

Penjaga pembaruan terus-menerus yang tidak mencolok adalah layanan microser, wadah dan infrastruktur untuk orkestrasi mereka - Kubernetes (atau K8S, disebut dalam lingkaran teknis).

Bagaimana Kubernetes menyediakan pembaruan sistem yang berkelanjutan


Tugas utama saat memperbarui solusi TI adalah memastikan operasi yang benar setelah transfer dari lingkungan pengembangan ke platform produk. Dan juga dalam kelancaran sistem pada saat memperbarui produk.

Masalahnya terletak pada kenyataan bahwa pengaturan lingkungan pengembangan dan server industri sering tidak cocok. Wadah memperbaiki masalah ini dengan menggabungkan semua komponen perangkat lunak ke dalam satu paket yang terisolasi dari lingkungan eksternal. Ini memungkinkan Anda untuk menyebarkan aplikasi dengan cepat dan andal pada infrastruktur apa pun dan memfasilitasi pembaruan basis kode sistem.

Tanpa disadari oleh pengguna, pembaruan terjadi melalui duplikasi wadah dan pengalihan sekuensial pengguna dari satu ke yang lain. Untuk manajemen kontainer (orkestrasi) kami menggunakan Kuberenetes. Pada akhirnya, ini memfasilitasi manajemen solusi, penyebaran dan peningkatan, pemantauan kinerja, dan debugging jika terjadi kegagalan.

Ketika sebuah perusahaan membutuhkan Kubernetes


Sudah waktunya bagi perusahaan untuk berpikir tentang beralih ke platform Kubernetes ketika:

  • Sebuah proyek atau sistem adalah alat yang signifikan untuk bisnis dan oleh karena itu harus toleran terhadap kesalahan dan terus bekerja, bahkan jika ada bagian yang rusak.
  • Sistem ini sarat muatan, dengan tetap mempertahankan pembaruan atau peningkatan cepat.
  • Sistem secara berkala membutuhkan kapasitas tambahan. Dan membutuhkan mereka segera.
  • Dan dengan semua ini, kecepatan pengiriman pembaruan ke lingkungan industri diukur dalam beberapa minggu, bulan, tahun, tetapi tidak pernah - berjam-jam atau berhari-hari.

Anda juga membutuhkan Kubernetes sebagai alat untuk otomatisasi dan standardisasi pekerjaan dengan solusi, jika selain dari yang di atas:

  • Tidak ada isolasi antara sistem TI perusahaan dan masing-masing dapat mempengaruhi yang lain.
  • Jika Anda perlu menulis skrip terpisah setiap kali untuk berkomunikasi dengan parameter server tempat sistem digunakan, yaitu, Anda dapat mengatur skala proses ini hanya dengan tangan.
  • Ada orang-orang kunci dalam tim pengembangan - pembawa “pengetahuan rahasia” tentang proyek atau sistem, dan mereka tampak unik dan tak tergantikan.

Pada dasarnya, beralih ke Kubernetes adalah suatu keharusan bagi perusahaan yang perlu mendukung sistem informasi online 24/7.

Kenapa Kubernetes?


Kubernetes bukan satu-satunya alternatif untuk integrasi dan penyebaran berkelanjutan (CI / CD). Tapi Kubernetes yang menjadi standar industri untuk mengelola sistem yang membutuhkan ketersediaan tinggi.

Bagi kami sebagai pengembang, argumen yang menentukan yang mendukung Kubernet adalah sebagai berikut:

  • Platform ini berfokus pada aplikasi, bukan infrastruktur.
  • Kubernetes nyaman untuk bekerja dengan satu pusat data, serta dengan beberapa, yang didistribusikan di berbagai kota.
  • Dukungan solusi mudah melalui dokumentasi yang jelas dan komunitas yang aktif.
  • Konfigurasi fleksibel berbagai aplikasi, distribusi lalu lintas aman.
  • Dukungan kontainer Docker.

Apa manfaat bisnis Kubernetes?


  • Konfigurasi fleksibel dan proses pembaruan otomatis
    Anda sendiri yang menentukan bagian mana dari sistem yang akan dioperasikan secara komersial. Kubernetes memungkinkan Anda membuat siklus rilis singkat. Semua operasi - dari kode sumber sistem hingga rilis ke lingkungan produk - berlangsung secara otomatis. Anda tidak perlu tim insinyur untuk membuat sistem bekerja. Pembaruan saat ini tidak mempengaruhi kinerja sistem dan dapat dilakukan kapan saja nyaman bagi pengembang.
  • Penempatan dan penskalaan sistem
    Sistem ini dapat ditempatkan pada kekuatan komputasi pelanggan (atau di pusat data), dan pada penyedia cloud apa pun, misalnya, Amazon atau Azure. Tingkat kinerja dan toleransi kesalahan apa pun dapat dengan mudah dicapai dengan meningkatkan skala kluster.
  • Standarisasi dan dokumentasi diri
    Solusinya tidak memerlukan instruksi. Ini mendokumentasikan diri dan segera secara otomatis dikemas ke dalam unit penggunaan - wadah. Kami menggambarkan konfigurasi di Kubernetes sebagai rencana / diagram. Kami tidak menulis skrip yang mempersiapkan lingkungan, seperti sebelum Kubernetes. Sebagai gantinya, kami meneruskan ke informasi Kubernetes (diagram) tentang bagaimana solusi seharusnya bekerja. Dan dia sendiri yang mengimplementasikan skema ini.

    Pengembang sekarang menulis aplikasi untuk bekerja dalam wadah. Insinyur DevOps menulis diagram tentang bagaimana aplikasi harus bekerja dalam sebuah wadah, dan Kubernetes sendiri melakukan tugas membangun solusi.

    Teknologi Kubernetes adalah standar. Mudah bagi Anda untuk melatih karyawan baru dalam sistem rilis Anda atau mentransfer sistem ke kontraktor baru.

    Deskripsi konfigurasi akhir yang dibuat Kubernetes juga merupakan dokumentasi untuk sistem. Dari namanya, segera hapus parameter apa yang dikonfigurasikan dan untuk apa parameter itu.

    Karena ini, platform Kubernetes secara keseluruhan merilis rilis, pembaruan, dan rilis aplikasi.

  • Pengujian langsung tanpa rasa sakit
    Proses pengujian solusi telah berubah. Pengembang dapat, sesuai permintaan, menciptakan lingkungan yang identik dengan produk untuk pengujian otomatis. Dan log umum tentang cara kerja aplikasi dan cara kerja Kubernetes dengan aplikasi membantu untuk menyelidiki masalah dan menemukan kesalahan lebih cepat.

Apa yang dibutuhkan oleh transisi bisnis ke Kubernetes


Kubernetes sendiri hanya akan menjadi bagian kecil dari sistem baru Anda. Anda harus siap bahwa Kubernetes sebagai alat untuk menstandarisasi seluruh siklus pengembangan, memperbarui dan menerbitkan aplikasi akan memerlukan perubahan dalam segala hal pada saat transisi: arsitektur perangkat lunak, proses pengembangan dan pemeliharaan infrastruktur.

  • Arsitektur Solusi
    Dari sudut pandang produk, transisi hanya dimungkinkan jika sistem diimplementasikan atau ditingkatkan ke arsitektur layanan mikro berdasarkan layanan yang dapat dikemas dalam wadah (layanan tanpa kewarganegaraan).
  • Proses pengembangan
    Dari sudut pandang proses pembangunan, transisi terutama melibatkan perubahan dalam pemikiran. Setiap perbaikan situasional dan "kruk" yang ditambahkan pada saat terakhir benar-benar dikecualikan. Pengembang solusi TI hanya dapat bekerja sebagai satu tim, yang awalnya membuat produk yang awalnya diuji, didukung, dikemas, dapat diurai. Semuanya harus dibangun secara logis dari baris pertama kode ke operasi.
  • Perbarui proses
    Bahkan pada tahap pengembangan arsitektur aplikasi, Anda perlu memikirkan cara memperbarui solusi tanpa henti. Dan segera mengerti bagaimana Anda akan memperbarui database, API, bagaimana logis untuk mendukung beberapa versi aplikasi, dengan mempertimbangkan fakta bahwa orang-orang bekerja dengan sistem selama pembaruan dan mereka dapat jatuh ke dalam versi yang berbeda.

    Dan satu putaran pemikiran terkait dengan fakta bahwa ketika beralih ke Kubernetes, infrastruktur mulai bekerja dalam mode read-only, dan untuk memperbarui sistem, Anda perlu membuat versi baru dari gambar aplikasi dan memberitahu Kubernetes untuk menggunakan versi baru, dan nantinya akan mematikan versi lama dan akan menghapus dirinya sendiri.


Sehingga perbaikan sistem dan perubahan dalam teknologi kerja tidak bisa dihindari. Bergerak tidak akan cepat. Tetapi Anda perlu mengubah paradigma hanya sekali.

Kasing. Bagaimana kami mentransfer sistem layanan-mikro ke Kubernetes


Kami beroperasi dalam lingkungan produk solusi yang sangat dimuat berdasarkan arsitektur layanan mikro, yang mentransmisikan lebih dari 300 ribu transaksi per hari, dan pada waktu puncak - 60-80 ribu per jam. Kami secara teratur memperbarui produk, ada juga rilis yang lebih mendesak yang sebelumnya diperlukan untuk menangguhkan sistem atau bagian dari fungsinya untuk sementara waktu.

Kami pergi ke lingkungan grosir tanpa K8S, tapi kami mengembangkan sistem awalnya dengan mata. Butuh 6 minggu untuk menerjemahkan solusi ke Kubernetes. Kami pindah ke arah berikut:

1) Menyiapkan pipa penempatan


a. Mengkonfigurasi pipa untuk perakitan berkelanjutan, pengujian, dan pembaruan aplikasi (CI / CD) di lingkungan pengujian.
b. Menyiapkan pembaruan terus-menerus di lingkungan industri.
c. Persiapan dan konfigurasi lingkungan sedekat mungkin dengan lingkungan industri (preprod). Kami menyebarkan dan menguji cluster di sebelah mesin virtual saat ini.
d. Pengembangan rencana untuk migrasi ke lingkungan industri.

Jadi, semuanya tampak sederhana, kami memiliki pipa CI / CD untuk semua lingkungan dan Anda dapat beralih, tetapi masih terlalu dini!

2) Pemilihan konfigurasi cluster


Beberapa minggu kami habiskan untuk memilih konfigurasi komponen dan versi yang paling stabil dari kluster Kubernetes: sistem operasi + Docker + Kubernetes.

Kami menguji 3 konfigurasi berbeda dari sistem operasi (Ubuntu, CentOS, Oracle Linux versi terbaru). Di setiap sistem operasi, kami memeriksa 2 versi Docker dan Kubernet yang berbeda - versi yang dikirimkan dalam versi terbaru dari paket sistem operasi standar, dan versi terbaru dari pabrikan. Sebagai hasilnya, konfigurasi dari distribusi standar Oracle Linux menunjukkan stabilitas terbesar, dan kami memutuskannya.

3) Mengkonfigurasi pengaturan wadah


Kami menghabiskan lebih banyak waktu menyetel parameter wadah - kami menyiapkan persyaratan untuk memori, disk, dan proses.

Dan hanya setelah kami melakukan semua ini dan menguji berbagai parameter fungsi sistem (stabilitas, toleransi kesalahan dan lain-lain) dalam preprode di bawah beban yang dekat dengan yang tempur, dan sistem bekerja dengan stabil, kami beralih ke tahap akhir - migrasi.

Kemudian semuanya sederhana.

Hari C. Migrasi


Untuk migrasi tempur, kami memilih waktu dengan beban sistem minimum: jumlah pengguna minimum dan tidak adanya peningkatan beban sesuai dengan jadwal kerja internal algoritma sistem.

Waktu henti sistem sekitar satu jam dan praktis tidak memengaruhi pengguna. Migrasi itu sendiri terdiri dari mengalihkan pengguna dari satu sistem ke yang lain dan mengamati bahwa semuanya berjalan dengan baik.

Hidup dengan Kubernet


Sekarang proses pembaruan tidak mempengaruhi kinerja sistem, itu dapat dilakukan kapan saja nyaman bagi pengembang dan terlihat sebagai berikut:

  1. Pengembang membuat revisi, mengujinya, mengirim kode ke publikasi.
  2. Kode secara otomatis dirakit, dikemas dalam gambar buruh pelabuhan, dan diterbitkan ke repositori buruh pelabuhan pribadi.
  3. Kubernetes secara otomatis meningkatkan versi layanan baru, memeriksa apakah layanan berfungsi dengan benar, mengalihkan pengguna untuk menggunakan versi layanan baru, menghentikan pekerjaan versi lama dan menghapusnya dari cluster. Pembaruan telah terjadi.

Merangkum pengalaman kami


Anda perlu Kubernet jika:

  1. Diperlukan ketersediaan sistem yang tinggi.
  2. Sistem ini berkembang secara dinamis, dan Anda perlu mengirimkan perubahan ke lingkungan produk dengan mata tertutup.
  3. Anda ingin bekerja sebagai tim tunggal dari kode ke lingkungan produk.
  4. Anda membuat sistem yang dinamis dan berkembang yang akan Anda operasikan selama bertahun-tahun.

Kubernetes “mahal”, karena memasuki teknologi akan membutuhkan:

  1. Belajar oleh pengembang teknologi terkait.
  2. Tinjauan desain, pengembangan, penyebaran, pengujian, dan proses manajemen lingkungan.
  3. Pengalaman dalam mengoperasikan Kubernetes sendiri: sekarang Anda perlu memantau tidak hanya sistem Anda, tetapi juga layanan aplikasi Kubernetes.

Bayar Kubernet dengan sangat cepat:

  1. Prosedur pembaruan sistem jauh lebih sederhana dan lebih cepat. Pengembang dibebaskan dari seluruh blok kerja.
  2. Setiap spesialis baru akan memasuki proyek sudah di rel.
  3. Konveyor akan transparan dan otomatis.
  4. Pengalaman akan diulangi oleh tim Anda untuk sistem lain.
  5. Anda akan memperbarui sistem tanpa mematikannya, yang berarti Anda tidak akan menghentikan bisnis.

PS Saran praktis: bagi pintu masuk teknologi ke dalam dua tahap: mengembangkan sistem dengan arsitektur layanan mikro yang tepat dan memindahkannya di bawah kendali K8S. Dengan demikian, transisi di bawah Kubernetes tidak akan berubah menjadi refactoring global.

Source: https://habr.com/ru/post/id419353/


All Articles