Birden fazla kıtada Kubernetes: dünya genelindeki veri merkezlerinde yüksek erişilebilir k3s ve k8s

Uygulamaların kesintilere dayanıklı çalışması ve otomatik olarak ölçeklenmesi gerektiğinde standart çözüm Kubernetes'tir. Akla ilk gelen fikir, ABD, Avrupa ve Asya'daki sunuculara yayılan tek bir Kubernetes kümesi kurmaktır; ancak bu fikir bir ayrıntıya takılır: Kubernetes'in tüm durumunu sakladığı veritabanı olan etcd'ye. Bu yazı, birden fazla kıtada Kubernetes çalıştırmanın buna rağmen nasıl mümkün olduğunu gösteriyor, üstelik bütün bir kıtanın devre dışı kalmasını kaldırabilecek şekilde: bölge başına bir küme, GitOps ile ortak bir dağıtım ve kullanıcıları en yakın sağlıklı bölgeye yönlendiren bir Geo-DNS ile.

Mimariyi k3s ile oluşturuyoruz: dakikalar içinde kurulabilen, hafif ve tamamen sertifikalı bir Kubernetes dağıtımı. Sonunda da kubeadm ile kurulan klasik bir Kubernetes'te nelerin değiştiğini gösteriyoruz. Birden fazla lokasyonda erişilebilirlik, quorum ve failover konusundaki temel bilgiler Üç kıtada Docker Swarm yazısında ayrıntılı olarak anlatılıyor; bu yazı ise Kubernetes'te farklı olan noktalara odaklanıyor.

Tüm kıtalara yayılan tek bir küme mi, bölge başına bir küme mi?

Birden fazla kıtada Kubernetes için doğru mimari, tüm kıtalara yayılan tek bir küme değil, bölge başına bir kümedir. Her küme kendi başına çalışır, hepsi aynı Git deposundan dağıtılır ve sağlık kontrolleri yapan bir Geo-DNS kullanıcıları bölgelere yönlendirir. Bir bölge devre dışı kalırsa diğerleri devralır; bunun için okyanusun öbür yakasıyla ortak bir küme durumu üzerinde uzlaşmak gerekmez.

etcd neden uzak mesafeleri kaldıramaz

Kubernetes tüm durum bilgisini, her yapılandırmayı ve her değişikliği, Raft konsensüsüyle çalışan bir anahtar-değer deposu olan etcd'de saklar. Her yazma işlemi, tüm etcd üyelerinin çoğunluğundan onay almak zorundadır. etcd varsayılan olarak 100 milisaniyelik bir heartbeat aralığı ve bir saniyelik lider seçimi zaman aşımıyla çalışır; Avrupa, Kuzey Amerika ve Asya arasındaki paket gecikmeleri ise 80 ila 250 milisaniyedir. Bu süreler yükseltilebilir, ancak o zaman kümedeki her yazma işlemi yavaşlar: bir pod'un zamanlanmasından bir Secret nesnesinin kaydedilmesine kadar. k3s dokümantasyonu bu noktada nettir: yerleşik etcd, birden fazla ağa dağıtılmış kümelerde desteklenmez, tüm sunucular aynı lokasyonda bulunmalıdır. Kubernetes'in kendisi de bir kümenin birden fazla kıtayı değil, tek bir bölge içindeki birden fazla alt bölgeyi kapsaması için tasarlanmıştır.

Üç modelin karşılaştırması

“Bölge başına bir küme” yaklaşımının çoğu zaman hafife alınan ikinci bir avantajı vardır: kontrol düzlemindeki bir hata, kümede yapılan hatalı bir değişiklik ya da ters giden bir yükseltme her zaman yalnızca tek bir bölgeyi etkiler. Diğer bölgelerdeki kullanıcılar bundan hiçbir şey fark etmez.

k3s mi, k8s mi?

İkisi de aynı API'ye, aynı manifest dosyalarına ve aynı araçlara sahip gerçek Kubernetes'tir. Fark, yapılarında ve gerektirdikleri emektedir:

Bölge başına bir küme mimarisi için k3s'i öneriyoruz: üç küme işletmek ancak her biri basit olduğunda rahattır. Zaten kubeadm deneyiminiz varsa mimariyi olduğu gibi uygulayabilirsiniz; aşağıdaki kubeadm bölümü farkları gösteriyor.

Mimari: üç bölge, üç küme, tek giriş noktası

Başlangıç ve genişletme

Başlangıç aşaması üç sunucudan oluşur: biri ABD'de, biri Avrupa'da, biri Asya'da ve her biri kendi başına tek düğümlü bir küme olarak çalışır. Bir sunucu arızalanırsa bulunduğu bölge de devre dışı kalır ve Geo-DNS o bölgenin kullanıcılarını komşu bölgeye yönlendirir. Bu aşama zaten bütün bir kıtanın devre dışı kalmasını karşılayacak şekilde tasarlanmıştır. Genişletme aşamasında her bölge aynı lokasyonda üç sunucu alır; böylece her bölge, kullanıcıların başka bir bölgeye yönlendirilmesine gerek kalmadan bir sunucunun arızalanmasını da kendi başına atlatır.

Hangi KernelHost lokasyonları uygundur

KernelHost, Frankfurt am Main'deki maincubes veri merkezinde sunucular işletir; Avrupa, Kuzey Amerika ve Asya-Pasifik'teki diğer lokasyonlarda ise sanal sunucular sunar. Bunlar arasında ABD'deki üç lokasyon, Kanada, Londra, Strazburg, Varşova, Helsinki, Singapur, Japonya, Sydney ve Mumbai bulunur. Tam listeyi Sunucu lokasyonları sayfasında bulabilirsiniz. Bu yazıdaki örnekte Avrupa için Frankfurt am Main, Kuzey Amerika için ABD'nin doğu kıyısı ve Asya için Singapur kullanılıyor.

Rehber: üç bölgede k3s ile Kubernetes

Örnekte Debian 12 veya 13 çalıştıran üç sunucu kullanılıyor: k3s-eu, k3s-us ve k3s-asia. Genel IP adresleri 203.0.113.0/24 dokümantasyon ağından geliyor, alan adı olarak da example.com kullanılıyor. İkisini de kendi değerlerinizle değiştirin.

Adım 1: üç bölgede sunucuları hazırlayın

Üç bölgede, k3s'in yanında uygulamanıza da yer kalması için en az 2 vCPU ve 4 GB RAM'e sahip üç sunucu sipariş edin. Yeni root sunucular için kontrol listesindeki temel sertleştirmeyi uygulayın ve anlamlı host adları verin. etcd hızlı SSD'lerden belirgin şekilde faydalanır; KernelHost sunucularının NVMe depolaması bu koşulu karşılar.

Adım 2: k3s'i kurun

Üç sunucunun her birine k3s'i tek bir komutla kurun. Böylece her sunucu, tek düğümlü eksiksiz bir Kubernetes kümesine dönüşür:

curl -sfL https://get.k3s.io | sh -
kubectl get nodes

Yaklaşık bir dakika sonra kubectl get nodes düğümü Ready olarak gösterir. Pakete dahil olanlar: Ingress controller olarak Traefik, ağ olarak Flannel ve yerel depolama birimleri için bir provisioner.

Adım 3: her bölgeyi üç sunucuya genişletin

Bir bölgenin kendi içinde de yüksek erişilebilir olması gerekiyorsa aynı lokasyona üç sunucu yerleştirin. İlk sunucu yerleşik etcd'yi başlatır, diğer ikisi ortak bir token ile kümeye katılır. etcd tek sayıda sunucu gerektirir; üç sunucuyla bölge, bir sunucunun arızalanmasını kaldırabilir:

curl -sfL https://get.k3s.io | K3S_TOKEN=GIZLI_TOKEN sh -s - server \
    --cluster-init \
    --tls-san=api.eu.example.com

