Жазылымсыз Kubernetes on‑prem үшін минималды архитектура

Мәселе: жазылымсыз Kubernetes on‑prem орнату

Kubernetes‑ті on‑prem орналастыруды таңдайды, егер деректерге бақылау, жеткізілімдердің алдын ала болжануы және бұлттан тәуелсіздік маңызды болғанда. Бірақ Kubernetes тек контейнерлерді іске қосып, оларды ұстап тұруды шешеді. Оның айналасына негізгі архитектураны жинамасаңыз, тез арада «қолмен жасалатын» шешімдер пайда болады: жұмсақ емес желілік ақаулар, сервисдерді сыртқа жариялаудың болмауы, образдармен тәртіпсіздік және мониторингтің «көрінбейтін» аймақтары.

Төлемді жазылымдар көбіне «сиқыр» орнына типтік сұрақтарға дайын жауаптар жиынтығын береді. Әдетте бұл сенімді CNI, сервис балансировкасы, Ingress және TLS, жеке registry, мониторинг пен ескерту жүйелері, қауіпсіздік саясаттары, жаңартулар мен қолдау. Осының бәрін тегін компоненттермен жабуға болады, бірақ интеграция мен эксплуатация ережелері сіздің жауапкершілігіңізде болады.

Алғашқы релиз үшін аса көп нәрсеге ұмтылмау маңызды. Күнделікті жұмысты қамтамасыз ететін негізгі жинақ жеткілікті: CNI, Ingress және сыртқы IP, жеке registry, метрикалар мен ескертулермен мониторинг.

Шекаралар қарапайым: күрделі мультикластер, service mesh немесе «платформа ретінде өнім» жоқ. Мақсат — минималды және тұрақты негіз көтеріп, кейіннен қауіпсіздік, логирование және жаңарту процестерін біртіндеп қосу.

Минималды стек: кластерде не болуы керек

Минималды Kubernetes on‑prem архитектурасы — тек Kubernetes орнату емес, кластер тез-ақ бұзылатын етіп қоймайтын міндетті бөлшектер жиынтығын жинау.

Негізі әрдайым control plane және worker түйіндерінен тұрады. Тұрақтылық үшін control plane‑ды бір серверге емес, кем дегенде 3 түйінге жоспарлаған жөн (бастапқыда 1 бола алады, бірақ кеңею жоспары анық болуы керек). Worker‑лар бастапта әдетте 2–3 болады, бір түйіннің бұзылуын көтеру үшін.

Одан әрі эксплуатацияны тұрақты етпей тұрған компоненттер:

• CNI — подтардың желісі және желілік саясаттар.
• Ingress — сервистерді жариялау және TLS басқару.
• Registry — образдарды сақтау және нұсқаларды бақылау.
• Мониторинг — нодтар, подтар және control plane жағдайын көру.

Бастапта жиі қосуға тырысатын, бірақ нақты қажеттілік пайда болғанша кейінге қалдыруға болатындар: service mesh, GitOps‑платформа, таралған СХД, күрделі IAM және жан-жақты көпарендалық мүмкіндіктер. Олар бастапта көбіне жаңа сәтсіздік нүктелерін қосады.

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

Жақсы ереже: егер компонентті тез арада кезекші инженегке түсіндіру мүмкін болмаса және бір командамен оның тірі екенін тексеруге болмайтын болса — ол қазір қажет емес.

Серверге қойылатын талаптар: кластер үшін негізгі бағыттар

On‑prem‑дағы басты қауіп — аппараттың аздығы емес, бір ақау платформаның жартысын сөндіріп тастай алатындығы. Сондықтан тұрақтылықтың минималды нұсқасы — 3 control plane түйіні (etcd және басқару компоненттері) және 2–3 worker түйіні қолданбалар үшін. Бақылау стенді үшін бір control plane рұқсат етіледі.

CPU мен RAM‑ды нақты есептеу оңай: бір уақытта қанша сервис іске қосылады және қай жерде жүктеме шыңы болады (мысалы, ай аяғындағы есептер). Кіші продакшенге бастапқы нүкте ретінде:

