Невероятная щедрость!

Специальная акция от нашего надежного VPS-хостинга: только 14 дней действует скидка 40%, при оформлении заказа сроком на 6 или 12 месяцев!

Почему это ВЫГОДНО?

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

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

Успейте воспользоваться акцией прямо сейчас и обеспечьте своему сайту надежное будущее с нашим VPS-хостингом! Теперь ваши ресурсы станут мощнее, быстрее и эффективнее, а затраты снизятся вдвое!

Акция действует до 11 мая 2025 при новом заказе ВМ на срок 6 или 12 месяцев, для тарифных планов Старт2, Старт3 и Старт4. Хостинг оставляет за собой право прекратить заказ новых ВМ раньше.

Успевайте!!!
elenahost.ru
https://billing.elenahost.ru

Главный прикол с k8s: поднять базовый кластер займёт всего 15 минут. А вот чтобы он реально заработал, ответить на все вопросы перед установкой, всё спланировать — на это нужны дни, реально дни мозгового штурма и планирования. Ну или потом придётся разбирать и делать ещё раз. Несколько раз.

Кубер унижает человеческое достоинство разными способами и на разных этапах. Это часть опыта от пользования продуктом. Так задумано.

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

Начнём с простых вещей, например, выбора дистрибутива, выбора способа хранения данных (и динамического выделения места), а также того, куда складывать пароли к критичным ресурсам. На этих трёх выборах ломается примерно 50 % админов.

Поехали в ад!



Архитектура

Kubernetes — это кластер. То есть много серверов, которые работают вместе. Эти серверы называются нодами, или узлами. Есть ноды управляющие (Control Plane). Раньше их звали Master, но сейчас это слово немодное, так что Control Plane. А есть ноды рабочие (Worker Nodes) — вот на них-то и крутятся ваши приложения в контейнерах (точнее, в подах).

Рядом с Control Plane живёт etcd. Это распределённая база данных (ключ-значение), где Кубер хранит всю инфу о себе и о том, что в нём запущено: какие поды, какие сервисы, какие конфиги — вот это всё. Она тоже обычно распределена по нескольким управляющим нодам для надёжности. Для полной надёжности её ставят отдельно.

Работает это так: вы пишете файл с конфигом, который описывает условия и состояния, например: «Хочу такой-то деплой из стольких-то подов, чтобы он при таких условиях вёл себя так, а при таких — вот так». Эти правила хранятся в etcd, а Control Plane следит за их исполнением. Если есть разница между тем, как надо, и тем, как есть, — всё приводится в нужное состояние. То есть что-то грохается или добавляется. Автоматически.

Казалось бы, всё просто, но тут огромная кроличья нора.

Дело — в условиях и работе приложений. Чтобы прописать нормальные условия для работы кластера, придётся вытащить наружу кучу метрик изнутри ваших приложений. Потому что более-менее доступные условия «из коробки» — это, например, «Если нагрузка на процессор больше 80 % 10 секунд подряд», а не «Если я записываю в базу данных быстрее чем за 0,1 секунды, и очередь — меньше 1 000 событий».

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

Вторая особенность — вам надо обеспечить правильное поведение приложения при добавлении-убавлении контейнеров. Это касается транзакций (надо корректно закрываться после обработки транзакции, а не терять её), записи на диск и так далее.

С диском — тоже отдельный сюрприз: мышление придётся изменить. Но давайте по порядку.

Если у вас планируется реально большой, нагруженный кластер, то Control Plane и особенно etcd лучше выносить на отдельные, выделенные ноды. Не надо на них вешать рабочую нагрузку, пусть они занимаются только управлением. У себя на деве или стейдже мы можем и совмещать, чтобы экономить ресурсы, но на проде лучше делить. В наших собственных продуктах на dev-части мы совмещаем узлы, а на прод-части создаём два отдельных контура.

Почему это проблема?



Потому что это унижает человеческое достоинство. Просто знайте: то, что у вас поначалу не всё получается, — это нормально. Это часть процесса. Так задумано. Вот как сталкивались с этим наши участники команды разработки:

• Начинаешь с Kubernetes — вроде всё понятно по верхам, курс прошёл, потыкал. Гугл и AI помогают. Но потом лезешь глубже: драйверы для хранилищ, autoprovisioning, сети… и это просто стена! Понять базово — это одно, а настроить под себя — совсем другое. Нужны или огромный опыт, или куча времени, чтобы просто сидеть и ковыряться. Настроить выход наружу? Тоже целая история с кучей нюансов: часто просто копируешь решения, не до конца понимая.
• Написать код — быстро. А вот развернуть его в Кубере первый раз — это дни мучений! Сертификаты, связь между сервисами, настройка Argo CD с ключами — всё совершенно неинтуитивно. Если рядом нет опытного DevOps, который проведёт за ручку, то это просто взрыв мозга и боль: не понимаешь, за что страдаешь! Но когда наконец всё настроишь, думаешь: «Боже, как же хорошо! Теперь только так и буду работать! Только, пожалуйста, пусть кто-нибудь другой развернёт сам Кубер, я этого больше не хочу!»
• Пытаешься соединить внутренние сервисы Кубера с внешним миром — и тут начинаются танцы с бубном. Куча технологий, и все — на разной стадии готовности.
• Самое сложное в начале — просто понять, как вообще работать с Kubernetes. У тебя не запускается простой сайт в Docker-контейнере, а DevOps объясняет проблему терминами Кубера, и ты даже не понимаешь, как это отладить, куда смотреть. Потом тебе дают конфиг для kubectl и говорят: «Разбирайся сам». Ощущение, будто тебя выкинули с лодки посреди озера: плыви!

Что ставить
Это классика жанра для новичка. Открываешь доку Кубера, а там бац — десяток способов установки! И хрен поймёшь, какой тебе нужен.

Дальше можно гуглить «Kubernetes Hard Way» и «Kubernetes Simple Way»: там статьи разной степени упоротости. Поскольку на дворе — XXI век, можно попросить помочь и LLM, но это будет step-by-step-воспроизведение одной из этих двух инструкций.

Третий путь — пойти к облачному провайдеру и там найти managed-service для k8s, обычно выглядящий для пользователя как волшебная кнопка «Создать кластер Kubernetes». Жмакнули, подождали минут 10–15, и вам вываливается файлик с конфигом. А дальше наступает ступор. Смотрите на этот файлик и думаете: «Ну зашибись, а дальше-то что?»

Мой личный совет: прежде чем лезть в облака или мучиться со своими серверами, поставьте себе на ноут Minikube. Это такая песочница, маленький Кубер на одной машине. Погоняйте его, потыкайте палочкой, разберитесь с базовыми понятиями: что такое Pod, Service, Deployment — вот это всё. Освойте kubectl — это главная команда для общения с кластером. Вот когда вы через это пройдёте, тогда и Managed Service в облаке станет в разы понятнее, и вы будете знать, что делать с этим загадочным admin.conf.

Итак, вариантов три с половиной:

• Managed Service в облаке (типа нашего H3LLO CLOUD) — это когда вы приходите к провайдеру, говорите: «Хочу Кубер», нажимаете пару кнопок (ну или не пару: всё зависит от упоротости провайдера), получая готовый кластер и kubeconfig. Плюсы: не надо париться с установкой и обновлением управляющих нод (Control Plane, etcd): всё это — головная боль провайдера. Масштабирование нод — часто «из коробки»: настроил правило, и если нагрузка растёт, то провайдер сам добавит виртуалок в ваш кластер. Автоматическое выделение persistent volume любого размера в любом количестве — тоже на провайдере, как и LoadBalancer для внешнего доступа. Минусы: зависимость от провайдера, его ограничений (про них ещё скажу) и его ценовой политики.
• На своих серверах (Bare Metal) или своих виртуалках. Полный контроль над железом, над софтом, над настройками. Делайте что хотите. Но на вас падает вся сложность установки, настройки, обновлений, бэкапов. Масштабировать кластер новыми серверами? Только ручками: пошёл, купил сервер, поставил в стойку, настроил, добавил в кластер. Никакой магии.
• Руками в облаке на виртуалках: можно, но зачем? Если очень хочется поковыряться в кишках, но своего железа нет. Или если Managed-сервис чем-то критично не устраивает (например, версией Кубера или доступными опциями). По сути, это то же самое, что и Bare Metal, только серверы арендованные. Вся сложность — ваша, но хотя бы серверы покупать не надо.

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

Как ставить

• Kubeadm — официальная утилита от создателей Кубера. Но это, как я говорю, «путь самурая». Все команды — ручками, все конфиги — ручками, бутстрэп каждой ноды — ручками. Если вы не мазохист и ставите Кубер первый раз — не советую категорически: намучаетесь и проклянёте всё на свете.
• Kubespray — это наш выбор для своих инсталляций на железе или виртуалках. Это, по сути, набор готовых Ansible-сценариев. Он автоматизирует 90 % рутины по развёртыванию кластера на куче нод. Есть неплохие статьи, как его подготовить и запустить. Очень рекомендую начинать именно с него, если вы решили ставить сами и уже выросли из Minikube. Очевидный плюс — в дальнейшем удачный конфиг можно многократно воспроизвести.
• Экзотика — есть и другие штуки, часто привязанные к специфичным ОС. Например, для Talos OS есть свои утилиты — Talos CTL (ручками) и talm (типа Helm, но для Талоса). Интересные вещи, но это уже для тех, кто в теме.

На какую ОС ставить ноды

• Есть обычные Linux — старая добрая Ubuntu, CentOS, Debian, и всё это прекрасно работает. Привычно, понятно, куча доков в сети.
• Специализированные ОС — есть дистрибутивы, заточенные специально под контейнеры и Кубер. Это Fedora CoreOS / Flatcar Container Linux: часто у них read-only — корневая файловая система для безопасности, атомарные обновления. Но есть нюансы: например, FCOS вместо привычного cloud-init использует свой формат конфигов — Ignition. Надо разбираться, как его готовить (там есть ещё утилита Butane). Talos — ещё более хардкорный вариант. Там вообще нет привычной ОС с shell! Всё управляется через API. Максимальная безопасность, минимализм. Но требует полного переосмысления подхода к управлению хостами.

Если нет особых требований к безопасности или специфике, то начинайте с обычной Ubuntu LTS — не ошибётесь.

