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

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

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

1. Подготовка к работе

Если вы хотите самостоятельно опробовать то, о чём тут пойдёт речь, загрузите набор данных Anime Recommendations Database с Kaggle. Распакуйте его и поместите в ту же папку, где находится ваш Jupyter Notebook (далее — блокнот).

Теперь выполните следующие команды.

import pandas as pd import numpy as np anime = pd.read_csv('anime-recommendations-database/anime.csv') rating = pd.read_csv('anime-recommendations-database/rating.csv') anime_modified = anime.set_index('name') 

После этого у вас должна появиться возможность воспроизвести то, что я покажу в следующих разделах этого материала.

2. Импорт данных

▍Загрузка CSV-данных

Здесь я хочу рассказать о преобразовании CSV-данных непосредственно в датафреймы (в объекты Dataframe). Иногда при загрузке данных формата CSV нужно указывать их кодировку (например, это может выглядеть как encoding='ISO-8859–1'). Это — первое, что стоит попробовать сделать в том случае, если оказывается, что после загрузки данных датафрейм содержит нечитаемые символы.

anime = pd.read_csv('anime-recommendations-database/anime.csv') 

Загруженные CSV-данные

Существует похожая функция для загрузки данных из Excel-файлов — pd.read_excel.

▍Создание датафрейма из данных, введённых вручную

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

df = pd.DataFrame([[1,'Bob', 'Builder'],                   [2,'Sally', 'Baker'],                   [3,'Scott', 'Candle Stick Maker']],  columns=['id','name', 'occupation']) 

Данные, введённые вручную

▍Копирование датафрейма

Копирование датафреймов может пригодиться в ситуациях, когда требуется внести в данные изменения, но при этом надо и сохранить оригинал. Если датафреймы нужно копировать, то рекомендуется делать это сразу после их загрузки.

anime_copy = anime.copy(deep=True) 

Копия датафрейма

3. Экспорт данных

▍Экспорт в формат CSV

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

rating[:10].to_csv('saved_ratings.csv', index=False) 

Экспортировать данные в виде Excel-файлов можно с помощью функции df.to_excel.

4. Просмотр и исследование данных

▍Получение n записей из начала или конца датафрейма

Сначала поговорим о выводе первых n элементов датафрейма. Я часто вывожу некоторое количество элементов из начала датафрейма где-нибудь в блокноте. Это позволяет мне удобно обращаться к этим данным в том случае, если я забуду о том, что именно находится в датафрейме. Похожую роль играет и вывод нескольких последних элементов.

anime.head(3) rating.tail(1) 

Данные из начала датафрейма

Данные из конца датафрейма

▍Подсчёт количества строк в датафрейме

Функция len(), которую я тут покажу, не входит в состав pandas. Но она хорошо подходит для подсчёта количества строк датафреймов. Результаты её работы можно сохранить в переменной и воспользоваться ими там, где они нужны.

len(df) #=> 3 

▍Подсчёт количества уникальных значений в столбце

Для подсчёта количества уникальных значений в столбце можно воспользоваться такой конструкцией:

len(ratings['user_id'].unique()) 

▍Получение сведений о датафрейме

В сведения о датафрейме входит общая информация о нём вроде заголовка, количества значений, типов данных столбцов.

anime.info() 

Сведения о датафрейме

Есть ещё одна функция, похожая на df.info — df.dtypes. Она лишь выводит сведения о типах данных столбцов.

▍Вывод статистических сведений о датафрейме

Знание статистических сведений о датафрейме весьма полезно в ситуациях, когда он содержит множество числовых значений. Например, знание среднего, минимального и максимального значений столбца rating даёт нам некоторое понимание того, как, в целом, выглядит датафрейм. Вот соответствующая команда:

anime.describe() 

Статистические сведения о датафрейме

▍Подсчёт количества значений

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

anime.type.value_counts() 

Подсчёт количества элементов в столбце

5. Извлечение информации из датафреймов

▍Создание списка или объекта Series на основе значений столбца

Это может пригодиться в тех случаях, когда требуется извлекать значения столбцов в переменные x и y для обучения модели. Здесь применимы следующие команды:

anime['genre'].tolist() anime['genre'] 

Результаты работы команды anime[‘genre’].tolist()

Результаты работы команды anime[‘genre’]

▍Получение списка значений из индекса

Поговорим о получении списков значений из индекса. Обратите внимание на то, что я здесь использовал датафрейм anime_modified, так как его индексные значения выглядят интереснее.

anime_modified.index.tolist() 

Результаты выполнения команды

▍Получение списка значений столбцов

Вот команда, которая позволяет получить список значений столбцов:

anime.columns.tolist() 

Результаты выполнения команды

6. Добавление данных в датафрейм и удаление их из него

▍Присоединение к датафрейму нового столбца с заданным значением

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

anime['train set'] = True 

▍Создание нового датафрейма из подмножества столбцов

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

anime[['name','episodes']] 

Результат выполнения команды

▍Удаление заданных столбцов

Этот приём может оказаться полезным в том случае, если из датафрейма нужно удалить лишь несколько столбцов. Если удалять нужно много столбцов, то эта задача может оказаться довольно-таки утомительной, поэтому тут я предпочитаю пользоваться возможностью, описанной в предыдущем разделе.

