Пользователь
Это продолжение практикума по развертыванию Kubernetes-кластера на базе облака Mail.ru Cloud Solutions и созданию MVP для реального приложения, выполняющего транскрибацию видеофайлов из YouTube.
Для запуска контейнеров платформа Kubernetes использует Container runtime, т. е. движок для контейнеров. Долгое время основным движком считался Docker, но им не ограничивался — Kubernetes также поддерживает такие движки, как CRI-O и containerd. Однако начиная с версии Kubernetes 1.20, было объявлено, что в будущих версиях поддержка Docker (а если быть точнее, то dockershim) будет полностью прекращена. Начиная с версии Kubernetes 1.24, Docker был полностью удален из Kubernetes. Одной из причин такого решения было то, что в Docker отсутствует поддержка интерфейса CRI (Container Runtime Interface). В качестве замены можно перейти на CRI-O, который позиционирует себя как легковесную исполняемую среду для контейнеров в Kubernetes. В данной статье мы рассмотрим миграцию с движка Docker на CRI-O.
Я продолжаю цикл статей по приручению домашнего сервера разработчика, который хочет уметь в DevOps. В первой своей статье я рассказал о развёртывании Xen Project гипервизора и миграции Windows-виртуалок из Hyper-V. Во второй о развёртывании на базе виртуалок этого сервера Kubernetes-кластера. Перед написанием данной я ставил перед собой следующие цели:
1. Развернуть тестовый сайт, состоящий из статических ресурсов и front-end API в vanila Kubernetes-кластере.
2. Обеспечить доступ к этому сайту с использованием NGINX Ingress Controller.
3. Сайт должен быть доступен по HTTPS-протоколу с автоматически обновляемым TLS-сертификатом Let’s Encrypt.
Вам не нужно изучать какую‑либо теорию, кроме этой статьи, чтобы начать собеседоваться. После прочтения смело приступайте к решению типовых System Design задач.
Изучая System Design, вы часто видите только теоретические материалы. В этой статье я постарался показать в том числе практическую реализацию многих вещей, чтобы вы не просто готовились к собеседованиям, но и знали, как эти вещи используются в реальном мире.
Вам не нужно изучать какую‑либо теорию, кроме этой статьи, чтобы начать собеседоваться. После прочтения смело приступайте к решению типовых System Design задач.
Изучая System Design, вы часто видите только теоретические материалы. В этой статье я постарался показать в том числе практическую реализацию многих вещей, чтобы вы не просто готовились к собеседованиям, но и знали, как эти вещи используются в реальном мире.
Всем привет. Меня зовут Добрый Кот Telegram.
В этой статье расскажем, как развернуть кластер чистыми бинарями и парочкой конфигов.
Вошли и вышли, приключение на 20 минут)
От коллектива FR-Solutions и при поддержке @irbgeo Telegram : Продолжаем серию статей о K8S.
Всем привет. Меня зовут Добрый Кот Telegram.
От коллектива FR-Solutions и при поддержке @irbgeo Telegram : Продолжаем серию статей по сертификатам k8s.
Хочу поделиться с вами некоторым мыслями на тему сертификатов в кубе.
Всем привет. Меня зовут Путилин Дмитрий (Добрый Кот) Telegram.
От коллектива FR-Solutions : Продолжаем серию статей о K8S.
В этой статье расскажем об архитектурных концептах развертывания kubernetes кластеров.
Затронем как легаси методы так и новые практики, такие как cluster-api и k8s in k8s.
Бывают случаи, когда инженеры хранят секретные данные, ключи, токены в открытом виде или в переменных Gitlab. В Kubernetes для хранения данных, которые нежелательно показывать широкому кругу лиц, предусмотрены секреты.
В этой статье предлагаю рассмотреть безопасный способ передавать, синхронизировать, интегрировать секреты напрямую из Vault в Kubernetes – с помощью метода аутентификации AppRole, используя external-secrets-operator.
Kubernetes отличная платформа как для оркестрации контейнеров так и для всего остального. За последнее время Kubernetes ушёл далеко вперёд как по части функциональности так и по вопросам безопасности и отказоустойчивости. Архитектура Kubernetes позволяет с лёгкостью переживать сбои различного характера и всегда оставаться на плаву.
Сегодня мы будем ломать кластер, удалять сертификаты, вживую реджойнить ноды и всё это, по возможности, без даунтайма для уже запущенных сервисов.
Есть колоссальная разница между тем, чтобы поднять на коленке небольшой кластерок Kubernetes на 5 воркеров для небольшого отдела разработчиков и внедрить его в виде полноценной платформы в большой компании. В домашней лаборатории или небольшом отделе вы почти не сталкиваетесь с вынужденно тяжеловесными бизнес-процессами и необходимостью заставить корректно работать вместе не только ПО разных версий, но и множество людей.
Когда мы в Газпромбанке ввязались в цифровую трансформацию, то сразу почувствовали, что в финале это будет даже близко не «Кубером с аутентификацией», как кажется многим с опытом небольших внедрений.
Если вы тоже поняли, что большие монолиты и сложные релизы не дают вам меняться с нужной скоростью, то наша история может оказаться полезной. Я попробую рассказать, на каком стеке мы выстраивали нашу платформу, про боль и унижение Open Source и о том, как работали с командой.
Всем привет! Это первая моя статья на Хабре, поэтому судите по всей строгости! Я рыскал по просторам интернетов и не нашел простой информации по созданию своими руками образа cloud-init, поэтому своими глазами изучал официальные маны и методом проб и ошибок теперь имею представление о том, как всё же запустить этот интересный и полезный инструмент!
Развитие методологий CI и CD не стоит на месте. Тем не менее, проверенные практики, вероятно, останутся актуальными и в 2025 году. В этой статье покажем некоторые из таких в действии.
Перевели статью и наглядную инфографику управляющего директора Learnk8s Daniele Polencic о корректном завершении работы подов в Kubernetes. В тексте много примеров и иллюстраций, которые помогут начинающим разобраться, как предотвратить разрыв соединений при запуске или остановке пода. В том числе для долгоживущих соединений и задач.