Cara menghubungkan cluster Kubernetes di pusat data yang berbeda

Selamat datang di seri Mulai Cepat Kubernetes kami. Ini adalah kolom reguler dengan pertanyaan paling menarik yang kami terima secara online dan dalam pelatihan kami. Jawaban pakar Kubernetes.

Pakar saat ini adalah Daniel Polenchik (Daniele Polensik). Daniel bekerja sebagai instruktur dan pengembang perangkat lunak di Pelajari8s.

Jika Anda ingin pertanyaan Anda terjawab di postingan berikutnya, hubungi kami melalui email atau Twitter: @belajar8s.

Ketinggalan postingan sebelumnya? Temukan mereka di sini.

Bagaimana cara menghubungkan cluster Kubernetes di pusat data yang berbeda?

Secara singkat: Kubefed v2 segera hadir, dan saya juga merekomendasikan membaca tentang Pengirim и proyek penjadwal multi-cluster.

Seringkali, infrastruktur direplikasi dan didistribusikan ke berbagai wilayah, terutama di lingkungan yang terkendali.

Jika satu wilayah tidak tersedia, lalu lintas dialihkan ke wilayah lain untuk menghindari gangguan.

Dengan Kubernetes, Anda dapat menggunakan strategi serupa dan mendistribusikan beban kerja ke berbagai wilayah.

Anda dapat memiliki satu atau beberapa klaster per tim, wilayah, lingkungan, atau kombinasi elemen-elemen ini.

Kluster Anda dapat dihosting di cloud dan lokal yang berbeda.

Namun bagaimana Anda merencanakan infrastruktur untuk penyebaran geografis seperti itu?
Apakah Anda perlu membuat satu cluster besar untuk beberapa lingkungan cloud melalui satu jaringan?
Atau punya banyak cluster kecil dan menemukan cara untuk mengontrol dan menyinkronkannya?

Satu kelompok kepemimpinan

Membuat satu cluster melalui satu jaringan tidaklah mudah.

Bayangkan Anda mengalami kecelakaan, konektivitas antar segmen cluster terputus.

Jika Anda memiliki satu server master, setengah dari sumber daya tidak akan dapat menerima perintah baru karena mereka tidak akan dapat menghubungi master.

Dan pada saat yang sama Anda memiliki tabel perutean lama (kube-proxy tidak dapat mengunduh yang baru) dan tidak ada pod tambahan (kubelet tidak dapat meminta pembaruan).

Lebih buruknya lagi, jika Kubernetes tidak melihat sebuah node, maka Kubernetes akan menandainya sebagai node yatim piatu dan mendistribusikan pod yang hilang ke node yang ada.

Hasilnya, Anda memiliki pod dua kali lebih banyak.

Jika Anda membuat satu server master untuk setiap wilayah, maka akan terjadi masalah pada algoritma konsensus di database etcd. (kira-kira. ed. — Faktanya, database etcd tidak harus ditempatkan di server master. Itu dapat dijalankan pada grup server terpisah di wilayah yang sama. Benar, sekaligus mendapatkan titik kegagalan cluster. Tapi dengan cepat.)

kegunaan dll algoritma rakituntuk menegosiasikan nilai sebelum menulisnya ke disk.
Artinya, sebagian besar kasus harus mencapai konsensus sebelum negara bagian dapat ditulis ke dll.

Jika latensi antara instance etcd meningkat secara dramatis, seperti halnya dengan tiga instance etcd di wilayah berbeda, diperlukan waktu lama untuk menegosiasikan nilai dan menulisnya ke disk.
Hal ini tercermin pada pengontrol Kubernetes.

Manajer pengontrol memerlukan lebih banyak waktu untuk mempelajari perubahan dan menulis respons ke database.

Dan karena pengontrolnya bukan hanya satu, melainkan beberapa, hasil reaksi berantai dan seluruh cluster mulai bekerja sangat lambat.

dlld sangat sensitif terhadap latensi Dokumentasi resmi merekomendasikan penggunaan SSD daripada hard drive biasa.

Saat ini tidak ada contoh jaringan besar yang bagus untuk satu cluster.

Pada dasarnya, komunitas pengembang dan grup cluster SIG mencoba mencari cara untuk mengatur cluster dengan cara yang sama seperti Kubernetes mengatur container.

Opsi 1: federasi cluster dengan kubefed

Tanggapan resmi dari SIG-cluster - kubefed2, versi baru dari klien dan operator federasi kube asli.

