Dell PowerEdge R660 Kubernetes үшін: CPU, RAM, NVMe және желі

1U түйіннің Kubernetes-тағы мақсаты

1U сервер көбінесе кластердің тығыз әрі болжамды «бөлігі» ретінде алынады: бір сатырға көп есептеу қуаты, стойка бойынша жылдам масштабтау және ақауда оңай ауыстыру. Dell PowerEdge R660 дәл осылай қарастырылады: бір түйін ондаған микросервисті сенімді көтеріп, пиктерде «түспеуі» керек.

Шындығында 1U түйін сирек қана бір нәрсеге тіреледі. Под тығыздығын бірнеше фактор шектейді: қосымшаларға нақты қолжетімді ядро саны, лимиттер мен кэштер қанша жады алады, жүйелік компоненттер (kubelet, контейнер рантаймы, CNI/CSI, логирование) қанша қалдық алады және диск пен желі көп шағын операцияларды қаншалықты тез өңдейді.

«Под тығыздығы» — жай контейнер саны емес. Бұл requests/limits, нақты тұтыну және әкімшілік шығындардың балансы. «Жеңіл» деп саналатын подтар да page cache пен sidecar-лар кесірінен жадқа, немесе TLS, service mesh, метрикалар мен логированиеден CPU-ға тап болуы мүмкін.

Тар шеңберлер әдетте мынадай белгілер бойынша көрінеді:

• CPU: latency өседі, HPA үнемі масштабтайды, бірақ нәтиже аз; сұрауларды өңдеу уақыты ұзарды.
• Жад: OOMKilled, жиі қайта іске қосулар, түйін MemoryPressure-ке түседі, нақты тығыздық төмендейді.
• Диск: подтар ұзақ старт алады, лог жазу бәсеңдейді, IOPS пиктерінде базалық операциялар «қатады».
• Желі: сервистер арасындағы RTT құбылады, ретрайлар өседі, өткізу қабілеті төмендейді, әсіресе east-west трафикте.

Конфигурацияны таңдағанға дейін минималды енгізу деректерін жинау маңызды, әйтпесе есептеу «көзімен» шығуы мүмкін. Әдетте жеткілікті:

• түйінде жоспарланған подтар саны және олардың қаншасы жүйелік;
• типтік және «ауыр» под үшін CPU және RAM requests/limits;
• жүктеме профилі (тұрақты, пиктер бар, CPU бойынша burst);
• диск талабі (көлем, IOPS, жазу үлесі, локалды кэш керек пе);
• желі профилі (кіріс трафик, east-west, TLS/service mesh, пакеттер сипаттамасы).

Жай мысал: команда «түйінде 60 под» дейді, бірақ олардың жартысы sidecar-пен, плюс активті метрикалар мен логирование бар. Нәтижесінде нақты тығыздық 1U форм-фактордан емес, жүйелік overhead пен пиктерге қалдырған ресурстан және түйін қай жерде «тығылып» жатқанына байланысты шектеледі.

Kubernetes түйінде CPU және жадыны қалай пайдаланатыны

Kubernetes планировщик подтарды requests бойынша орналастырады, ал limits бойынша емес. Requests — бұл «кепілдік»: подқа сонша CPU мен жады резервацияланады. Limits — шекті мән: одан жоғары болмайды. Егер requests төмен, ал limits жоғары болса, кластер подтармен тез толып кетеді, бірақ пик кезінде ресурстар үшін бәсеке басталады.

CPU жағынан жағдай жұмсақ: контейнер request-тен шығып кеткенде, түйінде бос циклдер болса, ол көбірек ала алады. Бос CPU жоқ кезде бөлініс пайызы бойынша жүреді, ал limit қойылғанда троттлинг іске қосылады. Ескеретін жайт — манифесттегі 1 vCPU нақты физикалық ядро емес, процессор уақытының үлесі. Hyper-Threading бар серверлерде және аралас жүктемеде «1 vCPU»-ның шынайы өнімділігі айтарлықтай өзгеше болуы мүмкін.

Жад бойынша Kubernetes қатал: контейнер memory limit-ті асырса, оны жай ғана өшіреді (OOMKill). Сондықтан под тығыздығы жиі CPU-дан бұрын RAM-ға тіреледі. Қосымшалардың жасырын шығыны бар: кэштер, JVM/Go, буферлер, page cache, сонымен қатар sidecar (service mesh, прокси) және агенттер.

