Рубрика «k8s» - 5

Слёрм растёт.

В Питере на Слёрм DevOps было 70 человек в зале. Москва десантировала в конференц-зал гостиницы "Севастополь" 104 человека. Очередной рекорд, который скромно подсказывает нам, что мы идём в нужном направлении. Расположились и не в тесноте, и не в обиде.

Слёрм Базовый в Москве. День Первый. Залп из СocaCola, у ведущего отобрали микрофон и поддержка бдит - 1

Перед началом Слёрма, лектор попросил выключить звук у мобильных телефонов.
А так же попросил заранее открыть баночки Колы, чтобы шипением не перебивать голос лектора. Все среагировали быстро, чётко и послушно. Такого эффекта спикер явно не ожидал. Раздался залп сотни баночек CocaCola — практически пушечный залп с борта пиратско-админского корабля. Фейерверк, знаменующий начало.

Препарировать K8S собрались три спикера — два опытных и один начинающий.

Читать полностью »

Компания-разработчик облачных решений Mirantis выкупила платформу Docker Enterprise - 1

Компания Mirantis выкупила бизнес-платформу Docker Enterprise, сообщается на официальном сайте Docker и в пресс-релизе Mirantis. Компания Mirantis специализируется на разработке собственной облачной платформы, основанной на кластерной архитектуре на базе Kubernetes. Покупка Docker Enterprise включает приобретение прав на платформу, а также всей разработки и бизнеса, связанного с этим направлением.

Сделка уже вступила в силу, и Docker Enterprise стал частью Mirantis.

Генеральный директор и соучредитель Mirantis Адриан Ионел на запрос zdnet.com по электронной почте сказал: «Мы не разглашаем условия сделки. Сделка закрывается в во вторник [12 ноября 2019 года] утром». Также он добавил:
Читать полностью »

Knative — платформа как услуга на основе k8s с поддержкой serverless - 1

Доминирующей платформой для развертывания контейнеров, несомненно, стал Kubernetes. Он предоставляет возможность управлять практически всем, используя свои API и пользовательские контроллеры, расширяющие его API посредством пользовательских ресурсов.

Тем не менее пользователь все еще должен принимать подробные решения о том, как именно разворачивать, настраивать, управлять и масштабировать приложения. На усмотрение пользователя остаются вопросы масштабирования приложения, защиты, прохождения трафика. Этим Kubernetes отличается от обычных "платформ как услуга" (PaaS), к примеру Cloud Foundry и Heroku.

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

Читать полностью »

Всем привет! Несколько месяцев назад мы запустили в продакшн наш новый open-source проект — Grafana-плагин для мониторинга kubernetes, который назвали DevOpsProdigy KubeGraf. Исходный код плагина доступен в публичном репозитории на GitHub. А в этой статье мы хотим поделиться с вами историей о том, как мы создавали плагин, какие инструменты использовали и с какими подводными камнями столкнулись в процессе разработки. Погнали!
Читать полностью »

GitLab 12.4 с улучшенными зависимостями мердж-реквестов и Audit API - 1
В GitLab 12.4 появилось несколько улучшений в сфере управления, включая Audit API, утверждение от владельца кода для защищенных веток и контроль доступа для Pages. Зависимости мердж-реквестов помогают управлять работой в командах, а другие замечательные фичи позволяют работать эффективнее и быстрее поставлять ПО лучшего качества.

Зависимости мердж-реквестов

GitLab улучшает прозрачность, совместную работу и продуктивность. Когда разработчики вместе работают над большим проектом, небольшие изменения часто нужно применять в определенной последовательности. Чтобы упросить эту задачу, функция зависимости мердж-реквестов позволяет определять зависимости в мердж-реквестах, чтобы изменения не поступали в хаотичном порядке и можно было видеть все зависимости во время ревью кода. Эта фича была представлена как зависимости мердж-реквестов между проектами в релизе 12.2, но теперь переименована в зависимости мердж-реквестов и поддерживает больше типов зависимостей. Сюда входят зависимости мердж-реквестов как между проектами, так и в одном проекте.

Мы понимаем, как важно всем управлять. Вот несколько улучшений в релизе 12.4, с которыми управление станет проще.

Читать полностью »

Распределенная трассировка в Istio - 1

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

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

В этом посте концепция распределенной трассировки будет рассмотрена через призму микросервисной архитектуры: как это все интегрируется и автоматизируется через Istio, а затем весь процесс упрощается и обрабатывается через Backyards — наш сервисный продукт для Istio.
Читать полностью »

К CI-CD и Kubernetes GitLab шел необычным путем - 1

Как наша команда Delivery, используя только собственные ресурсы, переделала нашу систему под CI/CD.

Команды инженеров постоянно испытывают давление: нужно выдавать новые функции в виде достойного продукта и при этом постоянно минимизировать время цикла. Зачастую специалисты не думая хватаются за современный инструментарий. Непрерывная интеграция и поставка (CI/CD) встроены в GitLab, наше единственное приложение для жизненного цикла DevOps, и сейчас мы, чтобы еще больше сократить время цикла, всем составом мигрируем на Kubernetes. Однако к CI/CD — и в конечном итоге Kubernetes — мы шли не совсем обычным путем. Команда Delivery, переводя нас на непрерывную поставку GitLab.com, напрягла старую систему, и только потом мы полностью перешли на Kubernetes.

Читать полностью »

Подготовка приложения для Istio - 1

Istio — это удобный инструмент для соединения, защиты и мониторинга распределенных приложений. В Istio используются разные технологии для масштабного запуска ПО и управления им, включая контейнеры для упаковки кода приложения и зависимостей для развертывания и Kubernetes — для управления этими контейнерами. Поэтому для работы с Istio вы должны знать, как приложение с несколькими сервисами на основе этих технологий работает без Istio. Если эти инструменты и понятия вам уже знакомы, смело пропускайте это руководство и переходите прямо к разделу Установка Istio на Google Kubernetes Engine (GKE) или установке расширения Istio on GKE.

Это пошаговое руководство, где мы рассмотрим весь процесс от исходного кода до контейнера на GKE, чтобы вы получили базовое представление об этих технологиях на примере. Также вы увидите, как Istio использует возможности этих технологий. Предполагается, что вы не знаете ничего о контейнерах, Kubernetes, service mesh или Istio.

Читать полностью »

Разбор: ООМ на узле Kubernetes - 1

Проблемы в производственной среде — это всегда беда. Происходят именно тогда, когда уходишь домой, а причина всегда кажется глупой. Недавно у нас на узлах в кластере Kubernetes закончилась память, правда узел тут же восстановился, без видимых прерываний. Сегодня мы расскажем об этом случае, о том, какой урон мы понесли и как намерены избегать подобной проблемы в будущем.

Случай первый

Суббота, 15 июня 2019 г., 17:12

Читать полностью »

Лучшие практики для контейнеров Kubernetes: проверки работоспособности - 1
TL;DR

  • Чтобы добиться высокой наблюдаемости контейнеров и микросервисов, журналов и первичных метрик мало.
  • Для более быстрого восстановления и повышения отказоустойчивости приложения должны применять Принцип высокой наблюдаемости (HOP, High Observability Principle).
  • На уровне приложение для НОР требуется: должное журналирование, тщательный мониторинг, проверки работоспособности и трассировки производительности/переходов.
  • В качестве элемента НОР используйте проверки readinessProbe и livenessProbe Kubernetes.Читать полностью »

https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js