Untuk pertama kalinya, kami mencoba mengelola kumpulan cluster sebagai satu objek menggunakan alat federasi kube.

Awalnya bagus, namun pada akhirnya federasi kube tidak pernah menjadi populer karena tidak mendukung semua sumber daya.

Ini mendukung pengiriman dan layanan gabungan, tetapi tidak mendukung StatefulSets, misalnya.
Selain itu, konfigurasi federasi dikirimkan dalam bentuk anotasi dan tidak fleksibel.

Bayangkan bagaimana Anda bisa mendeskripsikan partisi replika untuk setiap cluster dalam federasi hanya dengan menggunakan anotasi.

Benar-benar berantakan.

Cluster SIG melakukan banyak pekerjaan setelah kubefed v1 dan memutuskan untuk mendekati masalah dari sudut pandang yang berbeda.

Alih-alih anotasi, mereka memutuskan untuk merilis pengontrol yang diinstal pada cluster. Itu dapat dikustomisasi menggunakan Custom Resource Definitions (CRDs).

Untuk setiap sumber daya yang akan menjadi bagian dari federasi, Anda memiliki definisi CRD khusus dengan tiga bagian:

• definisi standar sumber daya, misalnya penerapan;
• bagian placement, tempat Anda menentukan bagaimana sumber daya akan didistribusikan di federasi;
• bagian override, di mana untuk sumber daya tertentu Anda dapat mengganti bobot dan parameter dari penempatan.

Berikut adalah contoh pengiriman gabungan dengan bagian penempatan dan penggantian.

apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - image: nginx
              name: nginx
  placement:
    clusterNames:
      - cluster2
      - cluster1
  overrides:
    - clusterName: cluster2
      clusterOverrides:
        - path: spec.replicas
          value: 5

Seperti yang Anda lihat, pasokan didistribusikan ke dua cluster: cluster1 и cluster2.

Cluster pertama menyediakan tiga replika, dan cluster kedua diatur ke 5.

Jika kamu memerlukan kontrol lebih terhadap jumlah replika, kubefed2 menyediakan objek ReplicaSchedulingPreference baru dimana replika dapat diberi bobot:

apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-ns
spec:
  targetKind: FederatedDeployment
  totalReplicas: 9
  clusters:
    A:
      weight: 1
    B:
      weight: 2

Struktur CRD dan API belum siap, dan pekerjaan aktif sedang dilakukan di repositori resmi proyek.

Awasi kubefed2, tapi ingat bahwa ini belum cocok untuk produksi.

Pelajari lebih lanjut tentang kubefed2 dari artikel resmi tentang kubefed2 di blog tentang Kubernetes dan di repositori resmi proyek kubefed.

Opsi 2: menggabungkan cluster dengan gaya Booking.com

Pengembang Booking.com tidak mengerjakan kubefed v2, tetapi mereka menciptakan Pengirim - operator untuk pengiriman di beberapa cluster, di beberapa wilayah, dan di beberapa cloud.

Pengirim agak mirip dengan kubefed2.

Kedua alat tersebut memungkinkan Anda menyesuaikan strategi penerapan multi-kluster (kluster mana yang digunakan dan berapa banyak replika yang dimilikinya).

Tetapi Tujuan pengirim adalah untuk mengurangi risiko kesalahan selama pengiriman.

Di Pengirim, Anda dapat menentukan serangkaian langkah yang menjelaskan pembagian replika antara penerapan sebelumnya dan saat ini serta volume lalu lintas masuk.

Saat Anda memasukkan sumber daya ke sebuah klaster, pengontrol Pengirim secara bertahap meluncurkan perubahan tersebut ke seluruh klaster yang bergabung.

Selain itu, Pengirim sangat terbatas.

Misalnya, ia menerima diagram kemudi sebagai masukan dan tidak mendukung sumber daya vanilla.
Secara umum, Pengirim bekerja seperti ini.

Daripada pengiriman standar, Anda perlu membuat sumber daya aplikasi yang menyertakan bagan Helm:

apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
  name: super-server
spec:
  revisionHistoryLimit: 3
  template:
    chart:
      name: nginx
      repoUrl: https://storage.googleapis.com/shipper-demo
      version: 0.0.1
    clusterRequirements:
      regions:
        - name: local
    strategy:
      steps:
        - capacity:
            contender: 1
            incumbent: 100
          name: staging
          traffic:
            contender: 0
            incumbent: 100
        - capacity:
            contender: 100
            incumbent: 0
          name: full on
          traffic:
            contender: 100
            incumbent: 0
    values:
      replicaCount: 3