curl -sfL https://get.k3s.io | K3S_TOKEN=GIZLI_TOKEN sh -s - server \
    --server https://203.0.113.21:6443 \
    --tls-san=api.eu.example.com

Bir bölgedeki tüm sunucuların ağ aralıkları ve özellikler için aynı ayarları kullanması gerekir. Sunucular arasında etcd için 2379 ile 2380/TCP arasındaki portlar, API için 6443/TCP, Kubelet için 10250/TCP ve Flannel ağı için 8472/UDP açık olmalıdır; dışarıya karşı ise bu portlar kapalı kalır. Token bir sırdır: onu bilen herkes kümeye kendi sunucularını ekleyebilir.

Adım 4: üç kümeye de erişimi ayarlayın

k3s erişim bilgilerini /etc/rancher/k3s/k3s.yaml dosyasına kaydeder. Her kümenin bu dosyasını çalışma bilgisayarınıza kopyalayın, içindeki 127.0.0.1 adresini sunucunun adresiyle değiştirin ve context'leri bölgeye göre adlandırın:

kubectl config rename-context default eu
kubectl config use-context eu
kubectl --context us get nodes

6443 portundaki API, kümeye açılan en güçlü kapıdır. Bu erişime güvenlik duvarında yalnızca kendi adresinizden veya bir VPN üzerinden izin verin, asla tüm internete açmayın. k3s.yaml dosyası bir yönetici sertifikası içerir ve bir root parolası kadar özenle saklanmalıdır.

Adım 5: her kümede Flux ile GitOps

Üç bölgenin de aynı uygulamayı aynı sürümde çalıştırması için istenen durum bir Git deposunda tutulur ve her kümede bu durumu kendiliğinden oluşturan Flux çalışır. Yani her küme yapılandırmasını kendisi çeker; arızalanabilecek merkezi bir dağıtım sunucusu yoktur. Kendini kanıtlamış bir depo yapısı:

apps/
  web/            uygulamanın ortak manifest dosyaları
clusters/
  eu/             Avrupa için ayarlar ve sürüm
  us/             Kuzey Amerika için ayarlar ve sürüm
  asia/           Asya için ayarlar ve sürüm

flux bootstrap git --url=ssh://git@git.example.com/infra/fleet.git --branch=main --path=clusters/eu

Aynı komutu ilgili context'te --path=clusters/us ve --path=clusters/asia ile çalıştırın. Her bölgenin kendi dizini olduğu için yeni bir sürümü önce bir bölgede, ancak ondan sonra diğerlerinde devreye alabilirsiniz.

Adım 6: uygulamayı kesintilere dayanıklı şekilde tanımlayın

Bir bölge içinde uygulamanın bakım çalışmalarını ve sunucu arızalarını atlatmasını üç şey sağlar: farklı düğümlere dağıtılan birden fazla replika, sağlıksız pod'ları tespit eden kontroller ve bir bakımın tüm pod'ları aynı anda kaldırmasını engelleyen bir kesinti bütçesi:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: web
      containers:
        - name: web
          image: registry.example.com/web:1.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            periodSeconds: 10
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: web

Readiness kontrolü, bir pod yanıt vermediği sürece onu trafikten çıkarır; liveness kontrolü ise pod takıldığında onu yeniden başlatır. Tek düğümlü bir kümede birden fazla düğüme dağıtım henüz bir etki göstermez; bölgede üç sunucu olduğu anda otomatik olarak devreye girer.

Adım 7: Ingress ve sertifikalar

Giriş noktası görevini pakete dahil olan Traefik üstlenir. Üç bölge de aynı alan adına hizmet verdiği için TLS sertifikalarını cert-manager ile DNS challenge üzerinden alın: bu yöntem, DNS kaydı o anda nereyi gösterirse göstersin her bölgede çalışır. HTTP challenge ise kaydın o anda göstermediği her bölgede başarısız olur. Kubernetes Ingress olmadan çalışıyorsanız temel bilgileri nginx'i reverse proxy olarak kurma yazısında bulabilirsiniz.

