Ni uzos Gitlab CI kaj manlibron GitOps por efektivigi kaj uzi Kanarian deplojon en Kubernetes
Artikoloj de ĉi tiu serio:
- (Ĉi tiu artikolo)
- Kanaria Deplojo uzante Istio
- Kanaria Deplojo uzante Jenkins-X Istio Flagger
Ni plenumos la Kanarian deplojon permane per GitOps kaj kreante/modifante la ĉefajn rimedojn de Kubernetes. Ĉi tiu artikolo estas destinita ĉefe por enkonduko kun kiel funkcias deplojo en Kubernetes Canary, ĉar ekzistas pli efikaj metodoj de aŭtomatigo, kiujn ni konsideros en la sekvaj artikoloj.
Kanaria Deplojo
Kun la Kanaria strategio, ĝisdatigoj unue estas aplikataj al nur subaro de uzantoj. Per monitorado, protokolaj datumoj, manlibrotestado aŭ aliaj sugestaj kanaloj, la liberigo estas provita antaŭ ol ĝi estas liberigita al ĉiuj uzantoj.
Kubernetes Deplojo (ruliĝanta ĝisdatigo)
La defaŭlta strategio por Kubernetes Deployment estas ruliĝanta ĝisdatigo, kie certa nombro da podoj estas lanĉitaj kun novaj versioj de la bildoj. Se ili estis kreitaj sen problemoj, balgoj kun malnovaj versioj de bildoj estas finitaj, kaj novaj podoj estas kreitaj paralele.
GitOps
Ni uzas GitOps en ĉi tiu ekzemplo ĉar ni:
- uzante Git kiel ununuran fonton de vero
- ni uzas Git-Operaciojn por konstruo kaj deplojo (neniaj komandoj krom git tag/merge estas bezonataj)
Ekzemplo:
Ni prenu bonan praktikon - havi unu deponejon por aplika kodo kaj unu por infrastrukturo.
Aplika deponejo
Ĉi tio estas tre simpla Python+Flask API, kiu resendas respondon kiel JSON. Ni konstruos la pakaĵon per GitlabCI kaj puŝos la rezulton al la Gitlab-Registro. En la registro ni havas du malsamajn eldonversiojn:
wuestkamp/k8s-deployment-example-app:v1wuestkamp/k8s-deployment-example-app:v2
La nura diferenco inter ili estas la ŝanĝo en la resendita JSON-dosiero. Ni uzas ĉi tiun aplikaĵon por vidi kiel eble plej facile, kun kiu versio ni komunikas.
Infrastruktura deponejo
En ĉi tiu napo ni deplojos per GitlabCI al Kubernetes, .gitlab-ci.yml aspektas tiel:
image: traherom/kustomize-docker
before_script:
- printenv
- kubectl version
stages:
- deploy
deploy test:
stage: deploy
before_script:
- echo $KUBECONFIG
script:
- kubectl get all
- kubectl apply -f i/k8s
only:
- master
Por ruli ĝin mem vi bezonos grapolon, vi povas uzi Gcloud:
gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80Vi devas forkiĝi kaj kreu variablon KUBECONFIG en GitlabCI, kiu enhavos la agordon por aliro kubectl al via areto.
Vi povas legi pri kiel akiri akreditaĵojn por areto (Gcloud) .
Infrastrukturo Yaml
En la infrastruktura deponejo ni havas servon:
apiVersion: v1
kind: Service
metadata:
labels:
id: app
name: app
spec:
ports:
- port: 80
protocol: TCP
targetPort: 5000
selector:
id: app
type: LoadBalancerKaj deplojo en deploy.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: app
spec:
replicas: 10
selector:
matchLabels:
id: app
type: main
template:
metadata:
labels:
id: app
type: main
spec:
containers:
- image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
name: app
resources:
limits:
cpu: 100m
memory: 100MiKaj alia deplojo en deploy-canary.yaml:
kind: Deployment
metadata:
name: app-canary
spec:
replicas: 0
selector:
matchLabels:
id: app
type: canary
template:
metadata:
labels:
id: app
type: canary
spec:
containers:
- image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
name: app
resources:
limits:
cpu: 100m
memory: 100MiNotu, ke app-deploy ankoraŭ ne havas iujn kopiojn difinitajn.
Farante komencan deplojon
Por komenci la komencan deplojon, vi povas komenci la GitlabCI-dukton permane sur la majstra branĉo. Post tio kubectl devus eligi la jenon:
Ni vidas app deplojo kun 10 kopioj kaj app-canary kun 0. Ekzistas ankaŭ LoadBalancer de kiu ni povas aliri tra curl per Ekstera IP:
while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done
Ni vidas, ke nia testa aplikaĵo nur resendas "v1".
Efektivigante Kanarian deplojon
Paŝo 1: liberigu novan version por iuj uzantoj
Ni fiksas la nombron da kopioj al 1 en la dosiero deploy-canary.yaml kaj la nova versio-bildo:
kind: Deployment
metadata:
name: app-canary
spec:
replicas: 1
selector:
matchLabels:
id: app
type: canary
template:
metadata:
labels:
id: app
type: canary
spec:
containers:
- image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
name: app
resources:
limits:
cpu: 100m
memory: 100MiEn dosiero deploy.yaml ni ŝanĝis la nombron da kopioj al 9:
kind: Deployment
metadata:
name: app
spec:
replicas: 9
selector:
matchLabels:
id: app
...Ni puŝas ĉi tiujn ŝanĝojn al la deponejo de kiu komenciĝos la deplojo (per GitlabCI) kaj vidas kiel rezulton:
Nia Servo montros ambaŭ deplojojn, ĉar ambaŭ havas la aplikan elektilon. Pro defaŭlta hazardigo de Kubernetes, ni devus vidi malsamajn respondojn por ~10% de petoj:
La nuna stato de nia aplikaĵo (GitOps, prenita de Git kiel Single Source Of Truth) estas la ĉeesto de du deplojoj kun aktivaj kopioj, unu por ĉiu versio.
~10% de uzantoj konatiĝas kun nova versio kaj neintence testas ĝin. Nun estas la tempo por kontroli erarojn en la protokoloj kaj monitoraj datumoj por trovi problemojn.
Paŝo 2: Liberigu la novan version al ĉiuj uzantoj
Ni decidis, ke ĉio iris bone kaj nun ni devas eldoni la novan version al ĉiuj uzantoj. Por fari tion ni simple ĝisdatigas deploy.yaml instalante novan version de la bildo kaj la nombro da kopioj egala al 10. En deploy-canary.yaml ni fiksas la nombron da kopioj reen al 0. Post deplojo, la rezulto estos kiel sekvas:
Resumi
Por mi, ruli la deplojon permane tiel helpas kompreni kiom facile ĝi povas esti agordita per k8s. Ĉar Kubernetes permesas vin ĝisdatigi ĉion per API, ĉi tiuj paŝoj povas esti aŭtomatigitaj per skriptoj.
Alia afero, kiu devas esti efektivigita, estas testilo enirpunkto (LoadBalancer aŭ per Ingress) tra kiu nur la nova versio povas esti alirebla. Ĝi povas esti uzata por mana foliumado.
En estontaj artikoloj, ni kontrolos aliajn aŭtomatigitajn solvojn, kiuj efektivigas plejparton de tio, kion ni faris.
Legu ankaŭ aliajn artikolojn en nia blogo:
fonto: www.habr.com