Kubernetes on‑prem үшін серверлер: жад, NVMe, желі, ядролар

Қайсы тар тотықтар ең жиі шығады іске қосқаннан кейін

Мәселелер әдетте іске қосқан күнде емес, 1–3 айдан кейін шығады. Команда жаңа сервистер қосады, логтау мен метрикаларды ұлғайтады, қолданушылар саны өседі, фондық тапсырмалар өз өміріне көшеді. Осы сәтте түсінеді: «пилотта жұмыс істеді» — «продакшнда тұрақты болады» дегенді білдірмейді.

Пилот әдетте қысқа әрі жинақы: деректер мен интеграциялар аз, деплойлар сирек, шыңдық кезеңдер жоқ (есептер, айды жабу, жаппай хабарламалар). Продакшнда микросервистер күтпеген жарылыстар тудырады. Бір сервис баяулайды, кезек өседі, ретрайлар жүктемені көбейтеді, сосын оқиға бүкіл кластерге таралады.

Көбінесе кезектер мен кешігулер төрт зонаға тіреледі:

• CPU: лимиттер «көзбен» қойылған, планировщик ядролар жетіспеуіне тап болады, көрші подтар шыңда бір-біріне кедергі жасайды.
• Память: OOM-kill, жиі қайта іске қосулар, подтардың эвакуациясы және кэштердің жоғалуы. Проблема көбінесе орташа тұтынуда емес, қысқа шоқтарда болады.
• Диски: контейнер қабаттары, логтар, базалар мен кезектердің операцияларын тежейді. IOPS орыннан бұрын таусылады, орын емес.
• Сеть: қызметтер арасындағы east-west трафикте тар тотықтар, storage пен бэкаптарға жеткіліксіз өткізу қабілеті, коммутаторлардың жүктелуінен кешігудің өсуі.

Жай мысал: трассировка қосып, метрикалардың retention-ын ұлғайттыңыз. Дискке жазу күрт өсті, параллельно шың уақытында сервистер арасындағы трафик күшейді. Нәтижесінде бір емес бірнеше компонент «түседі». Сондықтан Kubernetes on-prem үшін серверлерді ең сезімтал ресурстар бойынша қоржынды етіп және кластердегі жүктеме сирек біркелкі болмайтынын ескере отырып таңдау керек.

Құрал-жабдықты таңдаудан бұрын жүктемені сипаттаңыз

Кластерге арналған залдарды көбіне «көзбен» таңдайды, кейін таңқалады: бір жерде жады жетіспейді, бір жердегі дискілер «тапша», бір жердегі желі қызметтік трафикпен бітеледі. Kubernetes on-prem үшін серверлер айдан кейін ғана мәселе болмауы үшін, қарапайым тілмен, оны күтіп-қадағалайтын адамға түсінікті етіп жүктемені сипаттаудан бастаңыз.

Алдымен не іске қосатыныңызды және қай жерде екеніңізді тізіңіз. Микросервистер саны өз алдына көп нәрсе айтпайды: маңыздырақ — орталар саны (prod, stage, dev) және олардың ұқсастығы. Жиі жағдай: staging «дерлік prod» бірақ сол түйіндерде тұрып, жүктеме тестінде жұмыс подтарын ығыстыра бастайды.

Келесі stateful бөлшектерді белгілеңіз. Мәліметтер базалары, кезектер, лог-хранилище, мониторинг және трассировка әдетте тұрақты I/O тудырады және кешігуге сезімтал. Егер олар кластер ішінде болса, диск пен желі талаптары күрт өседі. Егер сыртта болса, тәуекелді желі мен сыртқы хранилищеге ауыстырасыз.

Бұлны қысқа «дерлік ТЗ» ретінде бекіту пайдалы:

• қазіргі кезде және бір жыл ішінде қанша сервис пен ортаны қолдайсыз;
• не stateful, не stateless;
• қай жүктеме профилі басым (CPU, жады, диск);
• қай SLO маңыздырақ (сұраныс кешігуі, деплой уақыты, қалпына келтіру жылдамдығы);
• 12–24 айда күтілетін өсу (қолданушылар, трафик, деректер).