Adım 8: failover destekli Geo-DNS kurun

Coğrafi yönlendirme ve sağlık kontrolleri sunan bir DNS hizmeti, Avrupa'daki kullanıcıları Frankfurt am Main'e, Amerika'dakileri ABD'nin doğu kıyısına, Asya'dakileri ise Singapur'a yönlendirir ve her bölgenin giriş noktasının yanıt verip vermediğini 30 ila 60 saniyede bir kontrol eder. Bir bölge devre dışı kalırsa hizmet o bölgenin adresini artık vermez. Kayıtların TTL değerini 60 saniyeye ayarlayın; böylece bir geçiş genellikle bir ila iki dakika içinde tamamlanır. Kayıtları küme içinden yönetmek isterseniz bunun için external-dns kullanabilirsiniz.

Adım 9: bölge bölge dağıtın ve arızayı test edin

Yeni bir sürümü önce tek bir bölgenin dizinine yazın, bölgeyi birkaç dakika gözlemleyin ve sürümü ancak ondan sonra diğer bölgeler için de uygulayın. Böylece hiçbir kontrolün yakalayamadığı bir hata en fazla tek bir bölgeye ulaşır. Bir bölgenin devre dışı kalmasını, o bölgenin sunucusunda k3s'i durdurarak prova edin; bu sırada Geo-DNS'in bölgeyi yanıtlarından çıkarıp çıkarmadığını ve komşu bölgenin yükü taşıyıp taşımadığını kontrol edin:

systemctl stop k3s
systemctl start k3s

Üç sunuculu bir bölgede tek bir sunucunun bakımını da prova edin. kubectl drain, 6. adımdaki bütçeye uyarak pod'ları taşır; kubectl uncordon ise sunucuyu yeniden devreye alır:

kubectl drain k3s-eu-2 --ignore-daemonsets --delete-emptydir-data
kubectl uncordon k3s-eu-2

Bölgeler arası veri

Kubernetes pod'ları dağıtır, verileri değil. Pakete dahil provisioner ile oluşturulan bir PersistentVolume tam olarak tek bir düğümde bulunur ve kümeler arasında varsayılan olarak hiçbir ortak veri depolama yoktur. Bu nedenle veri içeren her şey için, birden fazla lokasyona yayılan her kümede olduğu gibi aynı kurallar geçerlidir:

• Veritabanları replikasyonu kendileri üstlenir. Kendini kanıtlamış yapı, bir bölgede birincil bir örnek ve diğer bölgelerde replikalardır; PostgreSQL için CloudNativePG gibi veritabanı operatörleri bu tür replikaları küme sınırlarının ötesinde de destekler. Kıtalar arasında replikasyon asenkron çalışır; gerçek bir arıza durumunda son birkaç saniyelik yazma işlemleri eksik olabilir. Dünya genelinde kayıpsız yazma için CockroachDB veya YugabyteDB gibi çok bölgeli veritabanları vardır.
• Dosyalar ve yüklemeler, ikinci bir bölgeye replikasyonu yapılan S3 uyumlu bir nesne depolamaya konmalıdır.
• Oturumlar replike edilen bir veritabanında veya replike edilen bir önbellekte tutulur ya da uygulama imzalı token'lar kullanır.
• Yedekler zorunlu olmaya devam eder, çünkü replikasyon, sağlam verileri çoğalttığı gibi hataları da çoğaltır. Kubernetes nesneleri ve depolama birimleri için Velero uygundur; temel bilgiler için sunucular için yedekleme stratejisi yazısına bakın.

k3s yerine kubeadm ile Kubernetes

kubeadm ile de mimari aynı kalır: bölge başına bir küme, GitOps, Geo-DNS. Farklı olan, her kümenin kuruluşudur. Tüm düğümlere containerd gibi bir container runtime ile birlikte kubeadm, kubelet ve kubectl kurarsınız, bölgenin API'sinin önüne bir yük dengeleyici ya da örneğin kube-vip ile sanal bir adres koyarsınız ve ilk kontrol düzlemi düğümünü başlatırsınız:

