практическая серия k8s

https://blog.csdn.net/hguisu/category_9999400.html

Уже представлены услуги без гражданства, связанные с практика k8s(12)--k8s Подробное объяснение сервисного обслуживания

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

1. Классификация сервисов кластера k8s

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

1. Служба без гражданства:

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

2) Случайное расширение и сжатие: эти узлы можно расширять или уменьшать по желанию, просто увеличивая или уменьшая количество реплик. K8S использует RC (или более новый набор реплик) для обеспечения количества экземпляров службы. Если по какой-либо причине экземпляр Pod выходит из строя, RC немедленно запустит новый Pod, используя шаблон Pod, чтобы заменить его, вновь запущенный Pod. точно такой же, как Pod в исходном работоспособном состоянии. После перестройки Pod его IP-адрес может измениться. Чтобы обеспечить стабильный интерфейс доступа к внешнему миру, K8S вводит концепцию Сервиса. За сервисом можно повесить несколько модулей для достижения высокой доступности сервиса.

3) Несколько экземпляров могут использовать одни и те же постоянные данные: например, данные хранятся в MySQL.

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

2. Обычная служба с отслеживанием состояния:

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

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

Например, данные сеанса службы приложения php/java по умолчанию хранятся на диске, например в каталоге /tmp. Однако во время балансировки нагрузки с несколькими копиями каталоги нескольких контейнеров php/java изолируются друг от друга. . Например, есть две реплики A и B. Когда пользователь делает первый запрос, трафик перенаправляется на A и генерируется СЕАНС. Однако, когда пользователь запрашивает второй раз, трафик может быть перенаправлен на B с помощью. балансировщик нагрузки, а B не имеет данных SESSION, поэтому это вызовет ОШИБКИ, такие как тайм-аут сеанса.

Если вы используете том хоста и несколько контейнеров монтируют один и тот же каталог хоста, вы можете совместно использовать данные SESSION. Однако если вы используете сценарий балансировки нагрузки с несколькими хостами, вам необходимо хранить SESSION во внешней базе данных или Redis.

Kubernetes предоставляет систему хранения данных на основе Volume и Persistent Volume, которая может сохранять состояние сервисов.

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

1) Том хранилища (Volume) должен быть определен в Dockerfile создаваемого образа службы (образа), поскольку резервное копирование можно выполнить только в том каталоге, где находится том хранилища.

2) При создании сервиса необходимо указать объем дискового пространства, выделяемого под том хранилища.

3) Если при создании сервиса вам необходимо восстановить данные из предыдущей резервной копии, необходимо также указать, какую резервную копию использовать для восстановления тома хранилища.

Основные различия между службами без отслеживания состояния и службами с отслеживанием состояния заключаются в следующем:

Количество экземпляров: служба без отслеживания состояния может иметь один или несколько экземпляров, поэтому она поддерживает два режима регулировки мощности службы; служба с отслеживанием состояния может иметь только один экземпляр и не позволяет создавать несколько экземпляров, поэтому она не поддерживает настройку мощности службы; режим.

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

Хранение данных: все данные (кроме журналов и данных мониторинга) во время работы службы без отслеживания состояния сохраняются в файловой системе экземпляра контейнера. Если экземпляр остановлен или удален, данные будут потеряны и не могут быть получены для сохранения данных; Services Services, все содержимое файлов в каталоге, в котором смонтирован том хранилища, можно создать в любое время. Резервные копии данных можно загрузить, а также использовать для восстановления новых служб. Однако данные в каталогах без подключенных томов невозможно выполнить резервное копирование и сохранение. Если экземпляр остановлен или удален, содержимое файлов в этих несмонтированных томах также будет потеряно.

3. Служба кластеров с отслеживанием состояния

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

Одним из них является сохранение государства,

Другой — управление кластером.

К таким сервисам относятся Kafka, Zookeeper и т. д.

2. Приложение-служба кластера с отслеживанием состояния StatefulSet.

1 фон StatefulSet

RC, Deployment и DaemonSet — это службы без сохранения состояния. IP-адрес, имя, последовательность запуска и остановки подов, которыми они управляют, являются случайными.

Развертывание кластерных служб с отслеживанием состояния означает, что узлам необходимо сформировать групповые отношения. Каждому узлу необходим уникальный идентификатор (например, Kafka BrokerId, Zookeeper myid, MySQL, хранилище данных MongoDB) в качестве идентификатора каждого члена кластера. идентификаторы необходимы для внутренней связи между внутренними узлами.

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