Мысал: prod-та 40 сервис және stage-та 40, кластер ішінде Prometheus және Loki, база сыртта. Онда тар тотықтар көбінесе жадыда (метрикалар мен кэштер), логтар үшін I/O және түйіндер арасындағы желіде болады.

Жад узелге: OOM және подтарды эвакуациятан қалай сақтану

Kubernetes-та жад әдетте CPU-дан ерте таусылады. Процессорды лимиттермен «қысуға» болады, жоспарлағыш жүктемені бөледі. Ал жад нақты асып кеткенде OOMKilled немесе pod eviction болады. Одан кейін олар басқа түйіндерге көшіп, мәселе лавинасын тудырады.

Жиі тұзақ: RAM-ды requests қосындысы бойынша есептеу, ал шынайы тұтыну limits-қа жақын болады (немесе limits жоқ болса шексіздей өсуі мүмкін). Қосымша кластер өзіне де жад алады. Node Allocatable әрқашан сервердегі жалпы RAM-нан аз болады. Сондықтан бірдей 256 ГБ сервер нақты 200–220 ГБ «пайдалы» болуы мүмкін, баптаулар мен жүктемеге байланысты.

Жадты үш қабат ретінде ойлаңыз: қосымшалар, жүйелік компоненттер (kubelet, контейнер runtime, CNI) және айнала сервистер (логирование, мониторинг, қауіпсіздік агенттері). Жеке-жеке олар «шағын» болуы мүмкін, бірақ қосындысы сезілетін. Және кластер өскен сайын өседі.

Екі сокетті серверлерде NUMA нюанс бар: жады физикалық түрде сокетке байланған. Егер pod көп RAM пен CPU талап етсе, бірақ NUMA саясаты ескерілмесе, кешігулер мен тұрақсыз өнімділік пайда болуы мүмкін, тіпті «сан бойынша» жад жеткілікті көрінсе де.

Сатып алудан бұрын практикалық ережелер:

• жүйеге және шыңдарға 15–30% RAM қорын сақтаңыз;
• барлық маңызды сервистерге requests және ақылға қонымды limits қойыңыз;
• кэштерді, кезектерді және JVM/Go heap-ті жеке есептеңіз (олар күтпеген өседі);
• үлкен stateful компоненттер үшін үлкен RAM бар түйіндер жоспарлаңыз, ал көптеген шағын сервис үшін көбіне көп, бірақ кішірек түйіндер тиімдірек.

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

CPU және ядролар қоры: планировщик тұрақтылықты жақсы көреді

Kubernetes-та CPU — бұл тек «қанша ядро» емес. Маңызды — олар подтар үшін қаншалықты болжамды қолжетімді. Kubernetes on-prem үшін сервер таңдарда қорды «қазірге» емес, шыңдарға, фондық тапсырмаларға және өсуге есептеп қалдырыңыз.

Ең жиі қатесі — агрессивті oversubscription, яғни CPU лимиттері нақты ресурстардан әлдеқайда жоғары. Графиктерде орташа жүктеме әдемі көрінуі мүмкін, бірақ шыңда процессор уақыты үшін бәсекелестік басталады. Нәтижесінде кешігулер өседі, API latency секірістері, таймауттар және ретрайлар тізбегі — бұл кластерді әбігерге түсіреді.

Қашан жиілігі маңызды, қашан ядролар саны? Қысқа сұраулар мен қатаң SLO бар сервистер (gateway, авторизация, онлайн-төлемдер) үшін жоғары жиілік пен әр ядроның тұрақты өнімділігі артығын береді. Параллель тапсырмалар (кезектер, фон воркерлер, batch, CI) үшін көбірек ядро және анық лимиттер маңызды.

Жақсы тәжірибе — кластер инфрақұрылымына жеке түйіндер бөлу. Сол кезде CPU-ны сіздің бизнес-метрикалардан көрінбейтін нәрселер «жеп» қоймайды: DNS, ingress-контроллер, логирование, мониторинг, service mesh, storage контроллерлері.

