Для всех, кто хостит свои сайты, актуальна проблема продления доменного имени - если пропустить срок истечения регистрации, то можно на ровном месте получить кучу проблем. Для своевременного продления регистрации нужно отслеживать срок истечения.
Для небольшого количества доменов будет достаточно завести напоминание в календаре, но если доменов много - следует автоматизировать этот процесс.
Weave Scope — Open Source-утилита для контроля за микросервисными приложениями, развернутыми в Docker и Kubernetes. Утилита визуализирует топологию приложения на уровне контейнеров, помогает находить проблемы и оптимизировать архитектуру. Управление организовано через простой веб-интерфейс; командная строка нужна только для установки и запуска приложения.
Weave Scope можно использовать бесплатно на локальном сервере. Также есть платная SaaS-версия. Создатели Weave Scope — компания Weaveworks, которая известна и другими популярными cloud native-решениями (например, Cortex и Flux).
Чтобы продемонстрировать возможности Weave Scope, развернем утилиту на хосте, потом в кластере Kubernetes, после чего попробуем подключить один из готовых плагинов, который расширяет базовую функциональность Weave Scope.
В статье — варианты использования расширенного планирования подов в Kubernetes, а также передовые методы его применения на практике. Информация пригодится разработчикам приложений и администраторам K8s, чтобы реализовать расширенные шаблоны развёртывания приложений, в которых есть локальность данных, совместное размещение модулей, высокая доступность и эффективное использование ресурсов кластеров K8s.
В прошлом посте мы начали говорить о проблематике резервного копирования в контейнерных средах на базе Kubernetes. Тогда мы подробно рассмотрели реализацию систем резервного копирования (СРК) на базе внутрикластерных решений, таких как Kasten. Сегодня мы продолжаем эту тему и рассматриваем сценарий внешнего резервного копирования на примере продукта Commvault Backup & Recovery.
В статье представлен пример использования системы создания и проверки подписей образов Docker Content Trust и интеграции в Kubernetes с использованием сервера Notary и специализированного Admission Controller - Connaisseur.
Представлен теоретический обзор на используемые инструменты и практический пример интеграции с шагами и примерами конфигурации.
DevOps-инженер Константин Кулишов рассказал, как создал свой ChatOps, чтобы дать разработчикам возможность вносить изменения в проект в любое время. Константин выложил ChatOps на GitHub и подробно описал процесс создания.
У многих сочетание понятий «контейнеры» и «резервное копирование» вызывает недоумение. Зачем бэкапить те сущности, которые были созданы специально для быстрого развертывания и уничтожения? Однако в мире ИТ больших компаний такая «странность» необходима. Расскажем о ситуациях, когда резервные копии оказываются полезны, и подробно разберем бэкап двумя способами: с помощью Kasten — решения, установленного внутри кластера Kubernetes, — и внешнего CommVault. Но чтобы не cмешивать всё в одном посте, начнем с Kasten. Поехали!
Kubernetes стал стандартом для запуска микросервисных (и не только) приложений. Компании разных размеров — от стартапов до enterprise — стараются проектировать свои приложения готовыми для запуска в Kubernetes-кластере.
А для запуска приложения в K8s обычно используют Helm-шаблоны с описанием манифестов. Хотя формат шаблонов легко читается и прост в изучении, он может вызвать определенные сложности, когда логика деплоя приложения разрастается, когда создаются дополнительные тестовые контуры (с деплоем только отдельных частей приложения) и т.д. При активном использовании Go-шаблонов рефакторинг манифестов может превратиться в нетривиальную задачу*.
Что делать, если у разработчиков нет времени разбираться со всеми тонкостями Helm-шаблонов, синтаксисом YAML и Go templates, но нужно запустить приложение в Kubernetes? Ответом на этот вопрос может стать использование cdk8s.
Мы активно деплоим свои приложения в Kubernetes и используем HTTP-пробы для сервисов. Однако решили провести эксперимент с exec-пробами и… положили на лопатки кластер! Как так? Ведь именно exec пробы первыми описываются во всех руководствах и книгах по Kubernetes, включая официальные! Что же не так?
Вот вам свежая информация о граблях, которая может вас уберечь от потенциальных проблем и необдуманных решений. А в конце статьи – что же не так с HTTP-пробами и зачем мы вообще экспериментировали с exec-ом.
В предыдущем блоге мы изучили основы Kubernetes и провели семинар-тренинг с использованием установки Minikube на CentOs. Сейчас мы узнаем, как использовать Kubernetes на Google Cloud Platform, Microsoft Azure и Amazon Web Services.
В преддверии запуска Вечерней школы по Kubernetes, в этот раз для разработчиков, подготовили интервью с Павлом Селивановым архитектором в Mail.ru Cloud Solutions и Марселем Ибраевым CTO Слёрма. Речь пойдет о том, какие конкретно знания нужны разработчику в компаниях с Kubernetes, Павел и Марсель поделятся кейсами из своей практики.
... а также 5 вопросов, чтобы проверить, насколько успешно у вас идет цифровая трансформация.
Подборка новых шпаргалок, вебинаров, свежих статей и полезных книг в самом полезном дайджесте на просторах #Хабр! Оставайтесь с нами – станьте частью DevNation!
Привет, Хабр! Поговорим о возможностях микросервисной архитектуры и о том, как избежать миллионных трудозатрат на управление жизненным циклом контейнеров?
Развернуть кластер Kubernetes можно легко и быстро. Но чем больше становится приложений, построенных на микросервисной архитектуре, чем они сложнее, тем больше ресурсов и компетенций нужно для управления. А некоторые задачи решить «вручную» просто невозможно. Управление контейнерной инфраструктурой и жизненным циклом контейнеров в мультиоблачной среде оборачивается миллионными трудозатратами.
Встретимся 14 сентября на онлайн-митапе «Не 1 на 1 с Kubernetes: как упростить управление контейнерами». Расскажем, как преодолеть основные препятствия при переходе к микросервисной архитектуре с помощью продуктов семейства VMware Tanzu.
Соберем экспертов КРОК и VMware в области виртуализации и развития бизнеса, чтобы подойти к вопросу комплексно. Обсудим технические особенности решения, его влияние на управление инфраструктурой, разработку и бизнес в целом. Развеем популярные мифы и поделимся опытом реальных внедрений в крупнейших компаниях.
Интересно? Регистрируйтесь по ссылке:
Kubernetes произвел настоящую революцию в распределенных вычислениях. Хотя он решает ряд сверхсложных проблем, появляются и новые вызовы. Одна из таких проблем - обеспечение того, чтобы кластеры Kubernetes были спроектированы с учетом доменов отказов. Проектирование с учетом доменов отказов включает в себя такие аспекты, как предоставление инфраструктуры в зонах доступности, обеспечение того, чтобы физические серверы находились на разных стойках, также необходимо убедиться, что поды, поддерживающие ваше приложение, не окажутся в одном и том же физическом воркере Kubernetes.
Для решения последней задачи можно использовать правила совместного или раздельного существования между подами (inter-pod affinity and anti-affinity rules), и в официальной документации Kubernetes они описаны очень хорошо:
“Сходство между подами (inter-pod affinity) и анти-сходство (anti-affinity) позволяет вам ограничивать, на каких узлах может быть запланирован ваш под, основываясь на метках подов, которые уже запущены на узле, а не на основе меток на узлах. Правила имеют вид "этот под должен (или, в случае anti-affinity, не должен) работать на узле X, если на этом X уже работает один или несколько подов, удовлетворяющих правилу Y". Y выражается как LabelSelector с опциональным ассоциированным списком пространств имен; в отличие от узлов, поскольку поды разделены по именам (и поэтому метки на поды также неявно разделены по именам), селектор меток должен указать, к каким пространствам имен он должен применяться. Концептуально X - это домен топологии, такой как узел, стойка, зона облачного провайдера, регион облачного провайдера и т. д. Вы выражаете его с помощью topologyKey, который является ключом для метки узла, используемой системой для обозначения такого топологического домена; например, см. ключи меток, перечисленные выше в разделе "Интерлюдия: встроенные метки узлов".
Kalm — бесплатное приложение с открытым исходным кодом. Представляет собой стандартный контроллер Kubernetes, который можно установить в любой кластер (версии v1.15 и выше), включая Amazon EKS и Google GKE. Основная цель Kalm — предоставить разработчикам простой пользовательский интерфейс, чтобы упростить работу с K8s.
В этой статье я кратко расскажу о своих любимых инструментах для Kubernetes, уделяя особое внимание новейшим и малоизвестным, которые, как мне кажется, скоро станут популярными.
В основе этого списка — мой личный опыт, и чтобы избежать предвзятости, я расскажу и об альтернативных инструментах, чтобы вы могли всё сравнить и принять решение, исходя из своих потребностей. Постараюсь дать информацию сжато и привести источники, чтобы при желании вы могли изучить всё самостоятельно. Описывая инструменты для различных задач разработки ПО, я хотел ответить на вопрос: «Как я могу сделать X в Kubernetes?»
Мы в KTS на многих проектах пользуемся услугами managed database от selectel. За этими кластерами нужно следить, и делать это хотелось бы из одной точки. Этой точкой у нас является prometheus, alertmanager и grafana.
Из коробки у selectel нет prometheus exporter для manage-баз данных. Есть внутренние графики и мониторинг, но использовать их затруднительно. Поэтому мы написали свой selectel-exporter, который использует selectel API.
В статье расскажем, почему решили его написать и расскажем, что он умеет.
В одном из проектов мне пришлось столкнуться с классической ситуацией: нагрузка со стороны приложения на реляционную БД была чрезвычайно высока из-за большого RPS (requests per second). Однако реальный процент уникальных данных, извлекаемых приложением из БД, был относительно невелик. К тому же, медленный ответ БД порождал рост числа подключений к ней со стороны приложения — это еще больше увеличивало нагрузку и вызвало эффект снежного кома.
Выбранное решение для этой проблемы закономерно: кэширование данных. В роли кэша выступило хранилище memcached, которое приняло на себя основную нагрузку от запросов на получение данных. Однако при переезде приложения в Kubernetes возникли сложности…
Прошло уже 8 месяца времени с момента первой и пока единственной статьи о инструменте для композинга helm чартов – helmwave.
Что появилось нового? Какие планы?
Сегодня мы поговорим об Azure DevOps и процессах непрерывной интеграции/развертывания.
Можно использовать множество функций, которые интегрированы с Azure DevOps. Если подходить ко всему "как к коду" для развертывания, то вместо классического Azure DevOps в качестве решения можно применить Azure DevOps yaml deployment. В этом примере будет рассказано о шагах по развертыванию в среде kubernetes.
Во-первых, для развертываний Kubernetes можно управлять версиями во время миграций с помощью шаблона helm, а затем вы можете включить независимые от среды миграции, изменив файл values.yaml в шаблоне helm для каждого приложения и среды.
