Как стать автором
Обновить
828.09
OTUS
Цифровые навыки от ведущих экспертов

Проектирование надёжности сайта для Kubernetes

Время на прочтение 11 мин
Количество просмотров 3.5K
Автор оригинала: Tammy Bryant Butow

За последние 4,5 года Kubernetes значительно улучшилась с точки зрения удобства использования, и теперь начать работу с Kubernetes стало проще, чем когда-либо. Облачные провайдеры, такие как Amazon AWS, теперь располагают продуктами Kubernetes, которые создают кластеры для вас и управляют ими. Это существенное преимущество по сравнению с созданием собственного кластера Kubernetes.

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

Спасибо https://twitter.com/MindsEyeCCF за эту иллюстрацию
Спасибо https://twitter.com/MindsEyeCCF за эту иллюстрацию

Глубокое изучение надежности

Как в SRE, у меня также существует система, которую я использую при проведении глубокого анализа надежности:

  1. Оглянитесь назад и проанализируйте неудачи

  2. Определите цели и ключевые параметры

  3. Создайте стратегию надежности

  4. Проверьте стратегию надежности на практике

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

Оглянитесь назад и проанализируйте неудачи

Далее, давайте начнем с рассмотрения распространенных видов отказов при запуске Kubernetes в продакшн.

Распространенные типы отказов для Kubernetes в продакшн

На основе анализа отчетов, собранных и опубликованных на сайте k8s.af, мы можем определить наиболее распространенные виды отказов, которые в настоящее время влияют на Kubernetes в продакшн. Чаще всего инциденты были вызваны проблемами, связанными с процессором (CPU) (25%) или недоступностью кластеров из-за целого ряда проблем (25%). Остальные 50% инцидентов были связаны с сетью (DNS, задержка и потеря пакетов), ресурсами (диск или память) или безопасностью.

Перебои, связанные с CPU, можно разделить на три категории: высокий уровень загрузки CPU (High CPU), троттлинг CPU и автомасштабирование через CPU.

Тип отказа Kubernetes: High CPU

Несколько компаний сообщили о резких скачках нагрузки на процессор (High CPU), вызывающих проблемы для них и их пользователей. Инженер по тестированию компании Дэн Вудс рассказал о том, как его кластеры Kubernetes пострадали от инцидента с высокой нагрузкой на процессор, в заметке на Medium под названием "Инфраструктура в масштабе: Каскадный отказ распределенных систем".

Ниже приведены ключевые выдержки (иллюстрации Эмили Гриффин):

Тип отказа Kubernetes: троттлинг CPU

В июле 2019 года Хеннинг Якобс (Zalando) выступил на ContainerDays в Гамбурге с докладом "Истории неудач Kubernetes, или: Как обрушить ваш кластер - Хеннинг Якобс". В этом докладе Хеннинг объяснил, что троттлинг CPU влияет на надежность кластера.

Тип отказа Kubernetes: автомасштабирование через CPU

В 2017 году компания Nordstrom рассказала о 101 способе выхода из строя вашего кластера на основе опыта, который они получили при масштабировании Kubernetes. Среди них были примеры, связанные с автомасштабированием.

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

Анализ сообщений о сбоях Kubernetes от облачных провайдеров

На сайте k8s.af собрано и размещено 45 сообщений об инцидентах, связанных с продакшн Kubernetes . Анализируя список облачных провайдеров, которые чаще всего упоминаются в этих сообщениях, мы видим, что 65,8% этих инцидентов произошли на AWS. В основном это были кластеры AWS Kubernetes, запущенные вручную на EC2 (а не управляемый сервис Kubernetes, предоставляемый AWS, EKS), есть только 1 сообщение об инциденте AWS EKS. Пользователи GKE столкнулись с 23,7% сбоев, за ними следует Azure (5,3% сбоев). 5,3% сбоев произошли с кластерами Kubernetes, расположенными на локальных серверах.

Далее рассмотрим распространенные типы отказов в зависимости от поставщика облачных услуг. Поскольку автомасштабирование, CPU и отключение инстансов управляются по-разному у каждого облачного провайдера, я ожидаю, что определенные сбои будут чаще встречаться у конкретной компании (например, CPU у Amazon AWS).

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

