Прим. перев.: в очередной статье из категории «lessons learned» DevOps-инженер австралийской компании делится главными выводами по итогам продолжительного использования Kubernetes в production для нагруженных сервисов. Автор затрагивает вопросы Java, CI/CD, сетей, а также сложности K8s в целом.

Свой первый кластер Kubernetes мы начали создавать в 2017 году (с версии K8s 1.9.4). У нас было два кластера. Один работал на bare metal, на виртуальных машинах RHEL, другой — в облаке AWS EC2.

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

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

У каждого компьютера есть ОЗУ, встроенное в процессор или находящееся на отдельной подключенной к системе плате — вычислительные устройства просто не смогли бы работать без оперативной памяти. ОЗУ — потрясающий образец прецизионного проектирования, однако несмотря на тонкость процессов изготовления, память ежегодно производится в огромных объёмах. В ней миллиарды транзисторов, но она потребляет только считанные ватты мощности. Учитывая большую важность памяти, стоит написать толковый анализ её анатомии.

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

Зачем же ты, RAM-ео?

Процессорам требуется очень быстро получать доступ к данным и командам, чтобы программы выполнялись мгновенно. Кроме того, им нужно, чтобы при произвольных или неожиданных запросах не очень страдала скорость. Именно поэтому для компьютера так важно ОЗУ (RAM, сокращение от random-access memory — память с произвольным доступом).

Существует два основных типа RAM: статическая и динамическая, или сокращённо SRAM и DRAM.

Мы будем рассматривать только DRAM, потому что SRAM используется только внутри процессоров, таких как CPU или GPU. Так где же находится DRAM в наших компьютерах и как она работает?

Я довольно сильно затянул с продолжением. Частично из-за работы, частично из-за лени, частично из-за того, что задача несколько более объёмной оказалась. Но рассказывать про все поиски не буду, приведу только результаты.

Хотя для начала надо определить, что понимать под жизнью :-)



Обычно ретро-компьютеры собираются для ретро-игр. С ними, как правило, нет особых проблем (ну, кроме актуальных для той эпохи). Потому считать это «жизнью» не стоит. Я на жизнь смотрел с более повседневной точки зрения — посидеть в интернете, набрать текст, послушать музыку, посмотреть кино. Хотя, конечно, последнее зависит не столько от ОС, сколько от используемого железа. Моего туалатина должно без проблем хватать на ДВД и divx, а вот с х264 и более поздними кодеками он уже может и не справиться.

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

Многие электронщики, особенно работающие с SMD/BGA, пользуются флюсами Amtech. В основном популярны марки NC-559-ASM и RMA-223.



Одни покупают их в розничных радиомагазинах, другие заказывают по почте через популярные торговые площадки DealExtreme, eBay, AliExpress и т.п.

Наиболее дотошные владельцы шприцев/баночек с этими флюсами давно обнаружили, что рынок изобилует очевидными подделками. Например, текст на этикетке отпечатан расплывчато, слово «California» на многих этикетках напечатано как «Coliformia», встречаются и другие ошибки.

Некоторые гордо заявляют, что они используют только «оригинальный продукт», купленный у «американского продавца на eBay» и снабженный припиской «100% genuine» в заголовке (разумеется, по заметно более высокой цене). В доказательство «подлинности» приводятся голограммы, накленные на упаковку, напечатанные на этикетке «номера лотов», даты выпуска и окончания срока годности и т.п. При этом мало кого смущает, например, наличие на голограммах американского производителя китайских иероглифов рядом с надписью «Made in U.S.A.».

Известный провайдер heroku поддерживает манифест, который называется «12-факторное приложение» (Twelve-Factor App). Это набор лучших практик для разработки современных веб приложений на любой платформе. Практики описывают приложения, которые готовы:

• к горизонтальному масштабированию;
• к непрерывному развертыванию;
• к современным облачным хостингам.

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

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

Типовое условие при реализации CI/CD в Kubernetes: приложение должно уметь перед полной остановкой не принимать новые клиентские запросы, а самое главное — успешно завершать уже существующие.



Соблюдение такого условия позволяет достичь нулевого простоя во время деплоя. Однако, даже при использовании очень популярных связок (вроде NGINX и PHP-FPM) можно столкнуться со сложностями, которые приведут к всплеску ошибок при каждом деплое…

Защита pod’а от выселения при помощи Pod Disruption Budgets в Kubernetes

Это четвертая и заключительная часть нашего пути (прим. пер. — ссылка на первую статью) для достижения нулевого времени простоя при обновлении Kubernetes-кластера. В предыдущих двух частях мы фокусировались на том, как корректно выключить существующие pod’ы в кластере. Мы описали как использовать хуки preStop для корректного выключения pod’ов и почему важно добавлять задержку в процесс удаления, чтобы подождать, пока процесс удаления pod’а применится для всего кластера. Это поможет в отключении одного pod’а, но не защитит нас от выключения настолько большого количества pod’ов, что наш сервис не сможет функционировать. В этой статье мы будем использовать PodDisruptionBudgets (или PDB), для уменьшения этого риска.

Этим постом я хочу открыть ветку статей посвященную IdentityServer4. Начнем мы с основных понятий.

Самым перспективным на текущий момент протоколом аутентификации является OpenID Connect, а протоколом авторизации (предоставления доступа) является OAuth 2.0. IdentityServer4 реализует эти два протокола. Он оптимизирован для решения типичных проблем безопасности.

