Концепции Pod'ов в Kubernetes, которые должен знать каждый DevOps-инженер

Pod — это базовая единица выполнения в Kubernetes. Хотя базовое использование Pod'ов достаточно простое, продвинутые концепции позволяют DevOps-инженерам оптимизировать развёртывание, повысить устойчивость и максимально эффективно использовать ресурсы. В статье приведены ключевые важные концепции работы с Pod'ами, которые должен освоить каждый DevOps-инженер.

https://telegra.ph/Prodvinutye-koncepcii-Podov-v-Kubernetes-kotorye-dolzhen-znat-kazhdyj-DevOps-inzhener-04-19

#ит_статьи #devops #kubernetes #k8s #pod #cheatsheet

Стоит ли запускать PostgreSQL в Kubernetes?

Если у вас нет времени читать статью, то краткий ответ: да! Запуск кластера базы данных PostgreSQL в Kubernetes — это жизнеспособный и готовый к использованию в продакшене способ хостинга баз данных. Но так было не всегда. Раньше, когда единственным примитивом Kubernetes для этого были StatefulSets, управление базами данных в кластере Kubernetes было задачей не из простых. Сейчас, благодаря зрелости специализированных операторов для Kubernetes, таких как CloudNativePG, настоящие ограничения чаще связаны с навыками и опытом инженеров, управляющих кластером.

Тем не менее, запуск PostgreSQL в Kubernetes не гарантирует повышения уровня безопасности или автоматического решения проблем с отказоустойчивостью. Однако он открывает большие возможности для автоматизации и расширяемости, которых было бы крайне сложно достичь другими средствами.

https://telegra.ph/Stoit-li-zapuskat-PostgreSQL-v-Kubernetes-04-24

#ит_статьи #devops #linux #kubernetes #k8s #postgresql #statefulset #cloudnativepg

Под капотом Kubernetes: Container Runtime Interface простыми словами

Одной из ключевых особенностей Kubernetes является поддержка различных сред выполнения контейнеров. Чтобы обеспечить эту гибкость и не привязываться к конкретному контейнерному движку, был создан специальный интерфейс — Container Runtime Interface (CRI).

В этой статье подробно разберём, как устроен CRI, какую роль он выполняет при запуске и управлении контейнерами, а также посмотрим, какие инструменты можно использовать, чтобы лучше понимать, что происходит «под капотом» вашего Kubernetes-кластера.

https://telegra.ph/Pod-kapotom-Kubernetes-Container-Runtime-Interface-prostymi-slovami-04-25

#ит_статьи #devops #linux #kubernetes #K8s #cri #docker

Freelens: Свободная IDE для Kubernetes

https://github.com/freelensapp/freelens

Freelens — это open-source IDE, созданная, чтобы упростить управление кластерами Kubernetes. Это отдельное приложение для macOS, Windows и Linux с удобным интерфейсом для работы и визуализации ресурсов кластера K8s. По сути, это просто более удобная альтернатива стандартной Kubernetes Dashboard.

Основные плюсы:
- Упрощает управление Kubernetes благодаря интуитивному UI
- Работает на всех мейнстримных платформах (macOS, Windows, Linux)
- Помогает избежать ошибок и ускоряет рабочий процесс
- Открытый исходный код, плюс проект довольно активно развивается сообществом
- Подходит как новичкам, так и продвинутым пользователям

#ит_заметки #devops #linux #kubernetes #ide #freelens

Nginx Ingress Controller в Kubernetes

Nginx Ingress Controller — это реализация контроллера входящего трафика (Ingress) для Nginx. Он умеет балансировать нагрузку не только на HTTP, но и на WebSocket, gRPC, TCP и UDP-приложения. Помимо этого он поддерживает стандартные возможности Ingress. Например маршрутизацию на основе контента и завершение TLS/SSL-соединений. Некоторые функции Nginx доступны как расширения к Ingress через аннотации и ресурс ConfigMap.

Кроме реализации Ingress, контроллер Nginx также поддерживает ресурсы VirtualServer и VirtualServerRoute. С ними можно например делить трафик между сервисами и задавать более сложные правила маршрутизации. Также доступна балансировка TCP, UDP и TLS Passthrough через ресурс TransportServer.

