Kubernetes'teki yüksek erişilebilirlik, kümenizin arızalar sırasında bile çalışır durumda kalmasını sağlar. Bu kılavuz, temel bileşenleri, yedeklilik stratejilerini ve yapılandırma adımlarını kapsayarak hata toleranslı bir Kubernetes kümesinin nasıl tasarlanıp dağıtılacağını açıklar.

Önemli Noktalar:

• Yüksek Kullanılabilirliğin Önemi: Donanım arızaları, ağ sorunları veya bakım nedeniyle oluşan kesintileri önleyin.
• Temel Stratejiler:
  • Tek noktadaki arızaları ortadan kaldırmak için birden fazla kontrol düzlemi düğümü kullanın.
  • Dayanıklılık için işçi düğümlerini bölgelere veya alanlara dağıtın.
  • Trafiği yönetmek ve sorunsuz geçişleri sağlamak için yük dengeleyicileri uygulayın.
• Kritik Bileşenler:
  • API sunucusu, etcd veritabanı, zamanlayıcı ve denetleyici yöneticilerinin yedekliliğe ihtiyacı vardır.
  • Kurulumunuzun karmaşıklığına ve ölçeğine bağlı olarak yığılmış veya harici etcd topolojileri arasında seçim yapın.
• Dağıtım Adımları:
  • Kullanmak kubeadm kümeyi kurmak için.
  • Yük dengeleyicileri, sağlık kontrollerini ve çalışan düğümlerini yapılandırın.
  • Yedekleme ve yedekleme süreçlerini düzenli olarak test edin.

Yüksek erişilebilirlik, tutarlı performans ve çalışma süresini garantilemek için dikkatli planlama, sağlam altyapı ve sürekli testler gerektirir.

[ Kube 1.5 ] Adım adım yüksek düzeyde kullanılabilir Kubernetes kümesi kurulumu | Keepalived ve Haproxy

Yüksek Erişilebilirlikli Kubernetes Kümenizi Planlama

Yüksek erişilebilirlikli (HA) bir Kubernetes kümesi oluştururken, tasarımınızı net iş ve teknik hedeflerle uyumlu hale getirmeniz çok önemlidir. Dikkatli bir planlama yapılmazsa, erişilebilirlik ihtiyaçlarınızı karşılayamayacak kadar karmaşık veya kırılgan bir sistemle karşılaşabilirsiniz. Aşağıda, doğru dengeyi kurmanıza yardımcı olacak temel hususları ve mimari kararları inceleyeceğiz.

İş ve Teknik Gereksinimlerin Değerlendirilmesi

Kesinti ve veri kaybı toleransınızı tanımlayarak başlayın. Bu parametreler, kümeniz için yapacağınız her teknik seçimi şekillendirecektir.

• Kurtarma Süresi Hedefi (RTO): Bu, sistemlerinizin bir arızadan sonra ne kadar hızlı kurtarılması gerektiğini ölçer. Örneğin, işletmeniz sistemlerin 5 dakika içinde çalışır duruma gelmesini gerektiriyorsa, otomatik yük devretme süreçlerine ve önceden yapılandırılmış yedek kaynaklara ihtiyacınız olacaktır. Diğer yandan, daha uzun kurtarma süreleri kabul edilebilirse, manuel müdahale gerektiren daha basit ve daha uygun maliyetli çözümleri tercih edebilirsiniz.
• Kurtarma Noktası Hedefi (RPO): Bu, ne kadar veri kaybının kabul edilebilir olduğunu belirler. Örneğin, bir finansal işlem platformu sıfır veri kaybı gerektirebilir ve bu da eş zamanlı veri çoğaltmasını gerektirebilir. Öte yandan, bir e-ticaret platformu, sistem karmaşıklığını azaltmak için küçük bir veri boşluğuna tolerans gösterebilir.

Ayrıca kullanılabilirlik hedefinizi de tanımlamanız gerekecek. Referans olarak:

• 99.9% çalışma süresi yılda yaklaşık 8,77 saat kesintiye izin veriyor.
• 99.99% çalışma süresi bu süreyi yaklaşık 52,6 dakikaya düşürüyor.

Ayrıca, uygulamanızın trafik düzenlerini ve ölçeklendirme ihtiyaçlarını göz önünde bulundurun. Öngörülebilir trafik artışları, ani ve öngörülemeyen dalgalanmalar yaşayan uygulamalara kıyasla farklı stratejiler gerektirir. Kaynak yoğun iş yükleri, iş yüklerini bölgeler arasında nasıl dağıtacağınızı etkileyecek, özel donanım kurulumlarına sahip özel düğüm havuzları gerektirebilir.

Bu metrikler, teknik verimliliği iş talepleriyle dengeleyen küme mimarinizin temelini oluşturur. Bir sonraki adım, coğrafi dağıtımın tasarımınızı nasıl etkilediğini belirlemektir.

Bölgesel ve Bölgesel Mimari Seçimi

Kümenizi coğrafi olarak dağıtma şekliniz, dayanıklılığında büyük rol oynar. Hem bölgesel hem de bölgesel mimariler, ihtiyaçlarınıza bağlı olarak farklı avantajlar sunar.

