DevOps 👨🏼‍💻 Інженер

Kubernetes kubelet 🧑‍🔧 У постах про Control Plane (лінк) я обіцяв розказати про ⚙️ kubelet. Якщо Control Plane це мозок і пункт прийняття рішень, то kubelet - той, хто то все виконує. Це агент, який працює на кожній ⚙️ node (нода - зазвичай VM-ка в твоєму кластері, завжди готова розгорнути на собі якісь твої сервіси). Kubelet не вирішує що запускати, бо це робота ⚙ kube-scheduler. Задача ж kubelet - запустити вже вказаний Control Planʼом ворклоад. Що робить kubelet: 🔧 отримує від ⚙ kube-apiserver список подів на запуск 🔧 керує container runtime на машині (наприклад containerd) 🔧 стежить за здоров'ям контейнерів (не подів) і рестартує їх якщо впали (liveness/readiness проби, restartPolicy) 🔧 репортить статус ноди й подів назад в kube-apiserver DevOps Інженер 👨🏼‍💻

Kubernetes Gateway API 🚪 У минулому пості (лінк) розібрали Ingress. Що ж таке Gateway API і чому він гнучкіший? Замість монолітного Ingress-об'єкта є рольове розділення на ресурси: ⚙️ GatewayClass - яка саме реалізація Gateway API використовується в кластері (istio, envoy тощо). ⚙️ Gateway - сам балансувальник, керує платформна команда. ⚙️ HTTPRoute - правила роутингу, керує команда розробки. Тобто команди та сервіси більше не б'ються за один спільний об'єкт. Бонусом - L4+gRPC трафік, вбудований canary і все це без специфічного менеджменту анотаціями. У SIG Network є офіційний тул Ingress2Gateway, що допомагає перегенерувати маніфести. DevOps Інженер 👨🏼‍💻

Kubernetes Ingress 🌐 У минулому пості (лінк) розібрали Services і дійшли до LoadBalancer. Але піднімати окремий LB на кожен сервіс - дорого і незручно. Що робити, якщо треба виставити назовні десяток сервісів? Відповідь - Ingress. Він складається з двох частин: ⚙️ Ingress resource - YAML-об'єкт із правилами роутингу: який хост чи шлях веде на який сервіс, які TLS-сертифікати. Сам по собі нічого не робить. ⚙️ Ingress controller - софт (наприклад traefik), що виконує ці правила. Моніторить K8s API, помічає нові Ingress-правила і оновлює маршрути. Ingress працює на L7 - бачить HTTP-запит і роутить за хостом (api.example.com) або шляхом (/api). Сам контролер (зазвичай) виставляється назовні через один LB, а він уже роздає трафік усередину. ⚠️ Але в Kubernetes уже є офіційний наступник Ingress - гнучкіший Gateway API. Про нього розповім окремо, він набагато цікавіший. DevOps Інженер 👨🏼‍💻

Привіт! Зібрав корисні підбірки 🇺🇦 контенту в одному місці: 🗂 DevOps/Architecture Telegram канали, які сам читаю: [переглянути і додати папку] 💬 AI/ML канали - свіжа папка для тих, хто занурюється в цю тему: [переглянути і додати папку] 🚣 IT канали - ширша добірка каналів на різні теми: [переглянути і додати папку] ⚙️ Емоджі-пак з іконками Kubernetes-ресурсів - зручно підписувати флоу і пости: [переглянути і додати емодзі] Додавайте, лишайте в підписці тільки те, що до вподоби, і діліться зі знайомими. У коментах можете залишити свої канали, або ті, про які я міг не знати, зможу додати в папку 😉. На диво - дуже ефективний механізм. DevOps Інженер 👨🏼‍💻

Знову K8s Control Plane (наочно) 👀 У попередніх постах розібрали компоненти Control Plane (лінк). Але одна річ прочитати, а інша - побачити їх наживо у своєму кластері. Зробимо це за пару хвилин. 1. Встановлюємо minikube (гайд) 2. minikube start --driver=docker 3. kubectl get pods -n kube-system У виводі бачимо компоненти з минулого посту: ⚙ kube-apiserver, ⚙ etcd, ⚙ kube-scheduler, ⚙ kube-controller-manager - кожен як окремий под. Прибрати за собою: minikube delete Але якщо ці компоненти самі частково відповідають за життєвий цикл подів - то хто тоді створив поди, в яких працюють вони? Курка чи яйце? Про це - пізніше 🙂. DevOps Інженер 👨🏼‍💻

