Kubernetes *

Привет!

Мы продолжаем рассказывать о компаниях-разработчиках, использующих технологии Microsoft в своих проектах. В сегодняшнем выпуске — компания 2ГИС, основной офис которой находится в холодном Новосибирске и к которой автор статьи питает самые теплые чувства.

2ГИС недавно закончили большой проект, используя ядром функциональности .NET Core, Kubernetes и много Linux. Я часто получаю вопросы о том, можно ли использовать .NET Core в продакшене, каков наш опыт использования его в полностью Open Source среде. Я попросил ребят рассказать, что да как. Читайте подробнее под катом, это стоит того — это один из первых публичных и больших проектов, которые построены на .NET Core, да еще и в полном Open Source вокруг.

В предыдущих статьях о dapp было рассказано про сборку приложений и про запуск в Minikube. При этом dapp запускался локально на машине разработчика. Однако инструмент задумывался для поддержки процессов непрерывной интеграции (CI) и сами мы используем его в основном в связке с GitLab. Чем dapp помогает в процессах CI/CD?

7 ноября на конференции HighLoad++ 2017, в секции «DevOps и эксплуатация» прозвучал доклад «Лучшие практики CI/CD с Kubernetes и GitLab». В нём мы делимся практическим опытом решения проблем, возникающих при построении эффективного процесса CI/CD на базе указанных Open Source-решений.

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

Kubespray (ранее Kargo) — это набор Ansible ролей для установки и конфигурации системы оркестрации контейнерами Kubernetes. В качестве IaaS в этом случае могут выступать AWS, GCE, Azure, OpenStack или обычные виртуальные машины. Проект раньше назывался Kargo. Это проект с открытым исходным кодом и открытой моделью разработки, поэтому по желанию каждый может повлиять на его жизненный цикл.

На Хабре уже писали об установке Kubernetes с помощью Kubeadm, но в этом способе есть значительные недостатки: он до сих пор не поддерживает мультимастер конфигураций и, порой, не очень гибкий. Kubespray, хоть и использует Kubeadm под капотом, уже имеет функционал обеспечения высокой доступности как для мастера, так и для etcd на этапе инсталляции. О его сравнении с другими актуальными методами установки Kubernetes можно почитать по ссылке https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md

В этой статье мы создадим 5 серверов на ОС Ubuntu 16.04. В моем случае их перечень будет следующим:

192.168.20.10 k8s-m1.me
192.168.20.11 k8s-m2.me
192.168.20.12 k8s-m3.me
192.168.20.13 k8s-s1.me
192.168.20.14 k8s-s2.me

Добавляем их к /etc/hosts всех этих серверов, в том числе локальной системы, или же к dns-серверу. Фаервол и другие ограничения в сети этих хостов должны быть деактивированы. Кроме этого, необходимо разрешить IPv4 forwarding и каждый из хостов должен иметь свободный доступ к сети Интернет для загрузки docker-образов.

Очередной релиз системы Kubernetes, 1.9, должен случиться на этой неделе. Согласно текущему плану, это произойдёт сегодня (13 декабря). Об основных новшествах, которые принесёт этот выпуск, уже известно: как и в прошлый раз, их накопилось действительно много. Представляем обзор самых значимых изменений, которые приходят в Kubernetes с грядущим релизом 1.9.

В эти дни (6-8 декабря) в США проходит местная версия конференций KubeCon + CloudNativeCon 2017, в фокусе внимания которой многочисленные проекты некоммерческой организации CNCF во главе с Kubernetes. Мероприятие собрало более 4100 посетителей, 77 % из которых используют K8s, причём в 75 % случаев речь идёт про production. Событие оказалось не только богатым на анонсы от различных стартапов и гигантов индустрии, но и стало поводом для подведения итогов Open Source-сообщества из мира cloud native — достаточно заметить, что в декабре сразу у четырёх проектов CNCF состоялся знаковый релиз 1.0. Так что новенького?

Azure Container Instances (ACI) позволяют запускать контейнеры, не беспокоясь об инфраструктуре. Мы можем дать образ контейнера, и ACI с радостью запустит контейнер и даже обеспечит внешним IP-адресом. Когда ручное вмешательство необходимо только при запуске контейнеров, это называется «беcсерверные контейнеры». ACI отлично подходит для пакетных рабочих нагрузок или долгосрочных контейнеров, где мы не хотим иметь дело с инфраструктурой.

Прим. перев.: Вторая и заключительная часть перевода материала, озаглавленного в оригинале как «What happens when… Kubernetes edition!» и рассказывающего о том, какие процессы (каких компонентов и в какой последовательности) происходят в Kubernetes на примере выполнения команды, разворачивающей в кластере 3 пода с nginx.