Түйіннің тұрақты overhead-ын бөлек есептеңіз. Тіпті сіздің подтарыңыз болмаса да, ресурстардың бір бөлігі kubelet, контейнер рантайм, CNI және DaemonSet-тер (логирование, мониторинг, қауіпсіздік) үшін, сондай-ақ ОС қызметтері мен файлдық кэш үшін алынған болады.

Мысал: 40 подты 250m CPU және 512 MiB деп есептесеңіз, requests бойынша бұл 10 vCPU және 20 GiB. Бірақ егер түйінде тағы 4–6 GiB жүйеге кетсе, ал кей подтардың нақты жадысы 700–800 MiB болса, шектеу дәл RAM болады. Түйін CPU «қызылға» түспей тұрып-ақ OOM-ды көруі мүмкін.

Қолданба командасынан не сұрау керек есептеу алдында

Ядроларды, RAM және NVMe-ді есептемес бұрын қолданба командасынан бірнеше нәрсені нақтылаңыз. Әйтпесе «орташа» түйінді таңдап алып, бірінші пикте шектеулерге ұшырайсыз.

Ең алдымен жүктеме профилін анықтаңыз. Кей сервистер CPU-bound (есептеу, шифрлеу, сығымдау), басқалары memory-bound (кэш, үлкен объектілер, JVM), тағысы дискке тәуелді (логтар, временниe файлдар, кезектер), енді бірі желіге тәуелді (қолданбалар арасындағы жиі шақырулар, gRPC/REST, стриминг). Бір под күндіз CPU-bound болуы мүмкін, ал түнгі батч кезінде network-heavy болады.

Под тығыздығы маңызды, бірақ жалғыз метрика емес. Командадан неліктен сол сан керектігін сұраңыз. Кейде «нодаға 100 под» мақсатынан DaemonSet-тер, IP лимиттері, изоляция талаптары немесе 10 «ауыр» подтың 80 «жеңіл» бірақ тұрақсыз подтан тиімдірек болуы сияқты жағдайлар бұзылады.

SLO-ны бекітіңіз: әйтпесе табысты қалай есептеу керек түсініксіз болады (кідіріс, өткізу қабілеті, жауап уақыты). Қалпына келу талаптары да маңызды: түйін құлаған жағдайда бірнеше минуттық тоқтату рұқсат етіле ме, сервис қанша уақытта оралуы тиіс.

Көбіне қажетті деректер беретін сұрақтар тізімі:

• қазіргі requests/limits қандай, OOMKill немесе throttling болды ма;
• RPS пиктері мен жауап өлшемі қандай, жүктеме 2–3x өссе не болады;
• deployment кезінде не болады: репликалар қаншасы бір уақытта қайта іске қосылады, кэш қанша уақыт қызады;
• локалды күй бар ма (временные файлы, кэш, кезектер) және қанша IOPS қажет;
• желі бойынша ең «ауыр» тәуелділіктер қандай және қандай кідірістер қалыпты саналады.

Мысал: команда «сервис жеңіл» дейді, бірақ роллинг кезінде екі копия параллельді түрде көтеріліп, кэш 3–5 минут қызады және осы уақытта жадыны 2 есе көп тұтынады және белсенді жазба болады. Бұл есептеулерді өзгертеді: жады мен I/O үшін қорыңызды қосуыңыз керек, әйтпесе тығыздық релиз сәттерінде құлдырайды.

Под тығыздығына CPU таңдау: қадамдар

CPU есептеу «1U-ға қанша ядро сыйады» деп басталмауы керек, оның орнына планировщик қанша CPU талап ететіні және қолданбаларға нақты жүктеме үшін қанша қажет екенін анықтаңыз.

1) Түйіннің requests/limits профилін жинаңыз

Әр сервистің CPU requests және limits-ін (немесе кем дегенде requests) жинап, түйінде жоспарланған репликалар санымен көбейтіңіз. Арнайы «себепсіз» скрипттерді (фондық тапсырмалар, кезектер) бөлек белгілеп қойыңыз. Нақты тығыздықты бірінші кезекте requests шектейді: scheduler түйінге requests сомасынан артық под орналастырмайды.