• Bölgesel Mimariler: Bunlar, kaynakları tek bir bölge içindeki birden fazla kullanılabilirlik bölgesine dağıtır. Bileşenler arasında düşük gecikmeyi korurken, bireysel veri merkezi arızalarına karşı koruma sağlarlar. Bu kurulum, belirli bir bölgedeki elektrik kesintileri veya ağ arızaları gibi yerel sorunları ele almak için çok uygundur.
• Bölgesel Mimariler: Bunlar, kaynakları birden fazla coğrafi bölgeye dağıtarak doğal afetler veya bölgesel ağ kesintileri gibi büyük ölçekli felaketlere karşı koruma sağlar. Ancak bu yaklaşım genellikle daha yüksek gecikme süresine neden olur ve bu da etcd gibi bileşenlerin performansını ve genel küme yanıt hızını etkileyebilir.

Bölgesel dağıtımlar, küresel kullanıcı tabanlarına sahip uygulamalar veya düzenlemelerin verilerin belirli ülkelerde depolanmasını gerektirdiği durumlarda en iyi sonucu verir. Ayrıca, sıkı felaket kurtarma ihtiyaçları olan kuruluşlar için de idealdir.

Çoğu HA kurulumu için, çok bölgeli kontrol düzlemi Dengeli bir yaklaşım sunar. Kontrol düzlemi düğümlerini tek bir bölge içindeki üç kullanılabilirlik bölgesine yerleştirerek, etcd'nin bir bölge arızalansa bile yeter sayıyı koruyabilmesini sağlarsınız. Bu yaklaşım, bölgeler arası iletişimin gecikme dezavantajları olmadan hata toleransı sağlar.

Çalışan düğümler benzer dağıtım modellerini izleyebilir, ancak burada daha fazla esneklik vardır. Durumsuz uygulamalar herhangi bir düğümde çalışabilirken, durumlu iş yükleri, verilerin erişilebilirliğini ve performansın tutarlılığını sağlamak için dikkatli bir yerleştirme gerektirebilir.

Ağ ve Yedeklilik Gereksinimleri

Hem kuzey-güney trafiğini (istemci-küme) hem de doğu-batı trafiğini (küme bileşenleri arasındaki iletişim) desteklemek için güçlü bir ağ stratejisi çok önemlidir. Birden fazla katmanda yedeklilik tartışmasızdır.

• Kullanmak birden fazla yük dengeleyici ile /healthz Kontroller bölgelere dağıtılır. Her yük dengeleyici, tekil arıza noktalarını ortadan kaldırmak için tüm trafik yükünü kaldırabilecek kapasitede olmalıdır.
• Emin olmak ağ yolu çeşitliliği Bağlantı sorunlarına karşı korunmak için. Bölgeler arasındaki trafiğin birden fazla fiziksel rotası olmalı ve bulut sağlayıcısı veya veri merkezi yedekli ağ altyapısı sunmalıdır.
• İçin DNS ve servis keşfiKüme uç noktaları için uygun TTL yapılandırmalarıyla birden fazla DNS sunucusu dağıtın. DNS tabanlı yük dengeleme yedeklilik sağlasa da, istemci tarafındaki DNS önbelleğinin devralma tespitini geciktirebileceğini unutmayın.

İle çalışırken kalıcı hacimler, bölge arızaları sırasında depolama alanının erişilebilir kalmasını sağlayın. Bu, bölgeler arası çoğaltma veya dağıtılmış depolama sistemlerini içerebilir. Ayrıca, özellikle büyük veri kümeleri için, kurtarma olayları sırasında veri senkronizasyonunu sağlayacak yeterli ağ bant genişliği planlayın.

Eğer düşünüyorsanız Serverion'un altyapısıKüresel veri merkezi konumları, hem bölgesel hem de bölgesel mimariler için güçlü destek sunar. VPS ve özel sunucu seçenekleri, küme düğümleriniz için sağlam bir bilgi işlem temeli sağlarken, ortak yerleştirme hizmetleri, bulutun esnekliğini şirket içi kurulumların kontrolüyle birleştiren hibrit dağıtımlara olanak tanır. Ayrıca, yedekli ağ altyapıları, yüksek erişilebilirlikli kümelerin bağlantı taleplerini karşılayacak şekilde oluşturulmuştur ve Kubernetes dağıtımınızın dayanıklı ve güvenilir kalmasını sağlar.

Yüksek Kullanılabilirlik için Temel Bileşenler ve Topolojiler

Yüksek düzeyde kullanılabilir bir Kubernetes kümesi oluşturmak, sisteminizi çalışır durumda tutan temel bileşenleri anlamak ve bunları nasıl düzenleyeceğinize karar vermek anlamına gelir. Bu kararlar, kümenizin güvenilirliğini, performansını ve karmaşıklığını doğrudan etkiler.

HA için Temel Kubernetes Bileşenleri

Kontrol düzlemi, Kubernetes kümenizin omurgasıdır. Şunları içerir: API sunucusu, planlayıcı, kontrolör yöneticileri, Ve vb.bunların hepsi operasyonların sürdürülmesinde kritik rol oynar.

