Skip to main content

Command Palette

Search for a command to run...

Kubernetes Day-6: Deploying a Multi-Tier Application on Kubernetes (WordPress + MySQL)

Published
4 min read
Kubernetes Day-6: Deploying a Multi-Tier Application on Kubernetes (WordPress + MySQL)
N
DevOps and Cloud engineer passionate about building resilient, secure, and scalable systems. I work extensively with AWS, Terraform, Docker, Kubernetes, and CI/CD pipelines, focusing on real-world deployments rather than theory. I write about infrastructure design, debugging production issues, and simplifying complex tools into practical, actionable knowledge. Driven by curiosity and hands-on learning.

In the previous sessions, we learned how Kubernetes Services provide a stable endpoint for Pods, act as load balancers and reverse proxies, and solve the challenge of dynamic Pod IPs using labels and selectors.
We explored ClusterIP for internal communication, NodePort for external access, and briefly introduced LoadBalancer services.

With this foundation in place, we are now ready to move forward.


Agenda: Deploying a Multi-Tier Application

Today’s objective is to deploy a multi-tier application on Kubernetes.

Before deployment, we must understand what a multi-tier application is.


What Is a Multi-Tier Application?

A multi-tier application is an architecture where different layers (tiers) handle different responsibilities, such as:

  • Presentation (front-end)

  • Application logic

  • Data storage (database)

Real-World Example: Facebook

When you access Facebook:

  • The front-end web application (assume PHP) serves pages to users

  • The application runs on a web server like Apache

  • Apache itself runs on an operating system

This forms the application tier.

When users upload posts, images, or videos, the data must be stored permanently.
For this, a database like MySQL is used, which also runs on its own OS—forming the database tier.

In this setup:

  • PHP application runs on IP-1

  • MySQL database runs on IP-2

  • PHP must communicate with MySQL to store and retrieve data

Since multiple independent environments work together, this setup is called a multi-tier application architecture.


Multi-Tier Architecture on Kubernetes

To deploy this architecture on Kubernetes, we need:

  • One Pod for WordPress (PHP + Apache)

  • One Pod for MySQL (Database)

The most important requirement is network connectivity between Pods.

Kubernetes provides pod-to-pod networking by default, which makes this communication straightforward.

In today’s session, we deploy:

  • WordPress as the frontend application

  • MySQL as the backend database


Creating the MySQL Pod

We start by creating the MySQL Pod using an official image:

kubectl run mydb --image=mysql:5.7

Check the Pod status:

kubectl get pods

Initially, the Pod may show:

  • ContainerCreating (image download in progress)

  • CrashLoopBackOff (container repeatedly failing)

This is not a Kubernetes issue.

To investigate:

kubectl describe pod mydb
kubectl logs mydb

Understanding the Issue: Environment Variables

A MySQL container requires configuration:

  • Root password

  • Database name

  • User credentials

Without these, the container will fail.

These values must be provided as environment variables during Pod creation.

Correct MySQL Pod Creation

kubectl run mydb \
--image=mysql:5.7 \
--env=MYSQL_ROOT_PASSWORD=redhat \
--env=MYSQL_DATABASE=wpdb \
--env=MYSQL_USER=vimal \
--env=MYSQL_PASSWORD=redhat

Verify:

kubectl describe pod mydb
kubectl logs mydb

Now the Pod should be healthy.


Accessing the MySQL Database Inside the Pod

Enter the container:

kubectl exec -it mydb -- bash

Access MySQL:

mysql -u vimal -p redhat

Check databases:

show databases;

At this point, the database tier is ready.


Understanding Environment Variables in Kubernetes

Environment variables set inside a running container are temporary.

Kubernetes ensures permanent configuration by injecting environment variables at Pod creation time, so even if a Pod is recreated, the configuration remains consistent.


Creating the WordPress Pod

Now we create the frontend Pod using a compatible WordPress image:

wordpress:5.1.1-php7.3-apache

Version compatibility is critical. Incompatible versions may cause errors that look like Kubernetes issues but are actually image-level problems.

At this stage:

  • One Pod runs WordPress

  • One Pod runs MySQL


Exposing the Application Securely

Security Best Practice

  • Front-end (WordPress): Public access required

  • Database (MySQL): Must remain private

Services Used

  • NodePort Service → WordPress (external access)

  • ClusterIP Service → MySQL (internal access only)

Check Services:

kubectl get svc

Example:

  • Node IP: 192.168.99.100

  • NodePort: 30690

Access WordPress:

http://192.168.99.100:30690

This opens the WordPress setup page.


Completing WordPress Installation

  1. Click Run the installation

  2. Enter database details

  3. Complete setup

  4. Login to WordPress dashboard

  5. Create and publish a blog post

To verify data storage:

  • Enter the MySQL Pod

  • Check the wpdb database

  • View tables containing WordPress data


Day-6 Summary

In today’s session, we learned how to:

  • Deploy a multi-tier application on Kubernetes

  • Use separate Pods for application and database layers

  • Configure environment variables correctly

  • Handle image compatibility issues

  • Use NodePort for public access

  • Use ClusterIP to keep databases private

  • Verify real application data inside the database

By the end of the session, we successfully deployed WordPress on Kubernetes, published a blog post, and confirmed that the data was stored in MySQL - completing a full production-style multi-tier deployment.

Kubernetes: From Basics to Advance

Part 6 of 8

Kubernetes – Basics to Advance by Nitin Dhiman is a beginner-friendly series that covers everything from container basics to advanced Kubernetes concepts, with real-world use cases and CKA/CKAD prep to help you master container orchestration.

Up next

Kubernetes Day 8: Deployments, Scaling & Zero-Downtime Updates

In previous sessions, we deployed applications and managed secrets. But one important limitation we observed was: ⚠️ Container storage is temporary by default If a Pod restarts or gets deleted, the