Cara menyambungkan kluster Kubernetes dalam pusat data yang berbeza

Selamat datang ke siri Mula Pantas Kubernetes kami. Ini adalah lajur biasa dengan soalan paling menarik yang kami terima dalam talian dan dalam latihan kami. Jawapan pakar Kubernetes.

Pakar hari ini ialah Daniel Polenchik (Daniele Polencic). Daniel bekerja sebagai pengajar dan pembangun perisian di Learnk8s.

Jika anda ingin soalan anda dijawab dalam entri seterusnya, hubungi kami melalui e-mel atau Twitter: @learnk8s.

Terlepas siaran sebelumnya? Cari mereka di sini.

Bagaimana untuk menyambungkan kluster Kubernetes di pusat data yang berbeza?

Secara ringkas: Kubefed v2 akan datang tidak lama lagi, dan saya juga mengesyorkan membaca tentang Pengirim и projek multi-cluster-scheduler.

Selalunya, infrastruktur direplikasi dan diedarkan ke seluruh wilayah yang berbeza, terutamanya dalam persekitaran terkawal.

Jika satu wilayah tidak tersedia, lalu lintas diubah hala ke kawasan lain untuk mengelakkan gangguan.

Dengan Kubernetes, anda boleh menggunakan strategi yang serupa dan mengagihkan beban kerja ke seluruh wilayah yang berbeza.

Anda boleh mempunyai satu atau lebih kelompok bagi setiap pasukan, wilayah, persekitaran atau gabungan elemen ini.

Kelompok anda boleh dihoskan di awan dan di premis yang berbeza.

Tetapi bagaimana anda merancang infrastruktur untuk penyebaran geografi sedemikian?
Adakah anda perlu mencipta satu kluster besar untuk beberapa persekitaran awan melalui satu rangkaian?
Atau mempunyai banyak gugusan kecil dan mencari cara untuk mengawal dan menyegerakkannya?

Satu kluster kepimpinan

Mewujudkan satu kluster melalui satu rangkaian tidak begitu mudah.

Bayangkan anda mengalami kemalangan, ketersambungan antara segmen kluster hilang.

Jika anda mempunyai satu pelayan induk, separuh daripada sumber tidak akan dapat menerima arahan baharu kerana mereka tidak akan dapat menghubungi induk.

Dan pada masa yang sama anda mempunyai jadual penghalaan lama (kube-proxy tidak boleh memuat turun yang baharu) dan tiada pod tambahan (kubelet tidak boleh meminta kemas kini).

Lebih memburukkan keadaan, jika Kubernetes tidak melihat nod, ia menandakannya sebagai yatim piatu dan mengedarkan pod yang hilang ke nod sedia ada.

Akibatnya, anda mempunyai dua kali lebih banyak pod.

Jika anda membuat satu pelayan induk untuk setiap rantau, akan ada masalah dengan algoritma konsensus dalam pangkalan data etcd. (lebih kurang ed. — Sebenarnya, pangkalan data etcd tidak semestinya perlu ditempatkan pada pelayan induk. Ia boleh dijalankan pada kumpulan pelayan yang berasingan di rantau yang sama. Benar, pada masa yang sama mendapat titik kegagalan kelompok. Tetapi dengan cepat.)

kegunaan etcd algoritma rakituntuk merundingkan nilai sebelum menulisnya ke cakera.
Iaitu, majoriti contoh mesti mencapai konsensus sebelum negeri boleh ditulis kepada etcd.

Jika kependaman antara kejadian etcd meningkat secara mendadak, seperti halnya dengan tiga kejadian etcd di kawasan berbeza, ia mengambil masa yang lama untuk merundingkan nilai dan menulisnya ke cakera.
Ini ditunjukkan dalam pengawal Kubernetes.

Pengurus pengawal memerlukan lebih banyak masa untuk mengetahui tentang perubahan dan menulis respons kepada pangkalan data.

Dan kerana tidak ada satu pengawal, tetapi beberapa, tindak balas berantai terhasil dan keseluruhan kluster mula berfungsi dengan sangat perlahan.

etcd sangat sensitif kependaman itu Dokumentasi rasmi mengesyorkan menggunakan SSD dan bukannya pemacu keras biasa.