kubeadm init --control-plane-endpoint "api.eu.example.com:6443" --upload-certs

Çıktı iki join komutu içerir: diğer iki kontrol düzlemi düğümü için --control-plane --certificate-key içeren bir komut ve worker'lar için bir komut. Ardından Calico veya Cilium gibi bir ağ eklentisi ve k3s'in zaten hazır getirdiği bir Ingress controller kurarsınız. Bu ek emek, tek tek bileşenleri bilinçli olarak seçmeniz ya da upstream sürüme yakın kalmanız gerektiğinde karşılığını verir.

Birden fazla kıtada Kubernetes için neden KernelHost

Tüm bulut paketlerine genel bir bakışı ve büyük bulut sağlayıcılarıyla bir maliyet karşılaştırmasını Bulut sunucu kiralama sayfasında bulabilirsiniz.

Sık yapılan hatalar ve bunlardan nasıl kaçınırsınız

• etcd kıtalar arasına yayılmış. Sonuç yavaş yazma işlemleri ve kararsız lider seçimleridir; yerleşik etcd ile k3s'te bu kurulum desteklenmez. Çözüm: bölge başına bir küme.
• Bir bölgede iki sunucu. etcd çoğunluğa ihtiyaç duyar, iki sunucu tek bir arızayı bile kaldıramaz. Çözüm: bir veya üç sunucu.
• API tüm internete açık. 6443 portu kümenin ana anahtarıdır. Çözüm: erişim yalnızca kendi adresinizden veya VPN üzerinden.
• Merkezi dağıtım sunucusu. Arızalanırsa artık hiçbir şey dağıtılamaz. Çözüm: her kümede, Git'ten kendi başına beslenen Flux.
• Tüm bölgelerde aynı anda güncelleme. Bu durumda bir hata tüm kullanıcıları etkiler. Çözüm: depodaki dizinler üzerinden bölge bölge güncelleme.
• HTTP challenge ile sertifikalar. DNS kaydının o anda göstermediği bölgelerde yenileme başarısız olur. Çözüm: DNS challenge.
• Replikasyonsuz yerel depolama biriminde veritabanı. Düğüm arızalanırsa verilere erişilemez. Çözüm: bir veritabanı operatörü üzerinden replikasyon.
• Ne probe var ne bütçe. Sağlıksız pod'lar trafik almaya devam eder, bakım çalışmaları tüm pod'ları aynı anda devre dışı bırakır. Çözüm: readiness ve liveness kontrolü artı PodDisruptionBudget.

Kısaca özetle

• Birden fazla kıtada Kubernetes için doğru yol bölge başına bir kümedir; tüm kıtalara yayılan tek bir küme ise etcd gecikmesi yüzünden başarısız olur.
• Başlangıç aşaması, biri ABD'de, biri Avrupa'da, biri Asya'da olmak üzere üç sunucudan oluşur; bu aşama bile bütün bir kıtanın devre dışı kalmasını atlatır.
• Genişletme aşamasında her bölge aynı lokasyonda üç sunucu alır; böylece her bölge tek tek sunucuların arızalanmasını da atlatır.
• Her kümedeki Flux, uygulamayı aynı Git deposundan bölge bölge dağıtır.
• Sağlık kontrolleri yapan ve kısa TTL ile çalışan Geo-DNS, kullanıcıları en yakın sağlıklı bölgeye yönlendirir; sertifikalar DNS challenge ile alınır.
• Kubernetes pod'ları dağıtır, verileri değil: veritabanlarının kendi replikasyonuna ihtiyacı vardır, yedekler zorunlu olmaya devam eder.
• Bu mimari için çoğu zaman daha iyi seçim kubeadm değil k3s'tir, çünkü üç basit kümeyi işletmek üç karmaşık kümeyi işletmekten daha kolaydır.