Pengirim adalah pilihan yang baik untuk mengelola banyak cluster, tetapi hubungan dekatnya dengan Helm hanya menghalangi.

Bagaimana jika kita semua beralih dari Helm ke sesuaikan или capitan?

Cari tahu lebih lanjut tentang Pengirim dan filosofinya di siaran pers resmi ini.

Jika Anda ingin menggali kodenya, buka repositori proyek resmi.

Opsi 3: penggabungan klaster “ajaib”.

Kubefed v2 dan Shipper bekerja dengan federasi klaster, menyediakan sumber daya baru ke klaster melalui definisi sumber daya khusus.

Namun bagaimana jika Anda tidak ingin menulis ulang semua pengiriman, StatefulSets, DaemonSets, dll. untuk digabungkan?

Bagaimana cara memasukkan cluster yang ada ke dalam federasi tanpa mengubah YAML?

penjadwal multi-cluster adalah proyek Admirality, yang berhubungan dengan penjadwalan beban kerja pada cluster.

Namun alih-alih menemukan cara baru untuk berinteraksi dengan cluster dan menggabungkan sumber daya dalam definisi khusus, penjadwal multi-cluster tertanam dalam siklus hidup Kubernetes standar dan mencegat semua panggilan yang membuat pod.

Setiap pod yang dibuat segera diganti dengan boneka.

penggunaan penjadwal multi-cluster webhook untuk modifikasi aksesuntuk mencegat panggilan dan membuat pod tiruan yang menganggur.

Pod asli melewati siklus perencanaan lain di mana, setelah melakukan survei terhadap seluruh federasi, keputusan penempatan dibuat.

Terakhir, pod dikirimkan ke cluster target.

Hasilnya, Anda memiliki pod tambahan yang tidak melakukan apa pun, hanya memakan ruang.

Keuntungannya adalah Anda tidak perlu menulis sumber daya baru untuk menggabungkan persediaan.

Setiap sumber daya yang membuat pod secara otomatis siap untuk digabungkan.

Ini menarik, karena tiba-tiba Anda memiliki perbekalan yang tersebar di beberapa wilayah, dan Anda bahkan tidak menyadarinya. Namun, hal ini cukup beresiko, karena semua yang ada di sini bertumpu pada sihir.

Namun sementara Pengirim mencoba untuk mengurangi sebagian besar dampak pengiriman, penjadwal multi-cluster menangani tugas-tugas yang lebih umum dan mungkin lebih cocok untuk pekerjaan batch.

Ia tidak memiliki mekanisme penyampaian bertahap yang canggih.

Lebih lanjut tentang penjadwal multi-cluster dapat ditemukan di halaman repositori resmi.

Jika Anda ingin membaca tentang aksi multi-cluster-scheduler, Admiralty punya kasus penggunaan yang menarik dengan Argo — alur kerja, acara, CI dan CD Kubernetes.

Alat dan solusi lainnya

Menghubungkan dan mengelola beberapa cluster adalah tugas yang kompleks, dan tidak ada solusi universal.

Jika Anda ingin menjelajahi topik ini lebih jauh, berikut beberapa sumber:

• Kapal Selam oleh Rancher adalah alat yang menghubungkan jaringan overlay dari cluster Kubernetes yang berbeda.
• Jaringan ritel Target menggunakan Unimatrix dikombinasikan dengan Spinnaker untuk mengatur penerapan di beberapa cluster.
• Coba gunakan IPV6 dan jaringan tunggal di beberapa wilayah.
• Anda dapat menggunakan jaring layanan, misalnya Istio untuk menghubungkan beberapa cluster.
• Cilium, plugin antarmuka jaringan kontainer, menawarkan fungsi jaring cluster, yang memungkinkan Anda menggabungkan beberapa cluster

Itu saja untuk hari ini

Terima kasih telah membaca sampai akhir!

Jika Anda mengetahui cara menghubungkan beberapa cluster dengan lebih efisien, Beritahu kami.

Kami akan menambahkan metode Anda ke tautan.

Terima kasih khusus kepada Chris Nesbitt-Smith (Chris Nesbitt-Smith) dan Vincent de Sme (Vincent De Smet) (insinyur keandalan di swatmobile.io) untuk membaca artikel dan berbagi informasi berguna tentang cara kerja federasi.

Sumber: www.habr.com