Если первая часть была посвящена работе kubectl, kube-apiserver, etcd и инициализаторам, то теперь речь пойдёт про контроллеры Deployments и ReplicaSets, информаторы, планировщик и kubelet. Напомню, что мы остановились на моменте, когда переданный пользователем (через kubectl) запрос был авторизован и выполнен в Kubernetes, новые объекты (ресурсы) — созданы и сохранены в базу данных (etcd), после чего — инициализированы (т.е. стали видимыми для apiserver).

Прим. перев.: Этот материал, озаглавленный в оригинале как «What happens when… Kubernetes edition!» и написанный Jamie Hannaford из компании Rackspace, является отличной иллюстрацией работы многих механизмов Kubernetes, которые зачастую скрыты от нашего глаза, но весьма полезны для лучшего понимания устройства этой Open Source-системы, алгоритма работы и взаимосвязей её компонентов. Поскольку вся статья весьма объёмна, её перевод разбит на две части. В первой речь идёт про работу kubectl, kube-apiserver, etcd и initializers.

P.S. Некоторые оригинальные ссылки на код в master-ветках были заменены на последние к моменту перевода коммиты, чтобы актуальность номеров строк, к которым отсылает автор, сохранялась долгое время.



Представим, что я хочу задеплоить nginx в кластере Kubernetes. Я введу в терминале нечто такое:

kubectl run --image=nginx --replicas=3

… и нажму на Enter. Через несколько секунд увижу 3 пода с nginx, распределённые по всем рабочим узлам. Работает — словно по волшебству, и это здорово! Но что на самом деле происходит под капотом?

Цикл историй успеха Kubernetes продолжается рассказом о британском банке-стартапе Monzo. Эту молодую компанию относят к категории «challenger banks» (да, это уже термин из Oxford Dictionary), т.е. таких небольших банков, которые бросают вызов крупной и давно сложившейся финансовой индустрии. Это становится возможным благодаря активному и повсеместному использованию современных информационных технологий в самой своей основе, т.е. отказу от операций в традиционном формате в пользу электронных аналогов, позволяющих качественно снизить расходы (банки с таким подходом ещё называют «digital-only»). Пример Monzo, созданного всего 2 года назад, интересен тем, что в достижении великих целей ему помогают платформа Kubernetes, язык Go и другие современные Open Source-продукты, хорошо знакомые DevOps-инженерам и не только.

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

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

Привет, Хабр!

Некоторое время мы присматриваемся к книгам по Kubernetes, благо, они уже выходят и в Manning, и в O'Reilly. Можно согласиться, что Kubernetes в наших краях пока интересен скорее с ознакомительной и инженерной, нежели с практической точки зрения. Однако, мы все-таки поставим здесь обложку с книги о Kubernetes и перевод статьи Дэниэла Морсинга, который сделал у себя в блоге интересный тизер об этой системе.

Приятного чтения!

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

Так родился проект loghouse, и я рад представить его альфа-версию DevOps-инженерам и системным администраторам, которым знакомы обозначенные проблемы.

Прим. перев.: Автор статьи Giancarlo Rubio — DevOps-инженер из ИТ-компании LINKIT (Нидерланды) — через онлайн-ресурс ITNEXT делится лаконичным рецептом по настройке мониторинга с Prometheus в Kubernetes с помощью Prometheus Operator. Инструкция появилась как следствие недавнего опыта выбора и внедрения системы проактивного мониторинга после миграции проекта с bare metal на облачную инфраструктуру. Рецепт отлично подходит для быстрого теоретического (первая половина статьи) и практического (вторая половина) знакомства. Для некоторых команд исправлены URL'ы, которые в оригинальном материале, по всей видимости, были преобразованы движком medium.

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

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

Вчерашний анонс официальной поддержки Kubernetes компанией Docker в своих продуктах — идеальный повод продолжить одну из наших последних публикаций, посвящённых CRI-O как альтернативному подходу к запуску контейнеров в Kubernetes. В ней уже затрагивались тема cri-containerd — своеобразного «ответа Docker» на попытки Open Source-сообщества уйти от единственного поставщика технологии для контейнеров. Чем же вызван новый поворот в жизни Docker и как его закономерность подтверждается в недавней истории проектов Moby?

В мае 2017 года онлайн-издание The New Stack проводило опрос 470 представителей организаций, которые охарактеризовали себя как пользователи контейнеров. Собранные данные были опубликованы в специальной электронной книге по Kubernetes, а ключевые полученные выводы публикуются в виде отдельных новостей на ресурсе. Последняя из них была посвящена вопросам внедрения Kubernetes, и вот что говорят полученные цифры…

Многие DevOps-инженеры и системные администраторы, особенно успевшие поработать с Kubernetes, уже слышали про проект CRI-O, озаглавленный как «легковесная исполняемая среда для контейнеров в Kubernetes». Однако зачастую представления о его назначении, возможностях и статусе весьма размыты — из-за молодости проекта, отсутствия опыта практического применения и растущего числа изменений в области стандартов для контейнеров. Эта статья — ликбез о CRI-O, рассказывающая о появлении проекта, его особенностях и актуальном статусе.