Я Дмитрий Лазаренко, руковожу командой, создающей и внедряющей собственный Kubernetes aaS на платформе Mail.ru Cloud Solutions. Давно работая с внедрением Kubernetes, мы часто сталкиваемся с недопониманием нюансов этой технологии. Хочу рассказать о типичных стратегических просчетах при внедрении Kubernetes в крупных проектах.
Kubernetes объявил Docker устаревшим и планирует прекратить его использование примерно через год, в версии 1.22 или 1.23. Эта новость вызвала много вопросов и непонимания. В блоге Kubernetes появилось целых две статьи, разъясняющих смысл записи в Changelog (раз и два). Если все обобщить, то для разработчиков (те, которые Dev) ничего не меняется — они все так же могут продолжать использовать docker build для сборки своих контейнеров, а вот для инженеров, ответственных за эксплуатацию кластера (OpsЧитать полностью »
Команда Kubernetes aaS от Mail.ru Group продолжает серию переводов о правильном использовании Kubernetes. В этот раз — об антипаттернах разработки на Kubernetes с рекомендациями, как сделать по-другому.
Настроить хранение данных приложений, запущенных в кластере Kubernetes, можно несколькими способами. Одни из них уже устарели, другие появились совсем недавно. В этой статье рассмотрим концепцию трёх вариантов подключения СХД, в том числе самый последний — подключение через Container Storage Interface.
Начав экспериментировать с Kubernetes, многие сталкиваются с одним из самых больших заблуждений: они считают в проде K8s будет работать так же, как и в среде разработки или тестирования.
Не будет.
Когда речь заходит о Kubernetes, и вообще о контейнерах и микросервисах, существует большая разница между запуском в «лабораторных» условиях и в полноценной эксплуатации. Такая же разница, как между просто запуском и запуском с обеспечением безопасности и надёжности.
Если спросить опытного многомудрого инженера, что он думает о cert-manager и почему все им пользуются, то спец вздохнёт, доверительно обнимет и устало скажет: «Все им пользуются, потому что нет альтернатив вменяемых. Наши мыши плачут, колются, но продолжают жить с этим кактусом. Почему любим? Потому что работает. Почему не любим? Потому что постоянно выходят новые версии, которые используют новые фичи. И приходится раз за разом обновлять кластер. А старые версии перестают работать, потому что заговор есть и великое таинственное шаманство».
Но разработчики уверяют, что с cert-manager 1.0 всё изменится.
Поверим?
Спешим поделиться новостью, что Contour размещён в инкубаторе проектов от Cloud Native Computing Foundation (CNCF).
Если вы еще не слышали о Contour — это простой и масштабируемый ingress controller с открытым исходным кодом для маршрутизации трафика к приложениям, запущенным в Kubernetes.
Мы подробно рассмотрим, как он работает, покажем «дорожную карту» развития на предстоящих конференциях Kubecon и CloudNativeCon Europe.
А в этой статье предлагаем ознакомиться с работой Contour. Поясним, что означает принятие проекта в CNCF. А также поделимся планами на будущее развитие проекта.
Конференции KubeCon и CloudNativeCon собирают приверженцев передовых технологий и инженеров, заинтересованных не только в дальнейшем обучении, но и продвижении облачных вычислений. В мероприятиях участвуют эксперты-практики и ключевые разработчики популярных проектов, таких как Kubernetes, Prometheus, gRPC, Envoy, OpenTracing и других.
Если вы применяли в работе предыдущие выпуски Kubernetes — тот же 1.16 — вы, возможно, видели странное предупреждение от kubectl run.
До недавнего времени этой командой можно было сгенерировать объекты для развертывания или YAML из командной строки. Начиная с Kubernetes 1.18 такая возможность была сломана весьма удивительным образом. В статье будут ответы на вопросы «Почему?» и «Как дальше с этим жить?»
В современном мире Kubernetes-облаков, так или иначе, приходится сталкиваться с ошибками в программном обеспечении, которые допустил не ты и не твой коллега, но решать их придется тебе. Данная статья, возможно, поможет новичку в мире Golang и Kubernetes понять некоторые способы отладки своего и чужого софта.
Меня зовут Виктор Ягофаров, я занимаюсь развитием Kubernetes-облака в компании ДомКлик, и сегодня хочу рассказать о том как мы решили проблему с одним из ключевых компонентов нашего production k8s (Kubernetes) кластера.
В нашем боевом кластере (на момент написания статьи):
Слёрму полтора года. Шесть интенсивов только по базовому курсу Kubernetes, плюс Мега, DevOps, SRE и Agile — более тысячи участников.
7 апреля стартует «Вечерняя школа Слёрма: базовый курс по Kubernetes», рассчитанная на 4 месяца занятий по вечерам (бесплатные вебинары по теории и платная практика). В мае пройдет седьмой Слёрм по Kubernetes (онлайн-интенсив, «как офлайн, только онлайн»). Будет всё «по-оффлайновому»: с голосовым чатом, видеосвязью, «курилкой» в зуме, групповой работой, выделенными наставниками и техподдержкой.
Мы заявляем, что Слёрм открывает путь к проектам на Kubernetes и росту зарплаты. Так ли это на самом деле?
Мы задали этот вопрос выпускникам Слёрмов. Полтора года — достаточный срок, чтобы стали заметными изменения в карьере, зарплате, работе и сфере задач.
Что важно понимать про этот опрос? Тут есть «ошибка выжившего»: нам ответили те, кто следит за чатом своего Слёрма и готов общаться. Наверняка есть те, кому Слёрм оказался бесполезен, и они молчат об этом. Жизнь меняется: те, кто начал работать с Kubernetes год назад, были в другом положении, чем те, кто начинает сейчас. Это работает в обе стороны: стать архитектором решений сейчас куда сложнее, а найти место джуниора куда проще.
Тем не менее, ответы вполне показательны. По ним можно понять, ради чего стоит проходить Слёрмы.
Карантин — хороший повод поинтересоваться, как там дела в других бункерах на Пустошах, кто какие технологии использует вместе с Kubernetes, что собирается изучать ещё и в какую сторону двигается, не вставая с кресла. Quarantine. Quarantine Never Changes.