anime.drop(['anime_id', 'genre', 'members'], axis=1).head() 

Результаты выполнения команды

▍Добавление в датафрейм строки с суммой значений из других строк

Для демонстрации этого примера самостоятельно создадим небольшой датафрейм, с которым удобно работать. Самое интересное здесь — это конструкция df.sum(axis=0), которая позволяет получать суммы значений из различных строк. 

df = pd.DataFrame([[1,'Bob', 8000],                   [2,'Sally', 9000],                   [3,'Scott', 20]], columns=['id','name', 'power level']) df.append(df.sum(axis=0), ignore_index=True) 

Результат выполнения команды

Команда вида df.sum(axis=1) позволяет суммировать значения в столбцах.

Похожий механизм применим и для расчёта средних значений. Например — df.mean(axis=0).

7. Комбинирование датафреймов

▍Конкатенация двух датафреймов

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

В данном примере мы сначала разделяем датафрейм на две части, а потом снова объединяем эти части:

df1 = anime[0:2] df2 = anime[2:4] pd.concat([df1, df2], ignore_index=True) 

Датафрейм df1

Датафрейм df2

Датафрейм, объединяющий df1 и df2

▍Слияние датафреймов

Функция df.merge, которую мы тут рассмотрим, похожа на левое соединение SQL. Она применяется тогда, когда два датафрейма нужно объединить по некоему столбцу.

rating.merge(anime, left_on=’anime_id’, right_on=’anime_id’, suffixes=(‘_left’, ‘_right’)) 

Результаты выполнения команды

8. Фильтрация

▍Получение строк с нужными индексными значениями

Индексными значениями датафрейма anime_modified являются названия аниме. Обратите внимание на то, как мы используем эти названия для выбора конкретных столбцов.

anime_modified.loc[['Haikyuu!! Second Season','Gintama']] 

Результаты выполнения команды

▍Получение строк по числовым индексам

Эта методика отличается от той, которая описана в предыдущем разделе. При использовании функции df.iloc первой строке назначается индекс 0, второй — индекс 1, и так далее. Такие индексы назначаются строкам даже в том случае, если датафрейм был модифицирован и в его индексном столбце используются строковые значения.

Следующая конструкция позволяет выбрать три первых строки датафрейма:

anime_modified.iloc[0:3] 

Результаты выполнения команды

▍Получение строк по заданным значениям столбцов

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

anime[anime['type'].isin(['TV', 'Movie'])] 

Результаты выполнения команды

Если нас интересует единственное значение — можно воспользоваться такой конструкцией:

anime[anime[‘type’] == 'TV'] 

▍Получение среза датафрейма

Эта техника напоминает получение среза списка. А именно, речь идёт о получении фрагмента датафрейма, содержащего строки, соответствующие заданной конфигурации индексов.

anime[1:3] 

Результаты выполнения команды

▍Фильтрация по значению

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

anime[anime['rating'] > 8] 

Результаты выполнения команды

9. Сортировка

Для сортировки датафреймов по значениям столбцов можно воспользоваться функцией df.sort_values:

anime.sort_values('rating', ascending=False) 

Результаты выполнения команды

10. Агрегирование

▍Функция df.groupby и подсчёт количества записей

Вот как подсчитать количество записей с различными значениями в столбцах:

anime.groupby('type').count() 

Результаты выполнения команды

▍Функция df.groupby и агрегирование столбцов различными способами

Обратите внимание на то, что здесь используется reset_index(). В противном случае столбец type становится индексным столбцом. В большинстве случаев я рекомендую делать то же самое.

anime.groupby(["type"]).agg({   "rating": "sum",   "episodes": "count",   "name": "last" }).reset_index() 

▍Создание сводной таблицы

Для того чтобы извлечь из датафрейма некие данные, нет ничего лучше, чем сводная таблица. Обратите внимание на то, что здесь я серьёзно отфильтровал датафрейм, что ускорило создание сводной таблицы.

tmp_df = rating.copy() tmp_df.sort_values('user_id', ascending=True, inplace=True) tmp_df = tmp_df[tmp_df.user_id < 10]  tmp_df = tmp_df[tmp_df.anime_id < 30] tmp_df = tmp_df[tmp_df.rating != -1] pd.pivot_table(tmp_df, values='rating', index=['user_id'], columns=['anime_id'], aggfunc=np.sum, fill_value=0) 

Результаты выполнения команды

11. Очистка данных

▍Запись в ячейки, содержащие значение NaN, какого-то другого значения

Здесь мы поговорим о записи значения 0 в ячейки, содержащие значение NaN. В этом примере мы создаём такую же сводную таблицу, как и ранее, но без использования fill_value=0. А затем используем функцию fillna(0) для замены значений NaN на 0.

pivot = pd.pivot_table(tmp_df, values='rating', index=['user_id'], columns=['anime_id'], aggfunc=np.sum) pivot.fillna(0) 

Таблица, содержащая значения NaN

Результаты замены значений NaN на 0

12. Другие полезные возможности

▍Отбор случайных образцов из набора данных

Я использую функцию df.sample каждый раз, когда мне нужно получить небольшой случайный набор строк из большого датафрейма. Если используется параметр frac=1, то функция позволяет получить аналог исходного датафрейма, строки которого будут перемешаны.

