Kumbuka tafsiri: Muhtasari huu kutoka kwa Weaveworks unatanguliza mikakati maarufu ya uwasilishaji wa programu na unaonyesha jinsi zile za hali ya juu zaidi zinaweza kutekelezwa kwa kutumia opereta wa Kubernetes Flagger. Imeandikwa kwa lugha rahisi na ina michoro ya kuona ambayo inaruhusu hata wahandisi wapya kuelewa suala hilo.
Mchoro unachukuliwa kutoka mikakati ya kusambaza iliyofanywa katika Suluhu za Kontena
Mojawapo ya changamoto kubwa katika kutengeneza programu asilia za mtandaoni leo ni kuongeza kasi ya utumaji. Katika mbinu ya huduma ndogo, wasanidi programu tayari wanafanya kazi na kubuni programu za kawaida kabisa, kuruhusu timu tofauti kuandika msimbo kwa wakati mmoja na kufanya mabadiliko kwenye programu.
Usambazaji mfupi na wa mara kwa mara una faida zifuatazo:
- Muda wa soko umepunguzwa.
- Vipengele vipya huwafikia watumiaji haraka zaidi.
- Maoni ya mtumiaji hufikia timu ya usanidi haraka zaidi. Hii inamaanisha kuwa timu inaweza kuongeza vipengele na kurekebisha matatizo kwa haraka zaidi.
- Ari ya wasanidi programu inaongezeka: vipengele zaidi katika ukuzaji vinafurahisha zaidi kufanya kazi navyo.
Lakini kadiri idadi ya matoleo inavyoongezeka, uwezekano wa kuathiri vibaya uaminifu wa programu au matumizi ya mtumiaji pia huongezeka. Ndiyo maana ni muhimu kwa uendeshaji na timu za DevOps kuunda michakato na kudhibiti mikakati ya utumaji kwa njia ambayo inapunguza hatari kwa bidhaa na watumiaji. (Unaweza kujifunza zaidi kuhusu otomatiki wa bomba la CI/CD .)
Katika chapisho hili, tutajadili mikakati mbalimbali ya upelekaji katika Kubernetes, ikijumuisha usambazaji na mbinu za juu zaidi kama vile uchapishaji wa canary na tofauti zao.
Mikakati ya kupeleka
Kuna aina kadhaa tofauti za mikakati ya kupeleka ambayo unaweza kutumia kulingana na lengo lako. Kwa mfano, unaweza kuhitaji kufanya mabadiliko kwa mazingira fulani kwa majaribio zaidi, au kwa kikundi kidogo cha watumiaji/wateja, au unaweza kuhitaji kufanya majaribio machache ya watumiaji kabla ya kutengeneza kipengele. umma.
Rolling (usambazaji wa hatua kwa hatua, "rolling")
Huu ndio mkakati wa kawaida wa uwekaji katika Kubernetes. Hatua kwa hatua, moja baada ya nyingine, hubadilisha maganda na toleo la zamani la programu na maganda na toleo jipya - bila kukatika kwa nguzo.
Kubernetes husubiri hadi maganda mapya yawe tayari kufanya kazi (kuyaangalia kwa kutumia ), kabla ya kuanza kukunja zile za zamani. Tatizo likitokea, sasisho hili linaloendelea linaweza kusitishwa bila kusimamisha nguzo nzima. Katika faili ya YAML inayoelezea aina ya utumaji, picha mpya inachukua nafasi ya picha ya zamani:
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: 8080Vigezo vya usasishaji wa ubadilishanaji vinaweza kubainishwa katika faili ya maelezo:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Unda upya
Katika aina hii rahisi ya upelekaji, maganda ya zamani huuawa mara moja na kubadilishwa na mpya:
Dhihirisho inayolingana inaonekana kama hii:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Bluu/Kijani (mipangilio ya bluu-kijani)
Mkakati wa uwekaji wa rangi ya samawati-kijani (wakati mwingine pia huitwa nyekundu/nyeusi) unahusisha utumiaji wa wakati mmoja wa matoleo ya zamani (ya kijani) na mapya (ya bluu) ya programu. Baada ya kuchapisha matoleo yote mawili, watumiaji wa kawaida wanaweza kufikia toleo la kijani kibichi, huku la bluu linapatikana kwa timu ya QA kufanyia majaribio kiotomatiki kupitia huduma tofauti au usambazaji wa moja kwa moja wa mlango:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Baada ya toleo la bluu (mpya) kujaribiwa na kutolewa kwake kupitishwa, huduma hubadilika kwake, na toleo la kijani (zamani) linakunjwa:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (usambazaji wa canary)
Utoaji wa Canary ni sawa na uchapishaji wa bluu-kijani, lakini una udhibiti na matumizi bora mbinu hatua kwa hatua. Aina hii inajumuisha mikakati kadhaa tofauti, ikijumuisha uzinduzi wa "siri" na majaribio ya A/B.
Mkakati huu hutumiwa wakati kuna haja ya kujaribu utendakazi mpya, kwa kawaida katika upande wa nyuma wa programu. Kiini cha mbinu ni kuunda seva mbili zinazofanana: moja hutumikia karibu watumiaji wote, na nyingine, na kazi mpya, hutumikia kikundi kidogo cha watumiaji, baada ya hapo matokeo ya kazi zao yanalinganishwa. Ikiwa kila kitu kitaenda bila makosa, toleo jipya linatolewa hatua kwa hatua kwa miundombinu yote.
Ingawa mkakati huu unaweza kutekelezwa kwa kutumia Kubernetes pekee, ikibadilisha maganda ya zamani na mapya, ni rahisi zaidi na rahisi zaidi kutumia matundu ya huduma kama Istio.
Kwa mfano, unaweza kuwa na maonyesho mawili tofauti katika Git: faili ya maelezo ya kawaida iliyo na lebo 0.1.0 na faili ya wazi iliyo na lebo 0.2.0. Kwa kubadilisha uzani katika faili ya maelezo ya lango pepe la Istio, unaweza kudhibiti usambazaji wa trafiki kati ya uwekaji haya mawili:
Kwa mwongozo wa hatua kwa hatua wa kutekeleza upelekaji wa canary kwa kutumia Istio, ona . (Kumbuka. tafsiri.: Pia tulitafsiri nyenzo kuhusu uchapishaji wa canary katika Istio .)
Usambazaji wa Canary na Bendera ya Weaveworks
hukuruhusu kudhibiti kwa urahisi na kwa ufanisi uchapishaji wa canary.
Bendera hufanya kazi nao kiotomatiki. Inatumia Istio au AWS App Mesh kuelekeza na kubadilisha trafiki, na metriki za Prometheus kuchanganua matokeo. Kwa kuongeza, uchambuzi wa kupelekwa kwa canary unaweza kuongezewa na webhooks kufanya vipimo vya kukubalika, vipimo vya mzigo, na aina nyingine yoyote ya hundi.
Kulingana na uwekaji wa Kubernetes na, ikihitajika, kuongeza ukubwa wa maganda (HPA) mlalo, Flagger huunda seti za vitu (usambazaji wa Kubernetes, huduma za ClusterIP na huduma pepe za Istio au App Mesh) ili kuchanganua na kutekeleza uwekaji wa canary:
Utekelezaji wa kitanzi cha udhibiti (kitanzi cha kudhibiti),Flagger hubadilisha trafiki polepole hadi kwenye seva ya canary, huku ikipima kwa wakati mmoja vipimo muhimu vya utendakazi kama vile asilimia ya maombi yaliyofaulu ya HTTP, wastani wa muda wa ombi na afya ya ganda. Kulingana na uchanganuzi wa KPI (Viashiria Muhimu vya Utendaji) , canary inakua au inaporomoka na matokeo ya uchanganuzi huchapishwa katika Slack. Maelezo na maonyesho ya mchakato huu yanaweza kupatikana katika nyenzo .
Usambazaji wa giza (uliofichwa) au A/B
Usambazaji wa siri ni tofauti nyingine ya mkakati wa canary (ambayo, kwa njia, Bendera pia inaweza kufanya kazi nayo). Tofauti kati ya uwekaji siri na canary ni kwamba uwekaji siri hushughulika na sehemu ya mbele badala ya nyuma kama vile uenezaji wa canary.
Jina lingine la matumizi haya ni majaribio ya A/B. Badala ya kufanya kipengele kipya kipatikane kwa watumiaji wote, kinatolewa kwa sehemu ndogo tu. Kwa kawaida, watumiaji hawa hawajui kuwa wao ni wajaribu watangulizi (kwa hivyo neno "usambazaji wa siri").
Kutumia swichi za utendaji (kugeuza kipengele) na zana zingine, unaweza kufuatilia jinsi watumiaji huingiliana na kipengele kipya, iwe wanakitumia, au kama wanaona kiolesura kipya kinatatanisha, na aina nyinginezo za vipimo.
Usambazaji wa Bendera na A/B
Kando na uelekezaji unaotegemea uzito, Bendera inaweza pia kuelekeza trafiki kwa seva ya canary kulingana na vigezo vya HTTP. Katika jaribio la A/B, unaweza kutumia vichwa vya HTTP au vidakuzi kulenga sehemu mahususi ya watumiaji. Hii inafaa sana katika kesi ya programu za mbele zinazohitaji kushurutisha kipindi kwa seva (uhusiano wa kikao). Maelezo zaidi yanaweza kupatikana katika hati za Bendera.
Mwandishi anaonyesha shukrani , Mhandisi wa Weaveworks (na muundaji wa Bendera), kwa mifumo hii yote ya ajabu ya utumiaji.
PS kutoka kwa mtafsiri
Soma pia kwenye blogi yetu:
- Β«";
- Β«";
- Β«";
- Β«'.
Chanzo: mapenzi.com