Before diving into the world of Kubernetes, we have to understand all the key WordPress components and how they interact with each other. This will help us make better decisions when splitting out these components into our Kubernetes cluster. This is especially important to understand when working with some of the more complex and scalable and/or highly available architectures.
PHP
At its core, WordPress is a PHP/MySQL application.
The PHP application includes the WordPress core software, themes and plugins, and sometimes even PHP-based translation files. It also includes plenty of static assets, such as images, icons, fonts, CSS and JavaScript files. Together with a database connection, this allows us to serve highly dynamic posts, pages, cat pictures (we’ll cover media and storage in another section) and API requests.
It is important to note that WordPress is not a microservice and was never designed to be one. A default WordPress install will assume it’s the only one running, so it’s more than happy to write files to disk, update and even delete application files (when updating the core software, or deleting a plugin for example) and other non-ephemeral behavior. We’ll learn how to overcome this in later topics.
MySQL/MariaDB
The database, typically MySQL or MariaDB, is what holds most of the WordPress content and configuration across a dozen or so database tables. This is a completely separate service which the PHP application needs to connect to, so we won’t have trouble making this work in our Kubernetes cluster. However, we will need to adjust some of the core WordPress behavior, to speak to more than one database server if needed for the more complex architectures.
Web Server
WordPress will also need a web server to function to help deliver the PHP-generated content, as well as any static assets and user-uploaded media. We’ll mostly be using Nginx in this guide, speaking to the PHP service over FastCGI (php-fpm), however any Apache-based setup will also work just fine.
Media
Media (user-uploaded files) is another component that’s worth treating separately. While it is part of the standard WordPress application and can certainly work in a non-ephemeral environment, for more complex and scalable architectures, we’ll want to move it to a separate service in our Kubernetes cluster. We might need to make some adjustments in our WordPress install to make this work correctly and efficiently.
Object Cache
Lastly, the WordPress object cache. This is one of the less critical components in a WordPress application. The built in method of operation is to cache WordPress objects for the duration of an HTTP request internally in the PHP application itself. However to improve performance and reduce database load, a persistent object caching backend is often used with larger WordPress installs. These are in-memory key-value stores, such as Redis or Memcached and a special WordPress plugin is required to communicate with these.
Recap
In this section we took a closer look at a typical WordPress application, what it consists of and what it needs to run. Understanding these concepts will help you understand the ways you can lay them out in a Kubernetes cluster when designing for scale, availability and failover. We’ll cover each component in more detail in future sections.
Continue to the next section to learn more about what Kubernetes is.