2) Жүйелік запас қосыңыз

Түйінде әрдайым CPU тұтынушылар бар: kubelet, контейнер рантайм, CNI, DNS, логирование, мониторинг, қауіпсіздік агенттері. Оларды есепке алмай, қалғанбарлықты подтарға беру дұрыс емес. Практикалық тәсіл — жүйеге арналған ядроларды алдын ала резервтеп, оларды қолданбалар есептеуінен шығаруға болады.

3) Нысаналық жүктемені таңдаңыз

Микросервистер үшін CPU-ны үнемі шектеп ұстау жаман: latency өседі, сұрау кезектері ұзартады және JVM/Go-де GC уақыттары ұзаруы мүмкін. Әдетте типтік жүктеме максимумға жақын емес болуы тиіс; запас пиктер мен под миграцияларын жабатын болуы маңызды.

4) «Не сыйдырады» пен «қалай жұмыс істейді»-ні салыстырыңыз

Тығыздықты бірден бірнеше нәрсе шектейді: requests сомасы, нақты өнімділік (жиілік, жүктеме түрі, пиктер), limits саясаты (троттлинг), желіден келетін жүктеме (пакет өңдеу үшін CPU) және под құрылымы (көп шағын немесе азырақ ауыр). Егер requests бойынша «көп сыйды» десе де, сервистер кідіріс сезімтал болса, ыңғайлы тығыздық төмен болады.

5) Частота, NUMA және контекст ауысуларын тексеріңіз

1U-да көп ядро жинауға оңай, бірақ ол әрдайым пайдасын бермейді. Latency сезімтал сервистер үшін ядро жиілігі маңыздырақ болуы мүмкін. Көп шағын подтар белсенді тредтермен көп контекст ауысулар туғызады және CPU «артық шығынға» келеді. Егер ауыр көп тредті подтарыңыз болса, NUMA шектеулеріне тиісіп, ядролар арасында жадтың «шеттен» тартыла отырып өнімділік төмендей ме соны тексеріңіз.

RAM таңдау: OOM-нан және тығыздықтың жоғалуынан қалай сақтану

Kubernetes-та OOMKill көбіне «RAM жетіспейді» дегеннен гөрі күрделірек болады. Ең жиі сценарий: подқа тым төмен memory limit қойылған, қосымша пікте (кэш, трафиктің ұлғаюы, прогрев) жадыны көбейтіп, ядро процессті өлтіреді, тіпті түйінде аз ғана бос жад болғанда да. Керісінше де болады: limits үлкен қойылғандықтан планировщик подтарды тығыз толтырып, нақты тұтыну төмен болса да тығыздықты жоғалтады.

Практикалық есептеу requests-тен басталады, «паспортақты» RAM емес. Целевой тығыздықтағы подтардың memory requests-сын қосып, requests көбінесе ескермейтін нәрселерге 20–40% запас қосыңыз: page cache, буферлер, жүйелік процестер, kubelet, контейнер рантайм, CNI, логирование.

Қадамдар бойынша нұсқаулық:

• мақсатты тығыздық үшін memory requests-ты қосып, пиктер мен теңестірілмеген жүктеме үшін 20–40% қосыңыз;
• ОС пен түйін компоненттеріне RAM қалдырыңыз (көбінесе бұл елеулі бөлік, әсіресе көптеген агенттер болғанда);
• контейнерлер белсенді файлдарды оқыса немесе образдарды pull жасаса, page cache үшін орын қалдырыңыз;
• маңызды подтар BestEffort немесе Burstable-де отырмайтынын тексеріңіз: олар жады қысымында бірінші өшіріледі.

Қай кезде үлкенірек RAM-ды таңдау тиімді, ал қашан бірнеше кішірек түйіндер пайдалы? Көбірек RAM микросервистерді тығыздау және аппаратты азайтуға көмектеседі, бірақ үлкен түйін апат болғанда «жоғалту радиусын» ұлғайтады және апгрейдтерді қиындатады. Қатты SLO бар және маңызды сервистер үшін әдетте 2–3 кішірек түйін ұтымды: бір түйіннің тоқтауы кластерді толық күйретпейді.