Kubernetes Services (всіх з суботою) 🌐 Поди (контейнери) в кластері постійно вмирають і перестворюються, і кожен раз отримують новий IP. Щоб не ганятись за цими IP, існує абстракція Service - стабільна точка доступу до групи подів. Є три основних типи, і кожен наступний надбудовується над попереднім: ⚙️ ClusterIP - внутрішній IP, доступний тільки всередині кластера. Дефолт для комунікації між сервісами. ⚙️ NodePort - відкриває порт (30000–32767) на кожній ноді. Тепер до сервісу можна достукатись ззовні через <node-ip>:<port>. Під капотом має ClusterIP. ⚙️ LoadBalancer - піднімає зовнішній load balancer (AWS, GCP) з публічним IP. Під капотом має і NodePort (не завжди), і ClusterIP. Тобто це не те щоб три окремі об'єкти - це один Service з вкладеними рівнями. DevOps Інженер 👨🏼‍💻

Kubernetes Control Plane ⚙️ Control Plane - це мозок кластера. Він не запускає додатки, але вирішує де, коли і як вони мають працювати. Складається з чотирьох компонентів: ⚙️ kube-apiserver - єдина точка входу. Будь-яке звернення до кластера (kubectl, контролери, ноди) йде через нього. Нічого не звертається до бази напряму, тільки через apiserver. ⚙️ etcd (або альтернативи) - база даних кластера. Зберігає весь стан: які поди мають працювати, які ноди існують, конфіги, секрети. Єдине джерело правди. ⚙️ kube-scheduler - слідкує за новими подами без призначеної ноди і вирішує на яку ноду їх запустити. ⚙️ kube-controller-manager - постійно звіряє бажаний стан із реальним і виправляє розбіжності. Базовий флоу: ти описуєш бажаний стан → apiserver зберігає це в etcd → scheduler призначає поду ноду → kubelet (розглянем пізніше) на цій ноді запускає контейнери → контролери постійно звіряють що реальність відповідає бажаному стану. DevOps Інженер 👨🏼‍💻

Чанкінг у RAG ✂️ Перед тим як зберегти документ у Vector DB (лінк), його треба розбити на менші шматки - чанки. Якщо цього не зробити, RAG просто не знайде потрібне місце в документі, бо embedding великого тексту дає занадто розмитий вектор. Розмір чанку напряму впливає на якість відповідей. Задовеликий - вектор розмитий. Задрібний - втрачається контекст. Щоб не розрізати думку на межі чанків, використовують overlap - сусідні чанки трохи перекривають одне одного. Детальніше про стратегії чанкінгу: 📃 Evaluating Chunking Strategies (стаття) 📹 The BEST Way to Chunk Text for RAG (відео) DevOps Інженер 👨🏼‍💻

Vector DB - місце, де зберігаються embeddings 🗂 Вже знаємо, що робить embedding model - вона перетворює текст (і не тільки) на вектор (лінк). Цей вектор треба кудись покласти і вміти швидко шукати по ньому. Для цього існують Vector DB. На відміну від звичайної БД, яка шукає точний збіг, Vector DB шукає найближчі за змістом вектори. Саме так RAG знаходить потрібний шматок вашого документу. Поширені варіанти: pgvector - екстеншн до Postgres. Qdrant - окрема БД написана на Rust. Швидша за pgvector на великих об'ємах, open-source. ChromaDB - в більшості для старту і прототипів. 📹 Відео від IBM щодо VectorDB: What is a Vector Database? Гарних всім вихідних! 🏖️ DevOps Інженер 👨🏼‍💻

Підбірка постів, що вийшли з моменту останнього розіграшу: 📌 Self-hosted AI модель - перший запит у кілька рядків 📎 NanoClaw - AI-помічник у контейнері, що сам себе розширює через промпти 📌 MCP + K8s - як дати Чату доступ до кластера 📎 newreleases - трекінг нових версій сервісів без ручного моніторингу 📌 Intro to LLM від Andrej Karpathy - база про те як влаштовані моделі 📎 RAG - як моделі отримують доступ до ваших даних 📌 Embedding model - AI модель що перетворює текст на вектор І окремо - 🇺🇦 підбірка україномовних DevOps/Architecture каналів, які сам читаю. Додавайте і діліться із знайомими. https://t.me/addlist/ymV0bfIYkkI2YTli DevOps Інженер 👨🏼‍💻