• Control plane: әр түйінге 4–8 vCPU және 16–32 ГБ RAM.
• Worker: әр түйінге 8–16 vCPU және 32–64 ГБ RAM.
• Қор: қайта жүктеулер мен жоспарлы жұмыстар үшін 20–30% бос ресурсты ұстаңыз.

Дискілер жиі тар орынға айналады, әсіресе метрикалар мен логтар шыққанда. ОС, контейнер деректері (containerd/Docker) және мониторинг деректеріне арналған жылдам томды бөлу (жақсырақ физикалық бөліп) ұсынылады. Stateful‑жүктемелер үшін локальды сақтау қолдансаңыз, дискіге қойылатын талаптар күрт өседі: NVMe және бекітілген бэкап стратегиясы міндетті.

RAID маңызды, себебі «бұлттағы дискіні алмастыру» мүмкіндігі жоқ. Жүйелік дискілерге әдетте RAID1 жеткілікті, деректер мен метрикалар үшін RAID10 немесе ұқсас сенімділік/жылдамдық. Мысалы, маңызды деректері бар түйіннің дискінің істен шығуын қалай көтеретініңізді алдын ала тексеріңіз.

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

Желілік талаптар: DNS, NTP, MTU және IP жоспары

On‑prem Kubernetes желісі жиі «күрделі Kubernetes‑тан» емес, ұсақ мәселелерден бұзылады: әртүрлі MTU, нашар DNS немесе уақыттың жүзбе‑жүз болмауы. Негізгі параметрлерді бір стандартқа келтірсеңіз, архитектура болжамды жұмыс істей бастайды.

Балансировка мен сервис жариялау үшін желі деңгейін алдын ала шешіңіз. MetalLB‑ны L2 режимінде қолдану ең оңайы, бірақ онда түйіндер мен клиенттер бір L2‑секторда (бір VLAN, маршрутизациясыз) болуы керек. Егер желі L3 және сегменттелген болса, MetalLB‑ның BGP режимін таңдайды — маршрутизаторлар арқылы VIP‑тер жарияланады. Бұл баста қиынлау, бірақ корпоративтік желілерге жақсырақ үйлеседі.

MTU‑ны CNI орнатпас бұрын тексеріңіз. Қай жерде MTU 1500 болса және CNI қосымша оверхед (мысалы, VXLAN) қосса, пакет фрагментациясы немесе жоғалуы басталуы мүмкін. Белгілер: кейбір сервистер «кейде» ашылмайды, readiness‑тексеру сәтсіз болады, ал дебаг ештеңе көрсетпейді. Практикалық ереже: барлық сілтемелерге бір MTU орнатыңыз және оверлей бола ма, жоқ па алдын ала шешіңіз.

DNS пен NTP — кластердің дұрыс жұмыс істеуі үшін маңызды. DNS тек подтар үшін ғана емес, кластер компоненттері (CoreDNS‑тің upstream‑қа сұрау салуы) үшін де қажет. NTP TLS үшін өте маңызды: сертификаттар, токендер және аудит уақытына тәуелді.

Орнатудан бұрын белгілеңіз:

• Pod CIDR және Service CIDR — корпоративтік диапазондар мен VPN‑бен қайталанбауы керек.
• LoadBalancer адрестерінің диапазоны (MetalLB қолдансаңыз).
• Kubernetes API (6443) және Ingress (әдетте 80/443)‑қа кім және қайдан қол жеткізетіндігі.
• Сегментация: әкімшілік желілер бөлек, қолданбалар бөлек, қажет порттар ғана ашық.

Жылдам тест: сынақ namespace ашып, офис желісінен Ingress ашылатынын және API‑ға тек әкімшілік хосттардан қол жететінін тексеріңіз. Маршрутизация мен қолжетімділік ережелері мәселелері дереу көрінеді.

CNI: артық күрделіліксіз қалай таңдау және баптау

CNI подтардың бір‑бірімен қалай байланысатынын анықтайды: маршруттау, IP беру, Service жұмысы және NetworkPolicy. On‑prem‑да CNI жиі «құпия» үзілістер мен ұзақ тергеулердің көзі болады, сондықтан қарапайым әрі болжамды шешімді таңдау жақсы.

