Tilauslomakkeen "teknisistä tiedoista"

In english here.

Mitä tehdä jos lomakkeen maksimiresurssit eivät riitä

• Tee tilaus ja kokeile - voit yllättyä! Sinun ei tarvitse pyörittää käyttöjärjestelmää, pelkästään kontteja.
• Jos kokeiltuasi huomaat, etteivät resurssit silti riitä, lähetä sähköpostia osoitteeseen grp-openshift-owner@helsinki.fi. Voimme säätää resursseja käsin kohtuuden rajoissa.

Tallennustilasta:

• Tallennustila on VAIN tiedostojen säilömiseen tarkoitettu levytilan kapasiteetti. Konttien Imaget EIVÄT kuluta tätä kapasiteettia.
• Jos projektisi ei tarvitse pysyvää tallennustilaa, eli ei PersistentVolumeClaimia (PVC), projektisi ei tarvitse laittaa raksia 'persistent storage' ruutuun.
• Jos myöhemmin haluat tai tarvitset pysyväistallennustilaa, lähetä sähköpostia grp-openshift-owner@helsinki.fi. Tallennustilaa voidaan lisätä olemassaolevaan projektiin, sinun ei tarvitse lähettää projektilomaketta uudelleen.
• Pysyväistallennus pohjautuu vsphere dynamic provisioniin. Tällä on tiettyjä rajoitteita:
  • Lyhyesti: AINOA tuettu pääsytila on ReadWriteOnce.
  • Pitkästi: Vaikka useammalle podille on mahdollista mountata yksittäinen PVC (mukaanlukien luku ja kirjoitus tarkoituksiin, älä hämäänny pääsytilan nimestä), kaikkien näiden podien tulee ja pitää olla ajossa samalla VM-noodilla. Jos yrität pakottaa podit eri noodeille (esim anti-affinityt), OpenShift ei suostu käynnistämään ensimmäisen podin rinnalle muita podeja. Tämä johtuu siitä, ettei virtuaalisten levyjen hallinnassa ole mitään taikuutta: OpenShift yksinkertaisesti yhdistää virtuaalisen levyn yksittäiseen noodiin vmware-kerroksella, ja mounttaa tuon levyn VM:ssä, ja sitten laittaa podien kontit osoittamaan tuohon levyyn.
    Tämä tarkoittaa että jos rakennat "aina saatavilla" olevaa sovellusta, tulet silti kokemaan klusterinlaajuisia päivityksiä jotka aiheuttavat downtimeä jokaiselle PersistentVolumeClaimille projektissasi.
  • Tiedämme ja ymmärrämme että tilanne ei ole täysin tyydyttävällä tasolla. Pyrimme parantamaan tilannetta ajan/resurssien puitteissa.

Mitä nämä arvot oikeasti tarkoittavat? Kuinka toimin niiden kanssa? Tai, "CPU ja RAM Kuberneteksessa: miten toimin pyyntöjen, rajoitteiden ja kiintiöiden kanssa"Virallinen dokumentaatio konttien resurssein hallintaan: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

Yksinkertaistaaksemme, katsotaan kolmen tyyppistä resurssia, joita pitää kontrolloida:

• CPU-syklit
• RAM-muistin määrä
• Levytilan koko (PersistentVolumes)

Resurssien hallinta Kuberneteksessa koostuu neljästä resurssista:

• Resourcequota (Resurssikiintiö, jota voit pyytää projektillesi Onify-tilauslomakkeessa)
• Limitrange
• Limits
• Requests
• (ja vakioarvot limiteille ja requesteille - määritellään LimitRange oliossa projektillesi. Tämä odottaa tilauslomakkeen seuraavaa versiota.)

Täällä pyrimme selittämään miten nämä asiat toimivat.

• ResourceQuota määrittää namespace/projekti tasolla kuinka paljon CPUta, RAMia ja levytilaa podit/kontit saavat yhteensä käyttöönsä. Mutta resurssikäytön rajaaminen ei lopu siihen!

Request- ja limit-arvot pitäisi lisätä jokaiseen podiin, tai vähintään RAM ja CPU, jotta Kubernetes voi pitää systeemin rullaamassa sujuvasti.

• Request: Tämän verran CPUta/RAMia Kubernetes TAKAA jokaiselle kontille saatavaksi. Jos Kubernetes huomaa ettei klusterilla ole tarpeeksi resursseja tämän pyynnön huomioimiseen, podia ei laiteta ajoon. Toisin sanoen, tämä on ALARAJA konttien resursseille.
• Limit: Tämän verran CPUta/RAMia Kubernetes VOI ANTAA podin konteille. Tämä on hyödyllinen monella tapaa: Podi voi käyttää tätä rajoitusta suojatakseen klusteria itseltään (bugit tai yllättävät resurssivaatimukset serverin ohjelmistolle), ja Kubernetes klusterilla on käyttökelpoista tietoa kuinka paljon resursseja kontin sisällä ajettava ohjelma oikeasti tarvitsee ollakseen hyödyllinen, silti rajaten resurssikäytön piikkien vaikutusta. Toisinsanoan tämä on YLÄRAJA konttien resursseille.
  • Käypä strategia voisi olla käyttää absoluuttisia minimeitä Requestissa CPU:lle/RAM:lle, juuri tarpeeksi että podit pystyvät juuri ja juuri pyörimään, ja käyttää Limit arvoja rajaamaan resurssienkäyttöä yläpäästä.

Viimeiseksi, tarkastellaan LimitRange oliota, jota klusterin ylläpito käyttää suoraviivaistamaan resurssien jakoa:

• LimitRange määritellään projekti/namespace tasolla ja sitä ei voi, eikä pitäisi, pystyä muuttamaan projekti/namespace admin-oikeuksilla oikein hallinnoidussa monen käyttäjän klusterissa. LimitRangella klusterin ylläpito voi pakottaa minimi- ja maksimimääriä pod/kontti -tason Requesteille ja Limiteille, sekä jotain järkeviä vakioarvoja, jotta projekti/namespace adminit/kehittäjät voivat käyttää klusteria helpommin.
  • Jos koet projektillesi LimitRangessa määritetyt vakioarvot haitallisiksi, kannattaa keskustella asiasta klusterin ylläpitäjien kanssa sähköpostitse grp-openshift-owner@helsinki.fi!
  • Jos maksimi- ja minimirajat ovat hyvät, mutta haluat käyttää eri arvoja podeillesi, nopein tapa on asettaa Limit ja Request itse podin määrityksiin (yleensä Deployment/DeploymentConfig olion templatessa). Voit tehdä tämän myös lisätessäsi Deploymenttia web-käyttöliittymästä.

Klusterin ylläpidon tehtävä on varmistaa että ResourceQuota ja LimitRange ovat keskenään järkevät, kuten että vakioarvot Limitille ja Requestille eivät ole kauempana toisistaan kuin on sallittu maxLimitRequestRatio:ssa, koska tämä tarkoittaa että kehittäjien on pakko asettaa vähintään toinen niistä tai Kubernetes ei suostu laittamaan podia ajoon, koska vakioarvot rikkovat maksimi suhdearvoa. Myös, Limittiin korkeamman maksimin asettaminen kuin namespacen ResourceQuota olioon on suhteellisen järjetöntä, vaikkakin tehtävissä, kunhan Request jää ResourceQuotassa määritellyn rajan alle. Jne jne. Jos löydät tälläisen (tai minkään muun) ongelman Limit/Request/Quota vakioarvoissa, ota matalalla kynnyksellä yhteyttä klusterin ylläpitoon. Olemme täällä AUTTAAKSEMME sinua. 

MIKSI RESOURCEQUOTA EI OLE RIITTÄVÄ?

Jos klusteri alkaa kokea CPU- tai muistirajoitteita, Kubernetes tarvitsee tavan priorisoida podeja. Podit, joille ei ole asetettu Requestejä/Limittejä ovat kube-schedulerin (aikatauluttaja) näkökulmasta kohtuuttomia. "Kohtuuttomia" tarkoittaen ettei aikatauluttajalla ole kykyä tehdä järkeviä päätöksiä sen suhteen mitä laittaa ja minne. Tämän vuoksi podit, joille ei ole asetettu limittejä tulevat aina olemaan ensimmäisiä jotka heitetään pois klusterista.

CPUn kohdalla kube-scheduler saattaa rajoittaa podeja ja prosessit vain hidastuvat. RAMin suhteen tämä ei ole mahdollista ja podeja joudutaan poistamaan.

Koko tarina ja yksityiskohdat siitä, kuinka Kubernetes hoitaa ulosheitot resurssirajoitteiden aikana joutuu odottamaan myöhempää hetkeä. 

OBJECT-COUNT -resurssit

Namespacelle on myös rajoitteet configmapsien, secretsien, podien ja muiden Kubernetes olioiden määrille. Kuberneteksen päässä ei ole kovaa ylärajaa configmapin tai secretin koolle, mutta etcd backendin datastore voi säilöä vain 1MB olioita, ja muut osat apiserverin putkistosta saattavat omata omat rajansa. Yleinen konsensus vaikuttaa olevan, että noin 1MB on nykyinen yläraja yksittäiselle configmap/secret/muulle oliolle. Jos tämä raja tulee vastaan, voit lisätä lisää configmapeja tms. sovelluksellesi, ei ole pakko tyytyä yhteen. Lisää tietoa täällä:  https://stackoverflow.com/a/53015758/1889463

Mitä numerot "0.5", "1.0", "1.5" or "2.0" jne. CPU :lle oikeasti tarkoittavat?

Tämä numero menee suoraan ResourceQuota olion määritykseen kohtaan hard.request.cpu uudelle projektillesi. Se rajoittaa KAIKKIEN projektisi konttien CPU-käyttöä yksittäisellä ajanhetkellä.
Halusitpa ajaa 10 konttia käyttäen 1/10 kiintiöstäsi jokaiselle, tai yhden kontin käyttäen kaiken kiintiösi siihen, valinta on täysin sinun.

Mitä numero teknisesti lopulta tarkoittaa on... hankalampi aihe jota ei voi tarkasti taata tai selittää. Sen pitäisi vastata noin 1:1 vCPU ytimiin VM nodeissa joissa OpenShift pyörii, mutta siinä on pari muttaa:

• Fyysiset laitteet joilla noodeja ajavat vmware-hostit pyörivät eivät ole keskenään aivan identtisiä CPU-tehojen suhteen. Yhden vCPU:n teho ei ole siis kiveen hakattu.
• Kuinka hyvin VM:t aikataulutetaan vmwaren platform hosteihin on täysin erillinen kysymys (joka on täysin OpenShift-konttialusta ylläpidon ulottumattomissa), joka tuo uuden haasteen kun ajatellaan paljonko CPU:ta konttisi saavat.
• CPU on rajoitettavissa oleva tekijä, joka tarkoittaa että CPU-resurssin ollessa rajoitettu, Kubernetes alkaa nappaamaan cpu-syklejä podeilta, jos se vain pystyy. Ääritapauksissa se saattaa myös heittää ulos (sammuttaa) podeja.