Container Runtime

• Docker (точнее, dockershim) — до недавнего времени был стандартом де-факто. Сейчас его официально выпилили из Кубера, но многие дистрибутивы и инсталляторы по-прежнему его поддерживают через прослойку. Если у вас нет веских причин для другого — можно начать с него: он самый привычный.
• Containerd — а вот это стандарт де-факто сейчас, поддерживаемый Кубером напрямую через интерфейс Container Runtime Interface. Кстати, Docker сам под капотом использует containerd, так что переход на него обычно безболезненный. Большинство новых инсталляций использует именно его.
• CRI-O — ещё реализация CRI, разрабатываемая Red Hat. Тоже хороший вариант.
• Есть и совсем специфичные вещи типа Kata Containers (запускает контейнеры в легковесных виртуалках для изоляции) или Kubevirt (позволяет запускать полноценные ВМ внутри Кубера). Но это уже для особых случаев.

Рекомендация: начинайте с containerd. Это сейчас мейнстрим.

Хранение
Вот это критически важный вопрос, если у вас не только stateless-вебморды, но и базы данных, очереди, кэши — всё, что должно переживать перезапуск и падение подов.

Сразу забудьте про использование локальных дисков на нодах для хранения важных данных в продакшене! Нода умерла — данные пропали.

То есть данные должны быть размазаны по кластеру или храниться в выделенном отдельном хранилище.

Кубер для работы с хранилищами использует стандартный интерфейс Container Storage Interface. Это позволяет подключать к нему самые разные системы хранения данных — как локальные, так и сетевые.

Базовое решение Ceph — очень популярное, мощное и надёжное распределённое хранилище. Наш опыт показывает, что это отличный выбор. Его можно развернуть отдельно, а можно прямо внутри Кубера с помощью специального оператора Rook. Rook сам поднимает все компоненты Ceph (мониторы, OSD на дисках нод) в виде подов и делает его доступным для Кубера через CSI. Мы у себя часто используем именно связку Ceph + Rook.

Всё это работает так. У вас есть приложение, работающее в контейнере внутри Kubernetes K8s. Этому приложению, например, базе данных, нужно место для хранения данных — скажем, пять гигабайт. Создаётся PVC (Persistent Volume Claim). Это как заявка на диск. Кубер понимает запрос и обращается к системе хранения данных (например, Ceph) через autoprovisioning с командой: «Создай диск на пять гигабайт». В Ceph создаётся блочный диск (RBD) и выделяется Куберу в виде его сущности PV (Persistent Volume). И уже этот PV подключается к поду.

Ceph — это распределённая система хранения, которая обычно устанавливается на те же серверы (узлы), где работают и сами контейнеры (сейчас мы — про Bare Metal). Она объединяет диски этих серверов в единое большое хранилище.

Хотя компоненты Ceph (например, процессы, управляющие отдельными дисками — OSD) могут запускаться в своих управляющих контейнерах (часто — с помощью инструмента Rook), сама система хранения тесно связана с физическими дисками и серверами. Когда контейнер падает, диск в Ceph остаётся. Когда падает целый сервер, данные сохраняются. Система не хранит всех данных на одном диске или узле: при записи копии данных «размазываются» по разным дискам на разных серверах. Мы сами выбираем, какой уровень репликации установить. Ceph автоматически обнаружит потерю OSD и начнёт перераспределять данные по оставшимся рабочим дискам, чтобы восстановить нужный уровень избыточности.

Если контейнер поднимется на другой машине после перезапуска, то новый экземпляр контейнера просто подключится к тому же самому постоянному тому (Persistent Volume), который был создан для него в Ceph. Данные на диске никуда не делись. Управление самим кластером Ceph — тоже отказоустойчиво. Есть специальные процессы-мониторы и манагер с репликами в режиме standby. Если сервер с главным манагером выходит из строя, то управление автоматически переходит к другому манагеру на другом сервере.

Конечно, система не неуязвима. Если выйдет из строя слишком много серверов или дисков одновременно, так, что оставшегося места не хватит для хранения всех данных или их реплик, или если не останется достаточно узлов для поддержания кворума управления кластером, то Ceph может перестать работать или перейти в состояние «Только для чтения». Там лучше разбираться руками.

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

Ещё варианты:

• LinStor — ещё одно распределённое хранилище, и тоже с CSI-драйвером. Говорят, может быть производительнее Ceph в некоторых сценариях. Тоже достойный вариант.
• Если вы в облаке, то у провайдера есть свои CSI-драйверы для их блочных хранилищ (Amazon EBS, Google Persistent Disk, Azure Disk, etc.). Обычно это самый простой вариант в облаке. Причём их можно смешивать для разных условий и для разных типов данных.
• Более экзотичные GlusterFS, локальные диски через Local Persistent Volumes (только для специфичных задач!) и куча других вариантов.

Вы можете определить разные «классы» хранения (StorageClass), например, fast-ssd, slow-hdd, cloud-premium. А потом в манифесте для вашего приложения (в PersistentVolumeClaim) вы просто указываете имя нужного класса. Кубер через CSI-драйвер сам создаст диск нужного типа в соответствующем бэкенде (Ceph, облако, etc.). Это позволяет абстрагироваться от конкретной реализации хранилища.



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

Kubernetes создаёт свою собственную виртуальную сеть поверх вашей физической (или облачной) сети. Каждый под (контейнер) получает свой IP-адрес в этой виртуальной сети. И поды, запущенные на разных физических нодах, должны иметь возможность общаться друг с другом по этим виртуальным IP. Чтобы эта магия работала, нужно выбрать и установить CNI-плагин (Container Network Interface). Это такой софт, который и отвечает за настройку сети для подов. Наши фавориты:

• Cilium — очень мощный и быстрый плагин. Он использует новомодную eBPF прямо в ядре Linux, что даёт ему производительность и кучу фич (сетевые политики, шифрование, балансировка). У Cilium есть ещё крутой инструмент Hubble — это UI и CLI для визуализации сетевых потоков и зависимостей между сервисами. Супервещь для отладки, мы его любим.
• Calico — тоже очень популярный и зрелый плагин. Часто идёт по умолчанию во многих инсталляторах (например, в Kubespray). Умеет работать как с оверлейными сетями (VXLAN, IPIP), так и без оверлея, используя BGP-маршрутизацию, если ваша сеть это поддерживает. Тоже отличный выбор.
• Flannel (простой, для начала неплох).
• Weave Net, Antrea и куча других, в том числе специфичных для облаков (AWS VPC CNI, Azure CNI, GKE Netd).

В зависимости от выбранного CNI и вашей инфраструктуры вам может потребоваться разбираться с BGP, VXLAN, IPIP-туннелями, настройкой маршрутов и файрволов. Сеть — это то место, где можно застрять надолго. Как сказал один наш сетевик, когда разбирался с какой-то проблемой: «По идее должно быть так, но хрен его знает, иди копай». Эта фраза будет преследовать вас примерно везде по мере реализации.

«Я запустил Nginx в поде, как мне его открыть в браузере?»

В Кубере есть специальная штука — Service. Это абстракция, которая даёт постоянный IP-адрес и DNS-имя для группы подов (например, для всех реплик вашего веб-сервера) и умеет балансировать трафик между ними.

Типы сервисов:

• ClusterIP: сервис получает внутренний IP, доступный только изнутри кластера. Для внутренних бэкендов — самое то.
• NodePort: сервис открывает порт на каждой ноде кластера. Вы можете обратиться на IP_любой_ноды:NodePort и попасть на сервис. Неудобно, небезопасно, порты надо выбирать из определённого диапазона. Для продакшена — фу.
• LoadBalancer: вот это уже интереснее. Если вы в облаке, то при создании сервиса такого типа облачный провайдер автоматически создаёт вам внешний облачный балансировщик (ELB, Google LB, etc.), назначает ему публичный IP и направляет трафик на ваш сервис (точнее, на его NodePort на нодах). Очень удобно! А что делать, если у вас свой кластер на железе (Bare Metal)? Облачного балансировщика нет. Тут на помощь приходит MetalLB. Это такой специальный контроллер, который эмулирует облачный LoadBalancer. Вы выделяете ему пул IP-адресов из вашей локальной или публичной сети (если вы крутой и имеете свою публичную сеть), и когда создаёте сервис типа LoadBalancer, MetalLB берёт свободный IP из пула и «анонсирует» его в вашей сети (обычно через ARP или BGP), чтобы трафик на этот IP приходил на ноды вашего кластера. Обязательная штука для Bare Metal!
• Есть еще ExternalName, который использует DNS с кастомными параметрами, но даже в официальной доке предупреждают, что для некоторых протоколов типа http(s) могут быть проблемы. Мы его не используем.

Ingress — стандарт для публикации веб-приложений (HTTP/HTTPS) в продакшене. Ingress — это не тип сервиса, это отдельный ресурс в Кубере. Он работает как умный реверс-прокси или «входные ворота» для внешнего трафика. Он позволяет рулить трафиком на разные сервисы внутри кластера на основе хоста (например, api.mysite.com -> сервис API, blog.mysite.com -> сервис блога) или пути (mysite.com/app1 -> сервис App1, mysite.com/app2 -> сервис App2). Ingress также обычно отвечает за TLS-терминацию (SSL-сертификаты).

Чтобы Ingress заработал, вам нужно установить Ingress-контроллер. Это, по сути, и есть тот самый реверс-прокси, который читает Ingress-ресурсы и настраивает себя соответствующим образом. Самый популярный — Nginx Ingress Controller: знакомый многим Nginx, но специально заточенный под Кубер. Мощный, гибкий. Но! Будьте осторожны: недавно в нём находили неприятные уязвимости, позволяющие читать секреты из кластера. Это к важности своевременных апдейтов. Из других хороши HAProxy Ingress, Traefik (очень популярен, умеет сам получать Let's Encrypt-сертификаты), Contour и другие.

Настроить Ingress, сертификаты, DNS — это тоже задача не на пять минут. А если обратиться к официальной документации, то она рекомендует идти не в Ingress, а в Gateway API. Тут может показаться, что надо начать с него, и даже есть классные GUI для Gateway API, и хорошо бы ими воспользоваться! Но погодите )

