Cara nyambungake kluster Kubernetes ing pusat data sing beda

Sugeng rawuh ing seri Kubernetes Quick Start. Iki minangka kolom biasa kanthi pitakonan sing paling menarik sing ditampa kanthi online lan ing latihan. Jawaban pakar Kubernetes.

Pakar saiki yaiku Daniel Polenchik (Daniele Polencik). Daniel kerja minangka instruktur lan pangembang piranti lunak ing Sinau 8s.

Yen sampeyan pengin pitakonan sampeyan dijawab ing kiriman sabanjure, hubungi kita liwat email utawa ing Twitter: @learnk8s.

Ora kejawab kiriman sadurunge? Golek wong kene.

Kepiye cara nyambungake kluster Kubernetes ing pusat data sing beda-beda?

Sedhela: Kubefed v2 teka rauh, lan aku uga nyaranake maca babagan Pengirim и project multi-cluster-scheduler.

Asring, infrastruktur ditiru lan disebarake ing macem-macem wilayah, utamane ing lingkungan sing dikontrol.

Yen siji wilayah ora kasedhiya, lalu lintas dialihake menyang wilayah liyane supaya ora ana gangguan.

Kanthi Kubernetes, sampeyan bisa nggunakake strategi sing padha lan nyebarake beban kerja ing macem-macem wilayah.

Sampeyan bisa duwe siji utawa luwih klompok saben tim, wilayah, lingkungan, utawa kombinasi unsur kasebut.

Kluster sampeyan bisa dadi tuan rumah ing macem-macem awan lan ing papan.

Nanging kepiye sampeyan ngrancang infrastruktur kanggo panyebaran geografis kasebut?
Apa sampeyan kudu nggawe siji kluster gedhe kanggo sawetara lingkungan maya liwat jaringan siji?
Utawa duwe akeh klompok cilik lan golek cara kanggo ngontrol lan nyinkronake?

Siji klompok pimpinan

Nggawe siji cluster liwat jaringan siji ora supaya gampang.

Mbayangno sampeyan duwe kacilakan, konektivitas antarane segmen kluster ilang.

Yen sampeyan duwe server master siji, setengah saka sumber daya ora bakal bisa nampa printah anyar amarga padha ora bisa ngubungi master.

Lan ing wektu sing padha sampeyan duwe tabel routing lawas (kube-proxy ora bisa ngundhuh sing anyar) lan ora ana pod tambahan (kubelet ora bisa njaluk nganyari).

Sing luwih elek, yen Kubernetes ora weruh simpul, iku menehi tandha minangka yatim piatu lan nyebarake pod sing ilang menyang simpul sing ana.

Akibaté, sampeyan duwe polong kaping pindho.

Yen sampeyan nggawe siji server master kanggo saben wilayah, bakal ana masalah karo algoritma konsensus ing database etcd. (kira-kira. ed. - Nyatane, database etcd ora kudu ana ing server master. Bisa mbukak ing klompok server sing kapisah ing wilayah sing padha. Bener, ing wektu sing padha entuk titik kegagalan kluster. Nanging cepet.)

etcd nggunakake algoritma rakitkanggo rembugan Nilai sadurunge nulis menyang disk.
Tegese, mayoritas kasus kudu tekan konsensus sadurunge negara bisa ditulis kanggo etcd.

Yen latensi antarane etcd kedadean mundhak dramatically, minangka kasus karo telung etcd kedadean ing wilayah beda, iku njupuk wektu dawa kanggo rembugan Nilai lan nulis menyang disk.
Iki dibayangke ing pengontrol Kubernetes.

Manajer pengontrol mbutuhake wektu luwih akeh kanggo sinau babagan owah-owahan lan nulis respon menyang database.

Lan amarga ora ana siji controller, nanging sawetara, asil reaksi chain lan kabeh kluster wiwit bisa alon banget.

etcd dadi latensi sensitif sing Dokumentasi resmi nyaranake nggunakake SSD tinimbang hard drive biasa.

Saiki ora ana conto sing apik babagan jaringan gedhe kanggo klompok siji.