• API Sunucusu: API sunucusu, gelen istekleri işleyen merkezi merkezdir kubectl, çalışan düğümler ve diğer dahili bileşenler. Bölgeler arasında birden fazla API sunucusu çalıştırmak, bir sunucunun kaybedilmesinin kümeyi aksatmasını önler.
• Zamanlayıcı: Zamanlayıcı, kullanılabilir kaynaklara ve tanımlanmış kısıtlamalara göre düğümlere kapsüller atar. Yedeklilik için birden fazla zamanlayıcı dağıtabilirsiniz, ancak aynı anda yalnızca biri etkin olarak karar verir. Etkin zamanlayıcı başarısız olursa, başka bir zamanlayıcı devreye girer.
• Kontrolör Yöneticileri: Bunlar, kümenin durumunu sürekli izleyerek kaynakların istenen yapılandırmayla uyumlu olmasını sağlar. Lider seçimini kullanırlar, böylece kaynakları yalnızca bir örnek etkin bir şekilde yönetir ve yedekler gerektiğinde devralmaya hazır olur.
• vb.: Bu dağıtılmış anahtar-değer deposu, yapılandırma verilerini, sırları ve durum bilgilerini tutar. Çalışması için düğümlerin çoğunluğunu (nisap) gerektiren bir fikir birliği algoritması kullanır. Örneğin, üç düğümlü bir etcd kümesi, işlevselliğini kaybetmeden bir düğümün kaybıyla başa çıkabilir.
• KubeletHer çalışan düğümde çalışan kubelet, pod özelliklerini almak ve düğüm durumunu raporlamak için API sunucusuyla iletişim kurar. Kubelet'ler yüksek erişilebilirlik için kümelenmemiş olsa da, birden fazla çalışan düğüme sahip olmak, bazı düğümler başarısız olsa bile iş yüklerinin devam etmesini sağlar.

Bu bileşenleri anladıktan sonraki adım ihtiyaçlarınıza en uygun topolojiyi seçmektir.

HA Topolojileri: Yığılmış ve Harici vb.

Kontrol düzlemi bileşenlerini düzenlerken, her biri güvenilirlik ve karmaşıklık açısından kendine özgü dezavantajlara sahip iki ana seçeneğiniz vardır.

• Yığılmış etcd Topolojisi: Burada, etcd örnekleri aynı düğümlerdeki kontrol düzlemi bileşenleriyle birlikte konumlandırılır. Bu kurulum daha kolay dağıtılır ve daha az sunucu gerektirir. Ancak bir risk de beraberinde getirir: Bir kontrol düzlemi düğümü arızalanırsa, hem kontrol düzlemi hizmetleri hem de bir etcd üyesi kaybolur.
• Harici etcd Topolojisi: Bu yaklaşımda, etcd, kontrol düzleminden ayrı özel düğümlerde çalışır. Bu ayrım, daha iyi bir izolasyon sağlar ve kaynakların bağımsız olarak ölçeklenmesine olanak tanır; bu da onu daha büyük veya daha zorlu ortamlar için iyi bir seçim haline getirir.

Özellik	Yığılmış vb.	Dış vb.
Kurulum Karmaşıklığı	Dağıtımı ve yönetimi daha kolay	Daha fazla düğüm ve yönetim gerektirir
Kaynak izolasyonu	Kontrol düzlemi ile paylaşılan kaynaklar	Etcd için özel kaynaklar
Başarısızlık Etkisi	Hem etcd hem de kontrol düzlemi etkilendi	Bağımsız olarak yönetilen başarısızlıklar
Ölçeklenebilirlik	Paylaşılan kaynaklarla sınırlı	Bağımsız ölçekleme mümkündür

Daha küçük dağıtımlar için, yığınlanmış bir topoloji yeterli yedeklilikle daha basit bir başlangıç noktası sunar. Öte yandan, daha büyük kümeler veya sıkı çalışma süresi gereksinimleri olanlar, harici bir etcd kurulumunun sağladığı ek dayanıklılıktan faydalanabilir.

Topolojiniz seçildikten sonraki adım, sorunsuz işlemleri garanti altına almak için yük dengeleyicileri yapılandırmaktır.

Yük Dengeleyici Yapılandırması

Yük dengeleyiciler, API isteklerini birden fazla API sunucusuna dağıtmada ve sunucular çöktüğünde yedeklemeleri yönetmede önemli bir rol oynar. Yük dengeleyiciler olmadan, istemcilerin ayrı API sunucusu uç noktalarını izlemesi gerekir ve bu da süreci karmaşıklaştırır.

Doğru yapılandırılmış bir yük dengeleyici şunları yapmalıdır:

• Sağlık kontrollerini gerçekleştirin /healthz Her API sunucusunun uç noktası. HTTP 200 yanıtı hazır olduğunu gösterirken, HTTP 500 yanıtı bir sorun olduğunu belirtir. Sorunların hızlı bir şekilde tespit edilebilmesi için sağlık kontrolleri 5 saniyelik bir zaman aşımıyla her 10-15 saniyede bir çalıştırılmalıdır.
• Kubernetes API sunucuları durumsuz olduğundan, istekleri eşit şekilde dağıtın. Oturum yakınlığı genellikle gerekli değildir, bu da sunucu arızaları sırasında bile trafiğin sorunsuz akmasını sağlar.
• SSL sonlandırmasını yönetin. API sunucularının iş yükünü azaltmak için yük dengeleyicideki TLS işlemlerini devre dışı bırakabilir veya uyumluluk gerektiriyorsa uçtan uca şifreleme için şifrelenmiş trafiği iletebilirsiniz.