Алдын ала тексеруге тұратындар: CPU қор қанша керек, oversubscription қандай деңгейде кешігусіз өтеді, SMT/Hyper-Threading сіздің жүктемеге қалай әсер етеді, және инфрақұрылымдық түйіндер пулына қажетті минималды мөлшер қажет пе.

Қарапайым бағдар: іске қосқаннан кейін сервистер «жап-жақсы көрінеді», бірақ шың уақытына кешігулердің құйрықтары өссе, көбіне бұл баг емес — болжамды CPU жетіспеушілік және тым батыл қойылған лимиттер.

NVMe және дискілер: қай жерде шын мәнінде жоғары жылдамдық қажет

Микросервистер үшін тек IOPS цифрлары ғана емес, кешігу де маңызды. IOPS секундқа қанша операцияны көтеретінін көрсетеді, ал кешігу — әр операция қаншалықты тез аяқталатынын. Kubernetes-та көбіне критикалықі — төмен кешігу: көптеген ұсақ сұраныстар (метадеректер, журналдар, кішкентай жазбалар) «тығылыстарға» сезімтал, орташа IOPS жақсы көрінсе де.

NVMe сол жерде мағынасы бар, қайда тар тотық — кездейсоқ қатынас пен жазбаны жылдам растау. Көбінесе бұл etcd (егер control plane сыртқа шығарылмаған және сіз сенімді төзімділік схемасына сенімді болсаңыз), базалардың ыстық бөліктері, кезектер, іздеу индекстері, логтар мен метрикалардың буферлері, сондай-ақ CI кэштері (артефактілер, контейнер қабаттары, тәуелділіктер).

Локалды NVMe мен сыртқы хранилище арасындағы компромисс қарапайым. Локалды NVMe кешігуде тез әрі «дәл әсері бойынша» арзан сезіледі, бірақ түйін деңгейінде деректерді сақтап қалу қиынырақ: диск істен шықса — сол түйіндегі деректер жоғалады. Сыртқы хранилище қорғауды және масштабтауды оңай етеді, бірақ ол желіні және кешігуді қосады және жаңа тар тотыққа айналуы мүмкін.

RAID та «тегін» емес. Контроллер мен оның кэші жылдамдықты шектеуі мүмкін, әсіресе NVMe-да, онда диск өзі контроллерден тезірек болады. Сондықтан локалды NVMe үшін схемаларды саналы таңдап, нақты жүктеме бойынша тексеріңіз.

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

Желі: өткізу қабілеті, кешігу және резервтеу

Kubernetes-та желі көбіне «қарапайым желі» болмайды. Іске қосқаннан кейін east-west трафик тез өседі: сервистер бір-бірімен сөйлеседі, sidecar-прокси service mesh-та қосымша трафик қосады, және бақылау (логтар, метрикалар, трассировка) үнемі деректер жібереді. Сыртқы жүктеме сабырлы көрінуі мүмкін, ал ішкі желі шектен шығады.

10/25/100GbE таңдау «қазір қанша» емес, бір жыл ішіндегі өмір салтына қарай болуы керек. 10GbE шағын кластерлерге, ауыр service mesh-і жоқ және орташа репликациясы бар жағдайларда жиі жетеді. 25GbE микросервис платформаларына жақсы теңдік береді. 100GbE көп түйіндер, интенсивті CI/CD, үлкен деректер, таралған хранилищалар немесе желі басты шектеу болғанда мәні бар.

Порттарды есіңізде сақтаңыз. Жиі қате: «жылдам» желі картасын бір портпен алу және трафикті бөлмеу. Түйінге практикалық минимум — отказоустойчивость үшін екі порт, қосымша бөлу үшін (storage/репликация мен басқару үшін) бөлек сегменттер (VLAN арқылы немесе физикалық).

MTU және jumbo frames тек желінің барлық жолында бірдей бапталған кезде көмектеседі. Егер бір сегмент таңдалған MTU-ны қолдамаса, ұстап тұру қиын «плавающие» мәселелер аласыз. MTU-ны санаулы түрде өзгертіңіз және end-to-end тексеріңіз.

Отказоустойчивость үшін түйіндерде әдетте bonding + LACP қолданылады, ал коммутатор деңгейінде — екі құрылғыға тарату. Бұл on-prem-да маңызды, себебі бір желі элементі оңай тар тотыққа айналуы мүмкін.

