Qeyd. tərcümə: Weaveworks-in bu icmalı ən populyar tətbiqetmə strategiyalarını təqdim edir və Kubernetes Flagger operatorundan istifadə edərək ən qabaqcıl strategiyaların necə həyata keçirilə biləcəyini göstərir. Sadə dildə yazılmışdır və hətta təcrübəsiz mühəndislərə də məsələni başa düşməyə imkan verən vizual diaqramlardan ibarətdir.
Diaqramdan götürülüb Konteyner Həllərində hazırlanmış rollout strategiyaları
Bu gün yerli bulud proqramlarının hazırlanmasında ən böyük problemlərdən biri yerləşdirməni sürətləndirməkdir. Mikroservis yanaşmasında tərtibatçılar artıq tam modul proqramlarla işləyir və dizayn edir, müxtəlif komandalara eyni vaxtda kod yazmağa və tətbiqdə dəyişiklik etməyə imkan verir.
Daha qısa və daha tez-tez yerləşdirmələr aşağıdakı üstünlüklərə malikdir:
- Bazara çıxma vaxtı azalır.
- Yeni funksiyalar istifadəçilərə daha tez çatır.
- İstifadəçi rəyi inkişaf qrupuna daha sürətli çatır. Bu o deməkdir ki, komanda funksiyalar əlavə edə və problemləri daha tez həll edə bilər.
- Tərtibatçının əhval-ruhiyyəsi yüksəlir: inkişafda daha çox funksiya ilə işləmək daha əyləncəlidir.
Lakin buraxılışların tezliyi artdıqca, tətbiqin etibarlılığına və ya istifadəçi təcrübəsinə mənfi təsir göstərmək şansları da artır. Buna görə əməliyyatlar və DevOps komandaları üçün proseslər qurmaq və yerləşdirmə strategiyalarını məhsul və istifadəçilər üçün riski minimuma endirəcək şəkildə idarə etmək vacibdir. (CI/CD boru kəmərinin avtomatlaşdırılması haqqında daha çox öyrənə bilərsiniz .)
Bu yazıda biz Kubernetes-də müxtəlif yerləşdirmə strategiyalarını, o cümlədən yuvarlanan yerləşdirmələri və kanareykaların yayılması və onların varyasyonları kimi daha təkmil metodları müzakirə edəcəyik.
Yerləşdirmə strategiyaları
Məqsədinizdən asılı olaraq istifadə edə biləcəyiniz bir neçə fərqli yerləşdirmə strategiyası var. Məsələn, əlavə sınaq üçün müəyyən mühitdə və ya istifadəçilərin/müştərilərin alt çoxluğunda dəyişiklik etməli ola bilərsiniz və ya bir funksiya yaratmazdan əvvəl məhdud istifadəçi testi etməlisiniz. ictimai.
Rolling (tədricən, "yayma" yerləşdirmə)
Bu Kubernetes-də standart yerləşdirmə strategiyasıdır. O, tədricən, bir-bir, klasterin dayanması olmadan, tətbiqin köhnə versiyası ilə podları yeni versiya ilə podlarla əvəz edir.
Kubernetes yeni podların işləməyə hazır olmasını gözləyir (onları yoxlayır ), köhnələri yuvarlamağa başlamazdan əvvəl. Problem baş verərsə, bu yayma yeniləmə bütün klasteri dayandırmadan dayandırıla bilər. Yerləşdirmə növünü təsvir edən YAML faylında yeni şəkil köhnə şəkli əvəz edir:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp
spec:
replicas: 3
template:
metadata:
labels:
app: awesomeapp
spec:
containers:
- name: awesomeapp
image: imagerepo-user/awesomeapp:new
ports:
- containerPort: 8080Rollover yeniləmə parametrləri manifest faylında göstərilə bilər:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Yenidən yaradın
Bu ən sadə yerləşdirmə növündə köhnə podlar bir anda məhv edilir və yeniləri ilə əvəz olunur:
Müvafiq manifest belə görünür:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Mavi/Yaşıl (mavi-yaşıl yerləşdirmələr)
Mavi-yaşıl yerləşdirmə strategiyası (bəzən qırmızı/qara da deyilir) tətbiqin köhnə (yaşıl) və yeni (mavi) versiyalarının eyni vaxtda yerləşdirilməsini nəzərdə tutur. Hər iki versiyanı dərc etdikdən sonra adi istifadəçilər yaşıl olana, mavi isə QA komandası üçün ayrıca xidmət və ya birbaşa port yönləndirmə vasitəsilə testləri avtomatlaşdırmaq üçün əlçatandır:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Mavi (yeni) versiya sınaqdan keçirildikdən və buraxılışı təsdiqləndikdən sonra xidmət ona keçir və yaşıl (köhnə) versiya qatlanır:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Kanareyka (kanareyka yerləşdirmələri)
Canary rollouts mavi-yaşıl yaymalara bənzəyir, lakin daha yaxşı nəzarət və istifadəyə malikdir addım-addım yanaşma. Bu növə “gizli” buraxılışlar və A/B testi daxil olmaqla bir neçə fərqli strategiya daxildir.
Bu strategiya adətən tətbiqin arxa hissəsində bəzi yeni funksiyaları sınamağa ehtiyac olduqda istifadə olunur. Yanaşmanın mahiyyəti iki demək olar ki, eyni server yaratmaqdan ibarətdir: biri demək olar ki, bütün istifadəçilərə xidmət göstərir, digəri isə yeni funksiyalarla yalnız kiçik bir alt qrup istifadəçilərə xidmət edir, bundan sonra onların işinin nəticələri müqayisə edilir. Hər şey səhvsiz gedirsə, yeni versiya tədricən bütün infrastruktura yayılır.
Bu strategiya köhnə podları yeniləri ilə əvəz etməklə yalnız Kubernetes-dən istifadə etməklə həyata keçirilə bilsə də, Istio kimi xidmət şəbəkəsindən istifadə etmək daha rahat və sadədir.
Məsələn, Git-də iki fərqli manifestiniz ola bilər: 0.1.0 teqli müntəzəm manifest və 0.2.0 teqli kanareyka manifesti. Istio virtual şlüz manifestindəki çəkiləri dəyişdirərək, bu iki yerləşdirmə arasında trafikin paylanmasına nəzarət edə bilərsiniz:
Istio istifadə edərək kanareyka yerləşdirmələrini həyata keçirmək üçün addım-addım təlimat üçün baxın . (Qeyd. tərcümə.: Biz həmçinin kanareykalar haqqında materialı Istio dilinə tərcümə etdik .)
Weaveworks Flagger ilə Canary Deployments
kanareykaları asanlıqla və effektiv şəkildə idarə etməyə imkan verir.
Flagger avtomatları onlarla işləyir. O, trafiki marşrutlaşdırmaq və dəyişdirmək üçün Istio və ya AWS App Mesh-dən, nəticələri təhlil etmək üçün Prometheus metriklərindən istifadə edir. Bundan əlavə, kanareyka yerləşdirmələrinin təhlili qəbul testləri, yükləmə testləri və hər hansı digər növ yoxlamalar aparmaq üçün veb-qancalarla əlavə edilə bilər.
Kubernetes yerləşdirməsinə və lazım olduqda podların üfüqi miqyasına (HPA) əsaslanaraq, Flagger kanareyka yerləşdirmələrini təhlil etmək və həyata keçirmək üçün obyektlər dəstlərini (Kubernetes yerləşdirmələri, ClusterIP xidmətləri və Istio və ya App Mesh virtual xidmətləri) yaradır:
Nəzarət dövrəsinin həyata keçirilməsi (nəzarət dövrəsi),Flagger, uğurlu HTTP sorğularının nisbəti, orta sorğu müddəti və podların sağlamlığı kimi əsas performans göstəricilərini eyni vaxtda ölçərkən, trafiki tədricən canary serverə keçir. KPI (Əsas Performans Göstəriciləri) təhlilinə əsasən, kanareyka ya böyüyür, ya da çökür və təhlilin nəticələri Slack-də dərc olunur. Bu prosesin təsviri və nümayişi materialda tapıla bilər .
Qaranlıq (gizli) və ya A/B yerləşdirmələri
Gizli yerləşdirmə kanareyka strategiyasının başqa bir variantıdır (yeri gəlmişkən, Flagger də onunla işləyə bilər). Gizli və kanareyka yerləşdirmələri arasındakı fərq, gizli yerləşdirmələrin kanareyka yerləşdirmələri kimi arxa hissə ilə deyil, ön hissə ilə məşğul olmasıdır.
Bu yerləşdirmələrin başqa bir adı A/B testidir. Yeni funksiyanı bütün istifadəçilər üçün əlçatan etmək əvəzinə, onların yalnız məhdud hissəsinə təklif olunur. Tipik olaraq, bu istifadəçilər qabaqcıl sınaqçılar olduqlarından xəbərsizdirlər (buna görə də "gizli yerləşdirmə" termini).
Funksional açarların istifadəsi (xüsusiyyət keçidi) və digər vasitələrdən istifadə edərək, istifadəçilərin yeni funksiya ilə necə qarşılıqlı əlaqədə olduqlarını, bu funksiya ilə məşğul olub-olmadıqlarını və ya yeni istifadəçi interfeysini çaşdırıcı tapıb tapmamalarını və digər ölçü növlərini izləyə bilərsiniz.
Flagger və A/B yerləşdirmələri
Çəkiyə əsaslanan marşrutlaşdırma ilə yanaşı, Flagger HTTP parametrləri əsasında trafiki də canar serverinə yönləndirə bilər. A/B testində siz istifadəçilərin müəyyən seqmentini hədəfləmək üçün HTTP başlıqlarından və ya kukilərdən istifadə edə bilərsiniz. Bu, serverə sessiyanın bağlanmasını tələb edən frontend proqramları üçün xüsusilə təsirlidir (sessiya yaxınlığı). Əlavə məlumatı Flagger sənədlərində tapa bilərsiniz.
Müəllif minnətdarlığını bildirir , Bütün bu heyrətamiz yerləşdirmə nümunələri üçün Weaveworks mühəndisi (və Flagger-in yaradıcısı).
Tərcüməçidən PS
Bloqumuzda da oxuyun:
- «";
- «";
- «";
- «.
Mənbə: www.habr.com