Daha fazla yedeklilik için farklı bölgelere birden fazla yük dengeleyici dağıtın. DNS tabanlı yük dengeleme, ek bir yük devretme katmanı sağlayabilir, ancak DNS önbelleğinin geçişler sırasında gecikmelere neden olabileceğini unutmayın.

Serverion'un altyapısını kullanıyorsanız, onların adanmış sunucular Güçlü kontrol düzlemi performansı sunarken, VPS seçenekleri daha küçük kurulumlar için idealdir. Dünya çapında veri merkezleri bulunan Serverion, çok bölgeli yapılandırmaları destekler ve zorlu ağ koşullarında bile trafik dağıtımını etkili bir şekilde yönetmek için yük dengeleme araçları sunar.

sbb-itb-59e1987

Adım Adım Kılavuz: Kubeadm ile HA Kubernetes Dağıtımı

Artık bileşenlere ve topolojilere aşina olduğunuza göre, yüksek erişilebilirliğe sahip Kubernetes kümenizi oluşturmanın zamanı geldi. Bu kılavuzda kubeadm kullanacağız; kubeadm, yapılandırmayı kontrol etmenize olanak tanırken dağıtımı da basitleştirir.

Altyapı Kurulumu ve Ön Koşullar

Üretim iş yüklerini karşılayacak altyapınızı hazırlayarak başlayın.

En az üç kontrol düzlemi düğümüne (minimum: 2 CPU çekirdeği ve 4 GB RAM; önerilen: 4 çekirdek ve 8 GB RAM) ve iki veya daha fazla çalışan düğüme (minimum: 1 çekirdek ve 2 GB RAM) ihtiyacınız olacak. Tüm düğümlere Ubuntu 20.04/22.04, CentOS 8 veya Rocky Linux 9 gibi desteklenen bir Linux dağıtımı yükleyin. Her düğümün benzersiz bir ana bilgisayar adına sahip olduğundan ve ağ üzerinden diğerleriyle iletişim kurabildiğinden emin olun.

Takas devre dışı bırak Kubernetes desteklemediğinden tüm düğümlerde çalıştırın. sudo swapoff -a ve herhangi bir takas girişini yorum satırına alın /etc/fstab Değişikliği kalıcı hale getirmek için gerekli portları açın: 6443 (API sunucusu), 2379-2380 (etcd), 10250 (kubelet) ve 10251-10252 (zamanlayıcı/denetleyici yöneticisi).

Bir tane kurun konteyner çalışma zamanı Her düğümde. Çoğu kullanıcı, iyi desteklenen containerd'yi tercih ediyor. Kubernetes'in varsayılan ayarlarıyla uyumlu olması için cgroup sürücüsü olarak systemd kullanacak şekilde yapılandırın. Ardından, uyumluluk sorunlarını önlemek için tüm düğümlere kubeadm, kubelet ve kubectl'i yükleyin ve hepsinin aynı Kubernetes sürümünü çalıştırdığından emin olun.

Bir tane kurun yük dengeleyici Kümeyi başlatmadan önce. Yük dengeleyici, donanım tabanlı, bir bulut sağlayıcısının sunduğu hizmetlerin bir parçası veya HAProxy gibi bir yazılım çözümü olabilir. 6443 numaralı bağlantı noktasını dinlemeli ve trafiği kontrol düzlemi düğümlerinizdeki API sunucularına yönlendirmelidir.

Küresel olarak hata toleranslı bir kurulum için, kontrol düzlemi düğümleri için özel sunucular ve çalışan düğümler için VPS örnekleri kullanmayı düşünün.

Kontrol Düzlemi Düğümlerini Ayarlama

İlk kontrol düzlemi düğümü, kümenizin temelidir. Komut satırı işaretlerini kullanmak yerine, HA ayarlarınızı tanımlamak için bir kubeadm yapılandırma dosyası oluşturun.

Adlı bir dosya oluşturun kubeadm-config.yaml ve küme yapılandırmanızı ekleyin. kontrolDüzlemiSon Noktası Yük dengeleyicinizin adresine ve portuna. Yığılmış bir etcd topolojisi için kubeadm, kontrol düzlemi düğümlerinde etcd'yi otomatik olarak yapılandıracaktır. Harici etcd kullanıyorsanız, uç noktaları bu dosyada belirtin.

Aşağıdaki komutla ilk kontrol düzlemi düğümünü başlatın:
sudo kubeadm init --config=kubeadm-config.yaml --upload-certs
The --yükleme-sertifikaları bayrağı, sertifikaların diğer kontrol düzlemi düğümlerine dağıtılması sürecini basitleştirir. Bu adım birkaç dakika sürer ve ek düğümler eklemek için birleştirme komutları çıktısı verir.

Bu birleştirme komutlarını güvenli bir şekilde saklayın; hassas belirteçler içerirler. Ardından, kubectl'yi ilk kontrol düzlemi düğümünde yapılandırın:
mkdir -p $HOME/.kube && sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config && sudo chown $(id -u):$(id -g) $HOME/.kube/config

Daha fazla düğüm eklemeden önce, ortamınıza uygun bir CNI eklentisi yükleyin.

Başlatma çıktısından birleştirme komutunu kullanarak kalan kontrol düzlemi düğümlerini ekleyin:
sudo kubeadm join yük dengeleyici-ip:6443 --token --discovery-token-ca-cert-hash sha256: --kontrol düzlemi --sertifika anahtarı
Bu komutu her ek kontrol düzlemi düğümünde çalıştırın.