Тек подтар мен сервистердің байланысы қажет болса, көбіне Flannel жеткілікті. Ол жеңіл және қарапайым, бірақ NetworkPolicy‑ге көп көмегі жоқ. Қолжетімді басқару қажет болса, Calico таңдайды: ол пісіп-жетілген, NetworkPolicy‑ді жақсы қолдайды және стандартты Linux ядросында әдетте тосынсый бермейді. Cilium‑ды бақылау мен икемді саясаттар маңызды болса қарастырыңыз, бірақ ол ядро қажеттеріне сезімтал және жаңартуларда абай болуды талап етеді.

Бірінші релиз үшін қандай NetworkPolicy енгізу керек

Барлығын бірден «жабуға» тырыспаңыз. Минималды ережелерден бастаңыз және сервистердің бұзылмауын тексеріңіз:

• «prod» namespace‑ында әдепкі бойынша трафикті тыйыңыз және қажетті порттарға анық рұқсат беріңіз.
• DNS‑ке (әдетте kube‑dns/CoreDNS) барлық подтар үшін рұқсат беріңіз.
• Ingress контроллерден веб‑сервистерге ғана кіруге рұқсат беріңіз.
• Деректер қорына тек нақты қолданбалардан қатынауға мүмкіндік беріңіз.

Сәйкестік және жылдам тесттер

CNI‑ның ядроға қажеттілігін (модульдер, eBPF, iptables/nftables) орнатпас бұрын тексеріңіз. ОС образын стандарт ретінде бекіткен дұрыс.

«Боевой» сервиске дейін қарапайым тексерістер жасаңыз: pod‑тан pod‑қа (бір түйін ішінде және түйіндер арасында), DNS‑ке қолжетімділік, Service/NodePort жұмысы, NetworkPolicy қолдану. Практикалық сценарий: frontend пен backend атты екі тесттік қосымшаны орналастырып, саясат артық қатынауды блоктайтынын тексеріңіз.

On‑prem‑дағы Ingress: сервис жариялау және TLS

Ingress практикалық тұрғыдан барлық жерде қажет. Ол HTTP(S) бойынша кластерге бірдей кіру береді: көптеген NodePort‑тар орнына бір мекенжай және ережелер жинағы, сондай‑ақ домендер мен TLS‑ты басқару. Бұл ішкі порталдар, API, мониторинг және домен мен TLS маңызды сервистер үшін өте ыңғайлы.

Бастау үшін көбіне NGINX негізіндегі Ingress Controller таңдалады. Ол 80–90% тапсырмаларды шешеді: хосттар, жолдар, редиректілер, лимиттер және қарапайым аутентификация. Баламалар (Traefik, HAProxy Ingress) де жұмыс істейді, бірақ NGINX командаға әдетте оңайырақ.

TLS‑ты бастаптан «прод» сияқты ұйымдастырған дұрыс, кейін миграция ауыр болады.

TLS: сертификаттарды сақтау және жаңарту

Сертификаттар әдетте Kubernetes Secrets‑та сақталады, ал Ingress арқылы қосымшаларға беріледі. Әрбір сертификатты қолмен жиі жаңартпау үшін бір процесс орнатыңыз: сертификаттың көзі (ішкі CA немесе жария УЦ), автоматты жаңарту (мысалы, cert‑manager арқылы) және жеке кілттерді тек қажетті namespace‑тарда сақтау, қолжетімділік саясаттарын алдын ала тексеру.

On‑prem‑да Ingress‑ке сыртқы IP қалай беру

Bare metal‑да тұрақты сыртқы IP алу жолы қажет. Әдетте бір шешім таңдалады: MetalLB, бар аппараттық L4 немесе кешенді контурда провайдер балансировшигі. Практикада сыртқы және ішкі трафикті бөлек IngressClass‑пен бөліп қою пайдалы: мысалы, internal ішкі қызметтерге, ал external — шектеулі сыртқы endpoint‑терге.