anime.sample(frac=0.25) 

Результаты выполнения команды

▍Перебор строк датафрейма

Следующая конструкция позволяет перебирать строки датафрейма:

for idx,row in anime[:2].iterrows():     print(idx, row) 

Результаты выполнения команды

▍Борьба с ошибкой IOPub data rate exceeded

Если вы сталкиваетесь с ошибкой IOPub data rate exceeded — попробуйте, при запуске Jupyter Notebook, воспользоваться следующей командой:

jupyter notebook — NotebookApp.iopub_data_rate_limit=1.0e10 

Итоги

Здесь я рассказал о некоторых полезных приёмах использования pandas в среде Jupyter Notebook. Надеюсь, моя шпаргалка вам пригодится.

Уважаемые читатели! Есть ли какие-нибудь возможности pandas, без которых вы не представляете своей повседневной работы?

Чтобы понять, как работает Cascadeur, нам необходимо обратиться к истории анимации и подходу к ее созданию. В этом материале Евгений Хапугин, ведущий аниматор студии Banzai.Games, постарается объяснить, как выход за рамки основополагающих принципов Уолта Диснея помогает создать реалистичную анимацию и как для этого применить физические инструменты Cascadeur.

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

Современная анимация может быть очень сложна, ее создание занимает много времени и требует использования реальных референсов и захвата движений. И все же мы встречаем подобные сцены снова и снова. Почему же?

Что происходит за кадром

Как ни странно, одной из причин могут быть всем известные 12 принципов анимации Диснея. Они хорошо работают и хорошо объясняют, как создавать анимацию. Но вот о реализме они ничего не говорят. Эти принципы появились в 1930-х, и аниматоры опираются на них по сей день.

В 2002 году Джереми Кантор, супервайзер Sony Animation, дополнил 12 диснеевских принципов 12-ю своими собственными. Они помогают улучшить качество анимации, вводят понятие сил, приложенных к персонажу. Силы могут быть внутренними, такими как вес или движение мускулов, а могут быть и внешними, как, например, гравитация или взаимодействие с воздухом, водой или другими персонажами.

Но эти силы аниматор должен применять вручную, так что они позволяют сделать анимацию более выразительной, но не более правдоподобной. Нет, по-настоящему реалистичная анимация должна учитывать настоящие физические силы, приложенные к персонажу, и откуда эти силы берутся. Здесь может помочь motion capture — он ведь делается в реальности, значит, и движения должны быть реальны.

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

И все это при том, что сама лошадь по крайней мере реальна. Если нам нужен дракон или супергерой, мокап едва ли поможет.

Физически корректная анимация

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

Когда Евгений Дябин, основатель Banzai.Games и Cascadeur, работал над первым прототипом Shadow Fight, он был очень удивлен, что центр масс — совершенно необходимый для создания реалистичной акробатики — отсутствует во всех известных анимационных программах. Оказывается, аниматоры и сейчас создают реалистичные движения вручную, полагаясь на видео референсы.

Shadow Fight, наша серия файтингов, делает большой упор на анимацию. Этот проект оказался очень успешным, и множество положительных реакций заслужила именно реалистичная анимация ударов. Такую анимацию мы не смогли бы сделать, используя только референсы и motion capture. Для работы над ней мы создали Cascadeur — систему создания физически корректной анимации.

Cascadeur находился в разработке почти десять лет, и за это время мы выяснили, что для создания реалистичного движения достаточно правильно рассчитать его основные параметры: центр масс, момент инерции и силы в точках опоры.

Центр масс

Центр масс — одна из самых важных точек персонажа. Он определяет, может ли персонаж сохранять равновесие в данной позе.

Взгляните на пример из всеми любимого Mortal Kombat. Удар, который делает Китана, выглядит довольно странно и неестественно. С учетом ее позы и того, как движется ее центр масс, она должна была бы завалиться вперед и упасть.

Вот как похожее движение может выглядеть в действительности. Этот человек немного поворачивается во время удара, но, в отличие от Китаны, он не пытается никого ударить, а потому сохраняет равновесие.

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

Центр масс — очень “инертная” точка. Он не может быстро замедляться или ускоряться, его траектория всегда должна оставаться плавной, хотя траектории отдельных частей тела могут быть очень резкими.

Баллистика

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

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

Как только все готово, Cascadeur рассчитывает траекторию и остается только привязать к ней центр масс персонажа. В результате мы получаем правдоподобную, физически корректную траекторию прыжка.

Угловой момент

Угловой момент определяет вращение персонажа в данной позе. Он зависит от момента инерции и скорости вращения персонажа.

На изображении ниже момент инерции представлен в виде двух окружностей серого цвета. Радиус этих окружностей определяется позой персонажа. Чем более раскрыта поза, тем больше момент инерции.

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

Вот эта фигуристка, например, вращается медленнее, когда отводит ногу в сторону, чем когда ее тело собрано.

Как и центр масс, угловой момент — очень инертная величина. Она не может внезапно появляться или исчезать и должна изменяться плавно. Также она сохраняется в полете, когда нет точек опоры. Энергия на момент начала вращения не должна меняться до окончания полета.

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