Sejatine, komunitas pangembang lan grup SIG-cluster nyoba ngerteni carane ngatur kluster kanthi cara sing padha Kubernetes ngatur kontainer.

Pilihan 1: federasi kluster karo kubefed

Tanggapan resmi saka SIG-cluster - kubefed2, versi anyar saka klien lan operator federasi kube asli.

Kanggo pisanan, kita nyoba ngatur koleksi klompok minangka obyek siji nggunakake alat federasi kube.

Wiwitane apik, nanging pungkasane federasi kube ora tau populer amarga ora ndhukung kabeh sumber daya.

Iki ndhukung pangiriman lan layanan federasi, nanging ora StatefulSets, contone.
Uga, konfigurasi federasi ditularake ing bentuk anotasi lan ora fleksibel.

Mbayangno carane sampeyan bisa njlèntrèhaké partisi tiron kanggo saben kluster ing federasi mung nggunakake anotasi.

Iku kekacoan lengkap.

SIG-kluster nindakake akeh karya sawise kubefed v1 lan mutusake kanggo nyedhaki masalah saka sudut sing beda.

Tinimbang anotasi, dheweke mutusake ngeculake pengontrol sing dipasang ing kluster. Bisa disesuaikan nggunakake Custom Resource Definition (CRDs).

Kanggo saben sumber daya sing bakal dadi bagian saka federasi, sampeyan duwe definisi CRD khusus kanthi telung bagean:

• definisi standar sumber, contone panyebaran;
• bagean placement, ing ngendi sampeyan nemtokake cara sumber daya bakal disebarake ing federasi;
• bagean override, ing ngendi kanggo sumber tartamtu sampeyan bisa ngatasi bobot lan paramèter saka panggonan.

Iki minangka conto pangiriman gabungan karo bagean panggonan lan override.

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

Kaya sing sampeyan ngerteni, pasokan kasebut disebar ing rong klompok: cluster1 и cluster2.

Kluster pisanan nyedhiyakake telung replika, lan sing kapindho disetel dadi 5.

Yen sampeyan butuh kontrol luwih akeh babagan jumlah replika, kubefed2 nyedhiyakake obyek ReplicaSchedulingPreference anyar ing ngendi replika bisa 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 lan API durung siap, lan karya aktif ditindakake ing gudang proyek resmi.

Tansah mripat ing kubefed2, nanging elinga yen iku durung cocok kanggo produksi.

Sinau luwih lengkap babagan kubefed2 saka artikel resmi babagan kubefed2 ing blog babagan Kubernetes lan ing repositori resmi proyek kubefed.

Pilihan 2: nggabungake klompok ing gaya Booking.com

Pangembang Booking.com ora bisa digunakake ing kubefed v2, nanging padha teka karo Shipper - operator kanggo pangiriman ing sawetara kluster, ing sawetara wilayah lan ing sawetara awan.

Pengirim rada padha karo kubefed2.

Piranti loro kasebut ngidini sampeyan ngatur strategi panyebaran multi-cluster (kluster sing digunakake lan jumlah replika).

Nanging Tujuane Shipper yaiku nyuda risiko kesalahan sajrone pangiriman.

Ing Shipper, sampeyan bisa nemtokake sawetara langkah sing njlèntrèhaké divisi saka replika antarane penyebaran sadurunge lan saiki lan volume lalu lintas mlebu.

Nalika sampeyan push sumber menyang kluster, controller Shipper nambah owah-owahan ing kabeh klompok gabungan.

Uga, Shipper winates banget.

Contone, iku nampa denah helm minangka input lan ora ndhukung sumber daya vanilla.
Ing istilah umum, Shipper dianggo kaya iki.

Tinimbang pangiriman standar, sampeyan kudu nggawe sumber daya aplikasi sing kalebu 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

Shipper minangka pilihan sing apik kanggo ngatur macem-macem klompok, nanging hubungane sing cedhak karo Helm mung dadi alangan.

Apa yen kita kabeh ngalih saka Helm kanggo ngatur utawa kapten?