В статье рассмотрим как настроить Nginx Ingress Controller в Kubernetes-кластере на bare-metal серверах

https://telegra.ph/Nginx-Ingress-Controller-v-Kubernetes-05-11

#ит_статьи #devops #linux #kubernetes #ingress #nginx

Простой способ отслеживать деплойменты Kubernetes в Grafana

- “Мы это задеплоили в то время?”
- “Это из-за новой версии?”
- “А какой это был коммит?”

Если вышеперечисленное для вас знакомо, вы не одиноки - умение связать метрики с деплойментами реально экономит время во время инцидентов.

Мы тоже хотели такую наглядность в своих сервисах - но без изменений в приложении, без правок CI/CD-пайплайнов и без дополнительного кода. В итоге нашли максимально простой способ: один запрос в Prometheus + небольшая настройка в Grafana.

Результат - автоматические аннотации для каждого нового деплоймента с ссылкой на соответствующий релиз в GitHub. И самое крутое? Если вы используете Kubernetes, нужные данные у вас, скорее всего, уже есть.

https://telegra.ph/Prostoj-sposob-otslezhivat-deplojmenty-Kubernetes-v-Grafana-05-22

#ит_статьи #devops #kubernetes #deployment #prometheus #grafana

Проверка контейнерных образов в Kubernetes с помощью Kyverno

Если вы запускаете рабочие нагрузки в Kubernetes, безопасность образов — это не то, чем можно пренебречь. Контейнеры подтягиваются из публичных или приватных реестров, и если вы не проверяете эти источники, вы буквально оставляете дверь открытой — для уязвимостей или даже атак на цепочку поставок.

Вот тут-то и вступает в игру Kyverno — нативный для Kubernetes движок политик, который позволяет проверять, изменять и генерировать конфигурации на основе заданных вами правил. В этой статье мы покажем, как с его помощью проверять источники контейнерных образов и обеспечивать безопасность на практике.

https://telegra.ph/Proverka-kontejnernyh-obrazov-v-Kubernetes-s-pomoshchyu-Kyverno-05-23

#ит_статьи #devops #kubernetes #workloads #kyverno

Лучшие практики Helm для развёртывания Kubernetes в нескольких окружениях

Helm, как многим известно - стандартный менеджер пакетов для Kubernetes. Но вот чтобы действительно с пользой использовать Helm (особенно когда у вас сразу несколько окружений типа dev, staging, prod) простого helm install будет маловато. В этой статье на показываем, как правильно организовать работу с Helm-чартами и как чисто и грамотно деплоить их в разных окружениях.

https://telegra.ph/Luchshie-praktiki-Helm-dlya-razvyortyvaniya-Kubernetes-v-neskolkih-okruzheniyah-06-09

#ит_статьи #devops #kubernetes #helm

Зачем и почему не стоит включать swap в Kubernetes

По умолчанию Kubernetes требует, чтобы swap был отключён на узлах. Это решение связано с желанием обеспечить предсказуемую производительность и управляемость ресурсов. Но с развитием систем управления памятью и появлением cgroups v2 сообщество Kubernetes начало пересматривать эту позицию.

В этой статье мы разберём, почему изначально swap отключали, какие плюсы и минусы есть у его включения, и как сейчас меняется поддержка swap в Kubernetes.

https://telegra.ph/Zachem-i-pochemu-ne-stoit-vklyuchat-swap-v-Kubernetes-06-11

#ит_статьи #devops #kubernetes #linux #swap #cgroups_v2

kubectl-atomic-apply: атомарное применение Kubernetes-манифестов с возможностью отката

kubectl-atomic_apply - это плагин для kubectl, который применяет сразу несколько Kubernetes-манифестов с гарантией «всё или ничего». В отличие от обычного kubectl apply -f, он обеспечивает транзакционное поведение: если хотя бы один ресурс не применился или не стал готов, всё, что успело примениться до этого, автоматически откатывается.