Tüm kontrol düzlemi düğümlerinin çalışır durumda olduğunu şu komutu çalıştırarak doğrulayın:
kubectl düğümleri al
Tüm düğümlerin "Hazır" durumuyla listelendiğini görmelisiniz.

Etcd ve Yük Dengeleyicileri Yapılandırma

HA kurulumunu tamamlamak için etcd ve yük dengeleyici ayarlarınızı hassas bir şekilde ayarlayın.

Yığılmış bir etcd topolojisi kullanıyorsanız, kubeadm bunu otomatik olarak yapılandırır. Harici etcd kümeleri için, özel düğümlerde etcd kurmanız, güvenli iletişim sertifikaları oluşturmanız ve her etcd üyesini diğerlerini tanıyacak şekilde yapılandırmanız gerekir. Arızalar sırasında yeter sayıyı korumak için her zaman tek sayıda etcd üyesi (örneğin 3, 5 veya 7) kullanın.

Etcd sağlığını kontrol etmek için şunu çalıştırın:
sudo kubectl exec -n kube-sistemi vb- -- etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key uç nokta sağlığı
Tüm uç noktalar sağlıklı olarak raporlanmalıdır.

Yük dengeleyiciler için, durumu izlemek üzere sağlık denetimlerini yapılandırın /healthz Her API sunucusunun 6443 numaralı bağlantı noktasındaki uç noktayı ayarlayın. Aralığı 5 saniyelik bir zaman aşımıyla 10 saniyeye ayarlayın ve sağlıksız sunucuların kurtarıldıklarında otomatik olarak kaldırılıp yeniden eklenmesini sağlayın.

Yük dengeleyiciyi test etmek için, API sunucusunu bir kontrol düzlemi düğümünde durdurun (sudo systemctl stop kubelet) ve kubectl komutlarının hala çalıştığını doğrulayın. Hizmeti yeniden başlatın ve düğümün kümeye yeniden katıldığından emin olun.

Birden fazla yük dengeleyici kullanıyorsanız, bunları aktif-pasif bir kurulumda yapılandırın veya ilk yük dağıtımı için DNS dönüşümlü dağıtımını kullanın. Ekibinizin yük dengeleyici sorunlarını ele almasına yardımcı olmak için yük devretme prosedürlerini belgelendirin.

Çalışan Düğümleri Ekleme ve Küme Sağlığını Test Etme

Çalışan düğümler, kümenizin omurgasını oluşturur ve uygulamalarınız için işlem gücü sağlar. Eklemeleri kolaydır, ancak test edilmesi kümenin dayanıklı olmasını sağlar.

İlk kubeadm kurulumu sırasında sağlanan işçi düğümü birleştirme komutunu kullanın:
sudo kubeadm join yük dengeleyici-ip:6443 --token --discovery-token-ca-cert-hash sha256:
Eğer token'ın süresi dolduysa yenisini üretebilirsiniz.

Çalışan düğümlerin başarıyla katıldığını şu şekilde kontrol edin:
kubectl düğümleri al
Tüm düğümler "Hazır" durumunu göstermelidir. Bir düğüm "Hazır Değil" durumunda kalırsa, kubelet günlüklerini şu şekilde inceleyin:
sudo journalctl -u kubelet -f

Kümenin sağlığını doğrulamak için bir test uygulaması dağıtın. Örneğin, birden fazla kopya içeren bir nginx dağıtımı oluşturun:
kubectl create deployment nginx-test --image=nginx --replicas=5
Daha sonra düğümler arası pod dağıtımını kontrol edin:
kubectl get pods -o wide

HA işlevselliğini test etmek için arızaları simüle edin. Kontrol düzlemi düğümleri için, bir düğümdeki kubelet hizmetini durdurun ve kubectl komutlarının hala çalıştığını doğrulayın. Üçten fazla kontrol düzlemi düğümünüz varsa, iki düğümü aynı anda durdurmayı deneyin; düğümlerin çoğu sağlıklı olduğu sürece küme çalışır durumda kalacaktır.

Çalışan düğümler için, bir düğümü kordon altına alıp boşaltarak bir arızayı simüle edin:
kubectl kordonu && kubectl drenajı --ignore-daemonsets --delete-emptydir-data
Kubernetes'in pod'ları diğer düğümlere yeniden planladığını gözlemleyin.

Kümenin bileşenlerini şu şekilde izleyin:
kubectl get componentsstatuses ve kubectl bölmeleri al -n kube-sistemi
Tüm sistem pod'ları çalışıyor olmalı ve bileşenler sağlıklı olarak raporlanmalıdır. Sürekli izleme için, zaman içindeki ölçümleri izlemek üzere Prometheus gibi araçlar kullanın.

Kurmayı unutmayın etcd ve sertifika yedekleriYedekleme ve geri yükleme prosedürlerinizi, etkili olduklarından emin olmak için üretim dışı bir ortamda düzenli olarak test edin.

Yüksek düzeyde kullanılabilir Kubernetes kümeniz çalışır durumda ve test edildiğinde, sürekli operasyonları desteklemeye ve rutin bakımı güvenle gerçekleştirmeye hazır olursunuz.