Кластер сенімділігі: басқару жазықтығы және сыйымдылық қоры

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

Продакшнге практикалық минимум — үш control-plane нода және бөлек worker-нектер. Үш control-plane кворум береді және бір түйіннің істен шығуын басқару тоқтамастан өтеді. Егер control-plane пен рабочие жүктемелер бір серверде араласса, қосымша жүктеме басқаруды бұза алады.

etcd-ны қайда сақтау және неге кешігу маңызды

etcd диск көлеміне емес, I/O кешігуіне және тұрақтылығына сезімтал. Тіпті орташа жүктемеде баяу немесе «плавающие» дискілер жазбаларда кешігулер береді, бұл басқару жазықтығына әсер етеді. Көп жағдайда ең жақсы нұсқа — control-plane түйіндерінде локалды тез дискілер, кешігудің төмен болуы. Мақсат — қағаздағы жылдамдықты қуалап емес, болжамдылықты қамтамасыз ету.

Сыйымдылық қоры: істен шыққаннан кейін не қалады

Кластерді бір түйін жоғалғандай етіп жоспарлаңыз. Критикалық платформалар үшін «минус 1–2 түйін» сценарийін жиі қалдырады (перезагрузка, жаңарту, ақау).

Тексеру керек бірнеше нәрсе: бір worker жоғалтылса, CPU мен жад жеткілікті ме; подтарды көшіріп алу үшін орын бар ма; хранилище мен желі миграция кезіндегі трафик шоқтарын көтере ала ма; түйіндерді кезектеп жаңарту downtime-сыз өтуі мүмкін бе.

Және «залдық» тәуекелдер бар, оларды оңай өткізіп жіберуге болады. Нашар салқындату CPU троттлингіне әкеледі: формальды түрде ядролар бар, бірақ олар күткен өнімділікті бермейді. Қуат та маңызды: сервердер мен коммутаторларда қуат блоктарының резерві және бөлек желілер ықтимал кенеттен тоқтаудың ықтималдығын азайтады.

Мысал: банк үшін микросервис платформасында сіз worker-нодың бірін түнде біртіндеп жаңартасыз. Егер қор «қат-қаңға» есептелген болса, екінші түйіннен бастап кезектер мен кешігулер өсіп, SLO түсіп қалады. Қор болғанда кластер жаңартуды да, нақты ақауды да тыныш өткізеді.

Жаңарту және өсу жоспары: жабдық мерзімінен бұрын ескірмес үшін

On-prem Kubernetes сирек «қойып қойған күйде» өмір сүреді. 6–12 айда кластердің жаңа нұсқалары шығады, қауіпсіздік талаптары өзгереді, сервис саны өседі. Және кенеттен CPU-дан емес, желі, порттар немесе адресация жетіспейтіндігі анықталады.

Kubernetes-тің кестесін және тәуелділіктердің үйлесімділігін бекітіңіз. Жаңартады тек Kubernetes емес: container runtime, CNI (желілік), CSI (хранилище), драйверлер, прошивкалар және ОС. Бір компонент артта қалса, кластерді жаңарту тәуекелге айналады.

Жалпы жұмыс істейтін тәжірибе: cordon/drain арқылы түйіндерді rolling update жасау және қысқа өзгерістер терезелері. Түйін жоспарлаудан шығарылып, подтар көшіріліп, ОС пен компоненттер жаңартылады, кейін пулға қайтарылады. Осылайша проблемалар бір түйінде ғана көрінеді, түгел кластерге емес.

Жаңа релиз ресурстарға қайшы келмейтінін алдын ала түсіну үшін қарапайым тексеру тізбегін ұстап тұрыңыз: тест кластерінде немесе бөлек пулде жүгіру, нақты CPU мен RAM шыңдарын requests/limits-пен салыстыру, диск (IOPS және p99 кешігу) және желі қоры (east-west трафик, p95 кешігулер, қателер) тексеру, және мониторинг пен логтардың retention өсуіне шыдайтындығын бағалау.

