Допустим, вам нужно перенести хранилище данных из одного кластера в другой. А выключать его нельзя, потому что это может вызвать незначительный (или значительный) коллапс сервисов, которые с ним работают. В статье мы расскажем о не самом очевидном и популярном способе переноса etcd из одного облачного кластера Kubernetes в другой. Такой способ поможет избежать простоя и связанных с ним последствий. Согласно стартовым условиям, оба кластера находятся в облаке, а потому нам предстоит столкнуться с некоторыми ограничениями и трудностями — им мы уделим особое внимание.
Рубрика «etcd»
Как настроить миграцию etcd между облачными кластерами Kubernetes и избежать простоев
2023-05-25 в 6:05, admin, рубрики: deckhouse, devops, etcd, k8s, kubernetes, Администрирование баз данных, базы_данных, Блог компании Флант, миграция, облако, облачные сервисы, системное администрирование, ФлантКто победит: средненагруженный Kubernetes или простой list-запрос?
2023-05-05 в 6:17, admin, рубрики: api, devops, etcd, kubernetes, requests, Блог компании Флант, кейс, системное администрированиеВ статье мы расскажем, как столкнулись со множественными запросами к API-серверу Kubernetes от одного из приложений, к чему это привело и каким образом проблема была решена.
Предыстория
Как с fio проверить диски на достаточную производительность для etcd
2020-06-04 в 9:34, admin, рубрики: etcd, fdatasync, fio, kubernetes, Блог компании Флант, производительность, системное администрирование, хранилища данныхПрим. перев.: эта статья — итоги мини-исследования, проведенного инженерами IBM Cloud в поисках решения реальной проблемы, связанной с эксплуатацией базы данных etcd. Для нас была актуальна схожая задача, однако ход размышлений и действий авторов может быть интересен и в более широком контексте.
Краткое резюме всей статьи: fio и etcd
Производительность кластера etcd сильно зависит от скорости хранилища, лежащего в его основе. Для контроля за производительностью etcd экспортирует различные метрики Prometheus. Одной из них является wal_fsync_duration_seconds. В документации к etcd говорится, что хранилище можно считать достаточно быстрым, если 99-й процентиль этой метрики не превышает 10 мс…Читать полностью »
Наш опыт работы с данными в etcd Kubernetes-кластера напрямую (без K8s API)
2020-05-21 в 8:17, admin, рубрики: etcd, kubernetes, Блог компании Флант, Сетевые технологии, системное администрированиеВсе чаще к нам обращаются клиенты с просьбой обеспечить доступ в Kubernetes-кластер для возможности обращения к сервисам внутри кластера: чтобы можно было напрямую подключиться к какой-то базе данных или сервису, для связи локального приложения с приложениями внутри кластера…
Например, возникает потребность подключиться со своей локальной машины к сервису memcached.staging.svc.cluster.local. Мы предоставляем такую возможность с помощью VPN внутри кластера, к которому подключается клиент. Для этого анонсируем подсети pod'ов, сервисов и push'им кластерные DNS клиенту. Таким образом, когда клиент пытается подключиться к сервису memcached.staging.svc.cluster.local, запрос уходит в DNS кластера и в ответ получает адрес данного сервиса из сервисной сети кластера или адрес pod'а.
K8s-кластеры мы настраиваем с помощью kubeadm, где по умолчанию сервисная подсеть — 192.168.0.0/16, а сеть pod'ов — 10.244.0.0/16. Обычно всё хорошо работает, но есть пара моментов:Читать полностью »
etcd 3.4.3: исследование надёжности и безопасности хранилища
2020-02-11 в 7:21, admin, рубрики: etcd, nosql, open source, Блог компании Флант, параллельное программирование, распределенные базы данныхПрим. перев.: Содержимое этой статьи не совсем типично для нашего блога. Однако, как многим известно, etcd находится в самом сердце Kubernetes, из-за чего данное исследование, проведённое независимым консультантом в области надёжности, оказалось интересным и в среде инженеров, эксплуатирующих данную систему. Кроме того, оно интересно в разрезе того, как Open Source-проекты, уже зарекомендовавшие себя в production, совершенствуются даже на таком, весьма «низком», уровне.
Хранилище пар «ключ-значение» (KV) etcd представляет собой распределённую базу данных, основанную на алгоритме консенсуса Raft. В ходе анализа, проведенного в 2014 году, мы обнаружили, что etcd 0.4.1 по умолчанию была подвержена так называемым stale reads (операциям чтения, возвращающим старое, неактуальное значение из-за запаздывания синхронизации — прим. перев.). Мы решили вернуться к etcd (в этот раз — к версии 3.4.3), чтобы снова детально оценить ее потенциал в области надежности и безопасности.Читать полностью »
HighLoad++, Михаил Макуров (Интерсвязь): опыт создания резервного и кластеризованного Zabbix-сервиса
2020-01-26 в 11:41, admin, рубрики: clickhouse, etcd, point of view, split brain, zabbix, Блог компании ua-hosting.company, высокая производительность, конференции, Серверное администрированиеZabbix — популярная открытая система мониторинга, используется большим количеством компаний. Я расскажу об опыте создания кластера мониторинга.
В докладе я коротко упомяну о сделанных ранее правках (патчах), которые существенно расширяют возможности системы и готовят базу для кластера (выгрузка истории в «Кликхаус», асинхронный поллинг). И подробно рассмотрю вопросы, возникшие при кластеризации системы — разрешение конфликтов идентификаторов в БД, немного о CAP theorem и мониторинге с распределёнными БД, о нюансах работы Zabbix в кластерном режиме: резервирование и координирование работы серверов и прокси, о «доменах мониторинга» и новом взгляде на архитектуру системы.
Коротко расскажу о том, как запустить кластер у себя, где взять исходники, какие доп. настройки потребуются для кластера.
HighLoad++ Siberia 2019. Зал «Томск». 24 июня, 17:00. Тезисы и презентация. Следующая конференция HighLoad++ пройдет 6 и 7 апреля 2020 года в Санкт-Петербурге. Подробности и билеты по ссылке.Читать полностью »
Построение кластера PostgreSQL высокой доступности с использованием Patroni, etcd, HAProxy
2019-12-28 в 9:42, admin, рубрики: etcd, haproxy, patroni, postgresql, высоконагруженные системы, кластеризация, Серверное администрирование, системное администрированиеТак уж вышло, что на момент постановки задачи я не обладал достаточной степенью опытности, чтобы разработать и запустить это решение в одиночку. И тогда я начал гуглить.
Не знаю, в чем загвоздка, но уже в который раз я сталкиваюсь с тем, что даже если делать все пошагово как в туториале, подготовить такой же enviroment как у автора, то все равно никогда ничего не работает. Понятия не имею, в чем тут дело, но когда я столкнулся с этим в очередной раз, я решил — а напишу-ка я свой туториал, когда все получится. Тот, который точно будет работать.
Скорость хранилища подходит для etcd? Спросим fio
2019-05-07 в 14:42, admin, рубрики: devops, etcd, fio, k8s, linux, prometheus, storage, Блог компании Southbridge, Серверное администрирование, системное администрирование
Короткая история о fio и etcd
Производительность кластера etcd во многом зависит от производительности его хранилища. etcd экспортирует некоторые метрики в Prometheus, чтобы предоставить нужные сведения о производительности хранилища. Например, метрику wal_fsync_duration_seconds. В документации к etcd сказано: чтобы хранилище считалось достаточно быстрым, 99-й процентиль этой метрики должен быть меньше 10 мс. Если вы планируете запустить кластер etcd на машинах Linux и хотите оценить, достаточно ли быстрое у вас хранилище (например, SSD), можно использовать fio — популярный инструмент для тестирования операций ввода-вывода. Запустите следующую команду, где test-data — это каталог под точкой подключения хранилища:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestНужно просто посмотреть результаты и проверить, что 99-й процентиль длительности fdatasync меньше 10 мс. Если да, у вас достаточно быстрое хранилище. Вот пример результатов:
sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
sync percentiles (usec):
| 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
| 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
| 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
| 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
| 99.99th=[15795]Разворачиваем Kubernetes HA-кластер на Baremethal с помощью Kubeadm и Keepalived (простое руководство)
2018-10-27 в 11:38, admin, рубрики: devops, etcd, high availability, kubernetes, multimaster, кластер, системное администрированиеЭта статья является свободной интерпретацей официального руководства Creating Highly Available Clusters with kubeadm для Stacked control plane nodes. Мне не нравятся сложный язык и примеры использованные в нем, поэтому я написал свое руководство.
Если у вас появятся какие-либо вопросы или вам будет что-то неясно, обратитесь к официальной документации или спросите Google. Все этапы описаны здесь в максимально простой и сдержанной форме.
CoreDNS — DNS-сервер для мира cloud native и Service Discovery для Kubernetes
2017-06-29 в 5:51, admin, рубрики: cloud native, coredns, devops, DNS, etcd, kubernetes, service discovery, Блог компании Флант, микросервисы, Сетевые технологии, системное администрирование, метки: coredns
Две недели назад Open Source-проект CoreDNS отметился своим очередным релизом — 008. Авторы называют свой продукт «DNS-сервером, состоящим из цепочки промежуточных компонентов (middleware), каждый из которых реализует какую-то возможность DNS». Что примечательно, они уже успели добиться включения CoreDNS в список официальных проектов организации CNCF (Cloud Native Computing Foundation), пополнив ряды Kubernetes, Prometheus, CNI, containerd, rkt и других разработок, активно применяемых в мире контейнеров, микросервисов и «родных облачных приложений» (cloud native).
Как появился CoreDNS, для чего он предназначен и как его можно использовать?Читать полностью »