Pada masa ini tiada contoh rangkaian besar yang baik untuk satu kelompok.

Pada asasnya, komuniti pembangun dan kumpulan SIG-cluster cuba memikirkan cara mengatur kelompok dengan cara yang sama Kubernetes mengatur kontena.

Pilihan 1: persekutuan kelompok dengan kubefed

Maklum balas rasmi daripada SIG-cluster - kubefed2, versi baharu pelanggan dan pengendali persekutuan kube asal.

Buat pertama kalinya, kami cuba menguruskan koleksi kluster sebagai objek tunggal menggunakan alat persekutuan kube.

Permulaannya bagus, tetapi akhirnya persekutuan kube tidak pernah menjadi popular kerana ia tidak menyokong semua sumber.

Ia menyokong penghantaran dan perkhidmatan bersekutu, tetapi bukan StatefulSets, sebagai contoh.
Selain itu, konfigurasi persekutuan telah dihantar dalam bentuk anotasi dan tidak fleksibel.

Bayangkan bagaimana anda boleh menerangkan pembahagian replika untuk setiap kelompok dalam persekutuan hanya menggunakan anotasi.

Ia benar-benar huru-hara.

Kluster SIG melakukan banyak kerja selepas kubefed v1 dan memutuskan untuk mendekati masalah dari sudut yang berbeza.

Daripada anotasi, mereka memutuskan untuk mengeluarkan pengawal yang dipasang pada kelompok. Ia boleh disesuaikan menggunakan Definisi Sumber Tersuai (CRD).

Untuk setiap sumber yang akan menjadi sebahagian daripada persekutuan, anda mempunyai definisi CRD tersuai dengan tiga bahagian:

• takrifan standard sumber, contohnya penempatan;
• seksyen placement, di mana anda menentukan cara sumber itu akan diagihkan dalam persekutuan;
• seksyen override, di mana untuk sumber tertentu anda boleh mengatasi berat dan parameter daripada peletakan.

Berikut ialah contoh penghantaran gabungan dengan bahagian peletakan dan ganti.

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, bekalan diedarkan di dua kelompok: cluster1 и cluster2.

Kelompok pertama membekalkan tiga replika, dan yang kedua ditetapkan kepada 5.

Jika anda memerlukan lebih kawalan ke atas bilangan replika, kubefed2 menyediakan objek ReplicaSchedulingPreference baharu di mana replika boleh ditimbang:

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 masih belum cukup sedia, dan kerja aktif sedang dijalankan di repositori projek rasmi.

Perhatikan kubefed2, tetapi ingat bahawa ia belum sesuai untuk pengeluaran.

Ketahui lebih lanjut tentang kubefed2 daripada artikel rasmi tentang kubefed2 dalam blog tentang Kubernetes dan dalam repositori rasmi projek kubefed.

Pilihan 2: menggabungkan kluster dalam gaya Booking.com

Pembangun Booking.com tidak berfungsi pada kubefed v2, tetapi mereka menghasilkan Shipper - pengendali untuk penghantaran pada beberapa kluster, di beberapa wilayah dan di beberapa awan.

Pengirim agak serupa dengan kubefed2.

Kedua-dua alatan membolehkan anda menyesuaikan strategi penggunaan berbilang kelompok anda (kelompok yang digunakan dan bilangan replika yang mereka ada).

Tetapi Matlamat penghantar adalah untuk mengurangkan risiko ralat semasa penghantaran.

Dalam Shipper, anda boleh menentukan satu siri langkah yang menerangkan pembahagian replika antara penggunaan sebelumnya dan semasa dan jumlah trafik masuk.

Apabila anda menolak sumber ke kluster, pengawal Pengirim secara berperingkat melancarkan perubahan itu merentas semua kluster yang dicantumkan.

Juga, Penghantar adalah sangat terhad.

Sebagai contoh, ia menerima carta helm sebagai input dan tidak menyokong sumber vanila.
Secara umum, Shipper berfungsi seperti ini.

Daripada penghantaran standard, anda perlu mencipta sumber aplikasi yang merangkumi carta 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 ialah pilihan yang baik untuk mengurus berbilang kelompok, tetapi hubungan rapatnya dengan Helm hanya menghalang.

Bagaimana jika kita semua bertukar dari Helm kepada menyesuaikan atau kapitan?

