Рубрика «kubernetes» - 61

В данной статье я хочу рассказать как деплоить приложения в разные среды. В этом примере, мы будем деплоить в: «Test» и «Production». Разумеется, вы можете добавить любые среды.

Для деплоя приложений я использую HELM. Он позволяет гибко управлять конфигурациями. В чем вы сможете убедится ниже. Предполагается, что у вас уже есть настроенный runner с helm-ом и вы знаете и умеете работать с HELM-ом.

Пример файла: .gitlab-ci.yml

.base_deploy: &base_deploy
  stage: deploy
  script:
  - PROJECT_NAME="${CI_PROJECT_NAME}-${CI_ENVIRONMENT_SLUG}"
  - if [[ -z $(helm ls ${PROJECT_NAME} --deployed -q) ]]; then
        helm --namespace ${CI_ENVIRONMENT_SLUG} --name ${PROJECT_NAME} install helm --set "global.env=${CI_ENVIRONMENT_SLUG}";
      else
        helm upgrade ${PROJECT_NAME} helm --set "global.env=${CI_ENVIRONMENT_SLUG}";
      fi

stages:
  - deploy

Deploy to Test:
  <<: *base_deploy
  environment:
    name: test

Deploy to Production:
  <<: *base_deploy
  environment:
    name: production
  when: manual

Здесь стоит обратить внимание на то, что в зависимости от среды мы передаем переменную: «test» или «production».

Имя проекта мы тоже формируем с учетом имени переменной, для того, чтобы helm понимал, что это разные проекты (helm ls).

Далее, мы передаем эту переменную (среду) в HELM как: «global.env».

Для выше указанного примера helm должен находиться в одноименной папке в вашем репозиторие.
Читать полностью »

Всем добра!

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

Поехали.

В этой статье собраны рекомендации по запуску production-grade Kubernetes кластера в условиях on-premise дата-центра или периферийных локаций (edge location).
Что значит production-grade?

  • Безопасная установка;
  • Управление развертыванием осуществляется с помощью повторяющегося и записанного процесса;
  • Работа предсказуема и последовательна;
  • Можно безопасно проводить обновления и настройку;
  • Для обнаружения и диагностики ошибок и нехватки ресурсов есть логирование и мониторинг;
  • Сервис обладает достаточной “высокой доступностью” с учетом имеющихся ресурсов, включая ограничения в деньгах, физическом пространстве, мощности и тд.
  • Процесс восстановления доступен, задокументирован и протестирован для использования в случае сбоев.

Если коротко, production-grade означает предвосхищение ошибок и подготовку восстановления с минимальным количеством проблем и отсрочек.

С облаков на землю: как создать production-grade Kubernetes в любых условиях - 1Читать полностью »

Практическое знакомство с пакетным менеджером для Kubernetes — Helm - 1

Статья является логическим продолжение нашей недавней публикации об истории пакетного менеджера для Kubernetes — Helm. В этот раз мы снова затронем вопросы устройства и функционирования нынешнего Helm (версия 2.x), а также управляемых им чартов и репозиториев, после чего перейдём к практике: установке Helm в кластер Kubernetes и использованию чартов.Читать полностью »

Ох, больше года прошло с предыдущего разбора, но пришла пора возвращать традиции. Сегодня смотрим доклад Дмитрия distol Столярова «Мониторинг и Kubernetes», который был представлен в мае этого года на фестивале РИТ++, и пытаемся на его примере понять, почему людям обычно нравятся доклады Дмитрия.

Слайды (все 344 штуки) можно найти тут.
Дисклеймер: про мониторинг и Kubernetes не сама статья, а доклад, который в ней разбирается.
Читать полностью »

Прим. перев.: Автор оригинальной статьи — Nicolas Leiva — архитектор решений Cisco, который решил поделиться со своими коллегами, сетевыми инженерами, о том, как устроена сеть Kubernetes изнутри. Для этого он исследует простейшую её конфигурацию в кластере, активно применяя здравый смысл, свои познания о сетях и стандартные утилиты Linux/Kubernetes. Получилось объёмно, зато весьма наглядно.

