Kubernetes 1.37లో 67 enhancements వచ్చాయి.
అప్గ్రేడ్ ప్లాన్ చేసుకునే ముందు ప్లాట్ఫారమ్ టీమ్లు ఆ 67 అన్నీ అర్థం చేసుకోవాల్సిన అవసరం లేదు.
క్లస్టర్లను ఎలా సురక్షితంగా ఉంచవచ్చు, ఖాళీగా ఉన్న వర్క్లోడ్లను ఎలా స్కేల్ చేయవచ్చు, చాలా కాలంగా వాడుకలో ఉన్న ఒక మెట్రిక్స్ API ఎలా సపోర్ట్ అవుతుందో అనే విషయాల్లో మూడు మార్పులు ప్రత్యేకంగా గమనించదగ్గవి.
అవి:
- rootless kubelet Beta స్థాయికి చేరడం;
- HPA scale-to-zero Beta స్థాయికి చేరడం;
- Kubernetes Metrics API స్టేబుల్ కావడం.
వీటిలో ఏదీ మీరు వెంటనే అప్గ్రేడ్ చేయాలని సూచించడం లేదు.
కానీ మీ తదుపరి Kubernetes అప్గ్రేడ్ సైకిల్కు ముందు ఇవి అర్థం చేసుకోవడం విలువైనవి.
Rootless kubelet ఆచరణాత్మక వాడకానికి మరింత దగ్గరగా వస్తోంది
Kubernetes నోడ్ కాంపొనెంట్లు సాంప్రదాయకంగా హోస్ట్పై root ప్రివిలేజెస్తో నడుస్తూ వచ్చాయి.
Kubernetes 1.37, తరచుగా rootless Kubernetes అని పిలవబడే KubeletInUserNamespaceని Beta స్థాయికి తీసుకువెళుతుంది.
ఆలోచన చాలా సూటిగా ఉంటుంది.
kubeletనూ, సంబంధిత నోడ్ కాంపొనెంట్లనూ హోస్ట్పై పూర్తి root యాక్సెస్తో నడపడానికి బదులు, వాటిని non-root హోస్ట్ యూజర్గా ఒక Linux user namespace లోపల నడపవచ్చు.
కంటైనర్-రన్టైమ్ లేదా నోడ్-కాంపొనెంట్ వల్నరబిలిటీని ఎవరైనా ఎక్స్ప్లాయిట్ చేస్తే, హోస్ట్-లెవల్ ప్రివిలేజెస్ను తగ్గించడం వల్ల అటాకర్ చేయగలిగే నష్టాన్ని తగ్గించవచ్చు.
ఇది ఉపయోగకరమైన సెక్యూరిటీ మెరుగుదల.
కానీ ఇక్కడ ఒక ముఖ్యమైన వివరం ఉంది.
Kubernetes 1.37లో ఈ feature gate డిఫాల్ట్గా enable అయి ఉన్నప్పటికీ, ఇప్పటికే ఉన్న క్లస్టర్లు అకస్మాత్తుగా rootless కావు. user namespace లోపల నడవడానికి నోడ్ను ఉద్దేశపూర్వకంగా కాన్ఫిగర్ చేయాల్సిందే.
ప్లాట్ఫారమ్ టీమ్లకు, ఇది అప్గ్రేడ్ సమయంలో ఆటోమేటిక్గా మారిపోయేది కాదు — టెస్ట్ చేయాల్సిన విషయం.
Compatibility కూడా ముఖ్యమే.
కొన్ని CNI లేదా CSI డ్రైవర్లు ఇప్పటికీ సాధారణ rootful నోడ్పై అందుబాటులో ఉండే ప్రివిలేజెస్ను ఆశించవచ్చు. rootless environments లో కొన్ని డ్రైవర్లకు compatibility సమస్యలు రావచ్చని Kubernetes స్వయంగా పేర్కొంటుంది.
కాబట్టి ఉపయోగకరమైన ప్రశ్న ఇది కాదు:
Kubernetes ఇప్పుడు root లేకుండా నడవగలదా?
నడవగలదు.
ఆచరణాత్మక ప్రశ్న ఇది:
మన Kubernetes స్టాక్ ఆ విధంగా సరిగ్గా నడవగలదా?
ఇందులో కంటైనర్ రన్టైమ్, నెట్వర్కింగ్, స్టోరేజ్ డ్రైవర్లు, నోడ్ మానిటరింగ్, హోస్ట్-లెవల్ యాక్సెస్ అవసరమయ్యే ఏ సాఫ్ట్వేర్ అయినా వస్తాయి.
Rootless మోడ్ టెస్ట్ చేయదగిన ఒక సెక్యూరిటీ మెరుగుదల.
ఒక స్టేజింగ్ సైకిల్ లేకుండా ప్రొడక్షన్ నోడ్ల మొత్తం మీద నేను దీన్ని enable చేయను.
ఖరీదైన వర్కర్లకు Scale-to-zero ప్రత్యేకంగా ఆసక్తికరం
Horizontal Pod Autoscaler సాధారణంగా కనీసం ఒక replicaను అయినా నడుస్తూ ఉంచుతుంది.
Kubernetes 1.37 దాన్ని మారుస్తుంది.
HPA scale-to-zero ఇప్పుడు Beta స్థాయిలో ఉంది, డిఫాల్ట్గా enable అయి ఉంది. ఒక వర్క్లోడ్ పూర్తిగా zero replicas వరకు scale down అయి, పని వచ్చినప్పుడు మళ్ళీ మొదలవ్వగలదు.
సాధారణ తేలికపాటి వర్క్లోడ్లకు ఇది ఉపయోగకరంగా ఉండవచ్చు.
GPU-బ్యాక్డ్ AI లేదా బ్యాచ్ వర్క్లోడ్లకైతే ఇది చాలా ఆసక్తికరంగా ఉంటుంది.
ఒక వర్కర్ కేవలం queue నుండి jobs ప్రాసెస్ చేయడానికే ఉంటే, queue ఖాళీగా ఉన్నప్పుడు కూడా GPU-బ్యాక్డ్ podను నడుస్తూ ఉంచడం ఖరీదైన సామర్థ్యాన్ని వృథా చేస్తుంది.
scale-to-zero తో, ఆ చివరి idle replicaను Kubernetes తొలగించగలదు.
ఇందులో ఒక క్యాచ్ ఉంది.
వర్క్లోడ్ను మళ్ళీ మేల్కొలపడానికి HPA సాధారణ CPU లేదా మెమరీ utilisationను ఉపయోగించలేదు.
ఎలాంటి pods లేనప్పుడు, కొలవడానికి CPU లేదా మెమరీ వాడకం అనేది ఉండదు.
అందుకే pods లేని సమయంలో కూడా ఉనికిలో ఉండే దేని నుండైనా scaling సిగ్నల్ రావాల్సి ఉంటుంది, అంటే:
- queue depth;
- pending jobs;
- మరో object metric;
- ఒక external metric.
cold-start సమయం కూడా ఉంటుంది.
పని వచ్చినప్పుడు, Kubernetes ఆ metricను గమనించి, ఒక podను షెడ్యూల్ చేసి, ప్రాసెసింగ్ మొదలయ్యేలోపు అప్లికేషన్ను స్టార్ట్ చేయాలి.
బ్యాక్గ్రౌండ్ వర్కర్లకైతే ఇది సరిపోవచ్చు.
వెంటనే స్పందించాలని ఎదురుచూసే యూజర్-ఫేసింగ్ HTTP సర్వీస్కు ఇది అంత సరిగ్గా సరిపోదు. scale-down అయిన అప్లికేషన్ మళ్ళీ స్టార్ట్ అయ్యేవరకు Kubernetes Services requestsను ఆపి ఉంచవు, కాబట్టి request-driven వర్క్లోడ్లకు మరో buffering మెకానిజం అవసరం.
AI ప్లాట్ఫారమ్లకు, ఇది ఒక ఉపయోగకరమైన ట్రేడ్-ఆఫ్ను సృష్టిస్తుంది:
తక్కువ idle ఖర్చు వర్సెస్ మొదటి రెస్పాన్స్ నెమ్మదిగా రావడం.
టీమ్లు కొలవాల్సింది అదే భాగం.
కేవలం డబ్బు ఆదా అవుతుందని scale-to-zeroను enable చేయకండి.
వర్క్లోడ్ మళ్ళీ ఉపయోగపడేలా మారడానికి ఎంత సమయం పడుతుందో టెస్ట్ చేయండి.
Metrics API స్టేబుల్ కావడం అంత నాటకీయం కాదు, కానీ ఇంకా ముఖ్యమైనదే
Kubernetes 1.37 metrics.k8s.ioను స్టేబుల్ v1కి కూడా ప్రమోట్ చేస్తుంది.
kubectl top వంటి టూల్స్ వెనుక, resource-based autoscaling వెనుక ఉపయోగించే CPU, మెమరీ మెట్రిక్స్ కోసం ఇది వాడే API.
చాలా టీమ్లకు నాటకీయంగా ఏమీ మారదు.
resource types, fields మునుపటి v1beta1 APIలో ఉన్నట్టుగానే ఉంటాయి.
అదే నిజానికి ముఖ్య విషయం.
ఇది కొత్త observability ఫీచర్ కాదు.
చాలా కాలంగా వాడుకలో ఉన్న ఒక APIకి, GA API కి ఉండే స్టెబిలిటీ గ్యారంటీలను Kubernetes అధికారికంగా ఇస్తోంది.
Kubernetes resource metrics చుట్టూ integrations, automation, లేదా internal tooling నిర్వహించే ప్లాట్ఫారమ్ టీమ్లకు, ఇది సంవత్సరాలుగా Beta లోనే ఉన్న ఒక dependency గురించి అనిశ్చితిని తగ్గిస్తుంది.
ఉపయోగకరమే, కానీ మీ మానిటరింగ్ స్టాక్ను redesign చేయాల్సిన అవసరం కలిగించేది కాదు.
అప్గ్రేడ్ చేసే ముందు టీమ్లు ఏం టెస్ట్ చేయాలి?
Kubernetes 1.37 రిలీజ్లో ఇంకా చాలా మార్పులు ఉన్నాయి, కానీ ఈ మూడూ చాలా చిన్న అప్గ్రేడ్ చెక్లిస్ట్కు దారితీస్తాయి.
Rootless నోడ్లను ప్రయత్నించాలనుకుంటే, ప్రొడక్షన్లో వాడే ముందు మీ CNI, CSI, runtime, monitoring, హోస్ట్-లెవల్ టూలింగ్ను టెస్ట్ చేయండి.
scale-to-zero వాడాలనుకుంటే, మీ వర్క్లోడ్కు నమ్మదగిన external లేదా object metric ఉందో లేదో నిర్ధారించుకుని, పూర్తి cold-start సమయాన్ని కొలవండి.
మీ internal tools నేరుగా Metrics APIని వాడుకుంటే, API structure పెద్దగా మారకపోయినా, అవి metrics.k8s.io/v1కు రెడీగా ఉన్నాయో లేదో చెక్ చేయండి.
మిగతా ప్రతి Kubernetes అప్గ్రేడ్లాగే, ఒక ఫీచర్ Beta లేదా GAకు వెళ్లిందని దాని చుట్టూ ఉన్న ప్రతి కాంపొనెంట్ కూడా రెడీగా ఉందని అనుకోకుండా, మీరు అసలు నడుపుతున్న ప్లాట్ఫారమ్నే టెస్ట్ చేయండి.
Kubernetes 1.37లో ఉపయోగకరమైన భాగం
Kubernetes రిలీజ్లు తేలికగా feature gates, enhancement numbersతో నిండిన సుదీర్ఘ లిస్టులుగా మారిపోతాయి.
చాలా ప్లాట్ఫారమ్ టీమ్లకు, వాటిని చదవడానికి అది ఉపయోగకరమైన విధానం కాదు.
Kubernetes 1.37లో కొన్ని ముఖ్యమైన మార్పులు ఉన్నాయి, కానీ ఆచరణాత్మక కారణాల వల్ల మూడు ప్రత్యేకంగా నిలుస్తాయి.
నోడ్-లెవల్ ప్రివిలేజ్ని తగ్గించడానికి Rootless kubelet టీమ్లకు మరో మార్గాన్ని ఇస్తుంది.
నడుస్తూ ఉండాల్సిన అవసరం లేని వర్క్లోడ్ల ఖర్చును, ముఖ్యంగా GPU-బ్యాక్డ్ jobs వంటి ఖరీదైన వర్కర్ల ఖర్చును, scale-to-zero తగ్గించగలదు.
Metrics API చివరికి సుదీర్ఘమైన Beta దశ నుండి స్టేబుల్ APIకి మారుతోంది.
వీటిలో ఏదీ వెంటనే ప్రొడక్షన్లో మార్పు అవసరం అని కోరదు.
కానీ మూడూ మీ తదుపరి స్టేజింగ్, అప్గ్రేడ్ చర్చలో చేర్చుకోదగినవి.