Набор реплик Kubernetes | Учебник и лучшие практики

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

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

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

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

Анатомия манифеста ReplicaSet

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

Первое, что нужно отметить, это то, что они очень похожи на любой другой ресурс в Kubernetes, а это означает, что вы должны указать apiVersion , kind , metadata и spec . Ниже вы можете увидеть пример того, как выглядит манифест ReplicaSet:

  apiVersion: apps/v1  kind: ReplicaSet  metadata:    name: frontend    labels:      app: guestbook      tier: frontend  spec:    # modify replicas according to your case    replicas: 3    selector:      matchLabels:        tier: frontend    template:      metadata:        labels:          tier: frontend      spec:        containers:        - name: php-redis          image: gcr.io/google_samples/gb-frontend:v3  

Прежде всего, этот ReplicaSet создает сценарий, в котором у вас есть три модуля в вашей среде, и все они запускают демонстрационное приложение внешнего интерфейса. Если вы когда-либо создавали файл манифеста для простого модуля или развертывания, вы узнаете многие поля. Рассмотрим подробнее первую часть:

  apiVersion: apps/v1  kind: ReplicaSet  metadata:    name: frontend    labels:      app: guestbook      tier: frontend  ...  

Два самых первых поля простые и статические, и они всегда будут одинаковыми. Указание apiVersion и kind просто сообщает Kubernetes, с чем он должен работать, и они никогда не должны отличаться. Двигаясь дальше к определению метаданных , вы указываете имя и метки . Это поможет вам лучше контролировать ресурсы, имеющиеся в вашей среде.

Двигаясь дальше в манифесте, вы попадаете в поле спецификации , где первая часть:

  ...  spec:    # modify replicas according to your case    replicas: 3    selector:      matchLabels:        tier: frontend  ...  

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

Следующей частью манифеста является поле селектора . Здесь вы указываете, как ReplicaSet должен распознавать модули, которыми он должен управлять. В этом случае он должен соответствовать всем модулям с меткой tier: frontend .

Наконец, вам нужно определить фактический шаблон модулей:

  ...    template:      metadata:        labels:          tier: frontend      spec:        containers:        - name: php-redis          image: gcr.io/google_samples/gb-frontend:v3  

Это очень похоже на любой другой модуль, который вы бы определили. Во-первых, вы указываете поле метаданных , которому в данном случае присваивается метка tier: frontend . Как вы видели ранее, это то, что мы указали, что ReplicaSet будет искать, какие модули ему нужны. Поэтому убедитесь, что он совпадает с тем, что вы написали ранее в манифесте.

Наконец, вы указываете контейнер(ы) внутри модуля. В этом примере сценария мы используем простой демонстрационный интерфейс, разработанный Google. Если вы хотите попробовать этот пример, вы можете применить его, запустив:

  $ kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml  

Через некоторое время вы сможете увидеть, что ReplicaSet успешно развернут, выполнив:

$ kubectl получить рупий

ИМЯ ЖЕЛАННЫЙ ТЕКУЩИЙ ГОТОВЫ ВОЗРАСТ
внешний интерфейс 3 3 3 4 с

Что такое ReplicaSet?

На данный момент вы точно знаете, как выглядит манифест для ReplicaSet, но вам все еще может быть интересно, что это такое .

На первый взгляд, ReplicaSet — это просто ресурс в Kubernetes, который поддерживает определенное количество модулей, не более того. В предыдущем примере вы, возможно, заметили, что большая часть файла манифеста представляет собой стандартный шаблон Kubernetes. Без шаблона все можно быстро свести к «Создайте такое количество модулей и настройте их таким образом». Это делает ReplicaSets очень простым ресурсом для работы, и они великолепны, когда у вас есть простой вариант использования.

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

Допустим, вы хотите развернуть приведенный выше пример ReplicaSet, но в вашей среде уже есть модуль с меткой tier: frontend . В этом случае ReplicaSet получит право собственности на этот существующий модуль и создаст два новых в соответствии со своей спецификацией . Это оставляет вас с тремя разными модулями, что может привести к путанице.

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

Работа с наборами реплик

Теперь, когда вы лучше понимаете, что такое ReplicaSet, пришло время понять некоторые способы работы с ними. Это не слишком сложно, так как с ReplicaSet можно сделать не так много вещей.

Масштабирование наборов реплик

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

  $ kubectl scale --replicas=2 rs/frontend  

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

Удаление наборов реплик

Процесс удаления ReplicaSet довольно прост. Удаление самого ReplicaSet удалит как ReplicaSet, так и его модули.

  $ kubectl delete rs frontend  

Также можно удалить ReplicaSet и оставить модули потерянными, добавив –cascade=orphan к команде удаления.

Когда использовать ReplicaSet?

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

Kubernetes также имеет ресурс развертывания , который очень похож на ReplicaSet в том смысле, что вы устанавливаете определенное количество реплик, и он будет поддерживать его. Самая большая разница между этими двумя ресурсами заключается в том, что развертывание заботится об обновлении модулей. Это означает, что вам следует выбирать ReplicaSets, если вы не хотите иметь какое-либо автоматическое обновление модулей или хотите реализовать собственную пользовательскую логику обновления.

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

Последней основной альтернативой ReplicaSets являются DaemonSets . DaemonSets — это функция, которая запускает модули на каждом узле и позволяет этим модулям иметь доступ к функциям на уровне машины. Используйте DaemonSet, когда вам нужно, чтобы данный модуль работал на каждом узле в вашем кластере. Этот сценарий можно настроить с помощью ReplicaSet, но наборы DaemonSet созданы для него.

Последние мысли

ReplicaSet — отличный способ быстро запустить определенное количество модулей pod в вашей среде. Это не сложно настроить. Как правило, он работает очень просто, заменяя контейнеры, на которые влияют ошибки.

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

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

Перейти к верхней панели