Қазақстандағы шағын ұйымдарда бұл жиі ішкі қолжетімділік үшін офис‑жүйелер және сыртқыға тек DMZ арқылы бір‑екі сервис ұсыну ретінде ұтылады.

Registry: образдар қайда сақталатыны және жабық контурда өмір сүру

Жеке registry болмаса, кластер тезірек екі мәселеге тап болады: жылдамдық пен бақылау. Қоғамдық реестрлер қолжетімсіз немесе баяу болуы мүмкін, немесе күтпеген шектеулер келтіруі мүмкін. Сонымен қатар, бір шынайы дереккөз жоқ болады: қандай образдар рұқсат етілген, кім қай белгіні шығарды және қашан.

Минималды архитектура үшін әдетте бір ішкі registry жеткілікті — барлық түйіндер мен CI оған қол жеткізе алады. Бастапқы практикалық нұсқа — Harbor: жобалар, рөлдер, LDAP/AD интеграциясы, сақталу саясаттары және ыңғайлы интерфейс. Өте қарапайым шешім керек болса, Docker Registry мен basic auth те жарайды, бірақ құқықтар, тазалау және айнадандыруды өзіңіз ұйымдастыруыңыз керек.

Образ сақтау үшін бастапта бөлек VM‑да немесе арнаулы серверде локальды диск пайдалану оңай: тәуелсіздік аз, іске қосу жылдамырақ. Қуат артқанда немесе жоғары қолжетімділік қажет болғанда, S3‑үйлесімді on‑prem сақтау қарастырылуы мүмкін. Бұл масштабтау үшін ыңғайлы, бірақ тағы бір сервиске жауапкершілік қосады.

Өнімдегі мәлiметтерге сканерлеу мен қол қою пайдалы, бірақ бірінші күні міндетті емес. Көп жағдайда жеткілікті гигиена: тегтерді бекіту, SBOM‑ды сақтау және жаңарту процесін анықтау. Қол қою (мысалы, cosign) — релиз процесі тұрақты болғанда қосу логично.

Интернет жоқ немесе тұрақсыз болса, алдын ала тәуелділіктер жиынтығын дайындаңыз: Kubernetes add‑on образдары, базалық образдар, Helm chart‑тар. Harbor‑да айна жобаларды ұстап, оларды оқшауланған аймақтан жоспарлы түрде жаңарту ыңғайлы.

Орнатудан бұрын кем дегенде төрт сұраққа жауап беріңіз: registry қайда тұрады, қандай сақтау қолданылады, кімге push/pull рұқсат берілді және ескі тегтерді қалай тазалайсыз — диск жетіспеуі қауіпін болдырмау үшін.

Мониторинг пен логтар: минималды жеткілікті жинақ

Мониторинг пен логтарсыз on‑prem кластер жылдам лотереяға айналады. Бастапқы жинақты жазылымсыз және ресурсты шамадан тыс жұмсамай көтеруге болады.

Көбінесе жеткілікті минимум: Prometheus метрикалар үшін, Alertmanager хабарландырулар үшін және Grafana дашбордтар үшін. Бұл деградацияларды көруге және қолданушылар байқамай қалмас бұрын сигнал алуға мүмкіндік береді.

Басты назарды жиі бұзылатын нәрселерге аударыңыз: нодтар мен kubelet күйі, дискілердің толуы және латенттігі, etcd және API‑ның денсаулығы, DNS пен пакет жоғалтулар, 4xx/5xx қатесі мен Ingress жауап уақыты.

Логтарға қарапайымнан бастаңыз. Кіші кластер үшін жиі Loki жеткілікті (pod логтары + Grafana ішіндегі іздеу). Егер күрделі өңдеу керек болса, EFK қолдануға болады, бірақ ол ресурстарды көбірек талап етеді.

Ескертулер қысқа әрі пайдалы болу қажет, әйтпесе оларды елемей қояды. Түнде маңызды бірнеше сигналдар: диск дерлік толды, etcd қолжетімсіз, API‑да 5xx көбейді, түйін NotReady, Ingress‑те 5xx күрт күшейді.