Рантайм ерекшеліктері де есептеуді өзгертеді. Java көбіне heap-ке тіреледі: Xmx-ты limit-тан айтарлықтай төмен қою керек, әйтпесе heap-тан тыс метадеректер, JIT, direct buffers пайда болып OOM береді. .NET жадты фрагменттеуі мүмкін, сондықтан «тұрақты түрде лимиттен төмен» болу пиковтарды жояды деп кепілдік бермейді. Python бөлінген арена ұстап қалуға бейім, RSS GC кезінде өсіп тұруы мүмкін.

Егер OOM қайталанса, дереу түйінге RAM қоспаңыз. Алдымен тексеріңіз: RSS монотонды өседі ме (утечка сияқты), GC-дан «пилалар» бар ма, өлтірулер трафик пиктерімен ұштаса ма. Мысал: request 512 MiB және limit 600 MiB қойылған сервис күнде бір рет кэш прогрев кезінде құлап кетуі мүмкін, орташа тұтыну 350 MiB болғанымен. Мұндайда түйін жадысын көбейту емес, limit-ті көтеріп, кэшті реттеу дұрысырақ.

Жергілікті NVMe: олар қайда пайда әкеледі, қайда қауіп төндіреді

1U сервердегі жергілікті NVMe әдетте Kubernetes түйінінің «сезілетін» жылдамдығын айқын жақсартады. Бірақ не нәрсені жылдамдатып жатырғаныңызды түсіну маңызды: локальды дискте образдар, writable layer, emptyDir, қолданба кэштері, логтар және кез келген уақытша файлдар болуы мүмкін.

NVMe тиімді, егер подтар көп кішкентай блоктармен оқып-жазып, латенттіліктің төмендігі маңызды болғанда. Типтік мысалдар — локальды кэштер (API жиі бірдей деректерді қайта оқиды), файлдарды жылдам өңдеу үшін scratch, кезектер мен аралық нәтижелер. Сонымен қатар — деплойлар тезірек өтеді: образдарды тез тарту және ашу.

Қауіп — деректер түйінде қалса және түйін құлағанда оңай көшірілмесе. Егер локальды NVMe-де сақталған ақпарат үнемі сақталуы тиіс болса, түйінді қайта жүктеу немесе ауыстыру деректерді жоғалтуға немесе ұзақ тоқтап қалуға әкеледі. Мұндай жағдайларда желілік сақтау немесе сыртқы storage қауіпсіз.

NVMe таңдау кезінде тек терабайттарды қарамаңыз. Тығыздықта жиі IOPS пен латенттілік шектейді, әсіресе жазуларда. Алдын ала болжам жасаңыз: бір уақытта қанша под жазады, жазу өлшемдері қандай, пикте не болады (логтар, бэкаптар, қайта құру, көп реттік рестарт).

Жиі көмектесетін тәжірибелер:

• жүйелік диск пен контейнер рантайм/образдар дискін бөліп алу;
• кэш пен emptyDir үшін бөлек том/раздел жасау, сонда уақытша деректер образдарға орын алмайды;
• ephemeral storage үшін requests/limits орнату, әйтпесе бір шуақты под дискіні толтырып жібереді;
• inode пен тазалау жылдамдығын бақылау: "орын бар, бірақ жазуға болмайды" жағдайы жиі кездеседі.

Егер NVMe тездеткіш ретінде пайдаланылса, ал критикалық деректер сыртта сақталса, түйін жылдам әрі болжамды болады. Барлығын бір томға жинап, важный күйді локальда сақтау көбіне ең қажетсіз сәтте проблемалар туғызады.

Желілік опциялар, жиі тар шеңбер тудыратындары

CPU, RAM пен NVMe дұрыс таңдалғанымен де кластер желіден «тежелуі» мүмкін. Тар шеңбер көбіне «просто баяу сұраулар» түрінде көрінеді, анық қате емес.

MTU, jumbo frames және жасырын фрагментация

Ең жиі болатын қате — жолдағы MTU-лардың әртүрлілігі. Мысалы, түйінде jumbo frames қосылған, ал стойка аралық немесе балансировщик жағында стандартты MTU қалса. Нәтиже — фрагментация немесе drop, қайтажіберулер және кідірістер. Kubernetes-та бұл әсіресе CNI инкапсуляциясы (VXLAN/Geneve) кезінде көрінеді: туннель қосымша байт қосады, сондықтан қауіпсіз MTU кішірейеді.

