A few weeks ago, I wanted to learn how to host WordPress in Kubernetes. If you do a simple search engine search on how to host WordPress in Kubernetes, you will find a lot of blogs and articles on how to do this. However, none of the pages I came across explain how to horizontally scale a WordPress container in Kubernetes. Given there were no explicit instructions on this, I assumed I can just create a deployment using vanilla WordPress container and just increase the number of replicas. If you have ever successfully horizontally scaled WordPress site or are already moving your head sideways in disapproval, then this blog post may not be of much value for you.
There are two key challenges with horizontally scaling a WordPress site.
First, how do you make sure each WordPress replica exposes same content? A great deal of WordPress content lives in MySQL (or equivalent) database. As long as each replica has credentials to the same database, it is going to expose the same content. However, things like plugins, themes, and uploads (like images, etc.) don’t live in the database. In order for each replica to return identical response, we need to make sure that this content is available to each replica at all times.
Second, one of the most important config files related to WordPress site is wp-config.php. In this file, you typically configure the database credentials (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, DB_CHARSET, DB_COLLATE) that WordPress needs. However, there is another important section in this file that contain config variables for “authentication unique keys and salts”. All of these config variables control security related settings for a WordPress site: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT. If each replica of your WordPress site don’t have the same values, then you will experience issues when you are accessing your WordPress Admin page such as you either keep seeing login page, or random issues when trying to change something.