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

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

Два простых решения для случаев, когда нужен прокси.

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

В новой серии статей «Мир приключений по API-серверу Kubernetes» («k8s ASA») мы погрузимся во все детали работы API-сервера, получим представление о том, как они работают, а также с какими компонентами взаимодействуют. Параллельно поэкспериментируем с заменой пользовательских компонентов, создадим инструментарий и рассмотрим, как другие пользователи модифицировали его в соответствии с пользовательскими кейсами. Кто знает, возможно, даже построим наш собственный. 👀

За последние годы инфраструктура приватных ключей PKI (Public Key Infrastructure) незаметно окружила нас со всех сторон:

- Большинство сайтов в сети Интернет используют HTTPS протокол. Для его работоспособности необходимо получать сертификаты из удостоверяющих центров (Certificate Authority)

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

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

Давайте разберемся как работают системы PKI, т.к. они еще долго будут актуальны для обеспечения аутентификации и безопасной передачи данных. В данной статье рассмотрим теорию и в качестве примера PKI возьмём самую известную в мире реализацию PKI - HTTPS протокол в сети Интернет. В качестве удостоверяющего центра будем использовать бесплатный Let's Encrypt. В следующей статье "Сам себе PKI: Практика на примере OpenSSL и CA Smallstep" перейдем к практике и организуем безопасную передачу данных на основе TLS протокола.

На схеме упрощенная система PKI для организации HTTPS в сети Интернет.

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

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

Если ты неприлично много сидишь, а после рабочего дня мечтаешь о том, чтобы отсоединить от себя свою поясницу и оставить ее на полке, пока не перестанет ныть, тогда тебе сюда.

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

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

Об одном таком случае — как Kube API-серверы заняли всю память и уронили API Kubernetes — мы и рассказали в статье. И конечно, поделились, как ограничивать число запросов в Kubernetes API, чтобы с вами такого не случалось.

Можно ли при идеальном коде и защищённой инфраструктуре иметь серьёзные проблемы в безопасности продукта? Защитят ли нас полностью современные средства инфраструктурной защиты, анализа кода? А что, если нет? Давайте подумаем об этом на отвлечённых примерах из практики.

Привет, Хабр! Меня зовут Игорь Игнатьев, я директор департамента защиты приложений в VK. Сегодня расскажу о подходе к построению безопасных продуктов, и это будет моя первая статья из цикла про принципы Secure by Design.

Мне нравятся книги из серии Head First O`Reilly — они рассказывают просто о сложном. И я стараюсь делать также.

Когда речь идёт о базах данных, могут всплыть магические слова «Требования ACID». На собеседовании или в разговоре разработчиков — не суть. В этой статье я расскажу о том, что это такое, как расшифровывается ACID и что означает каждая буква.

Требования ACID — набор требований, которые обеспечивают сохранность ваших данных. Что особенно важно для финансовых операций. Мы же не хотим остаться без денег из-за разрыва соединения или ошибки в ПО, не так ли?

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

Данный материал подготовлен на базе выступления “eBPF в production-условиях” от Дмитрия Евдокимова и Александра Трухина из компании Luntry с конференции HighLoad++ 2022. Он будет полезен как компаниям, что используют внутри себя решения на базе eBPF, так и разработчикам, которые что-то пишут или планируют писать с использованием данной технологии.

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

В идеале хотелось бы иметь какую-то карту взаимодействия сервисов в Kubernetes, которая сама автоматически обновляется. Такую карту можно построить с помощью инструментов типа Istio и Cilium. Но иногда можно обойтись и более простыми решениями — например, NetFlow.

Хочу рассказать об интересном эксперименте, суть которого заключалась в развертывании и настройке Kubernetes на двух старых ноутбуках — один из них, кроме того, был с процессором на архитектуре i386. В качестве теоретической основы использовалось руководство Kubernetes The Hard Way, которое по ходу дела пришлось немного доработать, а в качестве системы на хостах — Gentoo (да, вам не показалось). Давайте погрузимся в этот увлекательный хардкор!

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

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

Фото: Jukan Tateisi | Unsplash

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

Возьмем самый простой пример — приложение HelloApp. Чтобы задеплоить HelloApp, создадим ресурс Kubernetes.

В докладе я препарирую Istio, дабы понять, как он работает, какие у него подводные камни и как им правильно пользоваться.

Это мой второй доклад про Istio и Service Mesh. Первый я сделал на конференции Kuber Conf 2021: «Что ждать от внедрения Istio?». Рекомендую ознакомиться сначала с ним, будет несколько проще.

Знакомьтесь: Ceph

Всем привет. Меня зовут Добрый Кот Telegram.

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

Вошли и вышли, приключение на 20 минут)

От коллектива FR-Solutions и при поддержке @irbgeo Telegram : Продолжаем серию статей о K8S.

К моему удивлению, в открытом доступе оказалось не так уж много подробных и понятных объяснений того как работает модель GPT от OpenAI. Поэтому я решил всё взять в свои руки и написать этот туториал.