HA Kubernetes İşlemleri için En İyi Uygulamalar

Yüksek düzeyde kullanılabilir bir Kubernetes kümesi kurmak sadece ilk adımdır. Verimli ve güvenilir bir şekilde çalışmasını sağlamak için sürekli izleme, test ve en iyi operasyonel uygulamalara odaklanmanız gerekir. Bu adımlar, performansı korumanıza, kesinti sürelerini önlemenize ve kümenizin dayanıklılığını korumanıza yardımcı olacaktır.

İzleme ve Bakım

Etkili izleme, yüksek erişilebilirliğin (HA) omurgasıdır. Aşağıdaki gibi araçları kullanın: Prometheus ve Grafana CPU kullanımı, bellek tüketimi, ağ gecikmesi ve etcd performansı gibi temel ölçümleri izlemek için. etcd sağlığına dikkat edin. izleme ölçümleri Lider seçimleri, teklif başarısızlıkları ve disk G/Ç gecikmesi gibi kritik eşikler için uyarılar ayarlayın; örneğin, CPU kullanımı birden fazla düğümde 80%'yi aşarsa veya etcd gecikmesi 100 ms'yi aşarsa, acil eylem gerekir. Düzenli olarak kullanın etcdctl uç nokta durumu Tüm etcd üyelerinin senkronize olmasını ve düzgün çalışmasını sağlayan komut.

Kubernetes bileşenlerinizi yapılandırılmış bir programla güncel tutun. Küçük sürümler için üç aylık güncellemeler planlayın ve uygulayın. güvenlik yamaları Mevcut oldukları anda güncelleyin. Güncellemeleri üretime dağıtmadan önce her zaman bir hazırlık ortamında test edin. Güncelleme yaparken, riskleri en aza indirmek için etcd ve Kubernetes'i ayrı ayrı yönetin; asla ikisini aynı anda güncellemeyin.

Sertifika yönetimi bir diğer kritik alandır. Kubernetes sertifikaları genellikle bir yıl sonra sona erer, bu da otomatik yenilemeyi zorunlu kılar. kubeadm veya sertifika yöneticisi Yenilemeleri yönetmek ve son kullanma tarihlerini yakından takip etmek için. Süresi dolan sertifikaların neden olduğu beklenmedik kesintileri önlemek için yenileme süreçlerinizi aylık olarak test edin.

Günlük toplamayı şu araçlarla merkezileştirin: Akıcı veya Akıcı BitBu, olay müdahalesi sırasında düğümler ve bileşenler arasında olayların ilişkilendirilmesini kolaylaştırır. Bu izleme ve bakım uygulamalarını uygulayarak, olası sorunları erkenden tespit edebilir ve kümenizin kullanılabilirliğini korumanıza yardımcı olabilirsiniz.

Yedekleme ve Devralma Prosedürlerinin Test Edilmesi

İzleme tek başına yeterli değildir; aynı zamanda yedekleme ve devreye alma süreçlerinizi de titizlikle test etmeniz gerekir. Gerçek dünyadaki arızaları simüle etmek için aylık hata enjeksiyon testleri gerçekleştirin. Örneğin, sisteminizin nasıl tepki verdiğini görmek için kontrol düzlemi düğümlerini kapatın, ağ bölümleri oluşturun veya çalışan düğümlerini aşırı yükleyin. Her senaryo için kurtarma sürelerini takip edin ve bunları azaltmak için çalışın.

Veri bütünlüğünü sağlamak için etcd yedekleme ve geri yükleme prosedürlerini düzenli olarak test edin. Doğruluğunu doğrulamak ve geri yükleme süresini ölçmek için bu testleri ayrı bir ortamda gerçekleştirin. Geri yükleme süreciniz Kurtarma Süresi Hedefinizi (RTO) aşarsa, daha hızlı depolama çözümlerini veya prosedürlerinizi basitleştirmeyi düşünün. etcd yedeklemelerini her altı saatte bir otomatikleştirin ve ek güvenlik için dağıtılmış konumlarda saklayın.

Uygulama düzeyindeki yedekleme testleri de aynı derecede önemlidir. Şunlar gibi araçları kullanın: Kaos Maymunu veya Turnusol İş saatleri içinde pod'ları veya düğümleri rastgele sonlandırmak. Bu, uygulamalarınızın kullanıcıları etkilemeden arızalarla başa çıkıp çıkamayacağını belirlemenize yardımcı olur.

Yaygın arıza senaryoları için ayrıntılı çalıştırma kitapları oluşturun. Bunlar, adım adım kurtarma talimatları, yükseltme iletişim bilgileri ve farklı olay türleri için karar ağaçları içermelidir. Bu belgeleri her olaydan sonra güncelleyin ve netlik ve kullanılabilirlik sağlamak için çeşitli ekip üyeleriyle test edin.

Yedekleme doğrulaması, yalnızca yedekleme oluşturmanın ötesine geçer. İzole ortamlarda küme durumunuzu düzenli olarak geri yükleyin ve uygulamaların beklendiği gibi çalıştığını doğrulayın. Çeşitli felaket senaryolarına hazırlıklı olmak için tam küme geri yüklemelerinin yanı sıra bireysel ad alanı kurtarmalarını da test edin.

HA için Uygulama Tasarlamak

