K3s или Kubernetes: мање RAM-а плаћа се компромисом у протоку

У независном тесту на Intel NUC и Raspberry Pi 4 уређајима K3s је трошио најмање ресурса, али је стандардни Kubernetes у Redis оптерећењу достигао готово 19.000 операција у секунди према мање од 15.000 код K3s, уз просечну латенцију од око 10,5 према 13,5 милисекунди. За ограничену меморију K3s је логичан почетни избор; када је одзив услуге пресудан, резултат теста даје разлог да се испита и стандардна поставка.

Ово су резултати конкретних кластера, а не универзална цена лакше дистрибуције. Уштеда меморије и брзина апликације мере различите делове система: прва одређује колико простора остаје подовима, а друга шта се догађа када саобраћај стигне до сервиса. Избор за уређаје на ивици мреже, лабораторију или мању продукцију зато зависи од стварног ограничења хардвера и врсте оптерећења.

Шта заузима меморију пре апликације

Према званичном профилу K3s ресурса, на тестираном Intel систему сервер кластера са агентом, без апликационог оптерећења, захтевао је 1.428 M RAM-а и 5% једног CPU језгра; сам агент 275 M и 3%, а сервер који дели чвор са једноставним оптерећењем 1.596 M и 6%. Ово су минималне резерве за компоненте оркестрације у описаним условима, не мерење укупне потрошње апликационих контејнера.

Важна је разлика између серверског и радног чвора. Сервер одржава управљачку раван и складиште стања, док агент извршава радно оптерећење без тих компоненти. Зато број малих радних уређаја не говори сам по себи колико меморије треба централном чвору. У буџет улазе и оперативни систем, контејнери, логови и простор за покретање нових подова током ажурирања.

Званични профил је добијен на Intel систему у облаку, а независни тест на другом хардверу. Њихове вредности RAM-а зато не треба одузимати једну од друге као да су две дистрибуције мерене у истом експерименту. Празан кластер открива почетни трошак, али не показује колико ће меморије остати када се подигну стварни сервиси и надзор.

Када се предност у RAM-у губи у протоку

Резултат протока односи се на раван података, односно на обраду Redis захтева у испитаном кластеру. Латенција у том мерењу описује одзив тог оптерећења, а не брзину са којом управљачка раван прихвата нови под или мења Kubernetes ресурс. Та разлика је важна за сервис који стално прима захтеве: мала потрошња RAM-а оркестратора сама по себи не обезбеђује кратко време одзива.

Исто истраживање је добило другачију слику за операције управљачке равни: K3s је код више промена ресурса имао ниску латенцију, а при постављању подова био је близу најбржим испитаним поставкама. Тиме се објашњава зашто се брзина кластера не може свести на једну метрику. Често креирање подова и непрекидан саобраћај ка апликацији оптерећују различите путеве кроз систем.

У тесту су се разликовали и верзије дистрибуција, мрежне компоненте и складиште стања: поставка K3s користила је SQLite, а стандардна etcd. Измерена разлика зато припада целој конфигурацији. На другом уређају или са другом мрежом смер разлике може да се промени, па је за захтев за строгом латенцијом меродаван тест сопственог сервиса на истом хардверу и при истом оптерећењу.

Шта се добија лакшим паковањем

K3s задржава Kubernetes API, али пакет K3s обједињује компоненте у једну бинарну датотеку и подразумевано користи SQLite; уз њега долазе containerd, Flannel, CoreDNS и Traefik. За лабораторију и удаљену локацију то скраћује пут до функционалног кластера. Уједно значи да већ изабрану мрежу, улазни контролер, складиште и правила за надоградњу треба ускладити са оним што је укључено у дистрибуцију.

Стандардна поставка даје тиму више избора при састављању тих делова и више одговорности за њихове међусобне зависности. Ако већ постоје усвојени додаци, поступак обнове и људи који одржавају кластер, та флексибилност може бити вреднија од мањег почетног трошка меморије. У малом лабораторијском систему исти број одлука може да потроши више времена него само покретање апликације.

Доступност мења рачуницу броја чворова

Архитектура K3s дозвољава један сервер са агентима, али за високу доступност управљачке равни описује најмање три сервера са уграђеним etcd-ом или најмање два са спољним складиштем стања. Један сервер остаје тачка отказа за управљање кластером, без обзира на то колико је радних чворова придружено. Додавање сервера троши хардвер и уводи бригу о бази, адреси за приступ и обнови после квара.

Kubernetes смернице за продукцију такође везују отпорност за умножавање управљачке равни, балансер испред API сервера и резервне копије etcd-а. Зато број чворова треба посматрати заједно са потребним нивоом доступности. Поређење једног K3s сервера и отпорног Kubernetes кластера меша две различите архитектуре и даје погрешну слику о стварном трошку одржавања.

Избор према ограничењу система

• Један чвор или мала лабораторија: K3s је погодан почетак када су меморија и време постављања строжи услови од максималног протока. Ако сервер носи и апликацију, резервишите простор за оба дела посла, а не само за процес оркестратора.
• Више малих чворова на ивици мреже: раздвојте меморијски буџет сервера од буџета агената. Када је потребан непрекидан рад управљачке равни, урачунајте додатне сервере или спољну базу пре поређења са стандардним Kubernetes кластером.
• Сервис осетљив на проток и латенцију: упоредите обе поставке са истим репликама, мрежом, складиштем и профилом саобраћаја. Мерите одзив апликације одвојено од брзине креирања подова; резултат Redis теста служи као сигнал за то поређење, не као гаранција.
• Постојећи Kubernetes додаци и процедуре: проверите да ли су потребне интеграције и захтеви за доступност изводљиви у K3s конфигурацији. Ако нису, трошак прилагођавања може надмашити уштеду RAM-а чак и на релативно малом кластеру.

Прочитајте и:

• CapCut или DaVinci Resolve: бржи клип плаћа се мањом контролом