Метрикаларды сақтау ұзақтығын (retention) алдын ала келісіңіз. Бастапта 7–15 күн жеткілікті, инциденттерді талдау және трендтерді көру үшін. Метрикаларға арналған диск кенеттен таусылады — сондықтан лимит қою және скрейп жиілігін нақтылау маңызды.

Қадамдық план: бірнеше итерацияда базалық стек орнату

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

Дайындаудан бастаңыз. Серверлерді (CPU, RAM, диск), рөлдерді (control plane және workers), IP‑адрестері мен қолжетімділікті бір кестеге жинаңыз. Желіні тексеріңіз: DNS резолвтай ма, NTP уақытты синхрондай ма, MTU түйіндер арасында бірдей ме.

Жол‑картасы мысалы:

• Итерация 1: Kubernetes орнатып (мысалы, kubeadm) түйіндердің Ready күйінде екенін және түйінді қайта жүктеу кластерді бұзбайтынын тексеру.
• Итерация 2: CNI қосып, pod‑тар арасындағы байланыс пен ClusterIP арқылы сервис жұмысының дұрыстығын тексеру.
• Итерация 3: Ingress орнатып, тесттік сервис пен TLS‑ты сырттан тексеру: сұрау қосымшаға жетіп, сертификат дұрыс екеніне көз жеткізу.
• Итерация 4: Registry (мысалы, Harbor) орналастырып, pull secret орнатып, namespace интернетсіз образды тартып алатынын тексеру.
• Итерация 5: Мониторинг (Prometheus және Grafana) орналастырып, мысалға тест түйінінде диск толтырып, ескерту келетінін тексеру.

Әр итерация соңында қысқаша бақылау жасаңыз: не өзгертілді, манифесттер қайда сақталады, қалай кері қайтуға болады. Бұл жаңа серверлерге орнатуды қайталау керек болғанда сағаттарды үнемдейді.

On‑prem Kubernetes‑тағы жиі қателіктер мен тұзақтар

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

Екінші тұзақ — control plane мен etcd‑ні резервтеуді ойламау. etcd бір серверде немесе жұмыс жүктемелерімен бірдей дискіде болса, тіпті шағын авариядан кейін кластерді қалпына келтіру қиын болады.

Желі де жиі ақау тудырады. Pod/Service диапазондарын «көздеп» таңдап, кейін корпоративтік подсеттермен немесе VPN‑мен қиылысып қалуы мүмкін. Нәтижесінде қарапайым себеппен таймауттар мен жоғалулар болады — адрес қақтығысы.

Тағы бір типтік қателік — Kubernetes API және әкімшілік панельдерді кең желіге ашық қалдыру. Тіпті ішкі интернет болмағанда да, офис сегментіндегі бір бұзылған машина жеткілікті қауіп тудырады.

Сондай‑ақ, көптеген командалар деректердің өсуіне лимит қоймайды. Логтар, метрикалар мен уақытша файлдар дискіні тез толтырып, kubelet‑тың құлауына және күтпеген қайта жүктелулерге әкеледі.

Көп жағдайда құтқарушы тексерістер:

• Рөлі бөлу: минимум 3 control plane және бөлек worker‑лар.
• Pod/Service CIDR‑ды бекіту және корпоративтік желілермен қиылысуын тексеру.
• API‑ға қолжетімдікті жабу: бөлек подсеть, firewall және минималды құқықтар.
• Логтар мен метрикаларға ретеншн мен квоталар орнату, диск толуын бақылау.
• Тек тесттік контур арқылы ғана жаңарту және нақты кері қайту жоспары.

Эксплуатацияға тапсыру алдындағы жылдам чек‑лист

Кластерді командаларға бермес бұрын қысқа тексеріс жасаңыз — ол 1–2 сағат алады және түнгі ауысымдарды үнемдейді.

Негізгі нәрселерді тексеріңіз:

• Control plane жалғыз емес: минимум 3 control plane, worker‑лар бөлек.
• DNS пен NTP тұрақты: барлық түйіндерден аттар резолвталады, уақыт синхрондалған.
• Желінің тосынсыйы жоқ: MTU бірдей, пакет жоғалуы жоқ және фрагментация байқалмайды.
• Сақтық көшірмелер бар: регулярлы etcd бэкаптары, registry және мониторинг конфигурацияларының сақтық көшірмелері.
• Ескертулер «көрінетін»: бірнеше негізгі сигналдар бар және анық канал арқылы хабарландыру түседі.

Айырмалы түрде жаңарту және кері қайту жоспарын келісіңіз: бір түйінді біртіндеп жаңарту, нұсқаларды алдын ала бекіту, негізгі сервистерді тексеру және нақты артқа қайту әрекеті (etcd snapshot, манифесттерді кері қайтару, түйін нұсқасын қалпына келтіру).

Мысал: Қазақстандағы ұйымға арналған шағын тұрақты кластер

Мысалы, ведомство, клиника немесе білім беру мекемесі: 15–30 ішкі сервис (порталдар, интеграциялар, кезектер, бірнеше дерекқор, есептер), локальды желіден қолжетімділік және кейде VPN арқылы. Контур жабық, жаңартулар айына бір рет немесе сирек жүргізіледі. Көбіне жергілікті жабдық пен қолдаудың болуы маңызды.

Минималды тұрақтылық рөлдерді бөлуден басталады. Control plane, Ingress және мониторинг бірдей машиналарда болса, кез келген жүктеме немесе ақау каскадты түрде әсер етеді.

Кішкентай on‑prem кластер үшін түсінікті орналастыру:

• 3 control plane түйіні (тек кластерді басқару, қолданбалы подтар жоқ)
• 2 Ingress түйіні (арнаулы, MetalLB арқылы бекітілген IP‑лер)
• Қызметтерге арналған 3–6 worker түйіні (CPU мен жадты қосымша қалдықпен)
• Registry (Harbor) және артефактілерге арналған 1 түйін, бөлек диск/RAID
• Мониторингге (Prometheus + Grafana) арналған 1 түйін, бөлек диск

Бірінші айда апат қауіпін азайтуға бағытталған нәрселерді қойыңыз: CNI, Ingress, DNS/NTP, жабық контурға registry, базалық мониторинг және ескертулер. Кварталға арналған жоспарға әдетте логтарды орталықтандыру, registry мен мониторингтің HA‑сы және жаңарту процесінің тұрақты графигі кіреді.

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

Келесі қадамдар: жоспардан сатып алу және эксплуатацияға

Бастапқы стек анықталғаннан кейін оны қысқа, тексерілетін жоспарға айналдыру керек. Бірінші кезектегі компоненттерді бекітіңіз: CNI, Ingress, балансировка (қажет болса), registry, мониторинг, etcd бэкаптары және жаңарту ережелері. «Кейінге қалдырмау» — пилотта тосынсыйларды азайтады.

Содан кейін кластер көлеміне сай спецификация жасаңыз. Жүктемеден бастап, ресурстарды сол арқылы есептеу тиімдірек. Желіні бөлек талқылаңыз: IP‑жоспар, VLAN/сегментация, DNS/NTP‑ға қолжетімділік, MTU және интернетке шығу нүктелері.

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

Ең аз жауапты шешімдер эксплуатацияға дейін:

• кластердің иесі кім және жаңартуларды кім орындайтыны (Kubernetes және аддондары);
• құпияларды қалай сақтайсыз және кімде қолжетімділік бар;
• бэкаптар қайда жазылады (etcd, registry, мониторинг конфигурациялары) және қалпына келтіру жиілігі;
• міндетті метрикалар мен ескертулер тізімі;
• техоперациялар кестесі және өзгертулер енгізу ережелері.

Егер толық «бастан аяғына» жергілікті жабдық пен жүйелік интеграция, сондай‑ақ 24/7 қолдау керек болса, GSE.kz (gse.kz) сияқты жергілікті жеткізушілерге қарау жақсы болуы мүмкін. Олар жұмыс станциялары, ПК және серверлермен қатар инфрақұрылым құру және 24/7 техқолдау қызметін ұсынады.