Все, что ему требуется, это черновая анимация: начальная и конечная позы и, возможно, сколько-то промежуточных поз. Наш алгоритм вычисляет точные значения вращения и корректирует положение персонажа во всех кадрах.

Силы в точках опоры

Точки опоры тоже играют важную роль в движении персонажа, так что физические инструменты должны учитывать и их. Когда сила в точке опоры и сила, приложенная к центру масс персонажа, лежат на одной линии, они не влияют на вращение. Когда же это не так, персонаж начинает вращаться.

Cascadeur способен визуализировать эти силы и учитывать их при расчете движения персонажа.

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

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

Разделение

Разделение — это накопление энергии в одном месте и передача ее в другое место. Этот принцип применяется при анимации мощных ударов. Здесь, например, персонаж переводит всю энергию своего прыжка в удар мечом.

Другой пример: вот этот таэквондист. Он очень сильно закручивается, затем его тело практически останавливается, и только нога продолжает движение. В результате вся энергия вращения передается в ногу.

Компенсация

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

Взгляните на этот удар цепом. Во время удара персонаж проводит цеп над головой. Но цеп тяжел и может потянуть его назад, заставив потерять равновесие.

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

Заключение

Реализм анимации часто разрушают мелкие детали: центр масс, который движется не так, как должен, или угловой момент, который ускоряется не вовремя. Вместе эти мелочи становятся заметны и портят общее впечатление.

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

Узнать больше о Cascadeur:

Cascadeur: задача о падающей кошке
Cascadeur: будущее игровой анимации
Cascadeur: предсказание позы персонажа по шести точкам

В команду Banzai Games требуется Senior Unity Developer. Подробнее о вакансии можно прочитать здесь.

Практически каждый инженер, практикующий DevOps, в какой-то момент сталкивается с задачей настройки правил доступа для своих проектов. В данной статье мы рассмотрим примеры настройки сетевых политик Kubernetes-кластера, в котором используется плагин Calico и осветим некоторые интересные моменты. Предполагаем, что у вас уже имеется кластер k8s, где в качестве сетевого плагина используется Calico.

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

Помимо этого Calico добавляет свою политику GlobalNetworkPolicy. Она позволяет применять набор правил доступа по селектору не только для pod’ов, но и для групп хостов/контейнеров/pod’ов, и контролировать применение мер безопасности для различных цепочек путей трафика с помощью таких параметров, как preDNAT, doNotTrack и applyOnForward.

Задачу по обеспечению базовых принципов безопасности мы условно разделим на две: на подзадачу по настройке взаимодействия между pod’ами и на подзадачу по настройке доступа к узлу в целом. Решить первую подзадачу можно при помощи такой сущности Kubernetes как NetworkPolicies и при этом можно расширить функционал данной сущности, если использовать её с api, предоставляемого Calico. Для решения второй подзадачи мы будем использовать сущность GlobalNetworkPolicy. По ходу дела так же будем анализировать детали и начнем с Zero Trust Networking.

Zero Trust Networking

Первое, что стоит учесть при написании сетевых политик, это то, что и Kubernetes, и Calico считают наилучшим подход Zero Trust Networking, то есть запретить все, что явно не разрешено.

Согласно данной концепции существуют следующие требования к контролю доступа:

1. Правила применяются ко всем сетевым подключениям (не только к тем, которые пересекают границы защищаемой зоны).
2. Идентификация удаленного endpoint всегда основана на нескольких критериях, включая надежные криптографические доказательства идентичности. В частности, идентификаторы сетевого уровня, такие как IP-адрес и порт, сами по себе недостаточны, поскольку могут быть подделаны враждебной сетью.
3. Все ожидаемые и разрешенные сетевые подключения явно указаны в белом списке. Любое соединение, явно не занесенное в белый список, отклоняется.
4. Трафик от скомпрометированных workload (pod/VM/container) не должен иметь возможности обойти применение сетевых политик.
5. Во многих Zero Trust Networks также реализуется шифрование всего сетевого трафика. Это не является обязательным требованием (если речь идет не о передаче приватных данных), но для соответствия критериям Zero Trust Networks шифрование должно использоваться для каждого сетевого соединения.

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

Аналогично с HostEndpoint, как только он будет создан, весь трафик к хосту будет запрещен, кроме определенного перечня портов, который останется открытым. Причем, даже если вы создадите политики, которые явно запрещают доступ к этим портам, они останутся открытыми:

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

Из чего состоит Calico

Кратко рассмотрим основные компоненты Calico. Как вы уже, наверное, поняли, Calico — это не один демон, который запущен на каждом хосте, где он управляет сетью, Calico состоит из нескольких элементов, так же как и Kubernetes. В целом он состоит из трех(иногда четырех) компонентов.

Felix

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

• Управление сетевыми интерфейсами, их создание, проверка их работоспособности и настройка пересылки трафика для управляемых интерфейсов.
• Программирование маршрутизации трафика через FIB (Forwarding Information Base) ядра Linux.
• Программирование ACL на уровне ядра Linux.
• Уведомления о статусе сети, Felix записывает данные о проблемах и ошибках в etcd.

Плагин для оркестратора

В зависимости от того, какой оркестратор вы используйте (например, OpenStack, Kubernetes) Calico предоставляет определенный плагин для наиболее эффективного взаимодействия с оркестратором. В случае Kubernetes — это CNI plugin.

