By it bouwen fan in CI/CD-proses mei Kubernetes, ûntstiet soms it probleem fan inkompatibiliteit tusken de easken fan 'e nije ynfrastruktuer en de applikaasje dy't derop wurdt oerdroegen. Yn 't bysûnder is it wichtich om te krijen by it bouwen fan' e applikaasje один ôfbylding dat sil brûkt wurde yn всех projektomjouwings en klusters. Dit prinsipe leit ûnder de juste kontenerbehear (mear as ien kear oer dit en ús technyske ôfdieling).
Jo sille lykwols gjinien sjen yn situaasjes wêr't de koade fan 'e side in klear makke ramt brûkt, wêrfan it gebrûk beheiningen opleit foar it fierdere gebrûk. En wylst yn in "gewoane omjouwing" dit maklik om te gean, yn Kubernetes kin dit gedrach in probleem wurde, benammen as jo it foar it earst tsjinkomme. Wylst in ynventive geast mei ynfrastruktueroplossingen komme kin dy't op it earste each fanselssprekkend of sels goed lykje ... it is wichtich om te betinken dat de measte situaasjes kinne en moatte arsjitektoanysk oplost wurde.
Litte wy nei populêre oplossingsoplossingen sjen foar it opslaan fan bestannen dy't liede kinne ta onaangename gefolgen by it operearjen fan in kluster, en ek in krekter paad oanwize.
Statyske opslach
Om te yllustrearjen, beskôgje in webapplikaasje dy't in soarte fan statyske generator brûkt om in set ôfbyldings, stilen en oare dingen te krijen. Bygelyks, it Yii PHP-ramt hat in ynboude assetbehearder dy't unike mapnammen genereart. Dêrtroch is de útfier in set paden foar de statyske side dy't fansels net mei-inoar krúst (dit waard dien om ferskate redenen - bygelyks om duplikaten te eliminearjen as meardere komponinten deselde boarne brûke). Dat, út it fak, de earste kear dat jo tagong krije ta in webboarnemodule, wurde statyske bestannen (feitlik faaks symlinks, mar mear oer dat letter) foarme en oanlein mei in mienskiplike root-map unyk foar dizze ynset:
-
webroot/assets/2072c2df/css/… -
webroot/assets/2072c2df/images/… -
webroot/assets/2072c2df/js/…
Wat betsjut dit yn termen fan in kluster?
It ienfâldichste foarbyld
Litte wy in frij gewoan gefal nimme, as PHP wurdt foarôfgien troch nginx om statyske gegevens te fersprieden en ienfâldige oanfragen te ferwurkjen. De maklikste manier - Deployment mei twa konteners:
apiVersion: apps/v1
kind: Deployment
metadata:
name: site
spec:
selector:
matchLabels:
component: backend
template:
metadata:
labels:
component: backend
spec:
volumes:
- name: nginx-config
configMap:
name: nginx-configmap
containers:
- name: php
image: own-image-with-php-backend:v1.0
command: ["/usr/local/sbin/php-fpm","-F"]
workingDir: /var/www
- name: nginx
image: nginx:1.16.0
command: ["/usr/sbin/nginx", "-g", "daemon off;"]
volumeMounts:
- name: nginx-config
mountPath: /etc/nginx/conf.d/default.conf
subPath: nginx.confYn in ferienfâldige foarm komt de nginx-konfiguraasje del op it folgjende:
apiVersion: v1
kind: ConfigMap
metadata:
name: "nginx-configmap"
data:
nginx.conf: |
server {
listen 80;
server_name _;
charset utf-8;
root /var/www;
access_log /dev/stdout;
error_log /dev/stderr;
location / {
index index.php;
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
}
}
As jo earst tagong krije ta de side, ferskine aktiva yn 'e PHP-kontener. Mar yn it gefal fan twa konteners binnen ien pod, nginx wit neat oer dizze statyske triemmen, dy't (neffens de konfiguraasje) moatte wurde jûn oan harren. As gefolch sil de kliïnt in 404-flater sjen foar alle fersiken nei CSS- en JS-bestannen. De ienfâldichste oplossing hjir soe wêze om in mienskiplike map foar konteners te organisearjen. Primitive opsje - algemien emptyDir:
apiVersion: apps/v1
kind: Deployment
metadata:
name: site
spec:
selector:
matchLabels:
component: backend
template:
metadata:
labels:
component: backend
spec:
volumes:
- name: assets
emptyDir: {}
- name: nginx-config
configMap:
name: nginx-configmap
containers:
- name: php
image: own-image-with-php-backend:v1.0
command: ["/usr/local/sbin/php-fpm","-F"]
workingDir: /var/www
volumeMounts:
- name: assets
mountPath: /var/www/assets
- name: nginx
image: nginx:1.16.0
command: ["/usr/sbin/nginx", "-g", "daemon off;"]
volumeMounts:
- name: assets
mountPath: /var/www/assets
- name: nginx-config
mountPath: /etc/nginx/conf.d/default.conf
subPath: nginx.confNo wurde statyske bestannen generearre yn 'e kontener korrekt betsjinne troch nginx. Mar lit my jo herinnerje dat dit in primitive oplossing is, wat betsjut dat it fier fan ideaal is en syn eigen nuânses en tekoarten hat, dy't hjirûnder besprutsen wurde.
Mear avansearre opslach
Stel jo no in situaasje foar wêr't in brûker de side besocht, in side laden mei de stilen beskikber yn 'e kontener, en wylst hy dizze side lies, hawwe wy de kontener opnij ynset. De aktivakatalogus is leech wurden en in fersyk oan PHP is nedich om nije te generearjen. Ek nei dit sille keppelings nei âlde statyk lykwols irrelevant wêze, wat sil liede ta flaters by it werjaan fan statyk.
Derneist hawwe wy nei alle gedachten in min of mear laden projekt, wat betsjut dat ien kopy fan 'e applikaasje net genôch is:
- Litte wy it opskaalje Deployment oant twa replika's.
- Doe't de side foar it earst tagong waard, waarden aktiva makke yn ien replika.
- Op in stuit besleat ingress (foar doelen fan load balancing) in fersyk te stjoeren nei de twadde replika, en dizze aktiva wiene der noch net. Of miskien binne se der net mear omdat wy brûke
RollingUpdateen op it stuit dogge wy ynset.
Yn it algemien, it resultaat is wer flaters.
Om foar te kommen dat jo âlde aktiva ferlieze, kinne jo feroarje emptyDir op hostPath, it tafoegjen fan statyske fysyk oan in klusterknooppunt. Dizze oanpak is min, om't wy eins moatte bine oan in spesifike klusterknooppunt jo applikaasje, om't - yn gefal fan ferhuzing nei oare knopen - de map net de nedige bestannen sil befetsje. Of in soarte fan eftergrûn triemtafel syngronisaasje tusken knopen is fereaske.
Wat binne de oplossingen?
- As hardware en boarnen it tastean, kinne jo gebrûk meitsje om in like tagonklike map te organisearjen foar statyske behoeften. advisearret SSD-skiven, op syn minst trijefâldige replikaasje en in stabile "dikke" ferbining tusken klusterknooppunten.
- In minder easken opsje soe wêze om in NFS-tsjinner te organisearjen. Dan moatte jo lykwols rekken hâlde mei de mooglike ferheging fan reaksjetiid foar it ferwurkjen fan oanfragen troch de webtsjinner, en fouttolerânsje sil folle te winskjen oerlitte. De gefolgen fan mislearring binne katastrofaal: it ferlies fan 'e berch doomt it kluster ta de dea ûnder de druk fan' e LA-lading dy't de loft yn raast.
Under oare alle opsjes foar it meitsjen fan persistente opslach sille fereaskje eftergrûn cleaning ferâldere sets fan triemmen sammele oer in bepaalde perioade fan tiid. Foar konteners mei PHP kinne jo sette DaemonSet út caching nginx, dat sil opslaan kopyen fan aktiva foar in beheinde tiid. Dit gedrach is maklik ynstelbere mei help proxy_cache mei opslach djipte yn dagen of gigabytes skiifromte.
It kombinearjen fan dizze metoade mei de hjirboppe neamde ferdielde bestânsystemen jout in enoarm fjild foar ferbylding, allinich beheind troch it budzjet en technysk potinsjeel fan dyjingen dy't it sille ymplementearje en stypje. Ut ûnderfining kinne wy sizze dat it ienfâldiger it systeem, hoe stabiler it wurket. As sokke lagen wurde tafoege, wurdt it folle dreger om de ynfrastruktuer te behâlden, en tagelyk nimt de tiid dy't bestege oan diagnoaze en herstel fan eventuele mislearrings ta.
Oanbefelling
As de ymplemintaasje fan 'e foarstelde opslachopsjes jo ek ûnrjochtfeardich liket (yngewikkeld, djoer ...), dan is it wurdich te sjen nei de situaasje fan' e oare kant. Nammentlik te graven yn it projekt arsjitektuer en reparearje it probleem yn 'e koade, bûn oan wat statyske gegevensstruktuer yn 'e ôfbylding, in ûndûbelsinnige definysje fan' e ynhâld of proseduere foar "opwaarming" en / of precompiling fan aktiva op 'e ôfbyldingsassemblage. Op dizze manier krije wy absolút foarsisber gedrach en deselde set bestannen foar alle omjouwings en replika's fan 'e rinnende applikaasje.
As wy weromgean nei it spesifike foarbyld mei it Yii-ramt en net ferdjipje yn har struktuer (dat is net it doel fan it artikel), is it genôch om twa populêre oanpak te wizen:
- Feroarje it byldbouproses om aktiva op in foarsisbere lokaasje te pleatsen. Dit wurdt suggerearre / ymplementearre yn útwreidings lykas .
- Define spesifike hashes foar asset directories, lykas besprutsen yn bgl. (begjinnend by dia nr. 35). Trouwens, de skriuwer fan it rapport úteinlik (en net sûnder reden!) advisearret dat nei it gearstallen fan aktiva op 'e build-tsjinner, upload se nei in sintrale opslach (lykas S3), wêrfoar in CDN pleatst.
Downloads
In oar gefal dat perfoarst yn spiel sil komme by it migrearjen fan in applikaasje nei in Kubernetes-kluster is it opslaan fan brûkersbestannen yn it bestânsysteem. Bygelyks, wy hawwe wer in PHP applikaasje dy't akseptearret triemmen fia in upload formulier, docht wat mei harren ûnder operaasje, en stjoert se werom.
Yn Kubernetes moat de lokaasje wêr't dizze bestannen pleatst wurde moatte mienskiplik wêze foar alle replika's fan 'e applikaasje. Ofhinklik fan 'e kompleksiteit fan' e applikaasje en de needsaak om de persistinsje fan dizze bestannen te organisearjen, kinne de boppeneamde opsjes foar dielde apparaat sa'n plak wêze, mar, lykas wy sjogge, hawwe se har neidielen.
Oanbefelling
Ien oplossing is mei help fan S3-kompatible opslach (sels as it in soarte fan sels-hosted kategory is lykas minio). Oerskeakelje nei S3 sil feroarings fereaskje op koade nivo, en hoe ynhâld sil wurde levere oan de foarkant, wy hawwe al .
Meidogger sesjes
Apart is it wurdich op te merken de organisaasje fan opslach fan brûkerssesjes. Faak binne dat ek bestannen op skiif, wat yn 'e kontekst fan Kubernetes sil liede ta konstante autorisaasjeoanfragen fan de brûker as syn fersyk yn in oare kontener telâne komt.
It probleem wurdt foar in part oplost troch ynskeakelje stickySessions op yngong (de funksje wurdt stipe yn alle populêre yngongskontrôles - sjoch foar mear details )om de brûker te binen oan in spesifike pod mei de applikaasje:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: nginx-test
annotations:
nginx.ingress.kubernetes.io/affinity: "cookie"
nginx.ingress.kubernetes.io/session-cookie-name: "route"
nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"
spec:
rules:
- host: stickyingress.example.com
http:
paths:
- backend:
serviceName: http-svc
servicePort: 80
path: /Mar dit sil problemen mei werhelle ynset net eliminearje.
Oanbefelling
In krekter manier soe wêze om de applikaasje oer te bringen nei opslach sesjes yn memcached, Redis en ferlykbere oplossings - yn 't algemien ferlitte triemopsjes folslein.
konklúzje
De oplossings foar ynfrastruktuer dy't yn 'e tekst besprutsen binne, binne allinich gebrûk wurdich yn' e opmaak fan tydlike "krukken" (wat moaier klinkt yn it Ingelsk as oplossing). Se kinne relevant wêze yn 'e earste stadia fan it migrearjen fan in applikaasje nei Kubernetes, mar moatte net root wurde.
It algemiene oanrikkemandearre paad is om se kwyt te reitsjen yn it foardiel fan arsjitektoanyske wiziging fan 'e applikaasje yn oerienstimming mei wat al goed bekend is foar in protte . Dit - it bringen fan de oanfraach yn in steatleaze foarm - betsjut lykwols ûnûntkomber dat feroarings yn 'e koade nedich binne, en hjir is it wichtich om in lykwicht te finen tusken de mooglikheden/easken fan it bedriuw en de perspektiven foar ymplemintaasje en ûnderhâld fan it keazen paad .
PS
Lês ek op ús blog:
- «";
- «";
- «» (fan Red Hat);
- «".
Boarne: www.habr.com