Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Эксперты
Войти
Забыли пароль?
или продолжите с
Создать аккаунт
Регистрируясь, я даю согласие на обработку данных и условия почтовых рассылок.
или
Восстановление пароля
Восстановление пароля
Получить код в Telegram
Войти с Яндекс ID Войти через VK ID
ПромокодыРаботаКурсыРекламаИгрыПополнение Steam
Пикабу Игры +1000 бесплатных онлайн игр  Что обсуждали люди в 2024 году? Самое время вспомнить — через виммельбух Пикабу «Спрятано в 2024»! Печенька облегчит поиск предметов.

Спрятано в 2024

Поиск предметов, Казуальные

Играть

Топ прошлой недели

  • solenakrivetka solenakrivetka 7 постов
  • Animalrescueed Animalrescueed 53 поста
  • ia.panorama ia.panorama 12 постов
Посмотреть весь топ

Лучшие посты недели

Рассылка Пикабу: отправляем самые рейтинговые материалы за 7 дней 🔥

Нажимая «Подписаться», я даю согласие на обработку данных и условия почтовых рассылок.

Спасибо, что подписались!
Пожалуйста, проверьте почту 😊

Помощь Кодекс Пикабу Команда Пикабу Моб. приложение
Правила соцсети О рекомендациях О компании
Промокоды Биг Гик Промокоды Lamoda Промокоды МВидео Промокоды Яндекс Маркет Промокоды Пятерочка Промокоды Aroma Butik Промокоды Яндекс Путешествия Промокоды Яндекс Еда Постила Футбол сегодня
0 просмотренных постов скрыто
1
elena.davydova

State of DevOps Russia 2025: рост зрелости команд, интеграция AI и приоритет безопасности⁠⁠

18 дней назад
State of DevOps Russia 2025: рост зрелости команд, интеграция AI и приоритет безопасности

Команда «Экспресс 42» — консалтинговое направление компании «Флант» — представила пятое ежегодное индустриальное исследование «Состояние DevOps в России 2025». Согласно его результатам, в российском ИТ-сообществе растёт доля высокоэффективных команд, усиливается роль информационной безопасности, а использование ML/AI-инструментов становится нормой для большинства специалистов.

Исследование проведено командой «Экспресс 42» при поддержке Deckhouse, Yandex Cloud, hh.ru, Т-Банка, VK Cloud, AvitoTech, Positive Technologies, ecom.tech, «Онтико», Selectel, X5 Tech, Axiom JDK, Okko и Sk Финтех Хаба и использует результаты опроса более 3300 специалистов из России и стран СНГ.

«DevOps как методология продолжает играть важную роль в реализации технологических проектов, однако эволюционирует вместе с изменяющимся ИТ-ландшафтом — от традиционных практик CI/CD к комплексным внутренним платформам разработки (IDP), DevSecOps и интеграции ML/AI-решений в процессы разработки. Исследование позволяет понять, в каком направлении движется российский DevOps-рынок, где мы сейчас находимся и что необходимо развивать, чтобы команды и бизнес функционировали эффективнее в новых условиях», — отметил Александр Титов, генеральный директор компании «Флант» и сооснователь «Экспресс 42».

Эволюция DevOps и рост эффективности команд

Аналитики отмечают рост эффективности DevOps-команд: доля высокоэффективных (Elite) команд выросла на 4 %, High — на 2 %, при этом доля Medium-команд сократилась на 9 %. Улучшились ключевые метрики: срок поставки в Low-командах сократился до 1–3 месяцев, время восстановления в Medium-командах достигло показателя «Меньше дня», а доля неуспешных изменений в Elite-командах упала до 0–5 %.

Команды с высоким уровнем Developer Experience (DX) — то есть с понятной и удобной средой для инженеров — чаще выстраивают быстрые и качественные циклы обратной связи, снижают когнитивную нагрузку и обладают большей автономностью. Среди ключевых факторов высокого DX респонденты отметили развитую инженерную культуру, наличие инструментальной платформы, прозрачные процессы релизов и тесное взаимодействие с безопасностью и эксплуатацией.

«В рамках нашей миссии по распространению передовых практик для достижения технологического суверенитета, мы с удовольствием поддержали открытое исследование рынка DevOps от команды «Экспресс 42». DevOps-решения сегодня — это не просто набор инструментов для автоматизации, а фундаментальный принцип построения высокоэффективных ИТ-команд. Они стирают барьеры между разработкой и эксплуатацией, создавая единый жизненный цикл, в котором скорость не противоречит надежности, превращая ИТ из затратного центра в ключевой драйвер любого бизнеса. Уверен, что исследование поможет многим нашим партнерам внедрить лучшие практики, а  разработчикам DevOps, DevSecOps и AIOps-инструментов - лучше понять запросы своих клиентов», - комментирует Павел Новиков, управляющий директор Центра экспертизы Фонда "Сколково"

Информационная безопасность как часть DevOps

Информационная безопасность укрепила позиции в процессах разработки. Согласно результатам исследования, 77,1 % участников используют инструменты ИБ, 75,1 % собирают метрики информационной безопасности, а у 66,8 % компаний эти инструменты уже интегрированы в пайплайны. Более того, 40 % респондентов сообщили, что безопасность встроена во все этапы DevOps-цикла — от планирования до эксплуатации.

Наиболее востребованные практики — это интеграция проверок безопасности на ранних стадиях (50 % опрошенных) и параллельная обработка задач в CI/CD (45 %). Чаще всего средства ИБ подключаются именно к системам непрерывной интеграции и доставки — такой вариант отметили 59,9 % респондентов. При этом 46,8 % используют сканеры уязвимостей в образах контейнеров, а 35,6 % — анализаторы конфигураций Kubernetes.

Однако внедрение ИБ сопряжено с вызовами: 45,5 % сталкиваются с нехваткой технической экспертизы, 42,2 % — с проблемами совместимости, а 26,8 % респондентов признают, что результаты проверок им непонятны.

«Как показывает исследование, многие компании всё ещё игнорируют вопросы безопасности разрабатываемого ПО. Знаю, что зачастую активная защита ещё вытесняет превентивные меры типа анализа кода и проведения автоматизированного анализа используемых приложений. Это один из факторов, который “расслабляет” разработчиков ПО. Однако игнорирование подхода безопасной разработки уже становится тупиковой ветвью развития для любого вендора, поскольку одним из наиболее распространённых методов атак на компании до сих пор остаётся эксплуатация уязвимостей веб-приложений (31 %). На фоне постоянно растущего числа кибератак небезопасный код уже нельзя назвать качественной разработкой», — отметила Светлана Газизова, директор по построению процессов DevSecOps и безопасности ИИ, Positive Technologies.