Ngerteni luwih akeh babagan Shipper lan filosofi ing release pers resmi iki.

Yen sampeyan pengin dig menyang kode, pindhah menyang repositori proyek resmi.

Opsi 3: gabung kluster "sihir".

Kubefed v2 lan Shipper nggarap federasi kluster, nyedhiyakake sumber daya anyar kanggo kluster liwat definisi sumber daya khusus.

Nanging kepiye yen sampeyan ora pengin nulis ulang kabeh kiriman, StatefulSets, DaemonSets, lsp.

Kepiye cara nyakup kluster sing ana ing federasi tanpa ngganti YAML?

multi-cluster-scheduler iku sawijining project Admirality, sing ngurusi jadwal kerja ing kluster.

Nanging tinimbang teka munggah karo cara anyar kanggo sesambungan karo kluster lan mbungkus sumber ing definisi adat, multi-cluster-scheduler ditempelake ing siklus urip Kubernetes standar lan intercepts kabeh telpon sing nggawe pods.

Saben pod sing digawe langsung diganti nganggo goblok.

nggunakake multi-cluster-scheduler webhooks kanggo modifikasi akseskanggo nyegat telpon lan nggawe polong goblok.

Pod asli ngliwati siklus perencanaan liyane ing ngendi, sawise polling kabeh federasi, keputusan penempatan digawe.

Pungkasan, polong dikirim menyang kluster target.

Akibaté, sampeyan duwe pod ekstra sing ora apa-apa, mung njupuk munggah spasi.

Kauntungane yaiku sampeyan ora kudu nulis sumber daya anyar kanggo nggabungake pasokan.

Saben sumber daya sing nggawe pod siap digabungake kanthi otomatis.

Iki menarik, amarga dumadakan sampeyan duwe persediaan sing disebar ing sawetara wilayah, lan sampeyan ora ngerti. Nanging, iki cukup beboyo, amarga kabeh kene gumantung ing sihir.

Nanging nalika Shipper nyoba kanggo nyuda pengaruh pangiriman, multi-cluster-scheduler nangani tugas sing luwih umum lan bisa uga luwih cocog kanggo proyek batch.

Ora duwe mekanisme pangiriman bertahap sing luwih maju.

Liyane babagan multi-cluster-scheduler bisa ditemokake ing kaca panyimpenan resmi.

Yen sampeyan pengin maca babagan multi-cluster-scheduler ing tumindak, Admiralty wis kasus panggunaan menarik karo Argo - alur kerja, acara, CI lan CD Kubernetes.

Piranti lan solusi liyane

Nyambungake lan ngatur macem-macem klompok minangka tugas sing rumit, lan ora ana solusi universal.

Yen sampeyan pengin njelajah topik iki luwih lanjut, kene sawetara sumber:

• Submariner dening Rancher minangka alat sing nyambungake jaringan overlay kluster Kubernetes sing beda.
• Retail chain Target nggunakake Unimatrix digabungake karo Spinnaker kanggo ngatur penyebaran ing pirang-pirang kluster.
• Coba nggunakake IPV6 lan jaringan tunggal ing sawetara wilayah.
• Sampeyan bisa nggunakake bolong layanan, contone Istio kanggo nyambungake sawetara kluster.
• Cilium, plugin antarmuka jaringan wadhah, nawakake fungsi cluster mesh, sing ngidini sampeyan nggabungake sawetara klompok

Sing kabeh kanggo dina iki

Matur nuwun kanggo maca nganti pungkasan!

Yen sampeyan ngerti carane nyambungake macem-macem klompok luwih efisien, ceritakno nang kene.

Kita bakal nambah cara sampeyan menyang tautan.

Matur nuwun khusus kanggo Chris Nesbitt-Smith (Chris Nesbitt-Smithlan Vincent de Sme (Vincent De Smet) (Insinyur keandalan ing swatmobile.io) kanggo maca artikel lan nuduhake informasi sing migunani babagan cara kerja federasi.

Source: www.habr.com