Gateway API — это относительно новая спецификация в Кубере, которая со временем должна заменить или дополнить Ingress. Она более гибкая, позволяет разделять ответственность по маршрутам для разработчиков. Выглядит перспективно. Но я бы пока советовал не лезть в экзотику типа Kong Gateway. Да, у него есть красивый UI, что подкупает в мире консольного Кубера. Но он ломает саму идеологию Кубера с его декларативными манифестами в etcd и использует другую логику представлений. Лучше освоить стандартный Ingress с Nginx или Traefik, а к Gateway API присматриваться постепенно по мере накопления опыта. Есть реализации на базе того же Nginx, Envoy (Istio, Contour), HAProxy. Если разбираться с Gateway API, то лучше начать с них.

Кусок информационной безопасности
Пароли от баз данных, ключи к внешним API, всякие токены — ни в коем случае нельзя хардкодить в коде приложения (если кто-то ещё так делает и не был распят) или пихать прямо в YAML-манифесты! Этим вы создаёте огромную дыру в безопасности.

Для этого в Кубере есть специальные объекты:

• Secrets — для хранения чувствительных данных (пароли, токены, TLS-сертификаты). Они хранятся в etcd в base64 (что не шифрование!), но Кубер предоставляет механизмы для их шифрования «at rest» и контроля доступа к ним через RBAC.
• ConfigMaps — для хранения нечувствительной информации конфигурации (URL’ы, параметры, конфиг-файлы целиком).
• Продвинутый уровень: можно интегрировать Кубер с внешними системами управления секретами, например, HashiCorp Vault, с помощью специальных инструментов (Vault Agent Injector, External Secrets Operator). Это даёт централизованное управление, ротацию секретов и т.д.

Вы можете «подсунуть» данные из Secrets и ConfigMaps вашему приложению как переменные окружения для контейнера или как файлы, смонтированные в определённую директорию внутри контейнера.

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

Но идеальный сценарий — это когда, например, кластер Cassandra создаётся автоматически через оператор типа k8ssandra, и приложение берёт креды для доступа из секрета, созданного оператором при запуске кластера. Ни в БД, ни в приложение ручками их никто не прокидывает.

Аутентификация и авторизация
В вашем кластере наверняка будут работать разные люди: DevOps/SRE, разработчики команды А, разработчики команды Б, может быть, QA-инженеры… Кто может деплоить приложения, кто может смотреть секреты, кто может удалять ноды?

• Аутентификация. Сертификаты X.509, токены (статичные, JWT, через OIDC-провайдера типа Keycloak или Dex), интеграция с LDAP/AD.
• Авторизация (RBAC — Role-Based Access Control). Вот это — самое главное. RBAC позволяет очень гибко настроить, что (какие действия: get, list, create, update, delete) с какими ресурсами (pods, services, secrets, nodes, etc.) в каких неймспейсах (или во всём кластере) и кто может делать (какой пользователь, группа или сервисный аккаунт). Вы создаёте Роли (Roles) или Кластерные Роли (ClusterRoles), где описываете набор разрешений. Затем вы создаёте Привязки Ролей (RoleBindings) или Кластерные Привязки (ClusterRoleBindings), чтобы связать роль с конкретным пользователем, группой или сервисным аккаунтом.
• Namespaces: используйте неймспейсы для логической изоляции ресурсов разных команд, проектов или окружений (dev, stage, prod). Это помогает упорядочить кластер и упрощает настройку RBAC (роли можно создавать внутри неймспейса). Хотя для окружений более правильно и эффективно использовать разные кластеры (опять же привет, облака).
• Золотое правило — минимальные привилегии. Давайте пользователям и сервисным аккаунтам только те права, которые им реально необходимы для выполнения их задач. Не надо всем раздавать cluster-admin: это прямой путь к катастрофе.

Observability
Вот мы и приехали к той самой волшебной части. Работать с кластером Kubernetes без настроенной системы мониторинга и логирования — это посадить админом слепого котёнка.

Метрики:

• Нужен Metrics Server — это базовый компонент (обычно ставится аддоном), который собирает основные метрики использования ресурсов (CPU, RAM) с нод и подов. Он нужен как минимум для работы kubectl top и базового HPA.
• Стек Prometheus + Grafana — это де-факто стандарт для сбора, хранения и визуализации метрик в мире Кубера. Prometheus — это база данных временных рядов, которая сама опрашивает метрики с разных источников (ноды, поды, сервисы). Grafana — инструмент для построения красивых дашбордов на основе данных из Prometheus (и не только).
• Приложения должны сами отдавать метрики в формате, понятном Prometheus (обычно это текстовый формат по HTTP-эндпоинту /metrics). Не только CPU/RAM, но и специфичные для приложения: количество запросов в секунду, время ответа, размер очереди, количество ошибок, бизнес-метрики. Без этого ваш мониторинг будет неполным.

А я предупреждал )

Логи:

• Контейнеры в Кубере обычно пишут логи просто в stdout и stderr. Эти логи собираются движком контейнеров (containerd/docker) и доступны через kubectl logs. Но смотреть логи каждого пода по отдельности — это ад.
• Нужен централизованный сбор логов. Необходимо настроить агентов (например, Fluentd, Fluent Bit, Promtail), которые будут бегать на каждой ноде, собирать логи из файлов или напрямую от движка контейнеров и отправлять их в центральное хранилище.
• Популярные варианты хранилищ логов — Elasticsearch (в составе стека ELK/EFK: Elasticsearch + Logstash/Fluentd + Kibana) или Loki (от создателей Grafana, хорошо интегрируется с Prometheus, обычно используется в стеке LGTM: Loki + Grafana + Promtail).

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

Трассировка. Если у вас микросервисная архитектура, то один запрос пользователя может проходить через десяток разных сервисов. Чтобы понять, где именно возникла задержка или ошибка, нужна распределённая трассировка. Инструменты: Jaeger, Zipkin, Tempo.

Конечно, приложения должны уметь принимать и передавать дальше специальные заголовки (trace ID, span ID) и отправлять информацию о своих операциях (спанах) в коллектор трейсов. Это тоже требует доработки кода.

Масштабирование
Ну что, база есть, доступ настроен, всё видно. Теперь можно и фишками обмазаться.

Устали поднимать руками и настраивать PostgreSQL, Kafka, Redis, Elasticsearch в Кубере? Следить за их состоянием, бэкапами, обновлениями? Для этого придумали операторов. Оператор — это, по сути, ваш кастомный контроллер внутри Кубера, который знает, как управлять определённым типом сложного приложения. Он расширяет API Кубера с помощью Custom Resource Definitions.

Работает это так:

• Вы устанавливаете CRD для, скажем, PostgreSQL. Теперь Кубер знает о новом типе ресурса, например, PostgresCluster.
• Вы устанавливаете сам Оператор PostgreSQL (это обычное приложение, работающее в поде).
• Вы создаёте простой YAML-файл, где пишете — kind: PostgresCluster, name: my-db, spec: { replicas: 3, version: «15», storage: «fast-ssd» }.
• Применяете этот YAML (kubectl apply-f).
• Оператор видит, что вы создали новый ресурс PostgresCluster, и начинает действовать: создаёт нужные StatefulSets/Deployments, заказывает диски (PersistentVolumeClaims) нужного StorageClass, настраивает сервисы для доступа, конфигурирует репликацию, может настроить бэкапы и мониторинг — в общем, делает за вас всю грязную работу по развёртыванию и поддержке сложного stateful-приложения.

Существует огромное количество готовых операторов от сообщества и вендоров для баз данных, очередей, мониторинга, CI/CD — да чего угодно! Это очень мощный механизм расширения Кубера. Для совсем уж специфичных внутренних систем можно даже написать свой оператор (но это уже высший пилотаж).

Автомасштабирование — одна из главных фишек Кубера, ради которой его часто и внедряют.

• Горизонтальное автомасштабирование подов (HPA — Horizontal Pod Autoscaler) — самый частый и полезный вид. Вы создаёте HPA-ресурс и говорите: «Хочу, чтобы количество реплик моего приложения my-app было от двух до десяти, и чтобы оно масштабировалось, если средняя загрузка CPU по подам превысит 70 % (или RAM, или кастомная метрика из Prometheus, например, длина очереди)». Кубернейтс сам будет следить за метриками и автоматически добавлять или удалять поды my-app в указанных пределах.
• Вертикальное автомасштабирование подов (VPA — Vertical Pod Autoscaler). Менее популярный, но тоже бывает полезен. VPA анализирует реальное потребление ресурсов подами и может автоматически изменять requests и limits по CPU/RAM в манифесте пода. Чаще используется в режиме «рекомендаций», чтобы понять, сколько ресурсов реально нужно приложению. Использовать VPA вместе с HPA нужно осторожно: они могут конфликтовать.
• Масштабирование кластера (Cluster Autoscaler). Это уже про добавление и удаление целых серверов (нод) в кластер. Работает так: если в кластере появляются поды, которые не могут никуда запланироваться (состояние Pending) из-за нехватки ресурсов (CPU, RAM) на существующих нодах, то Cluster Autoscaler замечает это и автоматически заказывает у облачного провайдера новую ноду (или несколько), ждёт, пока она не поднимется, и добавляет её в кластер. Поды тут же планируются на неё. И наоборот: если Cluster Autoscaler видит, что какие-то ноды долгое время недозагружены и все их поды можно переместить на другие ноды, то он может автоматически удалить эти лишние ноды, чтобы сэкономить деньги. Это главная фишка облачных Managed Kubernetes. Там это обычно работает «из коробки». Если у вас свой кластер — на железе или виртуалках, то заставить Cluster Autoscaler работать можно, но сложнее. Нужно использовать Cluster API. Это такой проект, который позволяет управлять жизненным циклом кластеров Kubernetes (в том числе создавать и удалять ноды) с помощью самого Kubernetes. Cluster API имеет провайдеров для разных инфраструктур (vSphere, OpenStack, AWS, Azure, Bare Metal через Tinkerbell/MAAS). Но это отдельная большая тема.

Кстати, тут надо передать пламенный привет некоторым российским облакам. У них часто есть довольно смешные лимиты на максимальное количество нод в одном Managed-кластере: где-то — 100 (привет, ТаймВеб), где-то — вообще 32 (Яндекс). А Кубер, на минуточку, сам по себе спокойно тянет 5 000 нод в кластере и 150 тысяч подов и даже не поперхнётся (по официальным тестам). У ВК вроде лимит побольше — 500 нод, у Сбера — 249 (хотя в доке пишут, что 500). Всё равно не 5 000. У нас в H3LLO CLOUD мы постарались эту проблему решить и даём возможность строить реально большие кластеры, близкие к максимальным возможностям Кубера.


