Павел Селиванов, архитектор решений Southbridge и преподаватель Слёрма, выступил с докладом на DevOpsConf 2019. Этот доклад — часть одной из тем углубленного курса по Kubernetes «Слёрм Мега».

Слёрм Базовый: введение в Kubernetes проходит в Москве 18-20 ноября.
Слёрм Мега: заглядываем под капот Kubernetes — Москва, 22-24 ноября.
Слёрм Онлайн: оба курса по Kubernetes доступен всегда.

Под катом — расшифровка доклада.

Мы уже писали о «консольных помощниках» для Kubernetes год назад, а ещё раньше делали обзор других полезных утилит. Однако с развитием K8s и его сообщества претерпевает изменения и сопутствующая экосистема. Поэтому нам снова есть о чём рассказать любителям консоли. Поехали!

Прим. перев.: Статья написана Javier Salmeron — инженером из хорошо известной в Kubernetes-сообществе компании Bitnami — и была опубликована в блоге CNCF в начале августа. Автор рассказывает о самых основах механизма RBAC (управление доступом на основе ролей), появившегося в Kubernetes полтора года назад. Материал будет особенно полезным для тех, кто знакомится с устройством ключевых компонентов K8s (ссылки на другие подобные статьи см. в конце).


Слайд из презентации, сделанной сотрудником Google по случаю релиза Kubernetes 1.6

Многие опытные пользователи Kubernetes могут вспомнить релиз Kubernetes 1.6, когда авторизация на основе Role-Based Access Control (RBAC) получила статус бета-версии. Так появился альтернативный механизм аутентификации, который дополнил уже существующий, но трудный в управлении и понимании, — Attribute-Based Access Control (ABAC). Все с восторгом приветствовали новую фичу, однако в то же время бесчисленное число пользователей были разочарованы. StackOverflow и GitHub изобиловали сообщениями об ограничениях RBAC, потому что большая часть документации и примеров не учитывали RBAC (но сейчас уже всё в порядке). Эталонным примером стал Helm: простой запуск helm init + helm install больше не работал. Внезапно нам потребовалось добавлять «странные» элементы вроде ServiceAccounts или RoleBindings ещё до того, как разворачивать чарт с WordPress или Redis (подробнее об этом см. в инструкции).

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



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

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

Прим. перев.: Оригинал этой статьи был опубликован в официальном блоге Kubernetes и написан Andrew Martin — одним из основателей молодой британской компании Control Plane, специализирующейся на безопасности для cloud native-приложений, запускаемых в K8s.



Безопасность в Kubernetes прошла длинный путь с момента появления проекта, однако в ней по-прежнему встречаются подводные камни. Предлагаем список полезных рекомендаций по тому, как защитить кластеры и повысить их устойчивость в случае взлома: начнём с control plane, продолжим с рабочими нагрузками и сетевой безопасностью, а закончим оценкой будущего безопасности.

Итак, у вас есть кластер Kubernetes, а для проброса внешнего трафика сервисам внутри кластера вы уже настроили Ingress-контроллер NGINX, ну, или пока только собираетесь это сделать. Класс!

Я тоже через это прошел, и поначалу все выглядело очень просто: установленный NGINX Ingress-контроллер был на расстоянии одного helm install. А затем оставалось лишь подвязать DNS к балансировщику нагрузки и создать необходимые Ingress-ресурсы.

Спустя несколько месяцев весь внешний трафик для всех окружений (dev, staging, production) направлялся через Ingress-серверы. И все было хорошо. А потом стало плохо.

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

Еще примерно год назад я наткнулся на статью «50 инструментов для автоматизации облачной ифраструктуры» в котором описывались инструменты для работы с виртуализацией и в нем промелькнул инструмент под названием Quadstor. И недавно, наконец-то дошли руки до этого замечательного софта, и теперь хочу немного о нем рассказать, что это такое и с чем его едят!
Quadstor — это виртуализация хранилищ которая работает на основе iSCSI. quadstor.com

И так, что он умеет:

1. Поддержка виртуальных дисков по Fibre Channel, iSCSI или локально.
2. Тонкие диски (Thin Provisioning)
3. Дедупликация данных
4. Высокая доступность (High Availability)
5. Поддержка VAAI (Hardware Acceleration)
6. Поддержка кластеров Windows server 2012, Hyper-V, VMware
7. Поддержка ZFS
8. И самое основное — он бесплатный (ну а поддержка за деньги).
9. Размер виртуального диска до 64Тб.

Disclamer: jehy опубликовал интересную статью — «Чем плохо быть full stack разработчиком».
Проблема, которую затрагивает автор, на самом деле гораздо шире чем мир разработки. Мы, скромные администраторы, испытываем такие же проблемы. Прочитав ее я не удержался, чтобы не сделать маленькую пародию, спроецировав, порою дословно, ее на мир системного администрирования.

Введение

Прежде всего определимся с терминами. Есть много разных представлений о том, кто же такой full stack администратор, кто-то даже обоснованно считает, что такой администратор – это миф, но в этой статье будет иметься в виду администратор, который обладает знаниями и умениями, позволяющими разобраться в ИТ-инфраструктуре «от» и «до» и при необходимости обслужить любую систему. Идеальный enterprise администратор это тот, кто владеет в какой-то мере как сетевой составляющей, так и системами хранения данных, платформами виртуализации и другими продуктами, может сам диагностировать, на каком уровне возникла неисправность или что потребуется для запуска нового сервера.

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

Уважаемое хабрасообщество, позвольте представить вашему вниманию на мой взгляд очень полезный инструмент — Netdot (Network Documentation Tool). Поиск по Хабру не выдал ни одного упоминания этого интересного инструмента. Русскоязычные информационные ресурсы тоже обошли его стороной. Я надеюсь, что мой небольшой обзор станет полезным сетевым администраторам.

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



Наша система мониторинга преследует несколько целей:

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

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