Практикалық ереже: бүкіл жол бойынша бір MTU таңдаңыз және оны end-to-end тексеріңіз — uplink, ToR, коммутаторлар арасындағы сілтемелер және сыртқы FW/балансировщиктерді қоса алғанда. Jumbo frames үлкен пакеттер көп болған жағдайларда (репликация, бэкаптар, үлкен жауаптар) көмектеседі, бірақ жолда бір ғана секция дайын болмаса, жұмыс бұзылуы мүмкін.

NIC кезектері, RSS және «бір ыстық ағын»

Көбінесе мәселе порттың өткізу қабілетінде емес, трафик өңдеу бір ядроға тығылып қалуында. Егер RSS (flow-тарды кезектерге тарату) дұрыс бапталмаса немесе кезектер аз болса, бір busy-pod не бір сервис кезекті «жаба алады». Нәтижесінде latency кейде төмен жүктемеде өседі.

Bonding/LACP және жаман хэштеу

Линктер агрегациясы әрдайым сызықты өсім бермейді. LACP кезінде бір байланыс бір физикалық портқа «қатталып» қалуы мүмкін хэш себебінен (MAC/IP/порт). Типтік жағдай — бір өте белсенді сервис немесе ingress, және бондингтың жартысы бос жүреді.

CNI, инкапсуляция және service mesh

CNI туннелдері overhead қосады және CPU-ға жүктеме береді, service mesh east-west трафикті көбейтеді, әр сұрауда шифрлау мен прокси қосады. Бұл микросервистерде кідірістерді CPU графиктерінен гөрі айқын күрделендіріп өсіреді.

Жиі көмектесетін рет‑тәртіп:

• MTU-ны бүкіл жолда теңестіріп, CNI туннельінің overhead-ін ескеріңіз;
• RSS, кезектер санын және interrupt affinity-ні қосып тексеріңіз;
• LACP хэш саясатын сіздің трафик түріңізге қарай тексеріңіз (көп қысқа сессия ма немесе аз бірақ ұзақтары ма);
• тестілік стендте mesh бар/жоқ кезінде east-west p95/p99 latency өлшеңіз;
• «жылдамдататын» опцияларды бірден көп қоспаңыз — өзгерістерге дейін және кейін өлшеу жасаңыз.

Мысал: service mesh қосқан соң подтар арасындағы кідіріс өскен болса, ал порттың жүктемесі қалыпты болса, себебі көбіне пакеттерді өңдеу CPU-ға, NIC кезектеріне және қосымша прокси логикасына байланысты болады, тек физикалық линкке емес.

Түйін есептеулерінде және баптауда жиі жіберілетін қателер

Тіпті дұрыс таңдалған 1U сервер под тығыздығын төмендететін типтік қателерге әкеп соғуы мүмкін. Төменде PowerEdge R660-ды микросервистерге әмбебап түйін ретінде қолданғанда жиі кездесетін мәселелер берілген.

CPU: цифрлары бар, пайдасы жоқ

Жиі қате — CPU limits-ті тым жоғары қою: планировщик түйінді «толған» деп санайды, ал шынайы жүктеме төмен, сондықтан тығыздық жоғалады. Керісінше — өте көп шағын подтармен request-тер тым кішкентай болғанда, әкімшілік шығындар өсіп, контекст ауысулар көп болады және CPU бизнес-логикаға кетпей қалады.

Бөлек қауіп — pinning және бөлінген ядроларды NUMA-ны назарға алмай пайдалану. Екі сокетті 1U-да подтар жадыны «шетелден» тартып, кідіріс өсіріп алуы мүмкін.

Жад: OOM әрқашан «жады аз» деген емес

Requests жиі нақты тұтынудан төмен қойылады, пиктер ұмытылып кетеді. Нәтиже — OOMKill және қайта іске қосулар. Басқа жиі қате — жүйелік процесс, kubelet, CNI және page cache үшін headroom қалдырмау. Кэштерді елемеу дисктен оқу көбейтіп, сервистердің жылдамдығын төмендетеді.

Жергілікті NVMe: жылдам, бірақ оңай толады