Думаете, это конец?
Нет, это начало.

Развернули кластер, настроили сеть, сторадж, мониторинг? Поздравляю! Вы прошли… ну, скажем, разминку.

• Короткий анонс. Приложения должны быть готовыми жить в динамичной эфемерной среде Кубера. Почитайте про 12-factor app — это мастхэв. Приложение должно:
• Читать конфиги и секреты из окружения или файлов (никаких локальных config.xml!).
• Писать логи в stdout/stderr (а не в файлы!).
• Быть максимально stateless (состояние хранить во внешних базах, кэшах, хранилищах).
• Быстро стартовать.
• Корректно обрабатывать сигналы SIGTERM для graceful shutdown.
• Уметь отдавать метрики для мониторинга (health checks, readiness/liveness probes).
• Быть упаковано в легковесный Docker-образ.

Вам нужны конвейеры, которые будут автоматически:

• Собирать Docker-образы вашего приложения при коммите в Git.
• Пушить образы в Docker Registry (типа Harbor, GitLab Registry, Docker Hub).
• Обновлять YAML-манифесты (Deployments, StatefulSets, Services, Ingresses) с новой версией образа.
• Деплоить эти манифесты в Kubernetes (например, с помощью kubectl apply, Helm, Argo CD, Flux).
• Проводить тесты после деплоя.
• Обеспечивать лёгкий откат на предыдущую версию.

Инструментов для этого — море: Jenkins, GitLab CI, GitHub Actions, Tekton, Argo CD, Flux…

В идеальном розовом мире единорогов ваши разработчики вообще не должны знать слова «Kubernetes». Они просто пишут код, коммитят в Git, а дальше некая «платформа» сама всё собирает, тестирует и выкатывает куда надо. Нажал кнопку — получил фичу в проде. Достичь такого уровня абстракции — это Грааль платформенного инжиниринга. Это требует не только зрелого Кубера со всеми обвесами, но и глубокого понимания ваших приложений, процессов разработки и кучи инструментов поверх Кубера (часто это называют Internal Developer Platform). Это долгий и сложный путь.

А оно вообще того стоит? Если у вас реально сложная, большая, динамичная система, которая должна быть отказоустойчивой, масштабироваться под нагрузкой, часто обновляться без простоя, то однозначно — ДА, стоит. Головной боли на старте будет много, но потом вы получите такие гибкость, скорость и надёжность, которых другими путями добиться очень сложно, если вообще возможно. Вы реально сможете выкатывать фичи быстрее и спать спокойнее (но это неточно).

Если вы прочитали всё это и подумали: «Мама дорогая, да я в этом никогда не разберусь!», но при этом фишки Кубера вам нужны — не отчаивайтесь. Есть решения, которые берут на себя большую часть этой боли:

• L1VESTACK или другой контейнерный хостинг — тут мы пошли по пути максимального упрощения: полностью спрятали оркестратор под капот. Вы просто даёте нам свой docker-compose.yaml (да-да, прямо его!) или используете наш простой CLI — и ваше приложение магическим образом разворачивается и работает на нашей инфраструктуре. Вообще не надо думать ни про ноды, ни про сети, ни про стораджи, ни про Ингрессы, ни про RBAC. Просто код и деплой. Идеально для тех, кто хочет «просто чтобы работало». Естественно, нет фишек инфраструктуры для продвинутых, потому что вы запустили контейнер, который работает.
• H3LLO.CLOUD — на нашей платформе есть Managed Kubernetes. Здесь мы не прячем Кубер полностью, но берём на себя самую нудную и сложную часть: бутстреппинг, Control Plane, etcd, обновления базовой системы, обеспечение работы сети и хранилища, предоставляем автомасштабирование нод «из коробки». Вам всё ещё нужно понимать основные концепции Кубера (поды, сервисы, деплойменты) и уметь пользоваться kubectl, но основную инфраструктурную рутину и сложность мы снимаем. Это хороший баланс между контролем и удобством.

Что почитать или посмотреть

• Для старта — Minikube.
• Запуск Кубера без заморочек — kubespray.
• Концепции Кубера из первоисточника — курим доку. Начать лучше с туториала, а потом читать Concepts и Tasks.
• Хорошая книга — Production Kubernetes. Есть на русском.
• Глубже по сетям — Networking and Kubernetes.
• Тоже есть на русском.
• GUI для Кубера — Lens
• The Twelve-Factor App

Жирнющие бесплтаные лимиты на облачные сервисы на целый год, включая Managed Kubernetes — H3LLO.CLOUD.

Не менее щедрые лимиты на платформу для запуска приложений в контейнере — L1veStack.

beta.h3llo.cloud
h3llo.cloud

Обновление в документах «Условия использования отдельных сервисов»
Мы обновили следующие документы:

• Условия использования отдельных сервисов: предоставление выделенного сервера и выделенного сервера произвольной конфигурации;
• Условия использования отдельных сервисов: размещение оборудования (Colocation);
• Условия использования отдельных сервисов: сетевое оборудование.

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

Данное уведомление носит информационный характер и не требует каких-либо дополнительных действий.

Актуальные обновленные версии документов доступны по ссылкам:
files.selectel.ru/docs/ru/conditions-dedicated.pdf
files.selectel.ru/docs/ru/conditions-colocation.pdf
files.selectel.ru/docs/ru/network_equipment.pdf

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



selectel.ru/services/mobile-farm

В апреле только и разговоров, что о космосе…

Сразиться с пиратами, починить пищевой 3D-принтер и преодолеть область «космической тени» — малая часть того, что вы можете сделать на пути к Земле до 28 апреля 23:59 по мск. Для этого надевайте оранжевый скафандр и стартуйте!

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

Лимитированные спецтарифы «Восток 3.0»
Гибкие диски от 100 до 240 Гб SSD или NVMe, до 128 IPv4 + бесплатная панель ispmanager 6 lite на первый месяц.
Локация — Москва или Амстердам.


Крутые призы за прохождение игры
На финише путешествия вас ждут — cкидка до 30% на заказ VDS, сертификат на баланс до 500 ₽
и возможность побороться
за LEGO Technic.


firstvds.ru/spaceday2025

Обсуждаем количество концовок, проводим расследование кто же рисовал картинки и написал музыку в игре в нашем телеграм-чате. Присоединяйтесь :) t.me/TakeFirst_chat

Мы с гордостью сообщаем, что Worldstream — первый поставщик IaaS, запустивший выделенный сервер с новейшим процессором AMD EPYC 9355P 5-го поколения. Этот сервер на базе Dell PowerEdge R6715 объединяет скорость, масштабируемость и безопасность на одной мощной платформе. И что самое лучшее? Он готов к развертыванию в течение 2 часов из наших центров обработки данных.

Раскройте мощь AMD EPYC 5-го поколения
Worldstream — первый поставщик, предлагающий выделенный сервер на базе процессора AMD EPYC 9355P. Это новое поколение оптимизировано для интенсивных бизнес-нагрузок — от виртуализации и баз данных до приложений ИИ и аналитики данных. Созданный на основе передовой архитектуры AMD «Zen 4» и являющийся частью новейшей серии 9005, 9355P обеспечивает исключительную производительность, масштабируемость и энергоэффективность. Благодаря поддержке DDR5 и PCIe Gen5 эта платформа идеально подходит для современных инфраструктур ИИ, облака и HPC.

Почему стоит выбрать AMD EPYC 9355P?
Серия AMD EPYC 9005 выводит производительность сервера на новый уровень:

• Максимальная скорость обработки
• Превосходная энергоэффективность
• Расширенная безопасность в одном комплексном пакете

Это делает 9355P идеальным выбором для компаний, ищущих серверное решение, ориентированное на будущее.
Серия EPYC 9005 основана на передовой архитектуре AMD и предлагает:

• 32 ядра / 64 потока для максимальной производительности
• Поддержка памяти DDR5 и PCIe Gen5
• AMD Infinity Guard для безопасности на уровне чипа
• Масштабируемая эффективность — идеально подходит для современных рабочих нагрузок

От виртуализации до искусственного интеллекта, от баз данных до CI/CD — это процессор, созданный для новой эры серверной инфраструктуры.

Теперь доступно на Worldstream

• Dell PowerEdge R6715
• AMD EPYC 9355P (32c / 64t)
• Настраиваемый
• PCIe Gen5, DDR5, Zen 4
• Развертывание за 2 часа
• Идеально подходит для: виртуализации, периферийных приложений, больших данных, искусственного интеллекта, хранения данных и конвейеров разработки.

www.worldstream.com/en/dedicated-servers/configure/115/

Обновление серверов ВПС 16.12.2024
Сообщаем что все виртуальные сервера перемещены на новые гипервизоры, платформа HPE Apollo R2600 GEN10, с подключением в интернет со скоростью 10G:

• Платформа: ProLiant XL170r Gen10
• Процессоры: 2x Intel Xeon Gold 6248 (LGA3647, 2.5GHz [Turbo: 3.9GHz], 27.5Mb cache, 20 ядер, 40 потоков)
• Оперативная память: 12x 64Gb Micron DDR4 ECC LRDIMM, 2666MHz (72ASS8G72LZ-2G6B2), всего 768Gb
• RAID: HPE Smart Array P408i-p, 2Gb cache, BBU
• Жёсткие диски: 4x Micron MTFDDAK3T8TDT 3.84Tb (собраны в RAID5)
• Подключение: HPE Ethernet 10Gb 2-port 568FLR-MMSFP+ Adapter
• Теперь, ваши виртуальные сервера будут работать ещё быстрей.

Прекращён приём платежей через КИВИ 21.02.2024
В связи с отзывом лицензии у КИВИ Банк (АО), кредитноц организации, входящей в состав группы компаний QIWI, отключена оплата посредством КИВИ кошелька.
Воспользуйтесь другими способами оплаты.

