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

Не про ДевОпс. 🚽 Не маючи на меті будувати культ продуктивності, а бажаючи спокійно проводити вихідні, практикую таку просту фішку. Ввечері пʼятниці записую 2-5 екшен айтеми, що робитиму в першу чергу на ранок понеділку. 🧑‍🎓 1. Написати першому; 2. Поздвонити другому; 3. Уточнити в третього; 4. Не забути пофіксити четверте. Особливий кайф ловлю від того, що сам то почав робити, а не десь прочитав, але сподіваюсь комусь така схема теж стане в нагоді. В моєму випадку це знімає думки про таски і блокери на вихідних, бо мозок розуміє, що план дій вже є і достатньо його дотриматись. Вважаю, що фішка ефективна, бо результат відчуваєш вже на наступний день (суботу), а не як з довлготривалими трекерами/планнерами. DevOps Інженер 👨🏼‍💻

Перший реквест до self-hosted AI моделі 💬 Використовуючи GenAI щодня, досі не доходили руки захостити якусь модель локально. А зробити це насправді не так і складно. Ось дуже базовий приклад як можна зробити перший запит до локальної моделі: docker run -d --rm --name ollama -p 11434:11434 ollama/ollama && \ sleep 3 && \ docker exec ollama ollama pull llama3.2:1b && \ curl -s http://localhost:11434/api/generate \ -H 'Content-Type: application/json' \ -d '{ "model": "llama3.2:1b", "prompt": "Explain what a Kubernetes operator does in 3 sentences.", "stream": false }' | jq -r '.response' && \ docker stop ollama >/dev/null Після цього Docker підніме runtime image ollama/ollama, вже в ньому завантажить модель llama3.2:1b і зробить до неї запит. Під час тестувань помітив, що відповіді українською доволі обмежені, певно через те що використовується невелика модель, здатна працювати на звичайних пристроях. Будь-які виправлення, пропозиції і обговорення - велком. Корисні лінки: Як і навіщо піднімати аплікейшн у контейнері? 🖼️ DevOps Інженер 👨🏼‍💻

Сподіваюсь у вас гарні і безпечні вихідні! ✈️ Хочу поділитись з вами підборкою DevOps/Architecture tg каналів, які сам регулярно читаю. Деякі із каналів трошки підзакинуті, але ти ніколи не знаєш, коли GCP релізне темну тему 🙃. За лінкою можна додати собі папку із каналами, а потім залишити підписку тільки на ті, що до вподоби. Тож додавайте і діліться із знайомими) Запрошую в коменти залишити свої канали, або DevOps канали, про які я не знаю. https://t.me/addlist/ymV0bfIYkkI2YTli DevOps Інженер 👨🏼‍💻

Intro to Large Language Models від Andrej Karpathy 💬 Andrej Karpathy - доволі відома людина в AI, і один із тих, хто реально вміє пояснювати складні речі простими словами. Саме відео вже не нове, і по деяких моментах відчувається, що AI за цей час пішов далі. Але якщо хочеться зрозуміти базу про LLM - як вони влаштовані, чому галюцинують, то відео варте уваги, бо розкладає по поличкам терміни які ви до цього могли просто чути. 🌐 Відео (recommended) / 🔗 Нотатки DevOps Інженер 👨🏼‍💻

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

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 Інженер 👨🏼‍💻

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

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

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

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