Про Helm и работу с ним «в общем» мы рассказали в прошлой статье. Теперь подойдём к практике с другой стороны — с точки зрения создателя чартов (т.е. пакетов для Helm). И хотя эта статья пришла из мира эксплуатации, она получилась больше похожей на материалы о языках программирования — такова уж участь авторов чартов. Итак, чарт — это набор файлов…

8 ноября в главном зале конференции HighLoad++ 2018, в рамках секции «DevOps и эксплуатация», прозвучал доклад «Базы данных и Kubernetes». В нём рассказывается о высокой доступности баз данных и подходах к отказоустойчивости до Kubernetes и вместе с ним, а также практических вариантах размещения СУБД в кластерах Kubernetes и существующие для этого решения (включая Stolon для PostgreSQL).



По традиции рады представить видео с докладом (около часа, гораздо информативнее статьи) и основную выжимку в текстовом виде. Поехали!

Есть ли среди нас (цефоводов) те, кто не любит «профессиональный экстрим»?

Вряд ли — иначе бы мы не кувыркались с этим чрезвычайно интересным и забавным продуктом.

Многие из тех, кто занимались эксплуатацией Ceph, встречали один не слишком частый (а скорее даже очень нечастый) но иногда востребованный кейс — подключить Ceph по iSCSI или FC. Зачем? Ну, например, подать образ с Ceph на почему-то еще не виртуализированный сервер Windows или Solaris. Или на виртуализированный, но посредством гипервизора, который не умеет Ceph — а их, как мы знаем, хватает. Например? Ну, например, HyperV или ESXi, которые активно используются. И если возникает задача подать образ с Ceph в гостевую машину, это превращается в весьма увлекательную задачу.

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

Цель этой статьи — рассказать о языке программирования Go (Golang) тем разработчикам, которые смотрят в сторону этого языка, но еще не решились взяться за его изучение. Рассказ будет вестись на примере реального приложения, которое представляет из себя RESTful API веб-сервис.

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

Хочу поделиться поделиться своим решением проблемы, которая указана в заголовке. Написанием статьи вдохновился от коллеги brnovk, который не поленился и предложил частичное (для меня) решение проблемы. Я сделал свой «костыль», который помог мне. Делюсь с вами.

Часть 1 Разворачиваем среду для работы с микросервисами. Часть 1 установка Kubernetes HA на bare metal (Debian)

Здравствуйте, уважаемые читатели Хабра!

В прошлой публикации я рассказал, как развернуть отказоустойчивый кластер Kubernetes. Но дело в том, что в Kubernetes удобно деплоить stateless приложения, которым не требуется сохранять свое состояние или работать с данными. Но в большинстве случаев нам требуются сохранять данные и не терять их при рестартах подов.
Для этих целей в Kubernetes используются тома (volume). Когда мы работаем с облачными решениями Kubernetes, то проблем особо нет. Нам лишь нужно у Google, Amazon или иного облачного провайдера заказать требуемый объем и, руководствуясь документаций , подключить полученные тома к подам.
Когда же мы имеем дело с bare metal, тут дела обстоят немного сложнее. Сегодня я хочу рассказать об одном из решений основанном на использовании ceph.

В данной публикации я расскажу:

• как развернуть распределенное хранилище Ceph
• как использовать Ceph при работе с Kubernetes

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

Кто везде — тот нигде. Кто проводит жизнь в странствиях, у тех в итоге гостеприимцев множество, а друзей нет.

Сенека.

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

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

«Flying Cart», Afu Chan

Я работаю в Mail.ru Cloud Solutons архитектором и разработчиком, в том числе занимаюсь нашим облаком. Известно, что распределенной облачной инфраструктуре нужно производительное блочное хранилище, от которого зависит работа PaaS-сервисов и решений, построенных с их помощью.

Изначально при развертывании такой инфраструктуры мы использовали только Ceph, но постепенно блочное хранилище эволюционировало. Хотелось, чтобы наши базы данных, файловое хранилище и различные сервисы работали с максимальной производительностью, поэтому мы добавили локализованные хранилища и наладили расширенный мониторинг Ceph.

Расскажу, как это было — возможно, эта история, проблемы, с которыми мы столкнулись, и наши решения будут полезны тем, кто тоже использует Ceph. Кстати, вот видеоверсия этого доклада.

Ubuntu потрясающая операционная система, давно не работал с Ubuntu server, а обновлять свой Desktop со стабильной версии не было смысла. И вот не давно пришлось столкнутся со свеженьким релизом Ubuntu server 18.04, моему удивлению не было предела. Когда я понял что я бесконечно отстал от жизни и не могу настроить сеть, т.к старая добрая система настройки сетевых интерфейсов по средствам редактирования файла /etc/network/interfaces канула в Лету. А что же пришло ей на смену? Что-то ужасное и на первый взгляд совершенно не понятное, встречайте «Netplan».

Прим. перев.: Ведущий инженер из компании Zalando — Henning Jacobs — не раз замечал у пользователей Kubernetes проблемы в понимании предназначения liveness (и readiness) probes и их корректного применения. Посему он собрал свои мысли в эту ёмкую заметку, которая со временем станет частью документации K8s.



Проверки состояния, известные в Kubernetes как liveness probes (т.е., дословно, «тесты на жизнеспособность» — прим. перев.), могут быть весьма опасными. Рекомендую по возможности избегать их: исключениями являются только случаи, когда они действительно необходимы и вы полностью осознаете специфику и последствия их использования. В этой публикации речь пойдет о liveness- и readiness-проверках, а также будет рассказано, в каких случаях стоит и не стоит их применять.