Уведомление о добавлении ООО «Эксимиус» (хостинг HOST-FOOD) в реестр провайдеров хостинга 16.01.2024
Сообщаем вам о том, что ООО «Эксимиус» полностью соответствует требованиям, связанным с изменением федерального закона от 27.07.2006 № 149-Ф3 «Об информации, информационных технологиях и о защите информации».
С 27.12.2023 г. ООО «Эксимиус» (хостинг HOST-FOOD) включено в реестр провайдеров хостинга. Информацию об этом можно найти на официальном сайте Роскомнадзора: rkn.gov.ru/activity/connection/register/p1578/.
Компаниям, работающим в сфере связи, которые не вошли в реестр Роскомнадзора, с 1 февраля 2024 года будет запрещено предоставление услуг хостинга на территории России.
ООО «Эксимиус» (хостинг HOST-FOOD) — проверенный хостинг провайдер, поэтому наши соглашения и договорные отношения остаются неизменными.

Необходимость подтверждённого телефона 04.12.2023
Обращаем ваше внимание, что в соответствии с требованиями Минцифры, для предоставления услуг с подключением в сеть Интернет, клиенты обязаны иметь подтверждённый аккаунт.
Самый простой вариант — добавить и подтвердить телефонный номер из ЕАЭС (Россия, Беларусь, Казахстан, Армения, Киргизия) по этой инструкции:
www.host-food.ru/faq/general.questions/add.and.confirm.mobile.phone/
На данный момент, альтернативным вариантом подтверждения является ваше фото с паспортом в руках, приложенное в систему поддержки

Автоматический перенос почты с Яндекс на хостинг 31.03.2023
Хотим обратить Ваше внимание на новую возможность, которая вам понравится!
Мы предлагаем вам перенести свою почту к нам на хостинг, и получить все необходимые инструменты для удобной работы с ней. Кроме того, мы рады сообщить, что в ispmanager появилась функция импорта почтовых ящиков по IMAP и по API Яндекс 360; (обновление ISP6-1080), что существенно упрощает перенос почты к нам.
Это предложение более чем актуально, так как Вы возможно уже знаете, Яндекс вынужден пересмотреть условия использования сервисов Яндекс 360 и с 17 апреля 2023 года, чтобы сохранить доступ к возможностям Яндекс 360, нужно выбрать и оплатить один из основных тарифов. А это может повлечь значительные затраты на использование почты.
Мы уверены, что перенос почты к нам на хостинг будет для вас выгодным решением, и готовы предложить вам тариф vip1 за 150 рублей в месяц с лимитом создания до 100 почтовых ящиков. (автоматический импорт возможен только на тарифной линейке VIP)
Инструкция по переносу почты доступна по этой ссылке:
www.host-food.ru/faq/technical.questions/email/import.yandex.businnes.email/
В случае вопросов и затруднений вы можете обратится в нашу техническую поддержку:
manager.host-food.ru/Tickets
Спасибо за внимание, мы будем рады видеть вас на нашем хостинге.

Изменение сроков заказа/продления тарифных планов микро/мини 26.12.2022
Уважаемые клиенты!
Сообщаем вам, что с 01.01.2023 года тарифы «микро» и «мини» будут продлеваться не менее чем на год.
Минимальный период оплаты при заказе — год. Никакие скидки на данных тарифах работать не будут.

10G сеть 01.11.2022
Уважаемые клиенты!
Мы завершили модернизацию сетевого оборудования и теперь на всех участках у нас используется 10 Gb подключения.
Мы стараемся делать все для вашего удобства и комфортной работы!

Добавлена поддержка Node.js на хостинге 18.09.2022
На новых серверах (srv11/srv12) тарифной линейки Lite добавлена поддержка Node.js
Данная возможность доступна на всех тарифах, включая «Пробный».

Важные новости об оплате услуг хостинга 23.03.2022
Ситуация с платежными системами стабилизируется. Мы снова принимаем к оплате карты, выпущенные за рубежом.
Внимание! Ориентируйтесь по картинкам!
Для клиентов с платежными картами, выпущенными на территории РФ при оплате нужно выбрать картинку MИР.
Для клиентов с платежными картами, выпущенными в других странах (СНГ, Европе, Азии и США), при оплате выбирайте Visa и Mastercard. Картинка «Иностранные Visa и Mastercard»

Работаем в штатном режиме 27.02.2022
Учитывая последние события, мы хотим сообщить вам о стабильной работе всех наших серверов.
Сервера расположены в одном из самых надёжных дата-центров нашей страны, в Москве.
Оборудование базируется только на самых качественных серверных комплектующих высокого класса, прошедших многоступенчатое тестирование.
Наш персонал прошёл разностороннее обучение и сможет оказать вам быструю помощь в любых, даже самых сложных вопросах, касающихся хостинга.
По любым вопросам работы ваших проектов рекомендуем обращаться в Центр поддержки (систему тикетов)

Снижение цен на VPS 01.02.2022
У нас снижаются цены на все тарифы виртуальных выделенных серверов VPS/VDS
Экономия составит до 20%

Теперь все ВПС на SSD дисках 14.12.2021
С сегодняшнего дня, все виртуальные сервера размещаются на серверах с промышленным SSD дисками и процессорами Intel Xeon, частотой до 3.3GHz.
Оплаченные услуги сохраняют актуальность. Никаких пересчетов. Только приятные сюрпризы по пути.
Такая уверенность связана с тем, что мы «бескровно» переходим на другой качественный уровень, отказываясь от устаревших технологий. И сервера мы делаем быстрее.
Мы можем утверждать, что Host-Food не только обеспечивают стабильную работу сайта, но и в качестве дополнительных услуг предоставляет выделенные физические или виртуальные сервера.
Расценки приятны, а тарифных вариантов — масса.
Но самое главное — квалифицированная служба поддержки, которая всегда на связи. Даже если вы перемещаете сайт на новый хостинг самостоятельно, то возникающие проблемы будут решены молниеносно.

Закончен перенос всех аккаунтов на новые сервера 08.06.2021
Все клиенты со «старых» серверов перемещены на новые:
www.host-food.ru/about/hardware/our.hosting.servers/
Теперь на любом тарифе хостинга вы получаете новые процессоры со скоростью в турбо-режиме до 5 GHz, и промышленные SSD диски.
Также, напоминаем; у нас есть большой выбор выделенных серверов:
www.host-food.ru/tariffs/vydelennyi-server-ds/

Запущен новый блейд-сервер 27.10.2020
Рады сообщить вам об обновлении парка серверов, запущен новый блейд-сервер, и первое лезвие — для VIP клиентов:
www.host-food.ru/about/hardware/our.hosting.servers/srv21.host-food.ru/
Данное оборудование отвечает всем современным требованиям и обеспечивает высокую производительность. Все это позволяет сделать работу ваших сайтов еще более быстрой, что несомненно повысит их привлекательность для пользователей и поисковых систем.
Мы расчитываем в течении месяца выпонить перенос всех аккаунтов со старого сервера на новый. У нового сервера будет новый IP адрес и тем пользователям, которые не используют наши ДНС сервера или используется CloudFlare нужно будет самостоятельно его сменить в записях доменов. Для согласования переноса и смены IP адреса просим вас написать соответствующее обращение в центр поддержки клиентов: manager.host-food.ru/Tickets
Для остальных пользователей переход на новый сервер пройдет незаметно в автоматическом режиме.

Добавлена поддержка HTTP/2 на всех серверах хостинга 13.12.2019
На все сервера виртуального хостинга добавлена поддержка нового протокола HTTP/2
Он обратно совместим с протоколами HTTP/1.1 и HTTP/1.0, клиентский браузер самостоятельно выбирает по какому протоколу он будет работать. Поддержка есть во всех современных браузерах.
Обратите внимание, что протокол работает только для шифрованных соединений, т.е. необходима установка SSL сертфиката.

Ещё один метод оповещений: ВКонтакте 12.11.2019
Здравствуйте, уважаемые пользователи нашего хостинга.
Мы добавили для вас ещё один способ получать уведомления от нашего хостинга – через сообщения от нашей группы ВКонтакте.
Для привязки вашего аккаунта VKontakte к оповещениям биллинговой системы, добавьте этот способ оповещения в её настройки, нажмите кнопку «Подтвердить» и отправьте выданный вам код сообщением в группу: vk.com/hosting.hostfood (можно найти поиском, по словам «host-food»)
Как и в Telegram, есть возможность отвечать на сообщения присланные ботом, но с теми же ограничениями – только если это ответ в существующий тикет.
Спасибо, что пользуетесь услугами хостинга host-food.ru.

Виртуальные сервера на промышленных SSD дисках 06.11.2019
Здравствуйте, уважаемые пользователи нашего хостинга.
Наша компания снова повышает качество своего сервиса: добавлена возможность размещения ВПС на промышленных SSD дисках. Миграция при смене тарифа происходит «наживую» без перезагрузки и перерывов работы. Также есть возможность вернуться на старые сервера — с Enterprise SATA дисками — также без перерывов в работе.
Подробнеее о тарифах вы можете узнать по ссылке: www.host-food.ru/tariff-order/?mode=VPS#36
И немного технических характеристик для интересующихся: модель — Toshiba HK4R Series SSD, используемый тип памяти – MLC, скорость работы:
Максимальная скорость записи — 500 Мбайт/сек
Максимальная скорость чтения — 480 Мбайт/сек

Добавлен метод оповещения: Viber 26.10.2019
Согласно пожеланиям клиентов, добавлен новый метод оповещений: Viber
Также для всех методов оповещений были добавлены следующие настройки:
Выставление времени получения сообщений – чтобы, к примеру, не приходили ночью.
Настройки оповещений по типам уведомлений.
Восстановление пароля.
Возможности отвечать через Viber на сообщения в систему тикетов, к сожалению, нет. Это связано с ограничениями самого мессенджера – невозможно определить, на какое сообщение пришёл ответ (что немаловажно, т.к. один и тот же контактный адрес может быть добавлен более чем у одного клиента).

Добавлен метод оповещения: Telegram 20.09.2019
По просьбам клиентов, была переработана система уведомлений:

• разрешено иметь более одного контакта одного типа
• появилась возможность настроить уведомления на каждый контакный адрес
• добавлена поддержка уведомлений через Telegram

Также, есть возможность отвечать на сообщения в Telegram, но с ограничениями — только если это ответ в существующий тикет.

