Deploy WordPress on Kubernetes Cluster with secure TLS/SSL Connection

The provided image illustrates the architecture and resources used in GCP for deploying WordPress on Kubernetes. It includes a Kubernetes cluster with pods for running WordPress and its associated database. An Ingress controller manages external access, while a load balancer ensures efficient traffic distribution. This setup in GCP enables a scalable deployment of WordPress on Kubernetes.

First, I created a project in the Google Cloud Platform (GCP). Then, I set up a Virtual Private Cloud (VPC) and created a subnet within it. This subnet was specifically configured with two secondary IP ranges, which were essential for the Kubernetes cluster deployment. 

For this demo, I created Cloud NAT and Cloud Router into the setup. Cloud NAT enables the Kubernetes cluster to download application dependencies from the internet. By configuring Cloud NAT, the cluster’s pods can securely access external resources and retrieve the required dependencies during the deployment process. This ensures that the WordPress application and its associated components can be successfully installed and run within the Kubernetes cluster. I also created a VM to test Cloud NAT functionality.

Furthermore, I set up a Private Cloud SQL instance with no external IP address. This Private Cloud SQL instance was specifically created to cater to the WordPress deployment. I configured the necessary user credentials and established the required database for WordPress to operate smoothly. By utilizing a Private Cloud SQL instance, I ensured enhanced security and restricted external access to the database, maintaining a more controlled and protected environment for the WordPress application and its associated data.

To enhance the security of authentication to the Private Cloud SQL instance, I created a Kubernetes secret using the ‘kubectl’ command. This secret securely stored the necessary credentials required to establish a connection with the Cloud SQL database. By utilizing a Kubernetes secret, sensitive information such as usernames and passwords were protected and not exposed in plain text within the Kubernetes configuration files or environment variables.

For the deployment of WordPress, I created a Kubernetes cluster in autopilot mode. This mode abstracts the underlying infrastructure management, allowing for simplified cluster operations. Within the cluster, I deployed a WordPress application using a deployment resource. Additionally, I created a Kubernetes service to provide stable network access to the WordPress pods. To enable secure HTTPS communication, I leveraged Google Managed Certificates to obtain SSL certificates automatically. Furthermore, I set up an ingress resource to manage external access to the WordPress service. To ensure data persistence, I created a persistent volume that each WordPress pod would be connected to. This configuration allowed the WordPress application to store and access data consistently across multiple pods, ensuring resilience and data integrity within the Kubernetes cluster.

To streamline the deployment process, I utilized YAML files to create the necessary Kubernetes resources. The YAML files included specifications for each resource, such as deployment, service, Google Managed Certificate, ingress, and persistent volume. By defining the desired configuration and properties in the YAML files, I could easily apply them to the Kubernetes cluster using the ‘kubectl apply’ command.

Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: wordpress
  name: wordpress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wordpress
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: wordpress
    spec:
      containers:
      – image: wordpress
        name: wordpress        
        resources: {}
        env:
          – name: WORDPRESS_DB_USER  
            valueFrom:
              secretKeyRef:
                name: wordpress-secret
                key: username
          – name: WORDPRESS_DB_PASSWORD
            valueFrom:
              secretKeyRef:
                name: wordpress-secret
                key: password
          – name: WORDPRESS_DB_HOST
            valueFrom:
              secretKeyRef:
                name: wordpress-secret
                key: address                      
        volumeMounts:      
        – mountPath: “/var/www/html”
          name: wpvolume
      volumes:            
        – name: wpvolume
          persistentVolumeClaim:
            claimName: wordpressclaim

Service

apiVersion: v1
kind: Service
metadata:
  name: wordpress-service
spec:
  selector:
    app: wordpress
  ports:
    – protocol: TCP
      port: 80
      targetPort: 80
  type: NodePort

Google Managed Certificate

apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: wp-certificate
spec:
  domains:
    – wordpress-dev.ml

Persistent Volume Claim

apiVersion: v1            
kind: PersistentVolumeClaim
metadata:
  name: wpvolume
spec:
  accessModes:
    – ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 10Gi

Ingress Controller

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: “wp-ip”
    networking.gke.io/managed-certificates: wp-certificate
    kubernetes.io/ingress.class: “gce”
spec:
  defaultBackend:
    service:
      name: wordpress  
      port:
        number: 80

To enable access to the WordPress deployment via a custom domain, I added an A record to the DNS configuration of my domain “wordpress-dev.ml”. This A record was configured to point to the external IP address of the Kubernetes ingress. By mapping the domain to the ingress external IP, incoming requests to my domain were properly routed to the WordPress application within the cluster. This setup allowed me to obtain an SSL certificate for my domain through the Google Managed Certificate service. With the DNS configuration in place, the SSL certificate was successfully issued, enabling secure HTTPS communication to the WordPress Application.