https://telegra.ph/kubectl-atomic-apply-atomarnoe-primenenie-Kubernetes-manifestov-s-vozmozhnostyu-otkata-06-21

#ит_заметки #devops #kubernetes #kubectl #github

Установка и интеграция Hashicorp Vault в Kubernetes

Vault - отличный инструмент для управления секретами, который кроме всего можно еще и интегрировать с Kubernetes. В этой статье разберём, как установить Vault в Kubernetes и как связать секреты Vault с аннотациями Kubernetes.

https://telegra.ph/Ustanovka-i-integraciya-Hashicorp-Vault-v-Kubernetes-06-23

#ит_статьи #devops #kubernetes #vault #secrets

Алгоритм поиска и устранения проблем при развертывании Kubernetes

В хорошем качестве в формате PDF, и с переводом на русский язык можно скачать тут.

#ит_заметки #devops #kubernetes #cheatsheet

Поды под капотом: нюансы архитектуры Kubernetes, которые стоит знать

Если вы когда-нибудь деплоили что-то в Kubernetes, значит, вы уже сталкивались с Подами. Обычно к ним относятся как к простой обёртке для контейнеров: запустить, проверить статус и забыть. Примерно как если бы вы использовали гоночную машину только для того, чтобы съездить в магазин за продуктами.

На деле, Поды - это не просто средство "что-то запускать". Под капотом у них скрывается масса фич: от паттернов и проб до политик и отладочных инструментов, которые могут как спасти вашу инфраструктуру, так и превратить её в кошмар, если что-то пойдёт не так.

В этой статье мы пройдёмся по настоящим возможностям Подов. Тут и сайдкары, и init-контейнеры, и эфемерные контейнеры, и тюнинг ресурсов - всё, что нужно, если вы хотите выйти за рамки базового использования Kubernetes. Хотите разобраться, почему ваш сервис флапает? Или выжать из кластера максимум? Или просто понять, как работают профи? Это всё сюда.

https://telegra.ph/Pody-pod-kapotom-nyuansy-arhitektury-Kubernetes-kotorye-stoit-znat-06-30

#ит_статьи #devops #kubernetes #pod

Иерархические пространства имён в Kubernetes

В Kubernetes Namespace буквально одна из ключевых вещей. С их помощью можно изолировать ресурсы, навести порядок в кластере, задать ограничения и прокинуть нужные политики.

Пока сервисов немного - жить можно и без них. Но как только в кластер приходит несколько команд, стейджинг и куча инфраструктуры - без namespace'ов начинается хаос.

https://telegra.ph/Ierarhicheskie-prostranstva-imyon-v-Kubernetes-07-03

#ит_статьи #devops #kubernetes #namespace #hnc

Пробуем Coroot — инструмент на базе eBPF для Kubernetes и не только

В этой статье мы посмотрим на Coroot - open source-инструмент, построенный на технологии eBPF. Он предназначен для использования в Kubernetes, средах с Docker/containerd и даже в неконтейнеризованных приложениях. Coroot собирает и анализирует телеметрию (метрики, логи, трейсы и профили), превращая её в понятную информацию, с помощью которой можно быстро находить и устранять проблемы в приложениях. Мы разберёмся, как установить и настроить Coroot в Kubernetes, что он вообще делает, и заодно посмотрим на его плюсы и минусы.

https://telegra.ph/Probuem-Coroot--instrument-na-baze-eBPF-dlya-Kubernetes-i-ne-tolko-07-31-2

#ит_статьи #devops #kubernetes #eBPF #coroot

Разница между Docker ENTRYPOINT и Kubernetes container spec COMMAND

Прежде чем углубляться в детали ENTRYPOINT и COMMAND, важно сначала разобраться, как вообще устроен запуск контейнеров. Независимо от того, запускаете ли вы контейнер напрямую через Docker или работаете с ним в составе Kubernetes, вся инициализация сводится к одному - запуску команды. Именно она и станет основным процессом, который будет выполняться внутри контейнера.

В случае с Docker эта команда определяет, чем будет заниматься контейнер после запуска. Это может быть веб-сервер, какой-то скрипт или фоновый процесс. Kubernetes, хотя и использует Docker (или другие рантаймы вроде containerd), добавляет поверх этого свою логику оркестрации - и иногда это немного меняет поведение контейнера, даже если он тот же самый.