Дню программиста посвящается! 13.09.2019
Поздравляем всех программистов с их профессиональным праздником!
Дарим для всех наших клиентов скидку 50% на все услуги хостинга на полгода, кроме регистрации доменных имён.
Промокод для получения скидки: programmer_day_2019_HF
Для активации необходимо перейти по ссылке: manager.host-food.ru/PromoCodesExtinguished
Ознакомиться с полным перечнем тарифов Вы можете на нашем сайте www.host-food.ru
ПРОМОКОД действует до 30 сентября включительно.
Скидка не суммируется с другими акциями нашего хостинга.

Миграция серверов линейки VIP на SSD диски 09.09.2019
Здравствуйте, уважаемые пользователи нашего хостинга.
Наша компания снова повышает качество своего сервиса: сегодня ночью на серверах линейки VIP были заменены диски – вместо Enterprise SATA были установлены SSD, так что скорость работы ваших сайтов стала ещё выше!
Подробнеее о тарифах линейки VIP вы можете узнать по ссылке: www.host-food.ru/tariffs/hosting/#vip
И немного технических характеристик для интересующихся: используемый тип памяти – MLC, скорость работы:

• Максимальная скорость записи (сжатые данные) — 535 Мбайт/сек
• Максимальная скорость чтения (сжатые данные) — 555 Мбайт/сек
• Скорость произвольной записи 4 Кб файлов (QD32) — 90000 IOPS
• Скорость произвольного чтения 4 Кб файлов (QD32) — 99000 IOPS

Спасибо, что пользуетесь услугами нашего хостинга :)

Мы перешли на обмен электронными документами 13.08.2019
Наша компания предлагает партнерам и клиентам бесплатно получать оригиналы закрывающих документов в системе электронного документооборота Диадок. Мы уже оценили плюсы обмена электронными документами и приглашаем партнеров присоединиться. Электронные документы являются оригиналами, их не нужно распечатывать, их принимают ИФНС и суды.
Перейдя на обмен электронными документами, мы:
Получаем документы в день выставления.
Не отправляем подписанные документы обратно — их достаточно подписать в Диадоке.
Подписываем входящие документы прямо в 1С и проводим их без ручного ввода.
Массово отправляем электронные документы в «один клик».
Для работы с документами нужен сертификат электронной подписи. Если вы используете систему интернет-отчетности, то подойдет сертификат, которым вы подписываете отчеты. Если нет, оставьте заявку и получите сертификат в сервисном центре вашего региона.
Нашим контрагентам мы уже отправили приглашения в Диадоке. Чтобы начать получать документы:
Перейдите на сайт diadoc.ru.
Выберите действие «Войти» — «По сертификату».
В Диадоке в разделе «Контрагенты» примите приглашение от ООО «Эксимиус».
Чтобы получать документы в 1С, воспользуйтесь модулем Диадока.
Вы сможете дать доступ к электронным документам всем сотрудникам, которые работают с документами, настроить передачу и согласование электронных документов внутри компании.
Для подписи документов необходим сертификат, для просмотра и согласования достаточно войти по логину и паролю.
Легко проверить, с кем еще вы можете перейти на обмен электронными документами. Для этого загрузите список ИНН в Диадоке в разделе «Контрагенты».

Обновлена основная версия php и mysql на серверах 25.05.2019
С целью совместимости с новыми версиями Bitrix, Joomla, ModX, WordPress и прочих популярных CMS, произведено обновление php до версии 7.3 и mysql до версии 5.6.
По результатам тестирования, 5 WordPress на php 7.3 работает почти в три раза быстрее чем на php 5.6, который до этого стоял на наших серверах!
Разумеется, для старых движков, как и ранее, доступен выбор версии php:
www.host-food.ru/faq/technical.questions/php/change.php.version.for.site/
Доступны версии php: 5.2, 5.3, 5.4, 5.5, 5.6, 7.0, 7.1, 7.2 и 7.3

Добавлена поддержка SSL сертификатов на младшие тарифы: «Микро» и «Мини» 27.03.2019
В связи с тем, что Яндекс.Браузер планирует выпуск новой версии, в которой все сайты без HTTPS будут помечаться как небезопасные, мы включили поддержку SSL на всех платных тарифах нашего хостинга
Теперь вы можете включить поддержку SSL для своих сайтов не меняя тариф на более дорогой. Также, нет необходимости заказывать выделенный IP адрес или платить дополнительные деньги центрам сертификации — вы можете использовать бесплатные сертификаты от Let's Encrypt.
P.S. Бесплатный тарифный план «Пробный» поддержки SSL не получил, и, вероятно, не получит — слишком популярен для фишинга и т.п.

Windows Server 2019 доступен для установки на ВПС 22.02.2019
Для установки на ВПС добавлен шаблон новой операционной системы Windows Server 2019.
Релиз собрал в себе все обновления Windows Server 2016, и включает следующие возможности:

• Windows Subsystem for Linux.
• Поддержка Kubernetes.
• Функции графического интерфейса пользователя из Windows 10 версии 1809.
• Storage Spaces Direct.
• Storage Migration Service.
• Storage Replica.
• System Insights.
• Обновлённый Защитник Windows.
• Вложенная виртуализация в Hyper-V

Акция: Выделенный сервер по цене виртуального 17.11.2018
Мы как-то давно не проводили никаких серьёзных публичных акций — последнее время это были внутренние, для наших действующих клиентов.
Решили исправить ситуацию — у нас новая акция, для всех — и новых клиентов и старых — сервера HP Proliant по цене виртуального сервера — всего 2000 рублей в месяц, размещение — Россия, Москва.
Все сервера оснащены системой удалённого управления iLO (встроеная IP-KVM), гигабитным подключением к интернет, бесплатной панелью управления ISPmanager5 и бэкапным аккаунтом на 100Gb

И снова переезд 26.04.2018
В ночь 28 на 29 апреля 2018 года, в период с 23:00 до 6:00 планируется переезд оборудования в другое здание.
На этот раз не плановый, по причине поиска более качественных услуг, а по внешним обстоятельствам — текущее здание, где размещается датацентр datacheap.ru, планируется к сносу.
Новое место размещения — Москва, Угрешская улица, д. 2 стр. 147. Это бывший датацентр Яндекса, съехавшего в губернию Российской Империи — Финляндию.
На новом месте будет гораздо лучше — каналы шире, сетевое оборудование качественнее. Появится внешняя защита от DDoS, фильтрующая любые виды атак, отсеивая паразитный трафик. Она станет действовать на всех услугах нашего хостинга: VDS, выделенные серверы, PHP хостинг и прочее.

• Подведённая мощность: 2 МВт
• Независимых линий городского электроснабжения: 2 шт.
• Источников бесперебойного питания: 6 шт.
• Схема подключения ИБП: N+2
• Запас аккумуляторов: 15 минут при полной загрузке дата-центра
• Дизель-генераторные установки: 2 шт.
• Производитель ДГУ: F.G. Wilson
• Производитель двигателя ДГУ: Perkins
• Суммарная мощность: 2.4 МВт
• Ёмкость баков: 6 тонн (18 часов работы)
• Всепогодные тепловые контейнеры: Да
• Прецизионные кондиционеры: 20 шт.
• Производитель: Eistorm, HiRef
• Схема подключения: N+2
• Автоматизированная система газового пожаротушения
• Система видеонаблюдения внутри и снаружи здания
• ЦОД находится на закрытой охраняемой территории московского бизнес-центра IQ-Park
• Опорная сеть: 10G
• коммутаторы Cisco
• Основной маршрутизатор: Juniper MX-960, рассчитан на передачу трафика до 10 Тбит/с
• Агрегирующие коммутаторы: Huawei, позволяют организовать подключения до 40G на стойку

Антикризисные скидки на выделенные сервера 11.04.2018
В ответ на санкции, мы решили оставить новогодние скидки в 40% — на все выделенные сервера.
Скидка действует при оплате сервера на год или более.
При заказе на два года, скидка составит 50%: www.host-food.ru/tariffs/vydelennyi-server-ds/
Мы предоставляем большой выбор тарифов на выделенные сервера — от самых простых, на пару одноядерных процессоров, до 16 ядерных. Возможен заказ любой конфигурации отличной от тех что в тарифах — просто это может занять один-два рабочих дня.
Активация готового сервера и установка нужной вам операционной системы занимает считанные минуты.

Поддержка SSL на тарифных планах Lite 02.02.2018
В связи с тем, что Google начал учитывать наличие SSL сертификата у сайта при ранжировании, а также с тем, что новые версии браузеров стали помечать сайты без SSL как небезопасные — мы добавили поддержку SSL на тарифной линейке Lite (кроме самых младших тарифных планов — «Микро» и «Мини»).
Теперь вы можете включить поддержку SSL для своих сайтов не меняя тариф на более дорогой. Также, нет необходимости заказывать выделенный IP адрес или платить дополнительные деньги центрам сертификации — вы можете использовать бесплатные сертификаты от Let's Encrypt.

Новогодняя скидка на выделенные сервера 21.12.2017
Хостинг HOST-FOOD.ru поздравляет с наступающим Новым годом всех наших клиентов! Мы искренне рады, что Вы выбирали нас, и надеемся, что в следующем году наше сотрудничество станет еще более плодотворным. Желаем Вам творческих успехов и благополучия в наступающем году!
А чтобы год был ещё лучше, мы запускаем новогоднюю акцию — скидка 40% на заказ или оплату любого выделенного сервера до 31 января.
Желаем удачного развития вашим проектам!

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

Снижение цен на все выделенные сервера 12.05.2017
Рады сообщить Вам о снижении цен на все выделенные сервера, представленные на нашем сайте. Также, при аренде выделенного сервера, бесплатно предоставляется панель управления ISPmanager 5 и 100Tb под бэкап.
По желанию, возможна бесплатная начальная настройка сервера нашими специалистами и помощь в переносе данных.

Интеграция с Let's Encrypt 02.03.2017
На всех тарифах линейки VIP, теперь доступны бесплатные SSL сертификаты от Let's Encrypt.
Для того чтобы воспользоваться этой возможностью, следуйте данной инструкции:
www.host-food.ru/faq/technical.questions/ssl.certificates/let.s.encrypt/