Uygulamaların HA ortamında başarılı olabilmesi için kullanılabilirlik göz önünde bulundurularak tasarlanması gerekir. Pod Kesinti Bütçeleri (PDB'ler) Bakım veya ölçeklendirme sırasında minimum sayıda kopyanın kullanılabilir durumda kalmasını sağlamaya yardımcı olun. Kritik hizmetler için, minMevcut bir yüzdeden ziyade belirli sayıda kopyaya.

Tek noktadan kaynaklanan arızaları önlemek için anti-affinite kurallarını kullanın. podAntiAffinity, kopyaları farklı düğümlere veya kullanılabilirlik bölgelerine yayabilirsiniz. Veritabanları gibi durum bilgisi olan uygulamalar için, iş yüklerini eşit şekilde dağıtmak amacıyla anti-affinity'yi topoloji yayılım kısıtlamalarıyla birleştirin.

Kaynak isteklerini ve sınırlarını gerçek kullanım verilerine göre yapılandırın. Bu, Kubernetes zamanlayıcısının daha akıllı yerleştirme kararları almasını ve kaynak çakışmalarını önlemesini sağlar. İzleme verilerinize göre bu değerleri üç ayda bir inceleyin ve ayarlayın.

Sağlık kontrolleri, uygulama hazırlığını korumada hayati bir rol oynar. Yanıt vermeyen süreçleri tespit etmek için canlılık kontrollerini ve trafik yönlendirmesini yönetmek için hazır olma kontrollerini kullanın. Dengeyi sağlamak için zaman aşımı değerlerini hassas bir şekilde ayarlayın; aşırı agresif ayarlar gereksiz yeniden başlatmalara neden olabilirken, esnek ayarlar başarısız olan kapsüllerin trafik almaya devam etmesine izin verebilir.

Mümkün olduğunda, uygulamaları durumsuz olacak şekilde tasarlayın. Oturum verilerini aşağıdaki gibi harici sistemlerde saklayın: Redis veya bellek içi yerine veritabanları. Bu, kullanıcı oturumlarını etkilemeden kapsüllerin yeniden başlatılmasını veya ölçeklenmesini sağlar. Durum gerektiren uygulamalar için, kalıcı birimlerle StatefulSet'leri kullanın ve verilerin bölgeler arasında çoğaltıldığından emin olun. Bu stratejiler, dayanıklı altyapıyla birleştirildiğinde uygulamalarınızın kullanılabilir kalmasını sağlamaya yardımcı olur.

Kullanarak ServerionHA Kubernetes için Altyapı

Serverion'ın küresel veri merkezi ağı, yüksek erişilebilirliğin temel bir bileşeni olan coğrafi dağıtımı basitleştirir. Gerçek yedeklilik elde etmek için kontrol düzlemi düğümlerini birden fazla bölgeye dağıtın. Özel sunucuları, etcd kümeleri için gereken tutarlı performansı sağlarken, VPS örnekleri çalışan düğümler için uygun maliyetli ölçeklenebilirlik sunar.

Serverion'ın özel sunucuları, "gürültülü komşu" etkisini ortadan kaldırarak öngörülebilir performans sağladıkları için kontrol düzlemi düğümleri için idealdir. Uyumluluk gereksinimleri veya mevcut donanım yatırımları olan kuruluşlar için Serverion'ın ortak yerleştirme hizmetleri, hibrit mimarilere olanak tanır. Bu kurulum, gerçek zamanlı veri çoğaltma ve sorunsuz geçiş için yüksek bant genişliğine sahip bağlantılarla desteklenen şirket içi altyapıyı veri merkezleriyle birleştirmenize olanak tanır.

Serverion'un birden fazla veri merkezi konumu, felaket kurtarmayı daha sağlam hale getirir. Farklı bölgelerde bekleme kümeleri kurun ve şu araçları kullanın: Velero Kümeler arasında geri yüklenebilen uygulama düzeyinde yedeklemeler için. DNS barındırma hizmetleri, birincil site çevrimdışı olduğunda DNS kayıtlarını güncelleyerek otomatik yedeklemeyi mümkün kılar.

Ek olarak, Serverion altyapı düzeyinde koruma sunar ve SSL sertifika hizmetleri Hem harici hem de dahili trafiği güvence altına almak için. Sunucu yönetim hizmetleri, donanım izleme, işletim sistemi güncellemeleri ve temel güvenlik görevlerini yöneterek ekibinizin Kubernetes'e özgü operasyonlara odaklanmasını sağlar. Bu özelliklerin birleşimi, Yüksek Performanslı Kubernetes kümelerini yönetmek için güçlü bir temel sağlar.

Çözüm

Her tasarım seçimi ve operasyonel adım, güvenilir bir Kubernetes kümesi oluşturmaya katkıda bulunur. Yüksek düzeyde kullanılabilir bir Kubernetes kurulumu oluşturmak, hem dayanıklılığını hem de performansını korumak için dikkatli planlama, sağlam uygulama ve sürekli bakım gerektirir.

Doğru topolojiyi seçmek ve güvenilir bir yük dengeleyici kurmak, kesintisiz API erişimini garanti eder. Birçok kuruluş için, yığılmış kontrol düzlemi modeli basitlik ve güvenilirlik arasında iyi bir denge kurar. kubeadm gibi araçlar dağıtımı kolaylaştırır ve sertifikaların etkili bir şekilde yönetilmesine yardımcı olur.

Operasyonel başarı, proaktif izleme, düzenli yedekleme tatbikatları ve Pod Kesinti Bütçeleri ve anti-affinity kuralları gibi özelliklerle uygulama tasarımına bağlıdır. Bu önlemler, altyapı aksaklıkları sırasında iş yüklerinin sabit kalmasına yardımcı olarak güvenilir performans sağlar.

Serverion'ın küresel altyapısı, bu stratejiye bir güvenilirlik katmanı daha ekliyor. Coğrafi çeşitlilik ve güçlü felaket kurtarma seçenekleri sunarak, özel sunucularla bir araya geldiğinde, birden fazla veri merkezinde tutarlı bir kontrol düzlemi performansının korunmasına yardımcı oluyorlar.

SSS

Kubernetes'te yığılmış ve harici etcd kurulumları arasındaki fark nedir ve kümem için en iyisini nasıl seçerim?

Aradaki temel fark yığılmış ve dış vb. Yapılandırmalar, etcd veritabanının nerede çalıştığına ve nasıl yönetildiğine bağlıdır. Yığınlanmış bir kurulumda, etcd, Kubernetes kontrol düzlemi bileşenleriyle aynı düğümlerde çalışır. Bu yöntemin uygulanması daha kolay ve daha ucuzdur, ancak bir dezavantajı vardır: Bir düğüm arızası hem kontrol düzlemini hem de etcd'yi etkileyerek önemli kesintilere yol açabilir.

Buna karşılık, harici bir etcd topolojisi etcd'yi ayrı, özel makinelere yerleştirir. Bu yaklaşım, özellikle daha büyük veya üretim düzeyindeki kümeler için dayanıklılığı ve performansı artırır. Ancak, yapılandırma ve sürekli bakım açısından daha fazla karmaşıklık da içerir.

Daha küçük veya daha az kritik Kubernetes ortamları için, genellikle yığınlanmış bir kurulum ihtiyaçları karşılar. Ancak büyük ölçekli veya yüksek kullanılabilirliğe sahip üretim kümeleri söz konusu olduğunda, güvenilirlik ve kararlılığı korumak için harici etcd tercih edilen seçenektir.

Çalışma süresi hedeflerine ulaşmak için yüksek düzeyde kullanılabilir bir Kubernetes kümesini izlemek ve sürdürmek için en iyi uygulamalar nelerdir?

Kubernetes kümenizin sorunsuz çalışmasını ve çalışma süresi beklentilerini karşılamasını sağlamak için üç kritik katmanı izlemeniz gerekir: altyapı, platform, Ve uygulamalarPrometheus gibi araçlar temel ölçümleri izlemenize yardımcı olurken, Grafana verileri görselleştirmeyi kolaylaştırır. CPU kullanımı, bellek tüketimi, pod yeniden başlatmaları ve hata oranları gibi ölçümlere dikkat edin. Uyarılar ayarlamak, sorunları daha da büyümeden önce tespit edip çözmenizi sağlar.

Kümenizi kurarken en iyi uygulamalara bağlı kalın. rol tabanlı erişim denetimi (RBAC) İzinleri etkili bir şekilde yönetmek, daha iyi bir yapı için kaynakları ad alanlarına ayırmak ve hata toleransını artırmak için yük dengeleyicilerle birden fazla kontrol düzlemi düğümü dağıtmak da aynı derecede önemlidir. En son Kubernetes sürümüne düzenli olarak güncelleme yapmak ve proaktif bakım planlamak da aynı derecede önemlidir. Bu önlemler yalnızca kesinti süresini azaltmakla kalmaz, aynı zamanda kümenizin iş ihtiyaçlarınızı karşılayacak şekilde ölçeklenebilmesini de sağlar.

Kubernetes kümesinde uygulamalarımı yüksek erişilebilirlik için nasıl tasarlayabilirim?

Uygulamalarınızın bir Kubernetes kümesinde sorunsuz çalışmasını sağlamak için öncelikle şunları ayarlayarak başlayın: birden fazla kopya Kubernetes Dağıtımları aracılığıyla uygulamanızın performansını artırın. Bu, iş yükünü dağıtır ve uygulamanızın pod arızalarını kesintisiz bir şekilde yönetebilmesini sağlar.

Bir diğer yararlı araç ise Pod Kesinti BütçesiBu özellik, güncellemeler veya bakım sırasında minimum sayıda etkin kapsülün korunmasına yardımcı olarak kesinti süresini azaltır. Daha da fazla güvenilirlik için kümenizi şuraya dağıtın: birden fazla bölge veya bölgeBu kurulum, uygulamalarınızı yerel kesintilere karşı korur ve yedekliliği artırır.

Bu yöntemleri kullanarak Kubernetes kurulumunuz daha dayanıklı olacak ve kesintiler meydana geldiğinde bile istikrarlı performans sağlanacaktır.

İlgili Blog Yazıları

• Akış Verileri için Hata Toleranslı Depolama: Temeller
• Veritabanı Devralma Testi: Önemli Adımlar
• DevOps için NGINX Yapılandırması: Serverion'un Sıfır Kesinti Süresiyle Dağıtımlar İçin Püf Noktası
• Kubernetes İş Yükleri için Otomatik Ölçeklendirme