С этой целью K8S разработал набор новых функций с StatefulSet (до версии 1.5 называемый PetSet) в качестве ядра, который облегчает развертывание и управление кластерными службами с отслеживанием состояния на K8S. Цель StatefulSets в Kubernets — отделить эту зависимость, назначив идентификатор конкретному экземпляру приложения, который не зависит от базовой физической инфраструктуры. (Потребитель не использует статический IP-адрес, а использует доменное имя DNS для поиска конкретной машины)

StatefulSet, по сути, является вариантом Deployment. В версии 1.9 он стал общедоступной версией. Чтобы решить проблему служб с отслеживанием состояния, поды, которыми он управляет, имеют фиксированные имена и последовательности запуска и остановки. В StatefulSet имя пода равно. называется идентификатором сети (имя хоста), и также необходимо использовать общее хранилище.

StatefulSet, как следует из названия, представляет собой коллекцию с отслеживанием состояния, которая управляет всеми службами с отслеживанием состояния, такими как MySQL, кластеры MongoDB и т. д. Начиная с kubernetes 1.5, функция PetSet была обновлена ​​до бета-версии и переименована в StatefulSet. За исключением изменения имени в соответствии с мнением сообщества, этот объект API не сильно изменился. Модуль развертывания кластера Kubernetes добавляет семантику «не более одного на индекс», с последовательным развертыванием, последовательным завершением, уникальным сетевым именем, а также надежностью и стабильностью. хранилище. .

В Deployment соответствующая служба — это служба, а в StatefulSet соответствующая служба — это безголовая служба.

headless Сервис — это автономный сервис. Отличие от сервиса в том, что у него нет кластера. IP, который Headless вернет при парсинге его имени Список конечных точек всех модулей, соответствующих Сервису. Кроме того, StatefulSet в Headless На основе Сервиса создается доменное имя DNS для каждой копии Pod, контролируемой StatefulSet. Формат этого доменного имени: (podname).(headless server name) FQDN： (podname).(headless server name).namespace.svc.cluster.local  

2. Функции StatefulSet

Почему StatefulSet подходит для программ с состоянием, так это то, что он имеет следующие характеристики по сравнению с Deployment:

Согласованность модулей: включая последовательность (последовательность запуска и остановки) и согласованность сети. Эта согласованность связана с модулем и не имеет никакого отношения к тому, на каком узле он запланирован;

Стабильный порядок (гарантированный порядок при запуске или завершении работы): для StatefulSet с N репликами каждому поду присваивается числовой порядковый номер в диапазоне [0, N), и он является уникальным элегантным развертыванием и масштабируемостью: при работе n; -th pod, первые n-1 pod уже запущены и готовы. Упорядоченные, элегантные операции удаления и завершения: удалить из n, n-1,... 1, 0 в этом порядке.

существуют. При развертывании или расширении действуйте последовательно в определенном порядке (т. е. от 0 до N-1).,существования Все предыдущие поды должны находиться в состоянии «Работа» и «Готовность» перед запуском следующего пода),на основе инициализации контейнеры для достижения

Стабильная и уникальная сетевая идентификация: шаблон имени хоста Pod: (имя набора состояний) – (имя набора состояний) – (имя набора состояний) – (поэтому его можно использовать для обнаружения других участников в кластере); имя StatefulSet — kafka, тогда первый встающий Pet называется kafka-0, второй — kafk-1 и так далее, и реализован на основе Headless Service (то есть Сервиса без кластерного IP).

Стабильное постоянное хранилище: реализовано через PV/PVC Kubernetes или внешнее хранилище (предварительно предоставлено), то есть создание PV/PVC для каждого модуля с помощью VolumeClaimTemplate. Удаление и уменьшение копий не приведет к удалению связанных томов.

Упомянутая выше «стабильность» означает, что под остается стабильным при многократном перепланировании, то есть хранилище, DNS-имя и имя хоста привязаны к поду, и не имеет значения, на каком узле запланирован под.

Таким образом, StatefulSet можно использовать, когда таким приложениям, как Zookeeper, Etcd или Elasticsearch, требуются стабильные члены кластера. Запросив запись A имени домена автономной службы, вы можете получить информацию о доменных именах участников кластера.

3. StatefulSet также имеет некоторые ограничения:

1) До версии Kubernetes 1.9 это была бета-версия, и она не была доступна до версии Kubernetes 1.5.

2) Хранилище Pod должно быть предоставлено в зависимости от класса хранилища через PersistentVolume Provisioner или внешнее хранилище, заранее предоставленное администратором.

3) Удаление или сжатие не приведет к удалению томов, связанных с StatefulSet. Это необходимо для обеспечения безопасности данных.