Локальды диск образдармен, уақытша файлдармен және логтармен тез толады. Барлық тапсырмалар бір NVMe-ге жаза бастағанда кезектер пайда болып, диск толған кезде подтар күтпеген жерден құлап жатады. Типтік сценарий: толық детальды логированы түнде қосылып, орын бір түнде бітеді.

Желі мен операциялар: байқалуы қиын тар шеңбер

Желілік мәселелер көбінесе «сервис баяу» ретінде көрінеді. Себептер: MTU сәйкес емес, LACP дұрыс емес немесе виртуалдық свитч/саясат деңгейіндегі шектеулер (rate limit, security rules), NIC-тің прерывания және кезектер модельдері, бақылаушы метрикалар мен нагрузка тесттерінің жоқтығы.

Егер метрикалар, логтар және трассировка алдын ала жиналмаса, сіз «CPU ба сеть қайсысы кінәлі» туралы дауласасыз, нақты лимитті тауып түзетудің орнына.

Сатып алудан бұрын және енгізгеннен кейін тез чек‑лист

Dell PowerEdge R660-ды Kubernetes үшін таңдасаңыз, мақсатты ұстаңыз: түйін под тығыздығын қажетті деңгейде ұстап, CPU троттлинг, RAM OOM, диск кезектері және желілік жоғалтулар болмауы керек.

Сатып алудан бұрын: жүктеме профилін жинаңыз

Дарынды емес, пиковтарды (p95) және симптомдарды жинаңыз.

• CPU: орташа және p95 түйіндер бойынша жүктеме, throttling бар ма, run queue ұзындығы, контекст ауысулардың өсуі.
• Жад: working set, page cache ролі, OOM жиілігі және memory pressure белгілері.
• Диск: толу деңгейі, p95 IOPS/latency, кезектер, лог жазу кезінде мінез-құлық.
• Желі: drops, retransmits, p95 кідірістер және интерфейстер жүктемесі бағыттар бойынша (pod-pod, pod-service, ingress-egress).
• Kubernetes: eviction жиілігі, контейнер қайта іске қосулары, под басталуы уақыты, образдарды тарту жылдамдығы.

Енгізгеннен кейін: түйіннің тығыздықты ұстайтынына көз жеткізіңіз

Бастапқы 1–2 аптада метрикалармен қатар оқиғаларға назар аударыңыз.

• Подтардың тұрақтылығы: типтік пиктерде қайта іске қосулар мен eviction-дар бар ма.
• CPU: егер p95 100%-ға жақын және throttling өссе, нақты тығыздық шектелген.
• Жад: working set өссе және page cache үнемі тазаланса, жылдамдық пен тығыздық төмендейді.
• Диск: лог жазуда latency көтерілуі tail latency-ге елеулі әсер етеді.
• Желі: retransmits және p95 latency өсуі әдетте конфигурация қатесі (порт жылдамдығы, bond/LACP, offload, MTU) немесе өткізу қабілетінің жетіспеушілігін көрсетеді.

Практикалық әдіс: 2–3 ең «шулы» сервисіңізді таңдап, олардың типтік пикін жүргізіңіз. Егер дәл соларда throttling, OOM, диск кезектері немесе retransmits пайда болса, түйін шын мәнінде есептескеннен бұрын шектеледі.

Типтік микросервис кластері үшін есептеу мысалы

Dell PowerEdge R660 деңгейіндегі түйінді 20–40 микросервисі бар кластерге елестетейік: кейбірі HTTP қызмет етеді, басқалары кезектермен жұмыс істейді, плюс кішкентай кэш және фондық воркерттер. Мақсат — подтарды көбірек орналастырып, latency секірістерін және күтпеген қайта іске қосуларды болдырмау.

Қарапайым есептеу — CPU және RAM

Подтың орташа профилінен бастаңыз. Қолданба командасы бақылаудан алынған requests-терді берсін:

• CPU request: 250m на под
• RAM request: 600Mi на под
• Орташа CPU пик: 800m дейін
• Орташа RAM пик: 1.2Gi дейін
• Репликалар орташа: 2–3 на сервис

Енді түйін сыйымдылығы. Егер түйінде 32 физикалық ядро және 256 ГБ RAM болса, барлығын Kubernetes-ке бермеңіз: ОС, kubelet, логтар мен DaemonSet-пен 1–2 ядро және 8–16 ГБ қалдырыңыз. Қолда шамамен 30 ядро және 230 ГБ қалады.