«40 % компаний уже интегрировали безопасность в свой DevOps-цикл. Это очевидный прогресс. Но есть тревожный сигнал: 26,8 % опрошенных говорят, что “результаты проверок им непонятны”. Это значит, что просто добавить сканер в пайплайн недостаточно. Нужно менять подход и культуру работы: делать результаты проверок прозрачными, объяснять их ценность и учить сотрудников правильно их интерпретировать», — подчеркнул Александр Ушаков, DevOps Lead, Okko.

Тренды на рынке облаков

В 2024 году среди опрошенных компаний по-прежнему популярна гибридная модель.

Что касается оценки ключевых преимуществ облачных решений, на первое место выходит повышение надёжности IT-инфраструктуры (82 % в 2024 году против 44 % в 2023 году). Второе и третье места разделяют рост масштабируемости и отказоустойчивости при увеличении трафика текущего продукта (82 %) и соответствие требованиям регулятора в области управления персональными данными (81 %).

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

Лидером среди облачных провайдеров стал Yandex Cloud с долей в 47,4 %. На втором месте Selectel — 17,5 %. А третье место делят Cloud.ru и Amazon Web Services, которых выбрали 14,3 и 14,1 % респондентов соответственно.

«Надежность остается одним из главных критериев для бизнеса при выборе инфраструктуры. Компании выбирают облачного провайдера как стратегического партнера, с которым можно уверенно разрабатывать ИТ-продукты, усиливать информационную безопасность и внедрять искусственный интеллект. Несмотря на стремительное развитие продуктового портфеля, мы в первую очередь фокусируемся на обеспечении надёжности, производительности и бесперебойной работы сервисов облачной платформы», – рассказал Иван Пузыревский, технический директор платформы Yandex Cloud.

AI в инженерных практиках

ИИ-инструменты становятся частью повседневной работы инженеров: 71,3 % опрошенных уже используют ML/AI-решения. Более половины из них (54,1 %) отмечает рост индивидуальной эффективности, 45,6 % — командной. Чаще всего ИИ применяют для автоматической генерации кода (65,2 %), создания документации (45,5 %) и анализа кода на наличие ошибок (45,2 %). Также значительная доля респондентов использует ИИ для автоматического создания тестовых сценариев (34,3 %).

«65 % респондентов уже активно используют автоматическую генерацию кода, а 45 % отмечают значительное упрощение работы с документацией благодаря AI. Эти инструменты постепенно становятся нормой, напрямую повышая индивидуальную и командную производительность. Умение эффективно использовать эти технологии уже сейчас является решающим конкурентным преимуществом, которое будет определять успех бизнеса на ближайшие годы», — рассказал Евгений Харченко, начальник отдела развития практик в разработке и эксплуатации, Райффайзенбанк.

Внутренние платформы: автоматизация и контроль

Развитие внутренних платформ (Internal Developer Platform, IDP) остаётся одним из ключевых направлений для компаний. Наиболее важными функциями IDP респонденты назвали управление доступом пользователей (45,8 %) и возможность быстрого поиска информации (45,2 %), а основной целью развития платформ на 2025 год — автоматизацию рутинных задач.

«Internal Developer Platform (IDP) постепенно перестаёт быть нишевым инструментом и становится must-have для крупных компаний с высокой интенсивностью разработки. Сейчас мы видим, что основной спрос на IDP формируют крупные компании с большим объёмом разработки, для которых критически важны унификация процессов, контроль доступа и безопасность», — отметил Станислав Старков, руководитель направления технологической стратегии VK Cloud, VK Tech.

Отечественное ПО и гибридные решения

Продолжается переход на российское программное обеспечение и on-premise-решения. Увеличилась доля пользователей отечественных ОС, в том числе Astra Linux, РЕД ОС и «Альт», растёт использование российских дистрибутивов Kubernetes. Каждый четвёртый участник опроса использует российскую ОС как базовый образ для контейнеров, а половина компаний развёртывает оркестратор on-premise.

«Мы на своей практике видим, что востребованность запуска Kubernetes в on-premise стабильно растёт, в том числе за счёт строгих требований службы информационной безопасности и необходимости выполнения требований регуляторов. При этом стоит обратить внимание на достаточно большой процент hybrid-инсталляций, которые позволяют совместить все преимущества собственной инфраструктуры и облачного подхода. Количество запросов на подобный тип инсталляций встречается всё чаще в компаниях разных масштабов, что предъявляет в свою очередь определённые требования к Kubernetes-дистрибутиву. Необходимо, чтобы он единообразно и одинаково хорошо развёртывался и управлял инфраструктурой и в on-premise, и в облаке. Это одна из функциональных возможностей, которая если уже не является определяющей, то должна стать такой в ближайшем будущем», — рассказал Константин Аксёнов, директор департамента разработки Deckhouse, «Флант».

Аналитики отмечают, что наблюдаются устойчивое сокращение доли ручного управления инфраструктурой и рост автоматизации. Увеличивается использование CI/CD- и Observability-систем, растёт доля on-premise-инсталляций GitLab и Kubernetes. При этом заметен тренд на стандартизацию подходов к инфраструктуре и развитие внутренних инструментальных платформ.

Рынок труда: баланс спроса и предложений

Рынок труда DevOps-специалистов в России за последние три года демонстрирует высокую активность: количество вакансий на hh.ru стабильно увеличивалось в среднем на 10 % ежегодно. В 2024 году число опубликованных предложений выросло на 16 % по сравнению с 2023-м, однако в первом полугодии 2025-го зафиксировано снижение — на 26 % относительно прошлого года.

При этом предложение со стороны специалистов продолжает расти: за 2022–2024 годы на hh.ru размещено на 72 % больше резюме, чем в предыдущем трёхлетнем периоде. Количество вакансий, опубликованных суммарно за первое полугодие, превысило количество резюме всего на 18 %. Это минимальный разрыв за последние годы, что свидетельствует о снижении дефицита кадров и росте зрелости индустрии.

«Согласно hh.индексу, в сфере ИТ в целом наблюдается высокий уровень конкуренции соискателей. В августе 2024 года индекс составлял 7,7, а к августу 2025 года вырос до 14,9. Это подтверждает тенденцию работодателей тщательно подходить к найму сотрудников и в сегменте DevOps», — отметила Мария Игнатова, директор по исследованиям, hh.ru.

Итоги и тенденции развития

