Оптимизация WordPress сайта установленного в Kubernetes (несколько реплик/копий)?

Question

[sheldon_coop]

Всем привет!

Есть WordPress сайт который ранее был просто на виртуальном хостинге, а теперь, с декабря, крутится в контейнере Kubernetes, у которого есть несколько копий/реплик.

Для оптимизации всегда использовали какой-либо плагин, по типу: "LiteSpeed Cache", "WP Fastest Cache" и проч., которые позволяют настроить кэширование, минифицировать CSS, JS, объединить их в один файл, создание оптимизированных копий изображений (/wp-content/), и многое другое.

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

Какое есть решение (если нужно продолжить использование нескольких реплик/копий)? Так как я ранее с этим не сталкивался, буду рад любым вариантам/предложениям!

PS
Разрабатывать какое-то полностью кастомное решение для замены всего функционала плагина(ов) - не вариант.

Comments

[Refguser]

Не мала баба клопоту - купила порося.. :) (укр поговорка)

Answer 1

[akelsey]

Готовые решения не знаю, варианты на вскидку:
- общий файловый кэш на все поды
- решение например на базе redis который будет источником кэшированных данных

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

Comments

[sheldon_coop]

искать какой-то плагин для работы в кубере, в официальных плагинах ворпдпресса

Не смог найти, насколько мне известно, нет таких(

[akelsey]

sheldon_coop, тогда второй вариант, кластер редиса там же в кубере и например этот плагин.

[sheldon_coop]

Извиняюсь, но, похоже, я не совсем понимаю идею.
Redis даст объектный кэш (содержимое основной базы данных), или даже настроить кэш страниц, если например использовать в связке с плагином W3TC, это хорошо.

Но как это использовать для решения описанной проблемы, когда WP плагин автоматически создает файлы где хранит весь JS и CSS код в минифицированном и объединенном виде, файлы которые периодически будут обновляться, например по клику кнопки из админки, но этот файл будет сохранен/обновлен только она одной из реплик в кубере?

[akelsey]

sheldon_coop, я далёк от WP и как он работает, по этому это просто общая идея чтоб хранить состояние кэша вне подов, будь то редис, файловый кэш или что либо иное.

Answer 2

[Vitaly Karasik]

Я вижу два варианта
1) простой - вернуться на хостинг на одном сервере линукс. Я не вижу преимуществ в K8S для Wordpress.
2) сложный и ненужный ИМХО - искать документы по правильному деплою в Кубернетисе

Возможно сработает workaround - убрать autoscaling, запускать на одном поде.

Comments

[sheldon_coop]

Решение о переходе на K8S не моё, я лишь столкнулся с указанной проблемой как WP разработчик(

[Vitaly Karasik]

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

Answer 3

[Иван Корюков]

Проще всего будет определить в какую папку всё это складывается и вынести её в PersistentVolume (PV). Ваш k8s конечно же должен иметь возможность создания PV с типом ReadWriteMany - это когда поды на разных машинах могут подключать к себе один и тот же PV. Проще всего выделить в инфраструктуре NFS сервер и настроить кубер работать с ним.

В результате в манифесте деплоймента будет что-то типа

volumes:
  - name: optimized-assets
    persistentVolumeClaim:
      claimName: my-optimized-assets-pvc
containers:
  - name: app
    image: "my.registry.org/wp-site:v1.2.3"
    volumeMounts:
    - name: optimized-assets
      mountPath: /var/www/public/assets

немного теории

Запуская веб-приложение в нескольких экземплярах на разных машинах/контейнерах, необходимо позаботиться о том чтобы некоторые его части шарились (share) между всеми экземплярами.
Обычно речь про
- папку загрузок
- сессии пользователя
- кэш

В идеале для всего этого стоит использовать отдельные сервисы, например сессии и кэш можно хранить в memcached или redis, а загрузки хранить не файлами на диске, а в S3.

Но можно делать проще. Те же загрузки - это файлы на диске, значит папку с этими файлами можно расшарить между экземплярами через nfs.

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