etcd

Так же Calico использует etcd. etcd — это распределенное хранилище ключ-значение, которое выполняет функцию базы данных и служит шиной для коммуникации между компонентами Calico. В случае, если вы используйте Kubernetes, они с Calico будут использовать одно и то же etcd.

BGP клиент (BIRD)

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

BGP повторитель для правил маршрутов (BIRD)

В случае, когда обслуживаемая Calico область достаточно велика при наличии только BGP клиента могут возникнуть проблемы, так как он требует чтобы каждый клиент мог соединиться с каждым клиентом, что может порождать слишком большое количество соединений(N ^ 2). В таких случаях для решения проблемы можно использовать повторитель маршрутов, то есть соответственно настроенный BIRD. Он занимается тем, что, если клиент BGP сообщает ему какую-либо информацию об изменении в маршрутах, он распространяет эту информацию для других BGP-клиентов.

Network Policy

NetworkPolicy, который предоставляет Calico (через api projectcalico.org) имеют более читаемый и развернутый синтаксис, чем тот, который предлагает сам Kubernetes (через api networking.k8s.io).

Ресурс сетевой политики NetworkPolicy представляет собой упорядоченный набор правил, которые применяются к группе endpoints, соответствующих селектору меток (labels). Простой пример из официальной документации:

apiVersion: projectcalico.org/v3 kind: NetworkPolicy metadata:   name: allow-tcp-6379   namespace: production spec:   selector: role == 'database'   types:   - Ingress   - Egress   ingress:   - action: Allow     protocol: TCP     source:       selector: role == 'frontend'     destination:       ports:       - 6379   egress:   - action: Allow

Здесь мы разрешаем трафик с подов/контейнеров, у которых есть селектор role == 'frontend' на порт 6379 для доступа к БД.

Host Endpoint

У каждого хоста (ноды) есть несколько реальных или виртуальных сетевых интерфейсов, с которыми взаимодействует Calico. Чтобы получить возможность применять политики конкретно к определенному интерфейсу необходимо создать для него сущность HostEndpoint. Они могут иметь метки (labels) и эти метки аналогичны меткам для pod’ов, поэтому сетевые политики в равной степени могут применяться и к HostEndpoint, и к endpoints pod’ов.

Предположим, что нам нужно запретить весь входящий трафик из внешней сети, кроме портов 22, 80, 443 на уровне хоста и при этом разрешить весь трафик от других нод кластера. Для этого, для начала, создадим для каждой ноды свой HostEndpoint. К примеру:

apiVersion: projectcalico.org/v3 kind: HostEndpoint metadata:   name: node4-ens160   labels:     type: production role: worker         node: 4 spec:   interfaceName: ens160   node: k8s-s4   expectedIPs:   - 10.213.0.11 ports:  - name: http    port: 80    protocol: TCP  - name: https    port: 443    protocol: TCP

В данном случае мы добавили также раздел ports, где описали определенные порты и протоколы для взаимодействия с ними. Мы сделали это для того, чтобы обозначить их и дать им названия (http, https), которые в дальнейшем можно использовать в сетевых политиках. interfaceName — название внешнего интерфейса сервера которому соответствует IP-адрес expectedIPs. Указывать порт 22 нет необходимости, так как он разрешен на уровне конфигурации Felix.

Global Network Policy

Теперь, когда почти весь трафик к ноде заблокирован, создадим GlobalNetworkPolicy, которая разрешит весь трафик с других нод кластера, входящий трафик на порты 80/443 и весь исходящий трафик для этого HostEndpoint:

kind: GlobalNetworkPolicy apiVersion: projectcalico.org/v3 metadata:   name: allow-s4 spec:   selector: role==worker   order: 10   applyOnForward: true   types:   - Egress   - Ingress   ingress:   - action: Allow     protocol: TCP     source:       nets:             - 10.213.0.0/24   - action: Allow     protocol: TCP     destination:       ports: [http,https]   - action: Allow     protocol: ICMP   egress:   - action: Allow

В целом, все параметры GlobalNetworkPolicy аналогичны NetworkPolicy и интуитивно понятны. order — очередность применения политики, чем она меньше, тем раньше будет применено правило.

Однако, для GlobalNetworkPolicyесть несколько интересных параметров, которые предоставляют дополнительные возможности для настройки политик, а именно: preDNAT, doNotTrack и applyOnForward, рассматриваемые ниже.

Опции applyOnForward, preDNAT и doNotTrack

Чтобы понять в каких случаях вам следует применять данные параметры, мы кратко рассмотрим как изменяется обработка трафика, если их включить. Более подробно и развернуто об это можно почитать в статье(ссылка на перевод) от Bikram Gupta.

applyOnForward

Параметр applyOnForward отвечает за то, применяется ли данная политика к трафику, который проходит по цепочке iptabels FORWARD. Например, трафик, направленный к pod’у. Так как pod является внешним ресурсом с точки зрения сети хоста (не считается локальным процессом), следовательно, трафик до него проходит по маршруту цепочек PREROUTING – FORWARD – POSTROUTING.