За традицією - розіграш Telegram Premium для підписників. Дякую всім, хто читає, реагує і пише в коменти, це реально мотивує продовжувати. 😉 DevOps Інженер 👨🏼‍💻

Steam Deck як k8s нода 🎮 Колись показував свій перший homelab на ThinkPad X250 (лінк). Тоді діло далеко не зайшло. Тепер є другий підопічний - Steam Deck. AMD Zen 2, 16GB RAM, швидкий NVMe (для сервака його не використовую). SteamOS живе на внутрішньому NVMe, Ubuntu Server із k3s на SD-карті. Boot Manager вирішує куди завантажуватись: ігри чи сервер. Поки найбільший біль - налаштувати все без дротової клавіатури ☺️. Вирішив через cloud-init скріптец: username, SSH ключ і пакети налаштовуються ще до першого завантаження. Далі все по SSH. DevOps Інженер 👨🏼‍💻

Embedding model та RAG 🧠 У попередньому пості розібрали RAG-флоу (лінк). Там був крок "твої доки → Vector embeddings". Його частково виконує embedding model. Embedding model - це AI модель, задача якої перетворити текст (а точніше його частинку) на вектор (масив чисел), який відображає зміст цієї частинки. Схожі за змістом тексти отримують близькі вектори. Саме завдяки цьому ми можемо знайти у RAG "найближчий шматок" до нашого питання. Популярні моделі: text-embedding-3-large (OpenAI), embed-v4 (Cohere), voyage-3-large (Voyage AI). У коментах під попереднім постом поділились посиланням на пояснення RAG-флоу українською. Дуже зрозуміло і наочно: лінк. DevOps Інженер 👨🏼‍💻

Що таке RAG і навіщо він потрібен 💬 AI модель не знає твоїх внутрішніх конфігів чи ранбуків - вона тренувалась на чомусь іншому. Донавчати модель під кожен чих - дуже дорого. Тут і зʼявляється RAG (Retrieval-Augmented Generation): перед відповіддю система шукає релевантні шматки у твоїй базі знань і підкладає їх моделі в контекст разом з питанням. Флоу такий: твої доки → Vector embeddings → Vector DB → пошук найближчого за змістом шматка → шматок + питання летять в LLM. Для підтримки цього флоу існує багато managed і self-hosted рішень. Їх розглянемо пізніше. DevOps Інженер 👨🏼‍💻

Трекінг нових версій сервісів 🗓 Час від часу трапляються моменти, коли ви очікуєте на вихід конкретної версії певної тули/ліби. Наприклад, під час ресерчу ви побачили, що потрібна вам фіча вийде у наступному релізі. Замість того, щоб щоранку заходити на GitHub цієї тули, можна підписатись на її оновлення за допомогою https://newreleases.io/. Сервіс безкоштовний і підтримує велику кількість джерел - GitHub / GitLab / Bitbucket, Docker Hub, PyPI та інші. Сповіщення можна отримувати на Email, Slack, Telegram, Discord, Microsoft Teams... або вебхуком. DevOps Інженер 👨🏼‍💻

MCP і т.д. 👨‍💻 Останнім часом почав використовувати AI набагато ефективніше. Вірний контекст та чіткий опис бажаного результату дають доволі добрий ефект. Із часом краще відчуваю грань між "Here is a problem. Make no mistakes" і "Зроблю краще сам". Один із методів, як надати Чату доступ до потрібного контексту - підключити MCP. Де MCP - це стандарт взаємодії між Чатом(Агентом) і зовнішніми сервісами. Як приклад - kubernetes-mcp-server. Підключивши цю MCP, Чат зможе пійти у ваш Куб кластер і глянути логи потрібного сервісу. Тепер ви цілком, на свій страх і ризик, можете вайб-кластерити, бо write-операції там також доступні. Я ж рекомендую ставитись до цього відповідально 🤓. Діліться своїми флоу. Я ж використав звʼязку Claude Desktop💬 і Kubernetes MCP👩‍💻. DevOps Інженер 👨🏼‍💻