Kubernetes на AWS: типы отказов

Если вы используете AWS, я рекомендую вам сосредоточиться на CPU в качестве основного способа устранения неисправностей во время ваших действий по обеспечению надежности. Затем я рекомендую исследовать отказы, связанные с сетью (в первую очередь "Черные дыры" (Blackhole), задержки и DNS).

Kubernetes на GKE: типы отказов

Если вы используете GKE, то я рекомендую вам сосредоточиться на Blackhole в качестве основного типа отказа во время мероприятий по укреплению надежности. Затем я рекомендую изучить отключение, задержку и DNS.

Если вы используете Azure, я рекомендую вам сосредоточиться на отключении (Shutdown) в качестве основного типа отказов во время мероприятий по укреплению надежности.

Kubernetes локальный вариант: типы отказов

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

Проектирование надежности сайта для Kubernetes

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

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

Теперь мы готовы определить наши цели и основные параметры.

Определение целей и основных параметров

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

  • Количество кластеров Kubernetes

  • Количество узлов

  • Количество узлов по кластерам

  • Количество подов

  • Количество подов по узлам

  • Узлы по времени работы (от минимального до максимального)

  • Поды по времени работы (от минимального до максимального)

  • Количество приложений/сервисов

  • Количество приложений/сервисов по кластерам

  • Использование ресурсов по узлам (например, CPU)

  • Запись на диск на узел

  • Чтение диска на узел

  • Сетевые ошибки на узел

Создание плана надежности

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

  1. Оглянитесь назад и проанализируйте неудачи

  2. Определите цели и основные показатели

  3. Создайте стратегию надежности

  4. Испытайте свою стратегию надежности на практике

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

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

Фиктивный план надежности: Интернет-банкинг как услуга

Давайте создадим фиктивный (придуманный) план надежности для банка, предоставляющего услугу интернет-банкинга:

Ценности: Увлеченность клиентами - ставим себя на место наших клиентов, находим и предоставляем им правильные решения и быстро исправляем ошибки.

Видение: Мы стремимся побеждать вместе, проявляя смелость и принимая правильные решения в интересах наших клиентов, людей и общества.

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

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

Тактика:

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

  1. Доступность - для того чтобы клиенты всегда могли получить доступ к интернет-банкингу, сосредоточимся на обеспечении длительности времени безотказной работы в качестве основной услуги и будем быстро исправлять ошибки. Мы будем следить за тем, чтобы клиенты всегда имели доступ к своим деньгам.

  2. Корректность - обеспечение точности операций интернет-банкинга и предоставление их клиентам в режиме реального времени.

Я лично не верю, что можно заниматься надежностью в вакууме, вдали от клиентов или ценностей, видения и миссии компании.

Протестируйте свою стратегию надежности Kubernetes

Теперь, когда мы проанализировали отказы, определили цели и создали план надежности, мы готовы испытать его на практике!

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

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

  1. Масштаб - процессор

  2. Доступность - Blackhole, DNS

  3. Корректность - отключение, задержка и потеря пакетов.

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

Укрепление кластеров K8s: Масштабирование (CPU)

Управление CPU очень важно для распределения рабочих нагрузок, и при неправильном его использовании могут возникнуть проблемы. Есть несколько важных вопросов, которые вы должны задать себе:

  • Сколько процессоров мне понадобится на один инстанс?

  • Буду ли я использовать приоритеты подов Kubernetes для управления ресурсами?

  • Насколько сложно мне будет обновить мои инстансы и увеличить количество CPU?

Пример по укреплению #1: Kubernetes - High CPU

Для этого задания мы будем использовать сценарий Gremlin "Kubernetes - Масштаб - High CPU". Это сценарий масштабирования Kubernetes. Он вызовет увеличение нагрузки на CPU. Мы ожидаем, что это не ухудшит функциональность для пользователя, и все операции будут выполняться так, как ожидается.

https://app.gremlin.com/scenarios/recommended/kubernetes-scale-high-cpu/hosts
https://app.gremlin.com/scenarios/recommended/kubernetes-scale-high-cpu/hosts

Пример по укреплению #2: Kubernetes - троттлинг CPU

