A Kubernetes onmagaban nem csodaszer. Erdemes az egesz rendszert egyutt vizsgalni.
Ha mar Kubernetes, akkor ezek kihagyhatatlan szempontok:
- kontenerizalt app futtatas
- az appok legyenek cloud native szempontokat koveto microservice-ek, jol skalazodjanak, konnyu legyen oket upgrade-elni
- kontener image-ek kozpontilag tarolhatoak, vulnerability scannelhetoek
- logok kozpontilag begyujthetoek, tarolhatoak, kereshetoek (pl.: Fluentd, ElasticSearch, Kibana)
- performance metric-ek begyujtese, vizualizalasa (pl.: Prometheus, Grafana)
- alerting hiba eseten (pl.: AlertManager + vmi kulso on-call rendszer: PagerDuty)
- bejovo REST hivasok lancolatanak (tracing) gyujtese (pl. Jaeger)
- bejovo forgalom Ingress-szen keresztul vezetve lehetoseg van HTTPS terminalasra, rate limitre, extra authra, cache-elesre, URL rewrite-ra (pl. Nginx alapu ingress controller)
- security policy-kat lehet enforce-olni vagy scannelessel felterkepezni a problemas teruleteket
- redundans architektura, infrastruktura (barmelyik public cloud managelt K8s megoldasa tobb AZ-n futtatott node-okkal)
- mindezt ugy, hogy barmely komponens upgrade-je leallas nelkul vegezheto (nyilvan elotte leteszteljuk azert egy teszt kornyezeten)
- backupot a cloud szolgaltato rendszerevel vegezzuk (adatbazisok, block volume-ok es tarsai)
- popec CI: minel tobb tesztet futtassunk deploy elott, hogy hibas szoftver ne menjen elesbe, deploy utan is futtassunk teszteket, hogy ne az ugyfel vegye eszre elobb
- popec CD: automatizalt pipeline, ami elvegez minden szukseges teendot a deploy soran (minimalizalva az emberi hibat, raadasul gyorsabb is)
Mindezek mukodhetnek on-prem infran is, de sokkal egyszerubb public cloudban uzemeltetni. Ha jol vannak implementalva a microservice-ek, akkor szepen skalazodik, cloud-bol tovabbi node-ok kerhetoek igeny eseten.
Ebbol nyilvan kovetkezik az, hogy ez nem az a KKV kategoria, ahol a sarokban fut par szerver, amire Jozsika felmasolja idonkent a sajat fejlesztesu exe filejait, hogy kiszolgalja a ~100 ugyfelet.