Переезд в новый датацентр 18.09.2016
16 сентября, около 7 часов по Москве, в этой самой Москве, неторопливо происходило следующее:
«Равшан» и «Джамшут», занятые на перекладке теплотрассы, в месте прохождения будущей восточной хорды (пересечение с шоссе Энтузиастов), копали котлован.
Место, где в здание входит пучок слаботочных кабелей, они аккуратно обкопали, повесили все кабеля на крепления — как и велел «насяльника».
Решили переставить бетонный блок, который огораживает котлован, зацепили чем-то за ковш эскаватора, подняли.
Когда перемещаемый блок находился над кабелями, висящими на временной опоре, это самое «чего-то» — оборвалось…
События понеслись вскачь — кабеля, естественно, порвались — все сразу, оптика, телефоны, сигнализация… Мало что они просто порвались, перед этим их вырвало из здания, и из колодца — т.е. прямо с «мясом» из распределительных коробок.
В момент этого безусловно печального события, которое прошло бы для всех незаметно, «почему-то» перестали быть доступны все наши сервера =(
Подъехавшая бригада ремонтников «обрадовала» — постараемся до конца светового дня сделать. Печально конечно, но такое у всех провайдеров бывало, и все это как-то пережили.
Мы честно ждали до конца, до 5 вечера — отвечая на звонки клиентов, отписываясь в фейсбуках/вконтактах.
Вечером, появились новости от операторов связи и техников — в изложении девочки ответившей по телефону, это звучало как: «если сегодня не успеют, продолжат завтра». Причём по интонациям угадывалось, что сегодня они точно не доделают.
Приехали. До завтра мы ждать не можем.
Переезд планировался, но на 30 сентября — поскольку из-за этих раскопок вокруг здания постоянно чего-то отваливалось — то кабеля слаботочки тронут, то кондиционер отломают, то силовой кабель выкопают — с искрами и прочими спецэффектами… Была договорённость с другим датацентром, но на 30 сентября, прямо сейчас у них оказалось не готово — нет готовой стойки, нет свободного бесперебойника.
Начали обзвон датацентров — бестолку, прямо сегодня нас принять были готовы только в одном, и то сомневались, что смогут анонсировать нашу сеть, предоставить BlackHole Community и прочее. Причины банальны — невозможно в пятницу вечером найти трезвого электрика, админа, или «менеджера» (не знаю кто это такие — «менеджеры», но без них вопросы с размещением не решаются — несмотря на существование твёрдо указанных прайсов, наличия под рукой трезвого электрика или админа и т.п. Причём, эта «менеджерская» болезнь — только у дорогих и крупных датацентров, у которых дежурный персонал способен нас включить/настроить если мы приедем. В мелких, всё можно решить без менеджеров, но электрики с админами бухают или разъехались далеко и надолго).
В седьмом часу, когда уже были готовы поехать в ДЦ с ценой в три раза выше чем в текущем (что забавно — они просили гарантийное письмо о оплате — с людей которые им привезут оборудования на два миллиона и не требуют с них ничего, кроме шнурка с интернетом взамен), раздался звонок от DataCheap.ru — к ним мы и собирались изначально — уточнили сколько у нас юнитов, сказали, что могут нас принять сегодня, выделить 35 юнитов в стойке, сделать сессию по bgp, анонсировать сеть — да хоть чёрта лысого в ступе =))
Дальше, повествование от первого лица, как участника событий.
Хорошо, но перевозить лично мне, хоть и не одному, а моя узбекская «шайтан-арба» (Матиз 2003 года выпуска) находится на даче. Договорился о помощи с человеком на машине, он поехал сразу к ДЦ, я на дачу, за машиной.
Пока еду в электричке, звоню в текущий ДЦ, прошу разрешить вынос оборудования, разрешить вход народа, въезд машин — там всё строго с этим. Через некоторое время, они мне перезванивают — начальник охраны уже ушёл, гендиректор уже ушёл, охрана машины не впустит, стойку железа вынести не даст. Финиш…
Прошу созвониться хоть с кем-то, может по телефону скомандуют своим «дуболомам», а мне в ответ — уже звонили, не берут трубки — видимо бухают, пятница же =)
А мужики подъезжают в датацентр, я уже сел в «шайтан-арбу» и выруливаю со стоянки у платформы электрички… Остановился, думаю, кому звонить, чего делать — перезванивают, свершилось чудо, дозвонились до старшого охраны, он отзвонился на пост охраны здания и промычал, видимо разглядывая часы: разрешаю въезд, вынос… с 21:00 до 22:00.
Ладно, время уже 9 вечера, через тридцать-сорок минут буду на месте, главное всем заехать, зайти в здание — пока всё не вынесем, хрен нас кто оттуда выгонит.
Мчусь по Горьковскому шоссе, в Москву, в Балашихе останавливаюсь на светофоре — и загорается лампочка давления масла. Газую — гаснет. Рулю на обочину, глушу, тяну щуп — масло есть, между метками на щупе. Абзац, думаю, кончились подшипники коренные.
Терять уже нечего — судя по симптомам — так и так попал на переборку движка — так что, тапку в пол, полетел — и лампочка не горит, главное обороты не сбрасывать =)
Приехал в 21:30, через 10 минут уже разбирали стойку и грузили сервера в «Матиз» и «Ланос». Предварительно, правда, я поинтересовался у хозяина «Ланоса» — утянет ли он меня вместе с гружёным в него и меня железом — вероятность, что «Матиз» словит клина, только прибывает с каждым пройденным километром.
Сказал что утянет, за что цеплять у него есть (это я специально уточнял — у меня до этого был «Москвич-2141» так на нём не было, я за крепление запаски цеплял когда надо было тянуть кого-то — благо она снизу и сделана из стального прутка миллиметров 12 в диаметре =)).
К 23:00 сняли всё что снимается, отломали всё что не снимается, загрузились, помахали охране ручкой и отчалили.
Едем в новый ДЦ — пробок уже нет, благодать, а в ВотсАпп пишет тамошний ГенДиректор, он же главный цисочник — для анонса нашей сети надо подвердить маршрут в ripe.net — майнтайнера ихнего я добавил заранее, знал же что скоро к ним поедем. Угу, побежал прям — во первых до компа я в лучшем случае если утром доберусь, во вторых на том утреннем компе пароля этого нет, а в третьих пароль от ripe хранится на тех самых серверах которые мы везём. Хорошо я про ситуацию подумал заранее, он был ещё и в браузере сохранён, на работе — откуда я его сегодня днём с экрана и сфоткал на телефон (принтер сломался — ну что за день же был!). Фотку и отправил цисочнику — доберусь до компа — сменю. Тока он не унимался, просил прислать в текстовом виде… Потом правда отстал и попозже отписался, что всё путём. Причину я понял тока на следующий день, глядя на этот пароль — 32 рандомных символа =)) Странно, что мне не икалось, пока он его вводил =))
В 12 часов ночи уже затаскивали железо в новый датацентр. Пока я переконфигурил джунипер (использовав наш сервер биллинга в качестве персоналки =)), начали примерять салазки в стойку — и тут очередной облом — стойка оказалась не стойкой, а шкафом, к тому же телекоммуникацонным, а не серверным — т.е. он по глубине меньше. Сервера не влезают. Других готовых стоек нет, будут только на следующей неделе.
Бросили всё, пошли курить и думать. Первая мысль была — не дотяну до круглой даты — в декабре будет 10 лет как бросил пить — а в «Ланосе» валялась бутылка вискаря, за которую его хозяин трясся больше чем за перевозимое железо =)
Поприкидывав тот самый орган к рылу, соображаем — в шкаф сервера встают, но задняя дверь не закроется — снимаем её к чёртовой бабушке. Дальше, закрепить их не получается — но — направляющие можно раздвинуть — место есть. Правда, проблема — шкаф не вытащщить, а крепления направляющих откручиваются только со снятыми боковыми стенками. Снова волшебный орган к рылу, печальные воспоминания о том, что в машине есть ключ с трещщоткой, а я потерял переходник с 1/4'' квадрата на шестигранник — и рождается «чудо-инструмент» — в разводной ключ зажимается крестовая бита, эта хреновина просовывается в щель между направляющими и стенкой шкафа (а расстояние там чуть больше чем короткая бита по длине), нащщупывается винт, и потихоньку, по четверти оборота ослабляется. С поисками, наощупь, винта через каждую четверть оборота. И так 16 раз — т.к. винтов именно столько. По прошествии часа все пальцы болят — изрезаны кромками направляющих, но они раздвинуты на максимум. Сервера влезают.
К восьми утра всё установлено, проверено что с серверов пингуются «интернеты», и под весёлое подмигивание лампочки давления масла я покатился до дому, до хаты.
Приехал, проверил — работает не отовсюду. Видимо, в старом ДЦ нашу сеть не сняли с анонса, часть клиентов ломится по старому маршруту — в т.ч. и я из дома. Ладно, не та проблема — отписываюсь сетевику старого ДЦ, он снимает — через 15 минут забегало отовсюду.
Ещё через 10 минут, вообще всё перестало пинговаться, из любой точки. Блин. Достало.
Звоню в новый ДЦ, прошу глянуть, что там и как. Через очередные 10 минут перезваниваю — всё просто — стойка висела на 10 амперном автомате. Там было телекоммуникационное оборудование, оно больше не кушало. У нас же потребление около 17 ампер, обычно. Вышибло.
Перевесили на автомат с током отсечки 32A, всё оборудование само включилось — не зря я у каждого сервера, в BIOS, выставлял автоматическое включение в случае пропадения питания. На этом, этот бесконечный день для меня окончился, и я впал в энергосберегающий режим =)
Вечером ещё раз съездил — подключил сеть на PDU'шки — забыл сразу прицепить, включил один сервер — благо свой, технический — никто не и не заметил. Всё ещё раз посмотрел на сежую голову, пощщупал, подёргал, перевесил пару серверов в другие порты коммутатора — как показалось логичней…
Где-то через неделю поставят бесперебойник, переключимся на него, и можно считать, что эпопея с переездом окончена.
P.S. Если бы не переезжали, заработало бы ночью — технари всё же работали до упора, не бросив на ночь.
P.P.S. В «шайтан-арбе» поменял масляный фильтр, и лампочка перестала загораться на холостом ходу. Видимо, бракованный фильтр — масло и фильтр я менял за 300 километров до этого.
P.P.P.S. По поводу расстановки запятых в тексте — возражения не принимаются — я их расставлял для акцентирования смысла, а не по правилам русского языка.
По которому у меня в школе было 5, кстати говоря. И все, что не сходится с правилами — я прекрасно вижу и знаю. Но это — авторский текст, и такое вполне допустимо.