Для этого примера укрепления мы будем использовать сценарий Gremlin "Kubernetes - Масштаб - Троттлинг CPU". Это сценарий масштабирования для Kubernetes. Он будет способствовать ускорению CPU в виде серии атак. С его помощью можно убедиться в отсутствии проблем, связанных с троттлингом CPU. В июле 2019 года Хеннинг Якобс (Zalando) выступил на ContainerDays в Гамбурге с докладом "Истории неудач Kubernetes, или: Как обрушить ваш кластер - Хеннинг Якобс". В этом докладе Хеннинг объяснил, что троттлинг CPU влияет на надежность кластера.

https://app.gremlin.com/scenarios/recommended/kubernetes-scale-throttle-cpu/hosts
https://app.gremlin.com/scenarios/recommended/kubernetes-scale-throttle-cpu/hosts

Пример по укреплению #3: Kubernetes - автомасштабирование через CPU

Для этого примера по укреплению мы будем использовать сценарий Gremlin "Kubernetes - Масштаб - Автомасштабирование через CPU". Это сценарий масштабирования для Kubernetes. Он запустит автомасштабирование AWS, основанное на ускорении работы CPU. Мы ожидаем, что это не приведет к ухудшению функциональности для пользователя, и все операции будут выполняться так, как ожидается.

AWS Autoscaling Docs

https://app.gremlin.com/scenarios/recommended/kubernetes-scaling-autoscaling-via-cpu/
https://app.gremlin.com/scenarios/recommended/kubernetes-scaling-autoscaling-via-cpu/

Укрепление кластеров K8s: Доступность (Blackhole и DNS)

"Черная дыра" (Blackhole) - способ, который можно использовать для более безопасного обеспечения недоступности узлов и подсистем. Это не такое разрушительное действие, как отключение. Есть несколько важных вопросов, которые вы должны задать себе:

  • Может ли мой кластер Kubernetes корректно справиться с недоступностью узла?

  • Может ли мой кластер Kubernetes корректно справиться с недоступностью пода?

  • Как мой кластер Kubernetes справится с отключением DNS?

Пример по укреплению #4: Kubernetes - Blackhole на узле Kubernetes

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

https://app.gremlin.com/scenarios/recommended/kubernetes-availability-blackhole-kubernetes-node/hosts
https://app.gremlin.com/scenarios/recommended/kubernetes-availability-blackhole-kubernetes-node/hosts

Пример по укреплению #5: Kubernetes - Blackhole в области

Для этого примера по укреплению мы будем использовать сценарий Gremlin "Kubernetes - Доступность - Blackhole в области". Этот сценарий сделает одну область недоступной. Мы предполагаем, что приложение сможет правильно маршрутизировать пользовательский трафик. Приложение будет функционировать так, как ожидается.

https://app.gremlin.com/scenarios/recommended/kubernetes-availability-blackhole-a-region
https://app.gremlin.com/scenarios/recommended/kubernetes-availability-blackhole-a-region

Пример по укреплению #6: Kubernetes - отключение DNS

Для этого примера по укреплению мы будем использовать сценарий Gremlin "Kubernetes - Доступность - отключение DNS". Это сценарий доступности для Kubernetes. Согласно такому сценарию произойдет отключение DNS. Мы ожидаем, что приложение все еще сможет обслуживать пользовательский трафик и работать как положено благодаря отказоустойчивости DNS. Если восстановление работоспособности DNS настроено неправильно, мы ожидаем, что произойдет перебой.

https://app.gremlin.com/scenarios/recommended/kubernetes-availability-dns-outage/hosts
https://app.gremlin.com/scenarios/recommended/kubernetes-availability-dns-outage/hosts

Укрепление кластеров K8s: Корректность (отключение, задержка и потеря пакетов)

Целостность и корректность данных всегда является одной из основных проблем клиентов. Проблемы с данными - самый быстрый способ потерять доверие и клиентов. Есть несколько важных вопросов, которые вы должны задать себе:

  • Если узел будет выключен, сохранится ли целостность и корректность данных?

  • Как мой кластер Kubernetes справляется с задержками?

  • Как мой кластер Kubernetes справляется с потерей пакетов?

Пример по укреплению #7: Kubernetes - выключение узла