За кулисами сети в Kubernetes - 1

Помимо того факта, что руководство Kubernetes The Hard Way от Kelsey Hightower просто работает (даже на AWS!), мне понравилось, что сеть поддерживается в чистоте и простоте; и это замечательная возможность понять, какова роль, например, Container Network Interface (CNI). Сказав это, добавлю, что сеть Kubernetes в действительности не очень-то интуитивно понятна, особенно для новичков… а также не забывайте, что «такой вещи, как сети для контейнеров, попросту не существует».Читать полностью »

Здравствуйте, коллеги.

Мы только что отдали в перевод интересную книгу Брендана Бёрнса, рассказывающую о паттернах проектирования для распределенных систем

Мониторинг кластера Kubernetes при помощи Prometheus - 1 Кроме того, у нас уже полным ходом идет перевод книги "Mastering Kubernetes" (2-е издание) и готовится к выходу в сентябре авторская книга о Docker, о которой обязательно будет отдельный пост.

Полагаем, что следующая остановка на этом пути — книга о Prometheus, поэтому сегодня предлагаем вашему вниманию перевод небольшой статьи Бьёрна Венцеля о тесном взаимодействии Prometheus и Kubernetes. Не забудьте пожалуйста поучаствовать в опросе.
Читать полностью »

Deerploy DevOps MeetUp - 1

Мы продолжаем серию технических митапов. Следующий на очереди — Deerploy DevOps MeetUp, на котором выступят специалисты от 2ГИС, Mail.ru Group, Altinity, Мамбы, Positive Technologies и, конечно, же FunCorp. Программа под катом.Читать полностью »

Что такое Istio? Это так называемый Service mesh, технология, которая добавляет уровень абстракции над сетью. Мы перехватываем весь или часть трафика в кластере и производим определенный набор операций с ним. Какой именно? Например, делаем умный роутинг, или реализуем подход circuit breaker, можем организовывать «canary deployment», частично переключая трафик на новую версию сервиса, а можем ограничивать внешние взаимодействия и контролировать все походы из кластера во внешнюю сеть. Есть возможность задавать policy правила для контроля походов между разными микросервисами. Наконец, мы можем получить всю карту взаимодействия по сети и сделать унифицированный сбор метрик полностью прозрачно для приложений.

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

Как запустить Istio, используя Kubernetes в production. Часть 1 - 1

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

Всем привет!

Сегодня расскажем об опыте одного из наших DevOps проектов. Мы решили реализовать новое приложение под Linux с использованием .Net Core на микросервисной архитектуре.

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

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

Поэтому использовали такие технологии:

  • .Net Core для реализации микросервисов. В нашем проекте использовалась версия 2.0,
  • Kubernetes для оркестрации микросервисов,
  • Docker для создания образов микросервисов,
  • шина интеграции Rabbit MQ,
  • EK для логирования,
  • TFS для реализации конвейера CI/CD.

В этой статье поделимся подробностями нашего решения.

Создание приложения на .NET Core и Kubernetes: наш опыт - 1

Это расшифровка нашего выступления на .NET-митапе, вот ссылка на видео выступления.
Читать полностью »

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

В наших решениях мы используем интеграцию и с помощью Kafka, и с помощью gRPC, и с помощью RabbitMQ.

В этой статье мы поделимся нашим опытом кластеризации RabbitMQ, ноды которого размещены в Kubernetes.

image

До RabbitMQ версии 3.7 его кластеризация в K8S была не очень тривиальной задачей, со множеством хаков и не очень красивых решений. В версии 3.6 использовался autocluster плагин из RabbitMQ Community. А в 3.7 появился Kubernetes Peer Discovery Backend. Он встроен плагином в базовую поставку RabbitMQ и не требует отдельной сборки и установки.

Мы опишем итоговую конфигурацию целиком, попутно комментируя происходящее.
Читать полностью »


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