Возможность использовать php 7 для сайта 15.03.2016
На всех серверах с новой версией панели ISPmanager, появилась возможность использовать для своего сайта не только php 5.x версий, но и php 7 / 7.1.
Для этого, следует воспользоваться встроенным селектором версии php

Снижены цены на IP адреса 04.09.2015
Сильно снижены цены на дополнительные IP адреса — те которые к заказам хостинга — до 30 руб/шт, к VPS — до 60 руб/шт.

Запущен новый сервер для тарифной линейки VIP: ISPmanager 5 Businnes, php 5.4 25.05.2015
У нас пополнение в списке серверов для размещения тарифов из линейки VIP: s31.host-food.ru
Используемая панель управления: ISPmanager 5 Businnes.
Сервер собран на платформе SuperMicro, использован аппартный RAID контроллер LSI / 3ware 9750 и настоящий 64-битный 8-ми ядерный процессор AMD Opteron 6235, а не клон от Intel; =)
Почему «настоящий»? Потому что 64 битную архитектуру разработала AMD, а Intel выпускает 64-битные процессоры по лицензии «отжатой» у АМД на основании просроченных договоров 20-летней давности. Кому интересны подробности — можете найти их в яндексе/гугле.

Очередной сервер в тарифной линейке Lite — на этот раз, необычный: Blade 21.05.2015
Мы потихоньку растём — клиентов становится больше, ресурсов им требуется тоже больше. Поэтому, для размещения аккаунтов тарифной линейки Lite был куплен Blade-сервер SuperMicro SuperServer 5037MC-H8TRF — 8 отдельных однопроцессорных лезвий, у каждого лезвия по два отдельных диска, на RAID контроллере LSI.
Первый сервер s02.host-food.ru, был запущен сегодня. Остальные семь лезвий будут запущены в ближайшие дни.

Запуск нового сервера, под управлением ISPmanager5 12.02.2015
Сегодня, для тарифной линейки Lite, был установлен и настроен новый сервер, под управлением новой панели ISPmanager 5.
Разработчики обещают, что всё будет работать быстро, ничего не будет тормозить и вообще ошибок больше не будет =)
Функционала, правда, пока поменьше чем в старой панели, но, не пройдёт и нескольких лет…
Подождём, посмотрим.
А пока — можно делать заказы на хостинг, и пользоваться.

Наш сайт переехал на новый сервер 25.01.2015
Наш сайт раньше жил на сервере бэкапов — bkp0.host-food.ru — как-то так исторически сложилось, самый мощный наш сервер, а занимается ерундой — хранит бэкапы. Чтобы зря вычислительные ресурсы не пропадали — поселили туда наш сайт и биллинг.
Со временем, хостинг вырос, вместо трёх серверов, нас теперь почти целая стойка, и начались проблемы — большая дисковая активность ночью/утром — результат архивации наших и клиентских ресурсов, стала приводить к медленной работе биллинга, вплоть до моментов недоступности.
Было принято решение, вынести сайт и биллинг с этого сервера на давно пустоваваший Aquarius Server T40 S13 — как купили новый, так и стоял в стойке, ненужный и даже неподключенный.
По синтетическим тестам (гоняли ubench в 10 проходов) новый сервер набрал ~270 тысяч «попугаев», старый же ~190 тысяч всё тех же «попугаев». Так что, в теории, сайт с биллингом должны были начать работать в полтора раза быстрей.
(Надо частно заметить, что сильно быстрей оно не стало… быстрей, да, но процентов на 15-20, но никак не на на 50%. Самое главное — больше по ночам и утром не тормозит, так что чего хотели — того добились. Ну а то что на биллинге Intel, а не наш любимый AMD… Подождём, подрастём, купим правильную платформу, на правильных процессорах AMD =))

Запуск виртуализации KVM 21.01.2015
Рады вам сообщить, что на нашем хостинге запущена в работу система виртуализации KVM (Kernel-based Virtual Machine), цены на которую вас приятно удивят:
www.host-food.ru/tariffs/virtualny-server-vps/
Как всегда, мы используем только лучшее оборудование:
www.host-food.ru/about/hardware/our.hosting.servers/

Мы в соцсетях 16.12.2013
Уважаемые пользователи нашего хостинга, теперь мы стали еще ближе к Вам. У нас работают странички в социальных сетях ВКонтакте и Facebook. На них Вы всегда сможете получить оперативную информацию о работе хостинга, в том числе и в случаях недоступности основного сайта.
Так же на них мы решили регулярно проводить акции для наших подписчиков и выкладывать промокоды с приятными скидками. Подписывайтесь и следите за новостями. Удачных Вам сайтов!

python27 модулем apache2.2 24.04.2013
На всех наших тарифных планах появилась возможность использовать python27, в режиме модуля веб-сервера apache.

Увеличение лимитов на процессорное время 19.10.2012
Заботясь о качестве предоставляемых услуг виртуального хостинга мы постоянно анализируем отзывы наших клиентов. Большое количество замечаний вызывает низкое количество ресурсов сервера (CPU, RAM) на дешевых тарифах. Оценив возможности своих серверов и приба?
Читать дальше →

ВЕНА, Австрия – 19 декабря 2024 г. – Разработчик корпоративного программного обеспечения Proxmox Server Solutions (далее «Proxmox») сегодня объявил о первом предварительном просмотре своего нового проекта с открытым исходным кодом Proxmox Datacenter Manager. Эта ранняя альфа-версия программного обеспечения предназначена для того, чтобы дать первое впечатление, и теперь опубликована, чтобы пригласить сообщество Proxmox к сотрудничеству.

Что такое Proxmox Datacenter Manager?
Proxmox Datacenter Manager — это программное обеспечение для управления серверами с открытым исходным кодом, разработанное для предоставления единого обзора всех узлов и кластеров, которые пользователи Proxmox VE имеют в своих виртуализированных средах. Предоставляя современный пользовательский интерфейс, первая альфа-версия позволяет пользователям подключаться к соответствующим узлам и/или кластерам из одного места, тем самым облегчая управление серверами и оптимизируя административные задачи.

Proxmox Datacenter Manager Alpha позволяет просматривать базовое использование ресурсов всех узлов и их гостей. Кроме того, он позволяет выполнять базовое управление ресурсами, включая выключение, перезагрузку, запуск и т. д., а также облегчает удаленную миграцию виртуальных гостей между различными центрами обработки данных. Для более сложного управления инструмент напрямую подключается к нужному узлу и/или кластеру в полном веб-интерфейсе Proxmox VE.

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

План развития и загрузка
Первый альфа-релиз доступен для сообщества для тестирования и совместной работы. План развития, а также инструкции по загрузке и установке доступны в официальном объявлении на форуме.

О решениях Proxmox Server
Proxmox предоставляет мощное и удобное серверное программное обеспечение с открытым исходным кодом. Предприятия всех размеров и отраслей используют решения Proxmox для развертывания эффективных и упрощенных ИТ-инфраструктур, минимизации общей стоимости владения и избежания привязки к поставщику. Proxmox также предлагает коммерческую поддержку, услуги обучения и обширную партнерскую экосистему для обеспечения непрерывности бизнеса для своих клиентов. Proxmox Server Solutions GmbH была основана в 2005 году и имеет штаб-квартиру в Вене, Австрия.

Контакт: Даниэла Хеслер, Proxmox Server Solutions GmbH

Мы рады сообщить, что наша последняя версия программного обеспечения 8.4 для Proxmox Virtual Environment теперь доступна для загрузки. Этот выпуск основан на Debian 12.10 «Bookworm», но использует ядро ​​Linux 6.8.12 и ядро ​​6.14 в качестве опции, QEMU 9.2.0, LXC 6.0.0, ZFS 2.2.7 с исправлениями совместимости для ядра 6.14 и Ceph Squid 19.2.1 в качестве стабильной опции.

Proxmox VE 8.4 включает следующие основные моменты:

• Динамическая миграция с посредническими устройствами
• API для сторонних решений резервного копирования
• Проход каталога Virtiofs
• и многое другое

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

Заметки о выпуске
pve.proxmox.com/wiki/Roadmap

Пресс-релиз
www.proxmox.com/en/news/press-releases

Загрузка
www.proxmox.com/en/downloads
Альтернативная загрузка ISO:
enterprise.proxmox.com/iso

Документация
pve.proxmox.com/pve-docs

Форум сообщества
forum.proxmox.com

Отслеживание ошибок
bugzilla.proxmox.com

Исходный код
git.proxmox.com

Мы получили много отзывов от членов нашего сообщества и клиентов, и многие из вас сообщали об ошибках, отправляли исправления и участвовали в тестировании — СПАСИБО за вашу поддержку!

Могу ли я обновить последнюю версию Proxmox VE 7 до 8 с помощью apt?

Да, следуйте инструкциям по обновлению на pve.proxmox.com/wiki/Upgrade_from_7_to_8

Могу ли я обновить установку 8.0 до стабильной версии 8.4 через apt?

Да, обновление возможно через apt и GUI.

Могу ли я установить Proxmox VE 8.4 поверх Debian 12 «Bookworm»?

Да, см. pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_12_Bookworm

Могу ли я обновиться с Ceph Reef до Ceph Squid?

Да, см. pve.proxmox.com/wiki/Ceph_Reef_to_Squid

Могу ли я обновить свой кластер Proxmox VE 7.4 с Ceph Pacific до Proxmox VE 8.4 и Ceph Reef?

Это трехэтапный процесс. Сначала вам нужно обновить Ceph с Pacific до Quincy, а затем вы можете обновить Proxmox VE с 7.4 до 8.4. Как только вы запустите Proxmox VE 8.4, вы можете обновить Ceph до Reef. Внесено множество улучшений и изменений, поэтому, пожалуйста, точно следуйте документации по обновлению:
pve.proxmox.com/wiki/Ceph_Pacific_to_Quincy
pve.proxmox.com/wiki/Upgrade_from_7_to_8
pve.proxmox.com/wiki/Ceph_Quincy_to_Reef

shop.proxmox.com

А так же удаление всей истории новостей