Если applyOnForward имеет значение false, GlobalNetworkPolicy к трафику для локальных workload (контейнер/pod/ВМ, которые имеют свои виртуальные интерфейсы) не применится. Она будет применяться только к трафику для локальных процессов и к трафику, исходящему от них. Пример приведу далее.

Если applyOnForward имеет значение true, GlobalNetworkPolicy также применяется к перенаправленному (forwarded) трафику, такому как:

• Трафик, который поступает через HostEndpoint и перенаправляется в локальные workload.
• Трафик из локальных workload, который перенаправляется черезHostEndpoint.
• Трафик, который поступает черезHostEndpointи пересылается на другой HostEndpoint.

По умолчанию applyOnForward имеет значение false. Для политик, использующих опции doNotTrack и preDNAT, для свойства applyOnForward должно быть установлено значение true, поскольку эти политики применяются ко всему трафику, проходящему через FORWARD.

По умолчанию пересылаемый трафик (FORWARD)разрешен, если к пункту его назначения или направлению не применены какие-либо политики. Иначе говоря: если у вас настроен HostEndpoint, но нет политик с параметром applyOnForward: true для этого HostEndpoint или направления трафика, то пересылаемый трафик будет разрешен. Если существуют политики applyOnForward:true, в которых упоминаются селекторы HostEndpoint или это направление, но никакие правила в политиках не разрешают трафик, трафик отклоняется.

Пример: вы создаете GlobalNetworkPolicy, разрешающую исходящий трафик по протоколу ICMP для данного HostEndpoint с applyOnForward:false. В этом случае, если вы попытаетесь сделать ping 8.8.8.8 из pod’а на данном хосте, вам это удастся, так как forwarded трафик по умолчанию разрешен, хотя GNP применилась только к локальному трафику. Но. Если вы создадите ещё одну политику для этого HostEndpoint, но уже с applyOnForward:true, например, вы разрешаете весь TCP-трафик, то ping 8.8.8.8 изнутри пода не пройдет. Потому что уже существует политика с applyOnForward:true для этого типа трафика (этого HostEndpoint) и этот тип трафика явно не разрешен.

preDNAT

Данная опция отвечает за то, применяется ли политика до прохождения через DNAT (Destination Network Address Translation) или нет.

Это может пригодится, например, если вы используйте NodePorts и хотите контролировать трафик, который приходит извне на эти порты. После того, как трафик извне приходит на NodePort его распределение по факту происходит при помощи DNAT (kube-proxy). Следовательно, для того, чтобы применить политику к трафику, приходящему на NodePort, preDNAT должен быть установлен в true.

Ключевые особенности для таких политик следующие:

• Политики с опцией preDNAT могут иметь правила только для входящего трафика, но не исходящего.
• Политика применяется для всего трафика, проходящего через host endpoint, не только к процессам на хосте, но и к локальным workload (pod/VM/container).
• По умолчанию весь preDNAT трафик разрешен. То есть если существует HostEndpoint, но для него нет preDNAT политик, для него не действует правило “отбрасывать все по умолчанию”.

doNotTrack

Опция doNotTrack позволяет отключить отслеживание (conntrack) трафика, который попадает под данную политику, причем именно для локальных процессов хоста (не pod / VM / container).

conntrack — это опция ядра из сетевого стека Linux, которая помогает ему отслеживать сетевые потоки, чтобы была возможность обрабатывать пакеты из одного потока одинаково, на основании правила обработки выбранного для первого пакета из потока.
Но эта опция также накладывает ограничение на количество соединений, по достижению которого соединения отклоняются. Хотя в обычных условиях практически нереально достигнуть его исчерпания, есть несколько сценариев при которых возникнет необходимость в отключении этой опции:

• Если вам необходимо одновременно обрабатывать активных соединений больше, чем установленное значение в таблице conntrack (больше 128k по умолчанию).
• Если вам необходимо обрабатывать большое количество коротких соединений в секунду. Так как даже после завершения соединения conntrack продолжает отслеживать соединение в течении некоторого времени (по умолчанию 120с). Например, если в таблице conntrack установлено значение на 128к доступных подключений, и вы пытаетесь обрабатывать 1100 соединений в секунду, лимит будет исчерпан, даже если эти подключения очень кратковременные (128k / 120s = 1092 connections/s ).

Такие цифры вам могут пригодиться, например, если Вы используйте memcached, который функционирует непосредственно на хосте и при этом принимает большое количество частых и кратковременных соединений. Если вы используете Calico для защиты хоста этого сервера, вы можете избежать этой проблемы, определив политику, которая разрешает доступ к портам сервера и помеченную как doNotTrack. Подробнее про то, какое влияние оказывает включение этой опции на обработку объемного трафика можно почитать [здесь] (тут ссылка на наш перевод).

Так как для активации doNotTrack политика должна примениться в самом начале цепочек OUTPUT и PREROUTING, она действует раньше других (тех, для которых doNotTrack:false), вне зависимости от её order. То есть одна политика без doNotTrack может иметьorder:1, а другая с doNotTrack может иметь order:1000, но раньше подействует политика с doNotTrack. Порядок оrder соблюдается только между политиками данного типа.

Заключение

Таким образом, мы с вам получили представление о том, как реализовать при помощи сетевых политик Calico нужные вам разграничения трафика для Kubernetes-кластера и какие опции политик при этом использовать.

Материалы используемые для публикации:

• Пояснение концепции от Calico Zero Trust Networking
• Список failsafe rules Calico
• Примеры работы с политиками Calico с примерами
• Понимание применения работы сетевых политик Calico
• Oб отключении conntrack

Также читайте другие статьи в нашем блоге:

• Понимание вариантов применения сетевых политик с Calico
• Когда Linux conntrack вам больше не товарищ
• 4 примера iota-перечислений
• Обновление Kubernetes-кластера без простоя
• Zero Downtime Deployment и базы данных
• Kubernetes: почему так важно настроить управление ресурсами системы?

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

ADAM-6700 это новая серия устройств на базе процессора Cortex-A8 под управлением Linux RT (real time). Совмещает в себе функции модуля связи с объектом, программируемого логического контроллера (ПЛК), устройства сбора и обработки данных, а так же IP-шлюза для цифровых и аналоговых интерфейсов.

Имеет встроенный сервер Node-RED и возможность конфигурации через веб-интерфейс. Благодаря открытой платформе, на модуле можно запускать клиентские приложения на языке C и реализовывать любую логику работы программно.

Технические характеристики

Новые устройства серии ADAM-6700 построены на базе ARM архитектуры и представляют из себя производительную систему, позволяющую выполнять локальные преобразования, хранение и обработку данных. Работают под управлением версии ОС Linux с поддержкой операций реального времени, благодаря чему могут использоваться для операций, критичных к таймингам.

• Операционная система: Linux RT
• CPU:Cortex-A8 32-Bit 1GHz
• Оперативная память: 512MB
• Порты LAN: 2 независимых
• USB Slave: 1 (консольный порт для настройки)
• USB Host: 1 (для подключения устройств)
• Порты ввода-вывода
• Цифровых входов: 5 (модель ADAM-6717) 12 (модель ADAM-6750)
• Цифровых выходов: 4 (модель ADAM-6717) 12 (модель ADAM-6750)
• Аналоговых входов: 8 (модель ADAM-6717)

Настройка

Первичная конфигурация устройства может выполняться через утилиту ADAM/Apax.NET Utility, где можно задать режимы работы сети и IP-адрес, или через веб-интерфейс. В веб-интерфейсе доступны два варианта конфигурации устройства: фирменная оболочка Advantech и Node-RED. На стартовой странице необходимо выбрать один из вариантов.

^{Веб-интерфейс с выбором оболочки для работы с устройством}

Node-Red — популярная открытая среда для визуального программирования и управления потоками данных. Устройства серии ADAM-6700 имеют встроенный сервер Node-RED, и программирование может происходить прямо через веб-браузер, либо с помощью импорта конфигурации.

^{Веб-интерфейс среды Node-RED}

Цифровые и аналоговые интерфейсы ввода-вывода доступны через API для языка C, и могут быть задействованы для реализации собственных протоколов, для интеграции с оборудованием заказчика.

Конфигурация через Micro USB

Для удобства конфигурирования ADAM-6700 может подключаться по Micro USB как slave-устройство к компьютеру. В этом случае питание модуля будет происходить через USB-порт, что значительно упрощает настройку, так как не требует подключения питания через клеммы, а значит может выполняться инженером без инструментов и дополнительного оборудования, вроде блоков питания и отверток. В хост-системе устройство определяется как виртуальный COM-порт.

Интерфейс USB Host

ADAM-6700 имеет полноценный USB A порт для подключения устройств в режиме Host. Он позволяет подключать внешние накопители, USB-флешки, а так же модули расширения, вроде WiFi-модуля ADAM 600W. При необходимости, ядро системы может быть скомпилировано с поддержкой любых драйверов для USB-устройств.

WiFi-модуль ADAM-600W

Модуль расширения ADAM-600W добавляет поддержку WiFi к устройствам серии ADAM-6700. Подключение происходит по USB и не требует установки дополнительного ПО. После подключения модуля ADAM-600W, меню настройки WiFi подключения станет доступно в веб-интерфейсе.

ADAM-6700 с WiFi-модулем расширения может работать в качестве шлюза для связывания остальных устройств, подключенных по Ethernet, с сервером.

Заключение

Универсальные устройства серии ADAM-6700 могут применяться для решения самых разных задач автоматизации, сбора данных и управления периферией. Многозадачная операционная система не ограничивает разработчика в написании сложных приложений. Поддержка открытой платформы Node-RED и возможность конфигурации через веб-интерфейс снижает порог входа и позволяет разработчикам работать в привычной понятной среде.

На предприятиях нередко возникает ситуация, когда требуется создание так называемого VIP-почтового ящика, отправлять письма на который может только определенный круг лиц. Такие почтовые ящики характерны для любых топ-менеджеров с личными секретарями. Всю электронную почту вместо топ-менеджера получает секретарь, который затем выбирает из общего потока действительно важные и нужные сообщения и перенаправляет их на почтовый ящик своего руководителя. Обычный же сотрудник предприятия при попытке отправить сообщение на VIP-почтовый ящик должен получать уведомление о том, что его сообщение не было доставлено. Такой VIP-почтовый ящик можно без труда реализовать в Zimbra Open-Source Edition с помощью встроенных инструментов для фильтрации почты под названием Amavis и cbpolicyd.