В целом по итогам исследования State of DevOps Russia 2025 можно сделать вывод, что российский рынок DevOps вышел на этап устойчивого развития. Компании усиливают фокус на эффективности, безопасности и автоматизации, активно интегрируют ML/AI-инструменты и развивают внутренние платформы для ускорения релизов и повышения прозрачности процессов. Продолжается переход на отечественные решения: растёт использование российских операционных систем и дистрибутивов Kubernetes, увеличивается доля on-premise-инсталляций и инструментов на базе открытого кода.

«Российский рынок ПО продолжает идти своим, местами парадоксальным путём: с одной стороны — жёсткое внешнее давление, с другой — необратимое взросление ИТ-ландшафта. В XL-сегменте тренд на интеграцию AI в производственные конвейеры только усилился. “Бигтехи” уже отстроили безопасные внутренние платформы, а теперь метят в AIOps и GenAI-копилотов, выжимая из DevOps максимум продуктивности. Средние и мелкие компании, пережившие кадровую турбулентность 2022 года, почти повсеместно выбрали проверенный OSS-стек — GitLab, Ansible, ELK, Kubernetes. Теперь к нему добавляются отечественные надстройки — от SCA-плагинов с ГОСТ-крипто до репозиториев кода вроде GitFlic. В результате рынок движется к гибридной модели — OSS-база плюс локальные специализированные модули, что и станет реалистичным сценарием 2025–2027 годов», — отметил Дмитрий Гаевский, Technical CPO, Т-Банк.


Об исследовании

«Состояние DevOps в России» — ежегодное индустриальное исследование, которое проводит команда «Экспресс 42» в России и странах СНГ. В исследовании отслеживается распределение организаций по профилям эффективности, определяются факторы, влияющие на эффективность, оценивается развитие инженерных практик. Целевая аудитория исследования — специалисты и руководители, которые тесно связаны с разработкой, тестированием и эксплуатацией программного обеспечения. Для поиска респондентов используется метод «снежного кома»: опрос с помощью рассылок по электронной почте, социальных сетей и маркетинговых кампаний. Это позволяет получить достаточно разнотипную исходную выборку.

Показать полностью
Исследования DevOps IT Искусственный интеллект Программное обеспечение Тренд Разработка Kubernetes Информационная безопасность Длиннопост
3
10
Tukamat
Tukamat
Лига Сисадминов

Cilium как универсальный компонент Kubernetes-инфраструктуры: от CNI до Service Mesh⁠⁠

1 месяц назад

Всем привет! На связи Алексей Баранович, сегодня я хочу вам рассказать о Cilium.

В современных Kubernetes-платформах стремление к упрощению архитектуры и снижению числа зависимостей становится всё более актуальным. Особенно это заметно при построении MVP-решений или управляемых платформ, где каждый дополнительный компонент — это не только рост сложности, но и увеличение поверхности для потенциальных сбоев и уязвимостей. В этом контексте Cilium выделяется как один из немногих проектов, способных заменить сразу несколько традиционных инструментов: CNI-плагин, Ingress-контроллер, Service Mesh и даже внешний LoadBalancer. Давайте разберёмся, как это работает и почему Cilium может стать единственным «сетевым» компонентом в вашем кластере.

Cilium как CNI: основа всего

Изначально Cilium позиционировался как высокопроизводительный CNI-плагин, использующий eBPF (extended Berkeley Packet Filter) вместо iptables или IPVS. Это даёт не только значительный прирост производительности, но и гибкость на уровне ядра Linux: политики сети, observability, балансировка трафика — всё это реализуется без перезаписи цепочек правил или установки дополнительных прокси.

Но Cilium быстро вырос за рамки CNI. Сегодня он предлагает полноценную платформу для сетевой и сервисной безопасности, объединяя в себе функциональность, которая раньше требовала развёртывания десятков отдельных компонентов.

Установка Cilium через Helm

Самый распространённый способ установки Cilium — через Helm. Сначала добавьте официальный репозиторий:

helm repo add cilium https://helm.cilium.io/

helm repo update

Затем установите с базовыми настройками (для большинства сред подойдёт):

helm install cilium cilium/cilium \

--namespace kube-system \

--set ipam.mode=kubernetes

Если вы хотите использовать собственный Pod CIDR (например, 10.224.0.0/13), как часто делают в on-prem:

helm install cilium cilium/cilium \

--namespace kube-system \

--set ipam.mode=cluster-pool \

--set ipam.operator.clusterPoolIPv4PodCIDRList="{10.224.0.0/13}" \

--set ipam.operator.clusterPoolIPv4MaskSize=22 \

--set ipv4NativeRoutingCIDR=10.224.0.0/13 \

--set routingMode=native \

--set autoDirectNodeRoutes=true

Эти параметры включают режим cluster-pool для IPAM и native routing через eBPF, что даёт максимальную производительность без kube-proxy.

Встроенный LoadBalancer без MetalLB или облачных провайдеров

Одна из самых болезненных тем в on-prem Kubernetes — отсутствие встроенного решения для внешнего LoadBalancer. Обычно приходится ставить MetalLB, использовать внешние балансировщики или обходиться NodePort.

Cilium решает эту проблему с помощью BGP-интеграции и DSR (Direct Server Return). Начиная с версии 1.13, Cilium поддерживает собственный L2 и BGP-режимы для сервисов типа LoadBalancer, что позволяет:

  • Назначать внешние IP-адреса сервисам без MetalLB.

  • Работать в bare-metal и виртуальных средах (включая VMware).

  • Использовать DSR для минимизации latency и снижения нагрузки на worker-ноды.

Чтобы включить встроенный LoadBalancer через Helm:

helm install cilium cilium/cilium \

--namespace kube-system \

--set loadBalancer.mode=dsr \

--set loadBalancer.acceleration=native \

--set loadBalancer.serviceTopology=true

Если вы используете BGP, добавьте:

--set loadBalancer.mode=bgp \

--set loadBalancer.bgp.announce=pool

И определите IP-пул в ConfigMap или через Helm-параметры, например:

--set loadBalancer.ipam.kubernetes.serviceIPBlocks="{192.168.10.0/24}"

Теперь любой Service с типом LoadBalancer автоматически получит IP из этого пула.

Gateway API: единая модель для Ingress и Egress

Традиционные Ingress-контроллеры (Nginx, Traefik, HAProxy) требуют отдельного развёртывания, настройки TLS, rate limiting, WAF и т.д. Cilium предлагает нативную поддержку Kubernetes Gateway API — современного стандарта управления трафиком, который заменяет устаревший Ingress API.

Чтобы включить Gateway API в Cilium, достаточно установить:

helm install cilium cilium/cilium \

--namespace kube-system \

--set gatewayAPI.enabled=true

После этого вы можете создавать ресурсы Gateway, HTTPRoute и другие. Пример Gateway:

apiVersion: gateway.networking.k8s.io/v1

kind: Gateway

metadata:

name: public-gateway

namespace: default

spec:

gatewayClassName: cilium

listeners:

- name: http

port: 80

protocol: HTTP

И HTTPRoute:

apiVersion: gateway.networking.k8s.io/v1

kind: HTTPRoute

metadata:

name: my-app-route

namespace: default

spec:

parentRefs:

- name: public-gateway

rules:

- matches:

- path:

type: PathPrefix

value: /api

backendRefs:

- name: my-app

port: 8080

Всё это работает без sidecar-прокси, благодаря eBPF и L7-парсингу на уровне ядра.

Service Mesh без Istio: Cilium + Envoy (опционально)

Istio — мощный, но тяжёлый Service Mesh. Он требует внедрения sidecar-прокси (Envoy) в каждый под, что увеличивает потребление ресурсов и усложняет отладку.

Cilium предлагает альтернативу: Cilium Service Mesh. Он реализует ключевые функции Service Mesh:

  • mTLS между сервисами (на основе SPIFFE/SPIRE или собственного PKI).

  • L7-наблюдаемость (HTTP, gRPC, Kafka).

  • Трассировка (через OpenTelemetry).

  • Retry, timeout, circuit breaking — через Envoy только при необходимости.

Чтобы включить базовые функции Service Mesh через Helm:

helm install cilium cilium/cilium \

--namespace kube-system \

--set l7Proxy=true \

--set hubble.enabled=true \

--set hubble.relay.enabled=true \

--set hubble.ui.enabled=true \

--set securityContext.capabilities.ciliumAgent="{CHOWN,KILL,NET_ADMIN,NET_RAW,IPC_LOCK,SYS_ADMIN,SYS_RESOURCE,DAC_OVERRIDE,FOWNER,SETGID,SETUID}"

Для mTLS:

--set encryption.enabled=true \

--set encryption.type=wireguard

Или для TLS на уровне сервисов:

--set serviceMesh.enabled=true

Если нужны продвинутые L7-политики с Envoy:

--set envoy.enabled=true

При этом sidecar не обязателен: базовые функции (шифрование, политики, метрики) работают через eBPF. Envoy подключается лишь тогда, когда нужны продвинутые L7-фичи. Это даёт гибкость: вы получаете Service Mesh без накладных расходов там, где он не нужен.

Cluster Mesh: много-кластерная сеть «из коробки»

Если у вас несколько Kubernetes-кластеров (например, dev/stage/prod или multi-region), традиционно для их объединения требуются сложные решения: submariner, istio multi-cluster, custom overlay-сети.

Cilium предлагает Cluster Mesh — встроенную возможность объединять кластеры в единую логическую сеть:

  • Сервисы из одного кластера доступны в другом по DNS-имени.

  • Единые сетевые политики применяются кросс-кластерно.

  • Поддержка identity-based security (не привязка к IP!).

Для включения Cluster Mesh нужно:

  1. Установить Cilium в каждом кластере с уникальным cluster.id и cluster.name.

  2. Настроить общий etcd или использовать clustermesh-apiserver.

Пример установки с поддержкой Cluster Mesh:

helm install cilium cilium/cilium \

--namespace kube-system \

--set cluster.name=cluster-a \

--set cluster.id=1 \

--set clustermesh.enabled=true \

--set clustermesh.useAPIServer=true

Затем выполнить настройку связи между кластерами с помощью cilium-cli:

cilium clustermesh enable --context cluster-a

cilium clustermesh enable --context cluster-b

cilium clustermesh connect cluster-a cluster-b

После этого сервисы автоматически станут доступны через DNS вида <service>.<namespace>.svc.clusterset.local.

Заключение

Cilium — это не просто CNI. Это единая платформа для всего сетевого стека Kubernetes, которая позволяет отказаться от Nginx Ingress, MetalLB, Istio и даже внешних балансировщиков в большинстве сценариев. Для инженеров, строящих управляемые, безопасные и минималистичные Kubernetes-платформы, Cilium становится не просто выбором, а стратегическим решением.

Если вы стремитесь к «меньше компонентов — больше контроля», Cilium стоит рассмотреть уже сегодня.

Показать полностью
[моё] Kubernetes DevOps Текст Длиннопост
5
21
Tukamat
Tukamat
Лига Сисадминов

Talos OS — способ сделать Kubernetes безопасным⁠⁠

1 месяц назад

Привет, друзья! Меня зовут Алексей Баранович, и сегодня я хочу рассказать о системе, которая кардинально изменила мой подход к развёртыванию и управлению Kubernetes — Talos Linux. Это не просто «ещё одна лёгкая ОС». Talos — это операционная система, спроектированная исключительно для Kubernetes, с философией иммутабельности, безопасности и полной автоматизации. Давайте разберёмся, почему он действительно крут — и что он умеет «из коробки».

Talos Linux: Kubernetes-нативная ОС нового поколения

Talos Linux — это open-source операционная система, разработанная компанией Sidero Labs, которая полностью отказывается от традиционных концепций Linux-дистрибутивов. В Talos нет:

  • пакетного менеджера (apt, yum, dnf);

  • shell-доступа (даже для root);

  • SSH-сервера;

  • возможности редактировать файлы вручную после загрузки.


Всё управление происходит через единый gRPC API, защищённый mTLS, и утилиту командной строки talosctl.

Официальный сайт

Полная документация

Иммутабельность и безопасность как основа

  • Корневая файловая система Talos монтируется только для чтения. Это означает:

  • Невозможно случайно или злонамеренно изменить системные файлы.

  • Все обновления — атомарные: система загружается либо полностью новой версией, либо откатывается.

  • Минимальная поверхность атаки: в образе нет интерпретаторов (Python, Bash), ненужных библиотек или демонов.

Даже диагностика не требует shell: для просмотра логов, состояния сервисов или ядра используется утилита osctl, работающая поверх API.

Подробнее о модели безопасности

Декларативная конфигурация: один YAML на всё

Вся конфигурация Talos задаётся в одном файле — machine.yaml. Он описывает:

  • тип ноды (control plane или worker);

  • сетевые настройки;

  • параметры времени и сертификатов;

  • статические поды (если нужны);

  • настройки kubelet и kube-proxy.

Пример минимальной конфигурации control plane:

version: v1alpha1

machine:

type: controlplane

