В этой статье показано, как внедрить и эффективно использовать наборы реплик, чтобы обеспечить стабильность, масштабируемость и правильное использование развертываний Kubernetes.
Одной из самых больших проблем при запуске приложения в производственной среде является не обеспечение того, чтобы оно всегда работало, а обеспечение того, чтобы когда что-то пойдет не так, оно было автоматически исправлено. Kubernetes как платформа имеет множество встроенных инструментов, которые могут помочь разработчикам в достижении этой цели, основным из которых является функция обнаружения ошибок .
Kubernetes быстро узнает, когда приложение, работающее в контейнере, допустило ошибку, и может сообщить о ней вам или другим частям системы. Здесь в игру вступают наборы реплик. Когда вы создаете ReplicaSet, вы, по сути, говорите Kubernetes, что хотите, чтобы конкретный модуль реплицировался x раз. Например, если вы хотите, чтобы четыре модуля работали постоянно, и один из них внезапно выходит из строя, ReplicaSet гарантирует, что сбойный модуль будет удален, и запустит новый, надеюсь, исправный.
В этой статье мы расширим эту идею, чтобы лучше понять этот процесс; как ReplicaSet узнает, какие модули ему принадлежат; и как вы можете вообще использовать их в своих развертываниях.
Contents
Анатомия манифеста ReplicaSet
Прежде чем углубляться в варианты использования ReplicaSet и рекомендации по работе с ними, важно сначала понять, как они работают.
Первое, что нужно отметить, это то, что они очень похожи на любой другой ресурс в Kubernetes, а это означает, что вы должны указать apiVersion , kind , metadata и spec . Ниже вы можете увидеть пример того, как выглядит манифест ReplicaSet:
Прежде всего, этот ReplicaSet создает сценарий, в котором у вас есть три модуля в вашей среде, и все они запускают демонстрационное приложение внешнего интерфейса. Если вы когда-либо создавали файл манифеста для простого модуля или развертывания, вы узнаете многие поля. Рассмотрим подробнее первую часть:
Два самых первых поля простые и статические, и они всегда будут одинаковыми. Указание apiVersion и kind просто сообщает Kubernetes, с чем он должен работать, и они никогда не должны отличаться. Двигаясь дальше к определению метаданных , вы указываете имя и метки . Это поможет вам лучше контролировать ресурсы, имеющиеся в вашей среде.
Двигаясь дальше в манифесте, вы попадаете в поле спецификации , где первая часть:
Здесь для поля replicas установлено значение 3 , но вы можете установить любое значение, соответствующее вашему приложению. Официально нет никаких ограничений на то, насколько это может быть установлено, но, конечно, вы должны помнить о базовых ресурсах вашего кластера Kubernetes.
Следующей частью манифеста является поле селектора . Здесь вы указываете, как ReplicaSet должен распознавать модули, которыми он должен управлять. В этом случае он должен соответствовать всем модулям с меткой tier: frontend .
Наконец, вам нужно определить фактический шаблон модулей:
Это очень похоже на любой другой модуль, который вы бы определили. Во-первых, вы указываете поле метаданных , которому в данном случае присваивается метка tier: frontend . Как вы видели ранее, это то, что мы указали, что ReplicaSet будет искать, какие модули ему нужны. Поэтому убедитесь, что он совпадает с тем, что вы написали ранее в манифесте.
Наконец, вы указываете контейнер(ы) внутри модуля. В этом примере сценария мы используем простой демонстрационный интерфейс, разработанный Google. Если вы хотите попробовать этот пример, вы можете применить его, запустив:
Через некоторое время вы сможете увидеть, что ReplicaSet успешно развернут, выполнив:
