🥇Farklı veri merkezlerindeki Kubernetes kümeleri nasıl bağlanır

Kubernetes Hızlı Başlangıç serimize hoş geldiniz. Bu, çevrimiçi ortamda ve eğitimlerimizde aldığımız en ilginç soruların yer aldığı düzenli bir sütundur. Kubernetes uzmanı yanıtları.

Bugünün uzmanı Daniel Polenchik (Daniele Polencic). Daniel, eğitmen ve yazılım geliştiricisi olarak çalışıyor Learnk8'ler.

Sorunuzun bir sonraki yazıda yanıtlanmasını istiyorsanız, e-posta yoluyla bize ulaşın veya Twitter: @learnk8s.

Önceki gönderileri kaçırdınız mı? Onları burada bul.

Farklı veri merkezlerindeki Kubernetes kümeleri nasıl bağlanır?

kısaca: Kubefed v2 yakında geliyorayrıca şunları okumanızı da tavsiye ederim nakliyeci и çoklu küme zamanlayıcı projesi.

Çoğu zaman altyapı, özellikle kontrollü ortamlarda, farklı bölgelere kopyalanır ve dağıtılır.

Bir bölgenin kullanılamaması durumunda, kesintileri önlemek için trafik başka bir bölgeye yönlendirilir.

Kubernetes ile benzer bir strateji kullanabilir ve iş yüklerini farklı bölgelere dağıtabilirsiniz.

Ekip, bölge, ortam veya bu öğelerin birleşimi başına bir veya daha fazla kümeniz olabilir.

Kümeleriniz farklı bulutlarda ve şirket içinde barındırılabilir.

Peki bu kadar coğrafi yayılma için altyapıyı nasıl planlıyorsunuz?
Tek bir ağ üzerinden birden fazla bulut ortamı için büyük bir küme oluşturmanız mı gerekiyor?
Veya çok sayıda küçük kümeniz var ve bunları kontrol edip senkronize etmenin bir yolunu mu arıyorsunuz?

Tek bir liderlik kümesi

Tek bir ağ üzerinden tek bir küme oluşturmak o kadar kolay değil.

Bir kaza geçirdiğinizi, küme bölümleri arasındaki bağlantının kesildiğini düşünün.

Bir ana sunucunuz varsa, kaynakların yarısı ana sunucuyla iletişim kuramayacağı için yeni komutlar alamayacaktır.

Ve aynı zamanda eski yönlendirme tablolarınız var (kube-proxy yenilerini indiremez) ve ek bölme yoktur (kubelet güncelleme talep edemez).

Daha da kötüsü, Kubernetes bir düğüm göremezse onu yetim olarak işaretler ve eksik bölmeleri mevcut düğümlere dağıtır.

Sonuç olarak, iki kat daha fazla kapsülünüz var.

Her bölge için bir ana sunucu yaparsanız,etcd veritabanındaki konsensüs algoritmasında sorunlar yaşanacaktır. (yaklaşık. ed. — Aslında, etcd veritabanının mutlaka ana sunucularda bulunması gerekmez. Aynı bölgedeki ayrı bir sunucu grubunda çalıştırılabilir. Doğru, aynı zamanda kümenin başarısızlık noktasına da ulaşıyoruz. Ama hızlıca.)

vbd kullanımları sal algoritmasıDeğeri diske yazmadan önce görüşmek için.
Yani, durumun etcd'ye yazılabilmesi için örneklerin çoğunluğunun fikir birliğine varması gerekir.

Farklı bölgelerdeki üç etcd örneğinde olduğu gibi, etcd örnekleri arasındaki gecikme önemli ölçüde artarsa, bir değer üzerinde anlaşmak ve onu diske yazmak uzun zaman alır.
Bu, Kubernetes denetleyicilerine de yansır.

Denetleyici yöneticisinin değişikliği öğrenmesi ve yanıtı veritabanına yazması için daha fazla zamana ihtiyacı vardır.

Ve tek bir kontrolör değil birden fazla kontrolör olduğundan, bir zincirleme reaksiyon ortaya çıkar ve tüm küme çok yavaş çalışmaya başlar.

vbd gecikmeye o kadar duyarlı ki Resmi belgeler normal sabit diskler yerine SSD'lerin kullanılmasını önerir.

Şu anda tek bir küme için büyük bir ağın iyi bir örneği yoktur.

Temel olarak, geliştirici topluluğu ve SIG kümesi grubu, Kubernetes'in konteynerleri düzenlediği gibi kümeleri de nasıl düzenleyeceğini bulmaya çalışıyor.

Seçenek 1: kubefed ile küme federasyonu

SIG kümesinden resmi yanıt - kubefed2, orijinal kube federasyon istemcisi ve operatörünün yeni bir sürümü.

İlk defa bir küme koleksiyonunu kube federasyon aracını kullanarak tek bir nesne olarak yönetmeye çalıştık.

Başlangıç iyiydi ama sonunda kube federasyonu tüm kaynakları desteklemediği için hiçbir zaman popüler olamadı.

Örneğin, birleşik teslimatları ve hizmetleri destekledi, ancak StatefulSets'i desteklemedi.
Ayrıca federasyon konfigürasyonu ek açıklamalar şeklinde aktarıldı ve esnek değildi.

Yalnızca ek açıklamaları kullanarak bir federasyondaki her küme için çoğaltma bölümlemesini nasıl tanımlayabileceğinizi hayal edin.

Tam bir karmaşaydı.

SIG-cluster kubefed v1'den sonra birçok çalışma yaptı ve soruna farklı bir açıdan yaklaşmaya karar verdi.

Ek açıklamalar yerine kümelere kurulu bir denetleyiciyi piyasaya sürmeye karar verdiler. Özel Kaynak Tanımları (CRD'ler) kullanılarak özelleştirilebilir.

Federasyonun parçası olacak her kaynak için üç bölümden oluşan özel bir CRD tanımınız vardır:

bir kaynağın standart tanımı, örneğin dağıtım;
bölüm placementkaynağın federasyonda nasıl dağıtılacağını tanımladığınız yer;
bölüm override, burada belirli bir kaynak için ağırlığı ve parametreleri yerleşimden geçersiz kılabilirsiniz.

Yerleştirme ve geçersiz kılma bölümleriyle birleştirilmiş teslimatın bir örneğini burada bulabilirsiniz.

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

Gördüğünüz gibi tedarik iki kümeye dağıtılıyor: cluster1 и cluster2.

İlk küme üç kopya sağlar ve ikincisi 5'e ayarlanır.

Replika sayısı üzerinde daha fazla kontrole ihtiyacınız varsa kubefed2, replikaların ağırlıklandırılabileceği yeni bir ReplicaSchedulingPreference nesnesi sağlar:

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

CRD yapısı ve API henüz tam olarak hazır değil ve resmi proje deposunda aktif çalışmalar sürüyor.

Kubefed2'ye göz kulak olun ancak henüz üretime uygun olmadığını unutmayın.

Kubefed2 hakkında daha fazla bilgiyi şuradan alabilirsiniz: kubefed2 hakkında resmi makale Kubernetes hakkındaki blogda ve kubefed projesinin resmi deposu.

Seçenek 2: Kümeleri Booking.com tarzında birleştirmek

Booking.com'un geliştiricileri kubefed v2 üzerinde çalışmadı, ancak çeşitli kümelerde, çeşitli bölgelerde ve çeşitli bulutlarda teslimat yapan bir operatör olan Shipper'ı buldular.

nakliyeci kubefed2'ye biraz benzer.

Her iki araç da çoklu küme dağıtım stratejinizi (hangi kümelerin kullanıldığı ve kaç kopyaya sahip oldukları) özelleştirmenize olanak tanır.

Ancak Göndericinin amacı teslimat sırasında hata riskini azaltmaktır.

Shipper'da, kopyaların önceki ve geçerli dağıtım ile gelen trafiğin hacmi arasındaki bölümünü açıklayan bir dizi adım tanımlayabilirsiniz.

Bir kaynağı bir kümeye gönderdiğinizde, Gönderici denetleyicisi bu değişikliği birleştirilmiş tüm kümelere aşamalı olarak dağıtır.

Ayrıca Gönderici çok sınırlıdır.

Örneğin, dümen çizelgelerini girdi olarak kabul eder ve vanilya kaynaklarını desteklemez.
Genel anlamda Shipper bu şekilde çalışır.

Standart teslimat yerine Helm grafiği içeren bir uygulama kaynağı oluşturmanız gerekir:

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, birden fazla kümeyi yönetmek için iyi bir seçenektir ancak Helm ile olan yakın ilişkisi yalnızca buna engel olur.

Ya hepimiz Helm'den Helm'e geçersek kişiselleştirmek veya kapitan?

Shipper ve felsefesi hakkında daha fazla bilgiyi şu adreste bulabilirsiniz: bu resmi basın açıklaması.

Kodun içine girmek istiyorsanız, resmi proje deposuna gidin.

Seçenek 3: "sihirli" küme birleştirme

Kubefed v2 ve Shipper, küme federasyonuyla çalışarak özel kaynak tanımı yoluyla kümelere yeni kaynaklar sağlar.

Peki ya tüm teslimatları, StatefulSet'leri, DaemonSet'leri vb. birleştirmek için yeniden yazmak istemiyorsanız?

YAML'yi değiştirmeden mevcut bir kümeyi bir federasyona nasıl dahil edebilirim?

çoklu küme zamanlayıcı bir Admirality projesidir, kümelerdeki iş yüklerinin planlanmasıyla ilgilenir.

Ancak kümeyle etkileşim kurmanın ve kaynakları özel tanımlara sarmanın yeni bir yolunu bulmak yerine, çoklu küme zamanlayıcı, standart Kubernetes yaşam döngüsüne yerleştirilmiştir ve bölmeler oluşturan tüm çağrıları engeller.

Oluşturulan her kapsül hemen bir kukla ile değiştirilir.

çoklu küme zamanlayıcı kullanımları erişim değişikliği için web kancalarıçağrıyı kesmek ve boşta kalan bir kukla bölme oluşturmak için.

Orijinal bölme, tüm federasyonun oylamasının ardından bir yerleştirme kararının verildiği başka bir planlama döngüsünden geçer.

Son olarak kapsül hedef kümeye teslim edilir.

Sonuç olarak, hiçbir şey yapmayan, yalnızca yer kaplayan fazladan bir bölmeye sahip olursunuz.

Bunun avantajı, malzemeleri birleştirmek için yeni kaynaklar yazmanıza gerek kalmamasıdır.

Kapsül oluşturan her kaynak otomatik olarak birleştirilmeye hazırdır.

Bu ilginç çünkü birdenbire birden fazla bölgeye dağıtılan malzemeler var ve farkına bile varmadınız. Ancak bu oldukça riskli çünkü burada her şey sihire dayanıyor.

Ancak Shipper çoğunlukla teslimatların etkisini azaltmaya çalışırken, çoklu küme planlayıcı daha genel görevleri üstleniyor ve belki de toplu işler için daha uygun.

Gelişmiş bir kademeli dağıtım mekanizması yoktur.

Çoklu küme zamanlayıcı hakkında daha fazla bilgiyi şu adreste bulabilirsiniz: resmi depo sayfası.

Çoklu küme zamanlayıcının işleyişi hakkında bilgi edinmek istiyorsanız Admiralty'nin Argo ile ilginç kullanım örneği — iş akışları, etkinlikler, CI ve CD Kubernetes.

Diğer araçlar ve çözümler

Birden fazla kümeyi birbirine bağlamak ve yönetmek karmaşık bir iştir ve evrensel bir çözüm yoktur.

Bu konuyu daha ayrıntılı incelemek isterseniz işte bazı kaynaklar:

Rancher'dan Denizaltı farklı Kubernetes kümelerinin yer paylaşımlı ağlarını birbirine bağlayan bir araçtır.
Perakende zinciri Target'in kullanımları Unimatrix, birden fazla kümede dağıtımı düzenlemek için Spinnaker ile birleştirildi.
IPV6 kullanmayı deneyin ve çeşitli bölgelerde tek ağ.
Örneğin bir servis ağını kullanabilirsiniz. Birden fazla kümeyi bağlamak için Istio.
Bir konteyner ağ arayüzü eklentisi olan Cilium şunları sunar: küme ağ işlevibirkaç kümeyi birleştirmenize olanak tanır

Hepsi bugün için

Sonuna kadar okuduğunuz için teşekkürler!

Birden fazla kümeyi daha verimli bir şekilde nasıl bağlayacağınızı biliyorsanız, bize söyle.

Yönteminizi bağlantılara ekleyeceğiz.

Chris Nesbitt-Smith'e özel teşekkürler (Chris Nesbitt-Smith) ve Vincent de Sme (Vincent De Smet'in) (güvenilirlik mühendisi swatmobile.io) makaleyi okuduğunuz ve federasyonun nasıl çalıştığına dair faydalı bilgiler paylaştığınız için.

Kaynak: habr.com

Kubernetes kümelerini farklı veri merkezlerine bağlama