Для этого примера  по укреплению мы будем использовать сценарий Gremlin "Kubernetes - Корректность - Выключение узла". Это сценарий корректности для Kubernetes. В этом сценарии узел будет выключен. Мы ожидаем, что приложение не потеряет данные. Приложение должно работать так, как ожидается.

https://app.gremlin.com/scenarios/recommended/kubernetes-correctness-shutdown-a-node/hosts
https://app.gremlin.com/scenarios/recommended/kubernetes-correctness-shutdown-a-node/hosts

Пример по укреплению #8: Kubernetes - отключение службы

Для этого примера по укреплению мы будем использовать сценарий Gremlin "Kubernetes - Корректность - Выключение службы". Это сценарий корректности для Kubernetes. В этом сценарии будет отключен один сервис. Мы ожидаем, что приложение сможет правильно маршрутизировать пользовательский трафик и что отключение одной службы не окажет влияния на работу других служб. Приложение должно работать так, как ожидается.

https://app.gremlin.com/scenarios/recommended/kubernetes-correctness-shutdown-a-service/containers
https://app.gremlin.com/scenarios/recommended/kubernetes-correctness-shutdown-a-service/containers

Пример по укреплению #9: Kubernetes - внесение задержки на узле

Для этого примера по укреплению мы будем использовать сценарий Gremlin "Kubernetes - Корректность - Внесение задержки на узле". Это сценарий корректности для Kubernetes. Данный сценарий приведет к задержке на одном узле. Мы ожидаем, что приложение будет продолжать обслуживать трафик, но, возможно, с меньшей скоростью. Приложение должно работать как ожидается и не выдавать ошибок.

https://app.gremlin.com/scenarios/recommended/kubernetes-correctness-inject-latency-to-a-node/hosts
https://app.gremlin.com/scenarios/recommended/kubernetes-correctness-inject-latency-to-a-node/hosts

Пример по укреплению #10: Kubernetes - внесение задержки в службу

В этом примере мы будем использовать сценарий Gremlin "Kubernetes - Корректность - Внесение задержки в службу". Это сценарий корректности для Kubernetes. В этом сценарии будет внесена задержка в один сервис. Мы ожидаем, что приложение будет продолжать обслуживать трафик, но, возможно, с меньшей скоростью. Приложение должно работать как ожидается и не выдавать ошибок.

https://app.gremlin.com/scenarios/recommended/kubernetes-correctness-inject-latency-to-a-service/containers
https://app.gremlin.com/scenarios/recommended/kubernetes-correctness-inject-latency-to-a-service/containers

Пример по укреплению #11: Kubernetes - внесение потери пакетов на узле

Для этого примера по укреплению мы будем использовать сценарий Gremlin "Kubernetes - Корректность - Внесение потери пакетов на узле". Это сценарий корректности для Kubernetes. В этом сценарии будет внесена потеря пакетов на одном узле. Мы ожидаем, что приложение будет продолжать обслуживать трафик, но, возможно, с меньшей скоростью. Приложение должно работать как ожидается и не выдавать ошибок.

https://app.gremlin.com/scenarios/recommended/kubernetes-correctness-inject-packet-loss-to-a-service/containers
https://app.gremlin.com/scenarios/recommended/kubernetes-correctness-inject-packet-loss-to-a-service/containers

Пример по укреплению #12: Kubernetes - внесение потери пакетов в службу

В этом примере мы будем использовать сценарий Gremlin "Kubernetes - Корректность - Внести потерю пакетов в службу". Это сценарий корректности для Kubernetes. В этом сценарии будет внесена потеря пакетов для одного сервиса. Мы ожидаем, что приложение будет продолжать обслуживать трафик, но, возможно, с меньшей скоростью. Приложение должно работать как ожидается и не выдавать ошибок.

https://app.gremlin.com/scenarios/recommended/kubernetes-correctness-inject-packet-loss-to-a-service/containers
https://app.gremlin.com/scenarios/recommended/kubernetes-correctness-inject-packet-loss-to-a-service/containers

Заключение

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


Материал подготовлен в рамках курса «SRE практики и инструменты». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.

Теги:
Хабы:
+9
Комментарии 0
Комментарии Комментировать

Публикации

Информация

Сайт
otus.ru
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия
Представитель
OTUS