Kubernetes Sürətli Başlanğıc Seriyasına xoş gəlmisiniz. Bu, onlayn və təlimlərimizdə aldığımız ən maraqlı sualların yer aldığı müntəzəm rubrikadır. Kubernetes eksperti cavab verir.
Bu günün eksperti Daniel Polençikdir (). Daniel bir təlimatçı və proqram tərtibatçısı kimi çalışır .
Əgər sualınıza növbəti postda cavab almaq istəyirsinizsə, və ya .
Əvvəlki yazıları qaçırdınız? .
Fərqli məlumat mərkəzlərində Kubernetes klasterlərini necə bağlamaq olar?
Qısaca: , və mən də sizə oxumağı məsləhət görürəm и .
Çox vaxt infrastruktur təkrarlanır və müxtəlif bölgələr arasında, xüsusən də idarə olunan mühitlərdə paylanır.
Bir bölgə əlçatan deyilsə, kəsilmələrin qarşısını almaq üçün trafik digərinə yönləndirilir.
Kubernetes ilə siz oxşar strategiyadan istifadə edə və iş yüklərini müxtəlif bölgələr arasında paylaya bilərsiniz.
Komanda, region, ətraf mühit və ya bunların kombinasiyası üçün bir və ya daha çox klasteriniz ola bilər.
Klasterləriniz çoxsaylı buludlarda və yerli yerlərdə yerləşdirilə bilər.
Bəs belə bir coğrafi yayılma üçün infrastrukturu necə planlaşdırmaq olar?
Bir şəbəkə üzərində bir neçə bulud mühiti üçün bir böyük klaster yaratmalısınız?
Yoxsa çoxlu kiçik klasterlər var və onları idarə etmək və sinxronlaşdırmaq üçün bir yol tapırsınız?
Bir liderlik klasteri
Tək şəbəkə üzərində bir klaster yaratmaq o qədər də asan deyil.
Təsəvvür edin ki, qəza keçirdiniz, klaster seqmentləri arasında əlaqə itdi.
Bir master serveriniz varsa, resursların yarısı yeni əmrlər ala bilməyəcək, çünki onlar master ilə əlaqə saxlaya bilməyəcəklər.
Və eyni zamanda köhnə marşrutlaşdırma cədvəlləriniz var (kube-proxy yenilərini endirə bilmir) və əlavə podlar yoxdur (kubelet yeniləmələri sorğulaya bilməz).
Daha da pisi, əgər Kubernetes node görə bilmirsə, onu yetim kimi qeyd edir və çatışmayan podları mövcud qovşaqlara paylayır.
Nəticə etibarı ilə sizdə iki dəfə çox qabıq var.
Hər bölgəyə bir master server etsəniz, etcd verilənlər bazasında konsensus alqoritmi ilə bağlı problemlər yaranacaq. (təqribən. red. - Əslində, etcd verilənlər bazası əsas serverlərdə yerləşməlidir. Eyni bölgədəki ayrı bir server qrupunda işlədilə bilər. Bununla birlikdə, eyni zamanda bir klasterin uğursuzluq nöqtəsini aldıqdan sonra. Amma tez.)
etcd istifadə edir diskə yazmadan əvvəl dəyəri razılaşdırmaq.
Yəni, dövlətin etcd-yə yazılmasından əvvəl əksər hallarda konsensusa gəlməlidir.
Əgər etcd nümunələri arasındakı gecikmə, müxtəlif bölgələrdəki üç etcd instansiyasında olduğu kimi sürətlə artırsa, dəyəri razılaşdırmaq və onu diskə yazmaq çox vaxt aparır.
Bu, Kubernetes nəzarətçilərində də əks olunur.
Nəzarətçi menecer dəyişikliyi öyrənmək və verilənlər bazasına cavab yazmaq üçün daha çox vaxt tələb edir.
Nəzarətçi bir deyil, bir neçə olduğundan, zəncirvari reaksiya əldə edilir və bütün klaster çox yavaş işləməyə başlayır.
etcd gecikməyə o qədər həssasdır ki .
Hal-hazırda tək klaster üçün böyük şəbəkənin yaxşı nümunələri yoxdur.
Əsasən, tərtibatçı icması və SIG-klaster qrupu, Kubernetes-in konteynerləri idarə etdiyi kimi klasterləri necə təşkil edəcəyini anlamağa çalışır.
Seçim 1: kubefed ilə federasiya qrupları
SIG-klasterindən rəsmi cavab - .
İlk dəfə kube federasiya alətindən istifadə edərək klasterlər toplusunu vahid obyekt kimi idarə etməyə çalışdıq.
Başlanğıc yaxşı idi, amma sonda kube federasiyası populyarlaşa bilmədi, çünki bütün resursları dəstəkləmədi.
O, məsələn, StatefulSets deyil, federativ təchizat və xidmətləri dəstəkləyirdi.
Həmçinin, federasiya konfiqurasiyası annotasiyalar şəklində keçdi və çevik deyildi.
Tək annotasiyadan istifadə edərək federasiyada hər bir çoxluq üçün replikaların bölünməsini necə təsvir edə biləcəyinizi təsəvvür edin.
Tam bir qarışıqlıq olduğu ortaya çıxdı.
SIG-klaster kubefed v1-dən sonra əla iş gördü və problemə fərqli bucaqdan yanaşmağa qərar verdi.
Annotasiyalar əvəzinə, klasterlərdə quraşdırılmış nəzarətçi buraxmağa qərar verdilər. Xüsusi resurs təriflərindən (Xüsusi Resurs Tərifi, CRD) istifadə edərək konfiqurasiya edilə bilər.
Federasiya ediləcək hər bir resurs üçün üç bölmədə fərdi CRD tərifiniz var:
- yerləşdirmə kimi resursun standart tərifi;
- bölmə
placement, resursun federasiyada necə bölüşdürüləcəyini müəyyən etdiyiniz yer; - bölmə
override, burada xüsusi resurs üçün yerləşdirmədən çəki və parametrləri ləğv edə bilərsiniz.
Budur, yerləşdirmə və ləğv bölmələri ilə birləşdirilmiş çatdırılma nümunəsi.
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: 5Gördüyünüz kimi, tədarük iki qrupa bölünür: cluster1 и cluster2.
Birinci klaster üç replika təqdim edir, ikincisi isə 5 dəyərinə malikdir.
Əgər replikaların sayı üzərində daha çox nəzarətə ehtiyacınız varsa, kubefed2 replikaların ölçülə bildiyi yeni ReplicaSchedulingPreference obyekti təqdim edir:
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: 2CRD strukturu və API hələ tam hazır deyil və rəsmi layihə deposunda aktiv iş aparılır.
kubefed2-yə diqqət yetirin, lakin istehsal mühiti üçün hələ kifayət qədər yaxşı olmadığını unutmayın.
kubefed2 haqqında daha çox məlumat əldə edin Kubernetes bloqunda və .
Seçim 2: Booking.com üslubunun klasterləşdirilməsi
Booking.com-un tərtibatçıları kubefed v2 ilə məşğul olmadılar, lakin onlar çoxlu klasterlərə, çoxsaylı bölgələrə və çoxsaylı buludlara çatdırılma operatoru olan Shipper ilə gəldilər.
kubefed2 ilə bir qədər oxşardır.
Hər iki alət çoxlu klaster yerləşdirmə strategiyanızı fərdiləşdirməyə imkan verir (hansı klasterlərdən istifadə olunur və onların neçə replikası var).
Lakin Yükgöndərənin işi göndərmə xətaları riskini azaltmaqdır.
Göndərəndə siz replikaların əvvəlki və cari yerləşdirmələr arasında bölünməsini və daxil olan trafikin miqdarını təsvir edən bir sıra addımlar müəyyən edə bilərsiniz.
Mənbəni klasterə itələdikdə, Göndərən nəzarətçi bu dəyişikliyi tədricən bütün federasiya qruplarına yerləşdirir.
Həmçinin Göndərən çox məhduddur.
Məsələn, giriş kimi Helm qrafiklərini qəbul edir və vanil qaynaqlarını dəstəkləmir.
Ümumiyyətlə, Göndərən aşağıdakı kimi işləyir.
Standart paylama əvəzinə, Helm diaqramını ehtiva edən proqram resursu yaratmalısınız:
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: 3Göndərən çoxlu klasterləri idarə etmək üçün yaxşı seçimdir, lakin onun Helm ilə sıx əlaqəsi yalnız buna mane olur.
Hamımız Helmdən keçsək nə olacaq? və ya ?
Shipper və onun fəlsəfəsi haqqında daha çox məlumat əldə edin .
Kodu öyrənmək istəyirsinizsə, .
Seçim 3: "sehrli" klasterin birləşməsi
Kubefed v2 və Göndərən xüsusi resurs tərifi vasitəsilə klasterlərə yeni resurslar təqdim etməklə klaster federasiyası ilə işləyir.
Bəs birləşdiriləcək bütün təchizatları, StatefulSets, DaemonSets və s.-ni yenidən yazmaq istəmirsinizsə?
YAML-i dəyişdirmədən mövcud klasteri federasiyaya necə daxil etmək olar?
, klasterlər üzrə iş yüklərinin planlaşdırılması ilə məşğul olan.
Lakin klasterlə qarşılıqlı əlaqə yaratmaq və resursları xüsusi təriflərdə yığmaq üçün yeni üsul icad etmək əvəzinə, çox klasterli planlaşdırıcı standart Kubernetes həyat dövrünə daxil edilir və podlar yaradan bütün zəngləri kəsir.
Hər yaradılmış pod dərhal bir dummy ilə əvəz olunur.
multi-klaster-planlayıcı istifadə edir Zəngə müdaxilə etmək və boş dummy pod yaratmaq.
Orijinal pod başqa bir planlaşdırma dövründən keçir, burada bütün federasiyanın səsverməsindən sonra hostinq qərarı verilir.
Nəhayət, pod hədəf klasterə çatdırılır.
Nəticədə, heç bir şey etməyən, sadəcə yer tutan əlavə bir pod var.
Üstünlük ondan ibarətdir ki, təchizatı birləşdirmək üçün yeni resurslar yazmağa ehtiyac yoxdur.
Pod yaradan hər bir resurs avtomatik olaraq federasiyaya hazırdır.
Bu maraqlıdır, çünki birdən-birə bir neçə bölgəyə ləvazimat paylandınız və siz fərq etmədiniz. Ancaq bu olduqca risklidir, çünki burada hər şey sehrə əsaslanır.
Lakin Yükgöndərən əsasən daşınmaların təsirlərini azaltmağa çalışsa da, çoxlu klasterli planlaşdırıcı daha ümumidir və bəlkə də toplu işlər üçün daha uyğundur.
Onun təkmil mərhələli çatdırılma mexanizmi yoxdur.
Çoxlu klaster planlaşdırıcısı haqqında ətraflı məlumatı burada tapa bilərsiniz .
Fəaliyyətdə olan çoxlu klasterli planlaşdırıcı haqqında oxumaq istəyirsinizsə, Admiralty var - iş axınları, hadisələr, CI və CD Kubernetes.
Digər vasitələr və həllər
Çoxlu klasterləri birləşdirmək və idarə etmək mürəkkəb bir işdir və hər kəsə uyğun bir həll yolu yoxdur.
Bu mövzu haqqında daha çox öyrənmək istəyirsinizsə, burada bəzi mənbələr var:
- müxtəlif Kubernetes klasterlərinin üst-üstə düşmə şəbəkələrini birləşdirən bir vasitədir.
- Hədəf pərakəndə satış zənciri istifadə edir .
- IPV6 və istifadə etməyə çalışın .
- Məsələn, bir xidmət şəbəkəsindən istifadə edə bilərsiniz .
- Konteyner şəbəkəsi interfeysi plagini Cilium təklif edir , bir neçə klasteri birləşdirməyə imkan verir
Bu gün üçün hamısı budur
Sona qədər oxuduğunuz üçün təşəkkür edirik!
Çoxlu klasterləri daha səmərəli şəkildə necə birləşdirəcəyinizi bilirsinizsə, .
Metodunuzu linklərə əlavə edəcəyik.
Chris Nesbitt-Smith-ə xüsusi təşəkkürlər () və Vincent de Sme () (etibarlılıq üzrə mühəndisə ) məqaləni oxumaq və federasiyanın necə işlədiyinə dair faydalı məlumatları bölüşmək üçün.
Mənbə: www.habr.com