4) StatefulSet теперь требует, чтобы безголовая служба (Headless Service) отвечала за генерацию уникального сетевого идентификатора модулей. Эту безголовую службу необходимо создавать вручную.

4. Когда использовать StatefulSet

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

Могут ли приложения использовать удаленное хранилище?

В настоящее время мы рекомендуем использовать удаленное хранилище для использования StatefulSets, но вы должны быть готовы к потере производительности хранилища, вызванной сетью: даже специально оптимизированные экземпляры не могут сравниться с локально загружаемыми твердотельными накопителями. Может ли сетевое хранилище в вашем облаке соответствовать требованиям SLA? Если ответ положительный, то запуск этих приложений с использованием StatefulSet может воспользоваться преимуществами автоматизации. В случае сбоя узла, на котором находится приложение, под, содержащий приложение, будет назначен другим узлам, после чего его сетевое хранилище и данные в нем будут перезагружены.

Есть ли у этих приложений потребность в масштабировании?

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

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

Почему важен ожидаемый рост производительности?

Kubernetes пока не поддерживает изоляцию сети или хранилища между модулями. Если ваше приложение использует один и тот же узел с шумным соседом, это приведет к падению вашего QPS. Решение состоит в том, чтобы запланировать под как единственного арендатора узла (эксклюзивный сервер) или использовать правила взаимного исключения для изоляции подов, которые будут конкурировать за сеть и диск, но это означает, что пользователи должны выявлять и устранять (конкурентные) горячие точки. .

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

Требуется ли вашему приложению определенное оборудование или типы экземпляров?

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

3. Принцип работы StatefulSet

1. Компоненты StatefulSet

Headless Service：использоватьопределитьPodИдентификатор сети( DNS domain)；

volumeClaimTemplates ：хранилище Шаблон заявки на объем,Создать ПВХ,Укажите название ПВХ, сообщите размер,ПВХ будет создан автоматически,А ПВХ должен поставляться по типу хранилища;

StatefulSet ：Определите конкретныеиспользовать,Такие как Нгинкс,Есть три реплики Pod.,И для каждого модуля определяется доменное имя для развертывания набора состояний.

2. Особый принцип работы

1. Работа по инициализации кластера выполняется через Init Container.
2. Используйте Headless Service для поддержания стабильных отношений между участниками кластера.
3. Динамическое выделение ресурсов хранилища для облегчения расширения кластера
4. Наконец, StatefulSet используется для комплексного управления всем кластером.

Для запуска кластерных служб с отслеживанием состояния необходимо решить две проблемы: проблемы сохранения состояния и проблемы управления кластером:

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

3. Init Container инициализирует службу кластера.

Что такое инициализирующий контейнер?

Судя по названию, это контейнер, выполняющий работу по инициализации. Их может быть один или несколько. Если существует несколько контейнеров инициализации, эти контейнеры инициализации будут выполняться последовательно в определенном порядке. Только после того, как будут выполнены все контейнеры инициализации, будет запущен основной контейнер. Поскольку объем хранилища в модуле является общим, данные, сгенерированные в контейнере инициализации, могут использоваться основным контейнером.

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

Где мы используем Init-контейнер?

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

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

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

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

Это пример использования Init Container.

В этом примере создается модуль, в котором работает контейнер nginx. В модуле Pod есть том хранения под названием workdir. При доступе к службе контейнера nginx в этом томе хранилища будет отображаться файл index.html.

Как был получен этот файл index.html? Он загружается из Интернета с помощью Init-контейнера. Этот контейнер инициализации использует образ busybox. После подъема выполните команду wget, чтобы получить файл index.html, а затем выйдите.

Поскольку контейнер Init и контейнер nginx используют общий том хранения (имя тома хранения здесь — workdir), файл index.html, загруженный в контейнер Init, доступен в контейнере nginx.

Вы можете видеть, что Init Container определен в аннотации. Аннотация — это площадка для тестирования новых функций K8S. Обычно, когда появляется новая функция, она сначала указывается в аннотации. Когда она становится зрелой и стабильной, ей присваивается формальное имя атрибута или имя объекта ресурса.

4. Используйте Headless Service для поддержания стабильных отношений между участниками кластера.

1). Определение безголовой службы:

Иногда балансировка нагрузки и отдельный IP-адрес службы не нужны или нежелательны. В этом случае вы можете создать автономную службу, указав для IP-адреса кластера (spec.clusterIP) значение «Нет».

2) Сравнение безголовой службы с обычной службой:

K8s не будет выделять IP-адреса кластера для Headless Service, kube-proxy не будет их обрабатывать, а платформа не будет выполнять для них балансировку нагрузки и маршрутизацию. k8s предоставит каждому члену кластера уникальное доменное имя DNS, поскольку сетевая идентификация каждого члена используется для связи между участниками внутри кластера.