CPU бойынша: 30 / 0.25 ≈ 120 под (по requests). Жады бойынша: 230 / 0.6 ≈ 380 под. Демек шектеу CPU болады. Реалистік тығыздық пиктер мен троттлингтің алдын алу үшін 80–110 под аралығында болады.

Локальды NVMe деплойларды және рестарттарды айтарлықтай жеделдетеді (образдарды тез тарту/ашу, ephemeral storage жылдамдығы, локальды кэш). Бірақ кэш пен кезектер локальда оңай қалпына келмейтін болса, түйін құлаған кездегі деректер жоғалу қаупі бар.

Типтік желілік проблема және оны қалай байқау

Мұндай кластерде желі көбіне порт өткізу шегінен гөрі параметрлер мен CPU түрінде шектеледі: переполненный conntrack, артық NAT, MTU сәйкес келмеуі, NIC-те аз кезектер немесе желі прерываниясының ядроларды «жеп» қоюы.

Егер түйін желілік тар шеңберге түскенін көрсететін белгілер:

• HTTP p95/p99 latency өседі, ал CPU requests бойынша қалыпты;
• интерфейсте drops/errors және retransmits көбейеді;
• conntrack пайдалануы және timeout саны өседі;
• traffic өсімімен бірге system/softirq CPU өседі.

Көп жағдайда тиімді компромисс — түйіндегі под тығыздығын 10–20% төмендетіп, жүйелік компоненттер мен желіге арналған ресурстарды (CPU/RAM) нақты бекіту. Пиковая өнімділік сәл төмендеуі мүмкін, бірақ latency тұрақтырақ болып, кластерді ұстап тұру оңайырақ болады.

Келесі қадамдар: пилот, тексеру және масштабтау

Сатып алмас бұрын нақты мақсаттар туралы келісіңіз: қай SLO маңызды (кідіріс, қателер, қалпына келу уақыты), түйінге қажетті под тығыздығы және «қалыпты» CPU/RAM/диск/желі пайдалану қандай. Бұл «қанша ядро» деген дауды нақты есепке айналдырады және артық төлеу немесе шектеуге тап болу қаупін азайтады.

Пилотты 1–2 бірдей түйінде орындау дұрыс: олар мақсатты конфигурацияға жақын болуы керек. Синтетикалық бенчмарктан гөрі нақты профильді іске қосыңыз: сіздің Ingress, CNI, образдар және лимиттеріңіз.

Мини‑пилот: 1–2 аптада не тексеру керек

Барлық көрсеткіштерді бір жерде сақтап, жоспарланған және алынған нәтижелерді салыстырыңыз.

• Requests/limits пен нақты тұтынуды салыстырып, тығыздық қай жерде RAM-ға не CPU-ға тірелетінін анықтаңыз.
• Желіні тексеріңіз: east-west өткізу қабілеті, p95 latency, errors/drops және MTU келісімі.
• Локальды NVMe: p95 жазу latency, толғанда мінез-құлық, рестарттарда не болатынын бақылаңыз.
• Автоскейлер мен eviction-ды қараңыз: пик кезінде қанша под нақты қайта жасалады.

Пилоттан кейін стандарттарды бекітіңіз: requests/limits шаблондары, логирование ережелері, image саясаттары (өлшем, pull жиілігі), біртұтас MTU және драйвер параметрлері.

Өсу жоспары: масштабтауды алдын ала болжау

Бұдан әрі тек «көп түйін қосамыз» деп ойлау жеткіліксіз — түйіндердің рөлін алдын ала жоспарлаңыз: compute подтар, бөлек ingress түйіндер, stateful жүктемелер үшін бөлек түйіндер. Резервті N+1 принципін енгізіңіз, жөндеу мен апгрейд кезіндегі әсерді минимизациялау үшін. Кеңейту процедурасын алдын ала сипаттаңыз: қанша түйін бірден қосылады және желі/сақтау жаңа тар шеңбер болмайтыны қалай тексеріледі.

Егер конфигурацияны есептеу, пилот өткізу немесе ЦОД-қа енгізу бойынша көмек керек болса, GSE.kz жүйелік интегратор ретінде серверлер мен инфрақұрылымды таңдап, жеткізіп, кейін 24/7 қолдауды қамтамасыз ете алады.