token: supersecret

ca:

crt: LS0t...

key: LS0t...

cluster:

id: my-cluster

controlPlane:

endpoint: https://192.168.1.10:6443

Этот файл передаётся ноде при загрузке (через cloud-init, ISO, PXE и т.д.) и не может быть изменён вручную — только через обновление через talosctl apply.

Примеры конфигураций

Сетевая подсистема: что есть «из коробки»?

Важный момент: Talos не включает CNI по умолчанию. Однако он нативно поддерживает Flannel как встроенный CNI-плагин. Это означает, что при указании:

cluster:

network:

cni:

name: flannel

Flannel будет автоматически развёрнут как часть bootstrap-процесса — без необходимости применять манифесты вручную.

Если вы хотите использовать другой CNI (Calico, Cilium, Weave и т.д.), его нужно устанавливать вручную после инициализации кластера, например, через kubectl apply или Helm. Talos не навязывает выбор — он даёт вам чистую, предсказуемую основу.

Поддерживаемые CNI

Полный жизненный цикл кластера — без ручного вмешательства

  • Talos управляет не только запуском Kubernetes, но и всем его жизненным циклом:

  • Инициализация кластера: talosctl bootstrap — инициирует etcd и control plane.

  • Обновление ОС и Kubernetes: через talosctl upgrade — с возможностью отката.

  • Резервное копирование etcd: talosctl etcd backup — создаёт снапшоты etcd.

  • Восстановление из бэкапа: talosctl etcd restore.

  • Безопасное удаление нод: talosctl reset — полностью очищает ноду.

Всё это работает без shell, без SSH, без риска человеческой ошибки.

Управление кластером

Локальная разработка и тестирование

Хотите попробовать Talos? За пару минут можно развернуть кластер на своём ноутбуке:

talosctl cluster create --nodes 3 --controlplanes 1

Это запустит виртуальные машины через QEMU или Docker (в зависимости от ОС), настроит сеть и выдаст готовый kubeconfig.

Локальные платформы

Почему Talos — это прорыв?

  • Предсказуемость: все ноды идентичны, конфигурация декларативна.

  • Безопасность: нет shell, нет пакетов, только необходимый минимум.

  • Автоматизация: всё через API, идеально для GitOps и CI/CD.

  • Сертификация: Talos прошёл официальные тесты CNCF Kubernetes Conformance.

Результаты conformance-тестов

Полезные ссылки

GitHub

Документация:

CLI-инструменты: talosctl

Сообщество в Slack:

Заключение

Talos Linux — это не просто инструмент, а новая парадигма управления инфраструктурой. Он убирает всё лишнее, оставляя только то, что нужно для надёжного и безопасного запуска Kubernetes. Если вы устали от «снежинок-серверов», ручных правок и нестабильных обновлений — пришло время попробовать Talos.

Удачи в автоматизации, и пусть ваши кластеры будут иммутабельными!

Показать полностью
[моё] Linux Kubernetes DevOps Кластер Текст Длиннопост
10
80
imctobitch
imctobitch
Программисты шутят
Серия I'm CTO, bitch

Типовая архитектура⁠⁠