IP-адрес кластера обычной службы является внешним и используется для внешнего доступа к нескольким экземплярам Pod. Роль Headless Service является внутренней и используется для предоставления уникального DNS-имени каждому члену кластера, чтобы участники кластера могли взаимодействовать друг с другом. Таким образом, безголовая служба не имеет кластерного IP, в чем ее отличие от обычной службы.

3), формат доменного имени безголовой службы управления службами.

        Доменное имя, которым управляет автономная служба, имеет следующий формат:：(service_name). (k8s_namespace).svc.cluster.local. «cluster.local» — это доменное имя кластера, если оно не настроено, по умолчанию используется имя домена кластера.

4) StatefulSet основан на Headless Service, чтобы обеспечить уникальность серийного номера каждого созданного модуля.

Чтобы решить проблему нестабильных имен, имя каждого пода, созданного в StatefulSet, больше не использует случайную строку. Вместо этого каждому поду присваивается уникальный и постоянный серийный номер. Например, если имя StatefulSet — mysql. первый, который запускается. Первый модуль называется mysql-0, второй — mysql-1 и так далее.

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

Каждый модуль, созданный в StatefulSet, получает соответствующее имя субдомена DNS в следующем формате:

(podname). (governing_service_domain), здесь goving_service_domain определяется именем службы, определенным в StatefulSet.

Например, доменное имя kafka, управляемое автономным сервисом: kafka.test.svc.cluster.local,

Имя поддомена, полученное созданным модулем, — kafka-1.kafka.test.svc.cluster.local. Обратите внимание, что упомянутые здесь доменные имена — это все доменные имена, используемые в кластере, управляемом компонентом kuber-dns. Их можно запросить с помощью команды:

    $ nslookup my-nginx

    Server:    192.168.16.53

    Address 1: 192.168.16.53

    Name:      my-nginx

    Address 1: 192.168.16.132

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

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

5. Хранение кластерного сервиса StatefulSet: система хранения K8S.

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

См. конкретно：система хранения k8s(5)-kubernetes

1. Обычный том

Самый простой обычный том — это том с одним узлом. Он похож на том хранилища Docker и использует локальный каталог узла K8S, на котором расположен модуль.

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

Межузловые тома хранения обычно используются в Kubernetes. Если существующее хранилище не соответствует требованиям, вы также можете разработать собственный плагин тома. Вам нужно только реализовать интерфейс, определенный в Volume.go. Если вы являетесь поставщиком хранилища и хотите, чтобы ваше хранилище поддерживало контейнеры, работающие в Kubernetes, вы можете разработать собственный плагин Volume.

2.pv：persistent volume

PersistentVolume (PV) — это часть сетевого хранилища в кластере. Как и Node, он также является ресурсом кластера и не принадлежит определенному пространству имен. PV похож на Volume, но его жизненный цикл не зависит от Pod.

Чем он отличается от обычного тома?

Между обычным томом и модулем Pod существует статическая связь. В файле, определяющем модуль, также определяется используемый им том. Том является аксессуаром Pod. Мы не можем создать том отдельно, поскольку он не является независимым объектом ресурса K8S.

Постоянный том, называемый PV, является объектом ресурса K8S, поэтому мы можем создать PV отдельно. Он не имеет прямой связи с Pod, но реализует динамическую привязку через Persistent Volume Claim, или сокращенно PVC. PVC указывается в определении Pod, и PVC автоматически привязывает соответствующий PV к Pod в соответствии с требованиями Pod.

Существует три режима доступа к фотоэлектрическим модулям:

Первый, ReadWriteOnce: это самый простой метод, его можно читать и записывать, но он поддерживает монтирование только одним модулем.

Второй тип, ReadOnlyMany: может быть установлен несколькими модулями только для чтения.

Третий тип, ReadWriteMany: это хранилище может использоваться несколькими модулями совместно для чтения и записи. Не каждое хранилище поддерживает эти три метода. Например, метод совместного использования в настоящее время поддерживается сравнительно немногими, и наиболее часто используемый метод — NFS. Привязка PV к PVC обычно осуществляется на основе двух условий: одно — это размер хранилища, а другое — режим доступа.

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

Вот жизненный цикл фотоэлектрических модулей:

Первый — это Provision, который предназначен для создания PV. Существует два способа создания PV: статический и динамический. Так называемый статический означает, что администратор вручную создает группу PV для формирования пула PV для привязки PVC. Динамический метод использует объект под названием Storage Class, который автоматически создается системой хранения в соответствии с требованиями PVC.