Ключевыми точками конфигурации здесь являются ENTRYPOINT в Docker и command в Kubernetes. Оба параметра определяют, что будет запущено внутри контейнера, но контекст их применения и последствия отличаются.

https://telegra.ph/Raznica-mezhdu-Docker-ENTRYPOINT-i-Kubernetes-container-spec-COMMAND-08-04

#ит_статьи #devops #docker #kubernetes #entrypoint #spec_command

DNS-хаос, зомби-поды и майнеры в кластере: самые невероятные случаи при работе с Kubernetes

Kubernetes - мощный и сложный инструмент, работа с которым неизбежно порождает… инциденты. У каждого, кто всерьёз имел дело с оркестратором, найдётся в запасе история о бессонной ночи, потраченной на поиски причин загадочного сбоя. Часто виновником выступает DNS (на этот счёт даже существует поговорка: «It’s always DNS»). Впрочем, как выясняется, DNS виновата далеко не всегда. Иногда корень зла прячется в совершенно неожиданных местах: от слишком длинного названия деплоймента до коварного физического сбоя сетевой карты на master-узле.

Reddit - настоящий кладезь таких невероятных и в то же время поучительных историй. Мы взяли одну из веток, в которой инженеры делились своими «боевыми шрамами», и выборочно перевели самые любопытные и уникальные случаи.

https://telegra.ph/DNS-haos-zombi-pody-i-majnery-v-klastere-samye-neveroyatnye-sluchai-pri-rabote-s-Kubernetes-08-04

#ит_статьи #devops #kubernetes #reddit #cluster

Типичное...

#ит_юмор #homelab #proxmox #kubernetes

Устали от классического хранилища в Kubernetes? Встречайте Longhorn

Когда мы работаем с Kubernetes, наши приложения масштабируются и перемещаются за секунды. Но есть одна фундаментальная проблема - постоянное хранилище. Как сделать так, чтобы критичные данные не потерялись из-за эфемерной природы контейнеров? Традиционные решения для хранения требуют сложной конфигурации, страдают от проблем с производительностью и, в целом, становятся настоящей головной болью для DevOps-команд.

Приложения, которым нужен доступ к сохранённым данным, требуют хранилища, которое будет высокодоступным, масштабируемым и простым в управлении. И тут на сцену выходит Longhorn. Longhorn - это облачно-нативное, распределённое блочное хранилище, созданное для упрощения постоянного хранения в Kubernetes. Это система хранения, такая же гибкая и устойчивая, как и контейнеризованные приложения. Longhorn без проблем интегрируется в среду Kubernetes и предлагает простоту, надёжность, автоматическую репликацию данных, создание снапшотов, возможности резервного копирования, самовосстановление и лёгкость в использовании.

https://telegra.ph/Ustali-ot-klassicheskogo-hranilishcha-v-Kubernetes-Vstrechajte-Longhorn-08-10

#ит_статьи #devops #kubernetes #block_storage #longhorn

Защищаем свой Kubernetes-кластер с помощью Kong OIDC и Keycloak

По мере того как наш Kubernetes-кластер растёт, вопросы аутентификации и авторизации всё больше могут превращаться в насущную проблему. Чем больше мы добавляем дашбордов и UI-инструментов, тем больше у нас копится аккаунтов и паролей, которые так или иначе приходится держать под контролем.

Типичный способ решить это - подключить Single Sign-On, например, через Keycloak. Создаём realm, клиент и переводим все наши инструменты на OAuth2.0.
Звучит просто, да? Но на деле - не особо. Проблема в том, что далеко не все инструменты из коробки поддерживают аутентификацию по OAuth2.0. А что ещё хуже - некоторые вообще не имеют никакой аутентификации.

https://telegra.ph/Zashchishchaem-svoj-Kubernetes-klaster-s-pomoshchyu-Kong-OIDC-i-Keycloak-08-17

#ит_статьи #devops #kubernetes #kong #keycloak