Amavis координирует действия агента пересылки электронной почты Postfix, спам-фильтра Spam Assassin, антивируса ClamAV и ряда других. В комплексе все эти утилиты обеспечивают надежную защиту от спама и вирусов, а также фишинговых писем, представляющих серьезную угрозу для информационной безопасности предприятия. По умолчанию Amavis подвергает такой фильтрации все электронные письма без исключения, однако встроенная функциональность ограничения политик позволяет не только отключить такую фильтрацию для каких-либо почтовых ящиков, но также и ограничить список лиц, которые в принципе могут отправлять на почтовые ящики электронные письма.

Для примера возьмем почтовый ящик генерального директора ceo@example.ru, для которого необходимо ограничить круг лиц, которые могут присылать сообщения напрямую. Список будет ограничен топ-менеджментом компании в виде CTO, CIO и CFO, а также личным секретарем. Для этого мы и воспользуемся ограничениями политик Amavis. С помощью команды zmprov ma ceo@example.ru +amavisWhitelistSender secretary@example.ru cto@example.ru cio@example.ru cfo@example.ru мы добавим в белый список адреса, которые могут писать электронные письма генеральному директору напрямую, а с помощью команды zmprov ma ceo@example.ru amavisBlacklistSender example.ru мы добавляем в черный список остальных.

Для того, чтобы убедиться в том, что все сделано верно, можно выполнить команду zmprov -l ga ceo@example.ru | grep amavis | grep Sender. В выводе команды будет видно как тех, кому разрешено отправлять сообщения генеральному директору, так и тех, кому отправка сообщений на его адрес электронной почты запрещена. Однако, помимо пользователей домена предприятия, письма на почтовый ящик генерального директора могут поступать и с доменов во внешнем интернете. Поэтому разумным шагом было бы введение безусловного запрета на получение электронных писем из внешнего интернета для данного почтового ящика.

Ввести подобные ограничения можно за счет использования cbpolicyd — службы политик, встроенной в Zimbra Collaboration Suite Open-Source Edition. Для того, чтобы её воспользоваться, необходимо сперва активировать соответствующий модуль в Zimbra OSE. Для этого необходимо ввести команду zmprov ms mail.example.ru +zimbraServiceEnabled cbpolicyd. Выполните эту команду на узле с MTA в том случае, если ваша Zimbra OSE работает на мультисерверной инфраструктуре. Также потребуется открыть доступ к cbpolicyd через веб-интерфейс. Для этого введем команду ln -s /opt/zimbra/data/cbpolicyd/share/webui /opt/zimbra/httpd/htdocs/, которая создаст символьную ссылку в сервере Apache. Кроме того, необходимо добавить в файл /opt/zimbra/cbpolicyd/share/webui/includes/config.php информацию о базе данных, к которой должно происходить подключение. Для этого в любом текстовом редакторе добавим в данный файл строку $DB_DSN=«sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb»;. После этого останется только перезапустить Zimbra OSE и веб-сервер Apache с помощью команд zmcontrol restart и zmapachectl restart.

Теперь веб-интерфейс для администрирования cbpolicyd доступен по адресу mail.example.ru:7780/webui/index.php, однако стоит учесть, что он может быть недоступен из-за настроек брандмауэра. Настройте его, чтобы получить доступ к веб-интерфейсу cbpolicyd. После того как вы зайдете в веб-интерфейс cbpolicyd, необходимо создать две группы: users_local_only для пользователей, которые могут получать почту только от пользователей локального домена, а также local_domain для локального домена и включить их, убрав галочку с пункта «Отключено». После этого нужно добавить участников в группы. В нашем случае мы добавим ceo@example.ru в группу users_local_only и домен example.ru в группу local_domain.

Теперь приступим к настройкам политик. Назовем нашу «Receiving Local Only» и укажем в ней группы пользователей, на которых она будет распространяться, и доменов, которые считаются локальными. В качестве их следует указать группы users_local_only и local_domain, а также указать приоритет применения политики. Это необходимо для тех случаев, когда к одному и тому же почтовому ящику применяются сразу несколько политик. На основе приоритета cbpolicyd решает, какая политика будет применяться, а какая будет проигнорирована. В нашем случае можно выставить приоритет 100 и в дальнейшем, если появятся дополнительные накладывающиеся друг на друга политики, скорректировать его.

Еще одним важным моментом является настройка действия при срабатывании политики. Иными словами, если мы запретили почтовому ящику генерального директора получать письма от любых внешних доменов, то надо определиться с тем, что будет происходить с письмами, которые продолжат поступать на его почтовый ящик. Предлагаем просто отклонять такие письма с помощью опции REJECT. После внесения изменений, остается лишь применить политики и перезапустить cbpolicyd с помощью команд zmprov ms mail.example.ru zimbraCBPolicydAccessControlEnabled TRUE и zmcbpolicydctl restart.

Таким образом, с помощью встроенных инструментов Zimbra Collaboration Suite Open-Source Edition мы создали VIP-почтовый ящик, отправлять письма в который могут лишь несколько человек. Используя данный шаблон, вы можете расширить число VIP-почтовых ящиков, а также число учетных записей, способных отправлять им письма.