Өсу жоспарын ережелер түрінде жазу жақсы. Мысалы: пулдың тұрақты жүктемесі 60–70% жеткенде түйін қосамыз, ал буынды буын ауыстыруды 3–5 жылда жасаймыз, ескі және жаңа серверлер біраз бірге жұмыс істейді.

Физика мен адресацияны ұмытпаңыз: стойкада орын, қуат, коммутаторда бос порттар, 25/100GbE қоры, Pod/Service үшін IP және адрес кеңістік. Практикада дәл осыдар NVMe мен SATA арасындағы таңдаудан жылдам өсуге бөгет болады.

Қалай конфигурацияны таңдау: қарапайым қадамдық тәсіл

Бастамас бұрын сервер моделін емес, өз сервис картаңызды жасаңыз. Кластер үшін маңызды — құрал-жабдық жүктеме профиліне сай болуы: бір жерде жадқа тап болады, бір жерде дискке, ал кейде түйіндер мен хранилище арасындағы желіге.

Әр орта (dev, stage, prod) және негізгі сервистер бойынша бастапқы деректер жинаңыз: репликалар саны, кезектер мен кэш бар ма, логирование мен мониторинг қандай, requests және limits қандай. Есептеулерді өлшемдерге негіздеңіз, болжамдарға емес.

Одан әрі қысқа чеклист көмектеседі:

• орта бойынша жалпы ресурс бюджетін (CPU, RAM, диск кешігуі мен IOPS, кластер ішіндегі және хранилищеға жалғанатын желі) есептеңіз;
• түйіндерді 2–3 типке бөліңіз (универсалды, CPU-қа бейімделген, RAM-ға бейімделген), ал storage-ноды тек NVMe және жоғары IOPS нақты қажет болса бөлеңіз;
• желіні және резервтеуді ойластырыңыз (түйінге екі порт, екі коммутатор, анық отказ схемасы, қажет болса storage үшін сегментация);
• қор мен N-1 ережесін қойыңыз: бір түйін жоғалғанда кластер жұмысын сақтауы тиіс;
• өсу жоспарын анықтаңыз: түйіндер қаншалықты тез қосыла алады және трафик артқанда қалай жылдамырақ желіге өту жоспарланады.

Осылайша серверлер Kubernetes on-prem үшін «впритык» сатып алынбай, 2–3 айдан кейін OOM, диск кезектері немесе желі жүктелуіне тірелу жағдайларын болдырмайсыз.

Сатып алудан бұрын не тестілеу қажет

Соңғы тапсырыс алдында пилоттық түйіндерге қысқа тест-жоспар өткізіңіз: типтік сервисдерді орналастырыңыз, HPA қосыңыз, база мен логтарда жүктеме беріңіз, түйінді өшіру кезіндегі подтардың көшірілу уақытын және диск деградациясы кезіндегі мінез-құлықты тексеріңіз. Сіз өз стекіңіздің метрикаларына қарай қарап, «нарық орташа көрсеткіштеріне» емес шынайы профильге сеніңіз.

Мысал сценарий: on-prem микросервис платформасы үшін компания

Мысал ретінде 50–80 микросервисі бар, күнделікті релиздер CI/CD арқылы өтетін, плюс міндетті мониторинг, логирование және трассировка бар компанияны алайық. Барлығы on-prem-та тұр, себебі деректерді бақылау және болжамды шығын маңызды.

Мұндай кластер қызмет рольдері бойынша пулдарға бөлінуі ыңғайлы: инфрақұрылым (ingress, DNS, метрикалар, логирование, CI runners), stateless (негізгі сервис пен воркерлар) және stateful (базалар, кезектер, кэштер, хранилище).

NVMe шын мәнінде қажет орындар: stateful түйіндер мен ауыр логирование, индексация және метрикаларды сақтау түйіндері. Онда маңызды — мегабайт/секунд қана емес, көптеген ұсақ операцияда төмен кешігу. Stateless пул үшін көбіне сапалы SSD жетеді: сервистер негізінен CPU мен RAM-ға тәуелді, ал диск суреттер мен уақытша файлдарға керек.