2 месяца назад
Типовая архитектура
Показать полностью 1
[моё] I`m CTO bitch Архитектура IT юмор Скриншот Идиотизм Страх и ненависть в Лас-Вегасе Golang Kubernetes Mvp Архитектор Программирование
5
10
AppFox
AppFox

Kubernetes в продакшене: основные понятия и вопросы на собеседовании⁠⁠

6 месяцев назад

Меня зовут Александр, я CTO компании AppFox. Мы более 10 лет занимаемся заказной разработкой и также имеем собственные продукты.

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

Что такое Kubernetes простыми словами?

Разберем на примере интернет-магазина с тремя серверами:

  1. Сервер №1 – основной (принимает заказы).

  2. Сервер №2 – база данных (хранит товары и пользователей).

  3. Сервер №3 – бекенд для API (обрабатывает платежи).

Проблема:

  • В Чёрную пятницу приходит в 10 раз больше покупателей. В результате, сервера №1 и №3 падают от нагрузки, магазин "висит".

  • Сервер №2 (база данных) ломается, а все заказы теряются.

  • Чтобы добавить новые сервера, админ вручную копирует настройки, что занимает часы.

Решение при помощи Kubernetes.

Те же 3 сервера, но теперь они управляются Kubernetes.

  1. Автомасштабирование

    • При наплыве покупателей Kubernetes автоматически запускает дополнительные копии серверов №1 и №3.

    • Когда нагрузка падает – лишние сервера отключаются.

  2. Отказоустойчивость

    • Если сервер №2 (база данных) упал, Kubernetes сразу переключает нагрузку на его резервную копию.

    • Покупатели даже не замечают проблемы.

  3. Гибкие обновления

    • Вы хотите обновить API (сервер №3).

    • Kubernetes делает это без downtime:

      • Запускает новые версии API, переключает трафик на них и останавливает старые.

  4. Экономия денег

    • Ночью, когда магазин почти не используют, Kubernetes отключает часть серверов.

    • Утром – снова включает.

Что это даёт бизнесу?

  • Магазин не "падает" в пиковые нагрузки (Чёрная пятница, распродажи).

  • Нет потери заказов – если что-то сломалось, система сама всё починит.

  • Быстрые обновления – можно выпускать новые фичи без остановки магазина.

  • Экономия на серверах – не нужно держать "лишние" мощности.

Kubernetes: мощный инструмент, но не серебряная пуля

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

Термин k8s является синонимом Kubernetes и означает 8 букв между первой и последней буквой. Да, программисты любят сокращения :)

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

Когда Kubernetes оправдан:

  • Микросервисная архитектура с большим количеством сервисов.

  • Необходимость автоматического масштабирования под нагрузку.

  • Высокие требования к отказоустойчивости.

  • Гибкость деплоя (Canary, Blue-Green, A/B-тестирование).

Когда Kubernetes — избыточное решение:

  • Монолитное приложение с низкой нагрузкой.

  • Маленькие проекты без потребности в масштабировании.

  • Стартапы с ограниченным бюджетом.

  • Проект для демо или MVP, в которых планируется масштабирования только после получения инвестиций

  • Команда не готова к сложности k8s (обучение и поддержка требуют ресурсов).

В компании AppFox мы используем Kubernetes при построения кластеров для мультиплеерных игр и проектов со сложной микросервисной архитектурой. В частности, мы его использовали при разработке решений для СберБанка и Банка ВТБ.

Основные понятия Kubernetes

  • Pod — минимальная единица развертывания (может содержать один или несколько контейнеров).

  • Deployment — декларативное описание желаемого состояния приложения.

  • Service — абстракция для доступа к подам (ClusterIP, NodePort, LoadBalancer).

  • Ingress — управление внешним трафиком (роутинг, SSL).

  • ConfigMap & Secret — хранение конфигураций и чувствительных данных.

  • PersistentVolume (PV) & PersistentVolumeClaim (PVC) — работа с постоянным хранилищем.

  • Helm — менеджер пакетов для k8s (чарты).

Вопросы по Kubernetes на собеседовании

Теперь самое интересное — какие вопросы задают кандидатам в зависимости от их уровня.

Для backend-разработчика

Что такое контейнер и зачем нужен Docker?

  • Контейнер - это изолированное окружение для запуска приложений со всеми зависимостями.

  • Docker - платформа для создания и управления контейнерами.

Разница между Docker и Kubernetes

  • Docker создает контейнеры

  • Kubernetes управляет множеством контейнеров на разных серверах.

Как работает kubectl get pods? Что выведет эта команда?

Команда показывает список подов (pods) - минимальных единиц развертывания в k8s. Вывод включает имя пода, статус, количество рестартов и возраст.

Что такое Deployment и зачем он нужен?

Это объект k8s для декларативного управления подами. Позволяет:

  • Разворачивать приложения

  • Обновлять их (rolling update)

  • Возвращаться к предыдущим версиям (rollback)

  • Масштабировать количество реплик

Как приложение в k8s получает конфигурацию (ConfigMap, Secrets)?

  • ConfigMap хранит конфигурации (например, настройки приложения)

  • Secrets - чувствительные данные (пароли, токены). Они монтируются в поды как файлы или переменные окружения.

Что такое Pod, Deployment и Service?

  • Pod — это минимальная единица в Kubernetes

  • Deployment управляет жизненным циклом Pod'ов

  • Service предоставляет сетевой доступ.

Как подать переменные окружения в Pod?

Через env, envFrom, ConfigMap, Secret.

Что произойдет, если Pod упал?

Kubernetes сам его перезапустит — важно понимать работу контроллеров.

Для Junior DevOps

Как создать под с помощью kubectl?

Как посмотреть логи пода?

Как работает Service? Какие типы сервисов знаете?

Абстракция для доступа к набору подов. Типы:

  • ClusterIP (внутренний IP)

  • NodePort (порт на каждой ноде)

  • LoadBalancer (внешний балансировщик)

  • ExternalName (CNAME-запись)

Как обновить приложение в k8s (стратегии деплоя)?

  • RollingUpdate (постепенная замена подов)

  • Recreate (удаление всех старых перед созданием новых)

Что делает kubelet и kube-proxy?

  • kubelet - агент на нодах, запускает и контролирует контейнеры

  • kube-proxy - обеспечивает сетевую связность между сервисами

Как создать кластер Kubernetes?

Как подключить volume к Pod'у?

Volume (том) в Kubernetes позволяет сохранять данные между перезапусками Pod'ов. Есть несколько типов томов, но для постоянного хранения данных используются PersistentVolume (PV) и PersistentVolumeClaim (PVC).

  • PersistentVolume — это ресурс в кластере, представляющий физическое хранилище (например, диск в облаке или NFS-шару). PV создаётся администратором кластера и существует независимо от Pod'ов.

  • PersistentVolumeClaim — запрос Pod'а на выделение PV. PVC связывается с подходящим PV (или динамически создаёт его, если настроен StorageClass). PVC монтируется в Pod как volume. Если не хочется создавать PV вручную, можно использовать StorageClass для автоматического создания томов.

Чем отличается Horizontal Pod Autoscaler от Vertical Pod Autoscaler?

  • HPA масштабирует количество Pod'ов на основе метрик нагрузки (увеличивает или уменьшает число реплик (replicas) Deployment'а в зависимости от, например, CPU или памяти, т.е., нагрузка выросла — добавили ещё Pod'ов).

  • VPA изменяет ресурсы (CPU, память) у контейнеров внутри Pod'а

Для Middle DevOps

Как настроить Ingress для доступа к сервису?

Как сделать Horizontal Pod Autoscaler (HPA)?

Как управлять ресурсами (requests/limits)?

Как настроить PersistentVolume для stateful-приложения?

Как диагностировать проблему с CrashLoopBackOff?

  1. Посмотреть логи пода

  2. Проверить readiness/liveness пробы

  3. Убедиться, что контейнеру хватает ресурсов

  4. Проверить монтирование томов

  5. Изучить события кластера:kubectl describe pod <pod-name>kubectl get events

Для Senior DevOps

Как настроить NetworkPolicy для изоляции подов?

Как работает etcd и что делать при его проблемах?

Распределенное key-value хранилище - "мозг" Kubernetes. Проблемы и решения:

  • Недостаток места: регулярная дефрагментация

  • Высокая задержка: оптимизация сети

  • Потеря кворума: восстановление из бэкапа

Как настроить мониторинг (Prometheus + Grafana)?

  1. Установка Prometheus Operator

  2. Настройка ServiceMonitor для сбора метрик

  3. Создание Grafana дашбордов

  4. Настройка алертов через Alertmanager

Как организовать multi-cluster управление?

Варианты:

  • Kubefed (Federation v2)

  • Cluster API

  • Коммерческие решения (GKE Anthos, EKS Anywhere)
    Основные задачи: синхронизация ресурсов, единая аутентификация, централизованное логирование.

Как оптимизировать costs в облачном k8s (автоскейлинг нод)?

  • Использование spot-инстансов

  • Автомасштабирование нод (Cluster Autoscaler)

  • Вертикальное масштабирование подов (VPA)

  • Планирование подов на дешевые ноды (node affinity/taints)

  • Использование serverless-решений (AWS Fargate, GCP Cloud Run)

Заключение: Kubernetes — мощный инструмент, но не панацея

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

Главный совет:

  • Если у вас микросервисы, высокая нагрузка или требовательная инфраструктура — Kubernetes может стать вашим решением.

  • Если проект небольшой или монолитный — начните с простых решений (Docker Compose, managed-сервисов) и масштабируйтесь постепенно.

Попробуйте Kubernetes в действии:

  • Разверните локальный кластер через minikube или kind.

  • Поэкспериментируйте с Helm-чартами и автоскейлингом.

  • Изучите managed-решения (GKE/EKS/AKS), чтобы оценить их преимущества.

Показать полностью 15
[моё] IT Разработка Системное администрирование Программирование Программист Kubernetes Интервью Собеседование DevOps Серверная Оптимизация Длиннопост
3
elena.davydova

Deckhouse Conf 2025: как прошла первая техническая конференция от команды Deckhouse⁠⁠

7 месяцев назад

Масштабная технологическая конференция объединила свыше 500 ведущих специалистов в области DevOps, Kubernetes и платформенной разработки

Deckhouse Conf 2025 - первая техническая конференция команды разработчиков Deckhouse

Deckhouse Conf 2025 - первая техническая конференция команды разработчиков Deckhouse

Компания «Флант» провела Deckhouse Conf 2025 — первую техническую конференцию, организованную командой разработчиков Deckhouse, которая состоялась в Центре событий РБК. Событие объединило более 500 ведущих специалистов в области DevOps, Kubernetes и платформенной разработки.

Deckhouse Conf 2025 стала площадкой для обмена опытом и обсуждения актуальных вопросов Cloud Native-разработки. Программа конференции включала доклады, посвященные практическим аспектам работы с Kubernetes, информационной безопасности, мониторингу, DevOps и SRE. Участники узнали о последних обновлениях продуктов Deckhouse, планах развития Deckhouse Kubernetes Platform и получили ценные рекомендации по оптимизации инфраструктуры и повышению эффективности процессов разработки.

Александр Титов, генеральный директор компании «Флант»

Александр Титов, генеральный директор компании «Флант»

«2024 год для Deckhouse Kubernetes Platform стал периодом стремительного развития — платформа показала рост выручки на 170%, а к началу 2025 года количество управляемых кластеров превысило 1000. Согласно исследованию TAdviser, объём российского рынка коммерческих платформ контейнеризации в 2023 году составил 931 млн рублей с учётом выручки от лицензий и поддержки OnPremise-решений. В этом сегменте платформа Deckhouse Kubernetes Platform от компании «Флант» уверенно занимает лидирующие позиции с долей рынка 31%», —  рассказал Александр Титов, генеральный директор компании «Флант».

Технологическая дорожная карта Deckhouse Kubernetes Platform в 2024 году была направлена на расширение поддерживаемых вычислительных сред и наращивание функциональности. Главным требованием при добавлении новых возможностей и внесении изменений являлось сохранение достигнутой производительности и объема потребляемых ресурсов. На текущий момент крупнейшая промышленная инсталляция DKP насчитывает более 450 узлов и свыше 20000 подов.

Давид Мэгтон, технический директор, сооснователь компании «Флант»

Давид Мэгтон, технический директор, сооснователь компании «Флант»

«Kubernetes перестал быть просто инструментом — теперь это новый стандарт для управления инфраструктурой, — отметил Давид Мэгтон, технический директор, сооснователь компании «Флант». — Но с ростом технических возможностей повышается и сложность управления ими. Наша миссия состоит в том, чтобы разорвать эту связь и обеспечить простоту разработки. Поэтому основой развития DKP является подход SDx (Software Defined Everything), поверх которого строится “правильный” API».

Давид Мэгтон выделил пять главных принципов, на основе которых происходит развитие API DKP. Первый – декларативный подход: пользователь задает правила, по которым система выполняет необходимые операции с использованием собственных механизмов. Второй – одна точка изменения того или иного параметра в API, обеспечивающая простоту использования. Третий – единообразие: применение единых подходов и терминов для всех инструментов управления в экосистеме. Четвертый – защита от неправильного использования: автоматическое ограничение нерабочих комбинаций параметров конфигураций. Пятый – обратная связь на любое действие пользователя.

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

«Мы помогаем бизнесу управлять приложениями и ресурсами. Наша платформа знает, что нужно приложению, и может динамически подстраиваться под нагрузку — давать больше или меньше ресурсов: процессора, памяти и так далее. В этом преимущество DKP: платформу можно использовать  в окружении с разными и меняющимися нагрузками. Это не коробка, в которой ничего нельзя поменять — это открытая платформа, которая развивается в такт с потребностями заказчика, обеспечивая непрерывные обновления и интеграцию с другими системами, чтобы новые возможности появлялись без долгого ожидания и приносили максимум пользы. Вся индустрия движется к этому подходу, и мы задаем тренд», — подчеркнул Александр Титов.

Таким образом, развитие DKP имеет свои особенности, но идет в соответствии с трендами эволюции всей экосистемы Kubernetes. Сегодня решение успешно применяется во всех ключевых секторах экономики: финансовые организации, государственный сектор, промышленные предприятия,  ритейл и e-come выбирают Deckhouse Kubernetes Platform для своих цифровых инфраструктур. Платформа одинаково эффективно работает в любых средах — от bare-metal серверов до сложных гибридных архитектур, подтверждая свою репутацию наиболее универсального и надёжного решения для контейнеризации на российском рынке.

Фото Deckhouse conf доступно по ссылке

Показать полностью 4
Импортозамещение Kubernetes Российское по Разработка Промышленность Информационная безопасность Программирование It-инфраструктура IT DevOps ВКонтакте (ссылка) Длиннопост
0
elena.davydova

Безопасная разработка приложений⁠⁠

8 месяцев назад

«Лаборатория Касперского» и компания «Флант» подтвердили технологическую совместимость Kaspersky Container Security и Deckhouse Kubernetes Platform

Безопасная разработка приложений

«Лаборатория Касперского» и крупнейший российский контрибьютор Kubernetes — компания «Флант» — объявили о технологической совместимости Kaspersky Container Security и Deckhouse Kubernetes Platform. Интеграция решений позволяет обеспечить комплексную защиту контейнерных приложений на всех этапах их жизненного цикла — от разработки до эксплуатации.

Deckhouse Kubernetes Platform (DKP) — лидер рынка российских Kubernetes-платформ*, полнофункциональная платформа управления контейнерными нагрузками для построения сверхнадежной enterprise-инфраструктуры. Решение входит в единый реестр ПО и является первой Kubernetes-платформой на российском рынке, прошедшей сертификацию ФСТЭК России**. На сегодняшний день на DKP запущено свыше 1000 кластеров в крупных компаниях нефтегазовой отрасли, финансового сектора и ритейла. Большой проектный опыт позволил разработчику занять ведущие позиции по контрибуциям в Kubernetes среди российских компаний и стать отраслевым технологическим стандартом.

Проведенные тестирования подтвердили совместимость решений: пользователи смогут воспользоваться интеграцией для реализации принципов DevSecOps и многоуровневой защиты контейнеров, включая контроль на уровне runtime.

«Контейнеры и Kubernetes прочно вошли в нашу жизнь. Они уже активно используются в production, а значит, вопрос безопасности нельзя обходить стороной. И если раньше наши клиенты использовали только средства безопасности из состава нашей платформы, то сейчас наблюдаем, что появляются наложенные средства для обеспечения безопасности в контейнерах. Kaspersky Container Security в процессе проверки совместимости отлично показал себя, и мы рады, что можем предложить нашим заказчикам возможность выбирать, какие инструменты лучше подходят для решения их задач по информационной безопасности», — отмечает Константин Аксёнов, директор департамента разработки Deckhouse компании «Флант».

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

«Мы оперативно реагируем на запросы и потребности отечественного рынка контейнерной разработки. Новые функции открывают дополнительные возможности не только для ИБ-специалистов, но и для разработчиков и ИТ-команд компаний, которые выбрали путь создания приложений в контейнерных средах, — комментирует Тимофей Титков, руководитель направления развития продуктов облачной и сетевой безопасности «Лаборатории Касперского». — Мы активно идём навстречу пожеланиям заказчиков и рынка, чтобы сделать разработку приложений по-настоящему безопасной, и продолжим совершенствовать наше решение, чтобы закрыть все свойственные контейнерным средам риски информационной безопасности».

Показать полностью
Промышленность Информационная безопасность Импортозамещение IT Kubernetes It-инфраструктура Российское по Российское производство
2
elena.davydova

Количество кластеров под управлением Deckhouse Kubernetes Platform превысило тысячу⁠⁠

8 месяцев назад

К началу 2025 года Deckhouse Kubernetes Platform поддерживает более 1000 кластеров в различных отраслях.

Количество кластеров под управлением Deckhouse Kubernetes Platform превысило тысячу

Deckhouse Kubernetes Platform (DKP) от компании «Флант» достигла значимого показателя – к началу 2025 года количество кластеров под  управлением платформы превысило 1000, охватывая широкий спектр отраслей: ретейл, промышленность, банкинг, финтех, сырьевые компании, госструктуры, ИТ, медицину, образование, логистику и СМИ. Большой проектный опыт позволил разработчику занять лидирующие позиции по контрибуциям в Kubernetes среди российских компаний и стать отраслевым технологическим стандартом.

За семь лет существования DKP зарекомендовала себя как надежное решение для развертывания и управления Kubernetes-кластерами на любой инфраструктуре: от физических серверов и виртуальных машин до публичных, частных и гибридных облачных сред. Платформа поддерживает широкий спектр сценариев использования, включая edge-инсталляции, платформы разработки, Kubernetes-as-a-Service (KaaS) и работу в аттестованных системах КИИ.

С 2020 года количество кластеров под управлением Deckhouse Kubernetes Platform демонстрирует стабильный рост по всем направлениям: Community Edition, коммерческие редакции и Managed Kubernetes. Свободно распространяемая Community Edition составляет более 40% от общего числа инсталляций, что свидетельствует о востребованности платформы в сообществе разработчиков, насчитывающем более 1700 участников.

Сегмент коммерческих редакций DKP, включая сертифицированные ФСТЭК России, демонстрирует наиболее динамичный рост, увеличиваясь более чем в два раза ежегодно и составляя около 30% от общего числа инсталляций. Исторически важным для компании является сервисное направление Managed Kubernetes, в рамках которого специалисты «Флант» обеспечивают круглосуточное обслуживание кластеров клиентов. Практический опыт DevOps-инженеров компании способствует постоянному совершенствованию DKP, позволяя предлагать рынку высококачественный продукт.

«Мы выражаем искреннюю благодарность нашим клиентам и партнёрам за совместную работу и доверие, которые стали основой для достижения столь значимых результатов. Наша платформа продолжает подтверждать свою надежность и гибкость, обслуживая широкий спектр отраслей и демонстрируя постоянный рост. Будучи лидерами в области Kubernetes-решений, мы стремимся поддерживать высокие стандарты качества и безопасности, предоставляя новейшие решения для устойчивого развития бизнеса», – подчеркнул Александр Титов, генеральный директор компании «Флант».

Deckhouse Kubernetes Platform (DKP)  — платформа контейнеризации, лидер рынка российских Kubernetes-платформ*, первая Kubernetes-платформа, получившая сертификат ФСТЭК России**. Решение позволяет создавать идентичные кластеры и управлять ими в любой ИТ-инфраструктуре. DKP можно разворачивать в публичных и приватных облаках, поверх любой виртуализации, на bare-metal-серверах, а также в гибридной модели. Платформа имеет более 240 внедрений в ключевых отраслях экономики: нефтегазовом секторе, банковской сфере, финтехе, ритейле, а также в государственном секторе. Среди клиентов — «Газпром нефть», Банк России, «ДОМ.РФ», «ОТП Банк», «Лемана ПРО», Mindbox, «ВсеИнструменты.ру», «Ленточка» (сервис доставки компании «Лента»), ЕДИНЫЙ ЦУПИС и другие.

*Лидер «Рейтинга российских платформ Kubernetes 2024» ИТ-маркетплейса Market.CNews и  «Рейтинга Kubernetes-платформ 2025» ИТ-ресурса IaaSSaaSPaas. Входит в число крупнейших поставщиков ИТ-решений для банков и промышленности (Рейтинги TAdviser, 2024 г).

*Сертификат ФСТЭК России № 4860 от 4 октября 2024 г., удостоверяющий, что Deckhouse Platform Certified Security Edition является средством контейнеризации 4-го класса защиты и соответствует требованиям документов «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (ФСТЭК России, 2020) — по 4-му уровню доверия, «Требования по безопасности информации к средствам контейнеризации» (ФСТЭК России, 2022) — по 4-му классу защиты.

Показать полностью
Импортозамещение IT It-инфраструктура Kubernetes Российское по Промышленность Фстэк Информационная безопасность Российское производство
0
Посты не найдены
О нас
О Пикабу Контакты Реклама Сообщить об ошибке Сообщить о нарушении законодательства Отзывы и предложения Новости Пикабу Мобильное приложение RSS
Информация
Помощь Кодекс Пикабу Команда Пикабу Конфиденциальность Правила соцсети О рекомендациях О компании
Наши проекты
Блоги Работа Промокоды Игры Курсы
Партнёры
Промокоды Биг Гик Промокоды Lamoda Промокоды Мвидео Промокоды Яндекс Маркет Промокоды Пятерочка Промокоды Aroma Butik Промокоды Яндекс Путешествия Промокоды Яндекс Еда Постила Футбол сегодня
На информационном ресурсе Pikabu.ru применяются рекомендательные технологии