Ketahui lebih lanjut tentang Shipper dan falsafahnya di kenyataan akhbar rasmi ini.

Jika anda ingin menggali kod, pergi ke repositori projek rasmi.

Pilihan 3: penggabungan kelompok "ajaib".

Kubefed v2 dan Shipper bekerjasama dengan persekutuan kluster, menyediakan sumber baharu kepada kluster melalui definisi sumber tersuai.

Tetapi bagaimana jika anda tidak mahu menulis semula semua penghantaran, StatefulSets, DaemonSets, dll. untuk digabungkan?

Bagaimana untuk memasukkan kluster sedia ada dalam persekutuan tanpa mengubah YAML?

multi-cluster-scheduler ialah projek Admirality, yang berkaitan dengan penjadualan beban kerja pada kelompok.

Tetapi bukannya menghasilkan cara baharu untuk berinteraksi dengan kluster dan membungkus sumber dalam definisi tersuai, penjadual berbilang kluster dibenamkan dalam kitaran hayat Kubernetes standard dan memintas semua panggilan yang mencipta pod.

Setiap pod yang dibuat segera digantikan dengan dummy.

kegunaan penjadual berbilang kelompok webhooks untuk pengubahsuaian aksesuntuk memintas panggilan dan mencipta pod tiruan terbiar.

Pod asal melalui kitaran perancangan lain di mana, selepas mengundi seluruh persekutuan, keputusan penempatan dibuat.

Akhirnya, pod dihantar ke kluster sasaran.

Akibatnya, anda mempunyai pod tambahan yang tidak melakukan apa-apa, hanya mengambil ruang.

Kelebihannya ialah anda tidak perlu menulis sumber baharu untuk menggabungkan bekalan.

Setiap sumber yang mencipta pod sedia secara automatik untuk digabungkan.

Ini menarik, kerana tiba-tiba anda mempunyai bekalan yang diedarkan di beberapa wilayah, dan anda tidak menyedarinya. Walau bagaimanapun, ini agak berisiko, kerana segala-galanya di sini bergantung pada sihir.

Tetapi sementara Shipper cuba untuk mengurangkan kesan penghantaran, penjadual berbilang kelompok mengendalikan tugas yang lebih umum dan mungkin lebih sesuai untuk kerja kelompok.

Ia tidak mempunyai mekanisme penghantaran berperingkat lanjutan.

Lebih lanjut mengenai multi-cluster-scheduler boleh didapati di halaman repositori rasmi.

Jika anda ingin membaca tentang penjadual berbilang kelompok dalam tindakan, Admiralty ada kes penggunaan yang menarik dengan Argo — aliran kerja, acara, CI dan CD Kubernetes.

Alat dan penyelesaian lain

Menyambung dan mengurus berbilang kluster adalah tugas yang kompleks, dan tiada penyelesaian universal.

Jika anda ingin meneroka topik ini dengan lebih lanjut, berikut ialah beberapa sumber:

• Kapal selam oleh Penternak ialah alat yang menghubungkan rangkaian tindanan bagi kelompok Kubernetes yang berbeza.
• Penggunaan sasaran rantaian runcit Unimatrix digabungkan dengan Spinnaker untuk mengatur penggunaan merentas berbilang kelompok.
• Cuba gunakan IPV6 dan rangkaian tunggal di beberapa wilayah.
• Anda boleh menggunakan jaringan perkhidmatan, sebagai contoh Istio untuk menyambungkan berbilang kelompok.
• Cilium, pemalam antara muka rangkaian kontena, menawarkan fungsi jaringan kluster, yang membolehkan anda menggabungkan beberapa kluster

Itu sahaja untuk hari ini

Terima kasih kerana membaca sehingga habis!

Jika anda tahu cara menyambung berbilang kluster dengan lebih cekap, beritahu kami.

Kami akan menambah kaedah anda pada pautan.

Terima kasih khas kepada Chris Nesbitt-Smith (Chris Nesbitt-Smith) dan Vincent de Sme (Vincent De Smet) (jurutera kebolehpercayaan dalam swatmobile.io) untuk membaca artikel dan berkongsi maklumat berguna tentang cara persekutuan berfungsi.

Sumber: www.habr.com