I'm not sure if this is the correct place to ask the question, but since this is specific to deploying WordPress, I thought I'd ask here first. What is the correct way to implement wp-cron server-side in Kubernetes?
I'm in the process of optimizing a website which is deployed to a Kubernetes cluster, and I'm interested in disabling the built-in web-based cron scheduler for WordPress by adding:
to my wp-config.php.
In a normal scenario, I know that I would simply add a cronjob to my cron daemon to call something similar to:
wget -q http://example.com/wp-cron.php -O /dev/null
However since I'm running WordPress in a container, and there may be multiple instances of the container running at the same time, I wasn't sure what the ideal deployment method for a server-side cron would be. I'm concerned that calling wp-cron from multiple instances at exactly the same time could potentially cause issues (since there may also not be enough time for the MySQL operations which would lock the crons to a single "runner" to propagate.). I've searched but was not able to find any concrete examples of WordPress websites deployed to Kubernetes clusters which disable the wp_cron functionality.
The options that I'm aware of:
Using the Kubernetes built-in cron service to call
wget -q http://example.com/wp-cron.php
Using an additional "service" runs a cron daemon and which either calls:
wget -q http://example.com/wp-cron.php -O /dev/nullor
wp cron event run --due-now
Since I'm using a custom-built container, I know that I can add a build argument to enable/disable the cron and deploy a single "main" instance which runs the cron, with additional child instances which don't run the cron.
Letting wp_cron run normally without any interference / changes.
Any insight into best practices would be very helpful. I'm ideally looking for a solution which will work in a situation where the WordPress service is running multiple instances at the same time (a minimum of 2).