После создания PV его статус изменится на «Доступен» и ожидается привязка к PVC.

После привязки к PVC статус PV изменится на «Привязано», и его смогут использовать поды с соответствующими определенными PVC.

После того, как модуль завершит его использование, PV будет освобожден, а его статус изменится на Released.

PV, который становится Выпущенным, будет переработан в соответствии с определенной стратегией переработки. Существует три стратегии переработки: сохранить, удалить и переработать. «Сохранить» означает сохранение сцены. K8S ничего не делает и ждет, пока пользователь вручную обработает данные в PV. После завершения обработки PV удаляется вручную. Удалив политику, K8S автоматически удалит PV и данные в нем. В режиме Recycle K8S удалит данные в PV, а затем изменит статус PV на Доступный, чтобы его можно было привязать и использовать новыми PVC.

В реальных сценариях использования создание и использование фотоэлектрических систем обычно не осуществляется одним и тем же человеком. Вот типичный сценарий приложения: администратор создает пул PV, а разработчики создают модули Pod и PVC. PVC определяет размер хранилища и режим доступа, необходимые для модуля, а затем PVC автоматически подбирает наиболее подходящий PV для пула PV. . Использование пода.

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

Каковы преимущества использования StorageClass? Помимо того, что система хранения данных динамически создается, что экономит время администратора, еще одним преимуществом является то, что различные типы хранилищ могут быть инкапсулированы для PVC на выбор. До появления StorageClass PVC мог привязывать PV только на основе двух условий: размер хранилища и режим доступа. После появления StorageClass добавляется измерение привязки.

Например, здесь есть два класса StorageClass. Оба они используют систему хранения данных Google, но один использует обычный диск. Мы называем этот StorageClass медленным. Другой использует SSD, который мы назвали быстрым.

В дополнение к стандартным требованиям к размеру и режиму доступа в PVC, имя класса хранилища также указывается как быстрое посредством аннотации, так что PVC будет привязан к SSD, а не к обычному диску.

На этом этапе представлена ​​вся система хранения Kubernetes. Подводя итог, можно сказать, что существует два типа томов хранения: обычный том и постоянный том. Обычный том определяется непосредственно при определении Pod, а постоянный том динамически привязывается через Persistent Volume Claim. PV можно создавать вручную или динамически с помощью StorageClass.

4. Пример StatefuleSet

Kafka и Zookeeper — два типичных кластерных сервиса с отслеживанием состояния. Во-первых, и Kafka, и Zookeeper нуждаются в дисках хранения для хранения информации о состоянии. Во-вторых, каждому экземпляру Kafka и Zookeeper нужен соответствующий идентификатор экземпляра (Kafka нуженbroker.id, Zookeeper — my.id) в качестве идентификатора каждого члена кластера. эти идентификаторы необходимы для внутренней связи между узлами кластера.

ZooKeeper — хороший пример StatefulSet по двум причинам.

Во-первых, StatefulSet демонстрирует возможность запуска приложений с распределенным, строго согласованным хранилищем;

Во-вторых, ZooKeeper также является необходимым условием для работы Apache Hadoop и Apache Kafka в Kubernetes. В документации Kubernetes есть подробное руководство, в котором объясняется процесс развертывания ZooKeeper Ensemble в кластере Kubernetes, а ключевые функции кратко описаны здесь.

Конкретный процесс развертывания включает в себя следующие развертывания:

(1) Создание хранилища постоянного тома

(2) Создание ресурсов StatefulSet (Petset)

(3) Создание безголового сервиса

。。。。。

Подробное объяснение StatefulSet в k8s_Blog самого красивого времени Ди-CSDN blog_k8s statefulset：

mysql-sc.yaml：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: mysql-nfs-storage
provisioner: storage-fsp
parameters:
  archiveOnDelete: "false"

Разверните набор состояний MySQL:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
  namespace: mysql-sts
spec:
  selector:
    matchLabels:
      app: mysql 
  serviceName: "mysql"  
  replicas: 1 1
  template:
    metadata:
      labels:
        app: mysql 
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: mysql
        image: www.my.com/sys/mysql:5.7
        ports:
        - containerPort: 3306
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: "123456"
        volumeMounts:
        - name: mysql-pvc
          mountPath: /var/lib/mysql

  volumeClaimTemplates:   #Можно рассматривать как шаблон для ПВХ
  - metadata:
      name: mysql-pvc
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "mysql-nfs-storage"  #хранилище имя класса, изменено на уже хранящееся в кластере
      resources:
        requests:
          storage: 1Gi