Егер сервистер арасындағы трафик белсенді болса (көп сұраныстар, service mesh, жиі деплойлар), желі тез шектеуге айналады. Практикада түйінге 25GbE минимум болып қалатын жағдайлар жиі кездеседі, ал тығыз кластерлер үшін жылдамырақ аплинктер мен екі жолмен резервтеу жобы қажет.

Қорды былай есептеңіз: бір түйін шыққаннан кейін паникасыз қалу үшін N+1. Мысалы, егер stateless-пулда requests бойынша 120 vCPU қажет болса, жоспарлауды солай жасаңыз, бір сервер жоғалғанда да 120 vCPU қалатындай, 90 емес.

Kubernetes үшін сервер таңдау кезінде жиі қателіктер

Kubernetes үшін залдарды таңдау кезінде басты проблема — қателіктер сатып алу кезеңінде емес, бірнеше айдан кейін шығады, жаңа сервистер мен трафик қосылғанда. Сол кезде кластердің болжамдылығы бұзылады: планировщик подтарды қоныс ауыстырады, кешігулер өседі, жаңартулар түнгі марафонға айналады.

Жиі тұзақ — көп CPU алып, жадыға үнемдеу. Нәтижесінде requests «көзбен» қойылған, контейнерлер OOM-ға түседі, түйіндер RAM бойынша жүктеледі, ядролар әлі бос. Kubernetes on-prem үшін әдетте CPU мен жадыны теңгерімдеу маңыздырақ, частотаның соңынан қуалау емес.

Тағы кездесетін қателіктер: everywhere NVMe орнату, бірақ жылдам диск тек нақты жерде керек; 10GbE қалдыру және кейін east-west жүктеме өсіп таусылу; control-plane және ауыр ворклоадтарды бір түйінде араластыру; drain және жөндеу үшін қор қалдырмау, сондықтан жаңартулар downtime талап етеді; қуат, салқындату және стойка лимиттерін елемеу, нақты конфигурация дата-центрге сыймай қалуы мүмкін.

Простой мысал: компания on-prem платформаға CI, мониторинг және бірнеше API орнатады. 3 айдан кейін аналитика сервисті мен логтау өседі. Егер желі 10GbE қалып қойса және жады қоры жоқ болса, таймауттар мен pod eviction басталады, ал CPU әлі бос болуы мүмкін.

Қысқа чеклист және келесі қадамдар

Сатып алудан бұрын бір бетке не маңызды екенін бекітіңіз: шыңдар мен жаңартуларға CPU қоры, жұмыс деректер мен шоктарға RAM қоры, дискілер схемасы (қай жерде NVMe, қай жерде SSD жеткілікті), желі резервтеу және өсу жоспары N-1 қағидасын ескере отырып.

Соңында әзірлеу командасынан нақтылаңыз: қандай сервис stateful, қайсысы кешігуге сезімтал, күтілетін RPS және өсу, образ өлшемі және деплой жиілігі, жауап беру SLO-лары.

Одан әрі гипотезаларды пилот түйінінде немесе шағын стендте тексеріңіз. Бірнеше тест жеткілікті: CPU троттлинг қай кезде басталады, OOM қай жағдайда шығады, БД немесе кезек профиліндегі диск p99 кешігуі қандай, east-west желінің мінезі (кешігулер, жоғалтулар, бір линк істен шыққанда мінез-құлық), түйінді drain және қалпына келтіру қанша уақыт алады.

Жылына жаңарту жоспарын күнтізбеге түсіріңіз: тоқсан сайын Kubernetes және негізгі аддондарды жаңарту, прошивкалар/BIOS үшін терезелер және сыйымдылықты қайта қарау (мысалы, жарты жыл сайын).

Егер конфигурация таңдауды және кейінгі қолдауды жеңілдеткіңіз келсе, конфигурациялар мен өсу жоспарын жеткізу мен қолдауды бір топпен жабатын интегратормен талқылау мағыналы. Мысалы, GSE.kz (gse.kz) Қазақстанда S200 серверлерін өндіреді және 24/7 техникалық қолдау ұсынады — компоненттерді жылдам ауыстыру және жауапкершіліктің бір контурын ұнататындар үшін ыңғайлы.