Skip to main content

diag-website-wordpress

Overview​

  • Namespace: diag-website-wordpress
  • Purpose: Main DIAG organization WordPress website
  • Age: ~2 years
  • Status: Active - All workloads healthy

Architecture​

This namespace runs a high-availability WordPress setup with:

  • Read/Write Split: Separate instances for read and write operations
  • Caching Layer: Varnish HTTP cache for performance
  • Persistent Storage: NFS-based storage via StatefulSet

Workloads​

Deployments​

NameReplicasStatusAgePurpose
wordpress3/3Ready2y127dRead replicas for serving website
wordpress-write1/1Ready133dWrite instance for content updates
varnish1/1Ready235dHTTP cache layer

StatefulSets​

NameReplicasStatusAgePurpose
wordpress-disk1/1Ready2y127dNFS storage service

HorizontalPodAutoscaler (HPA)​

NameTargetMinMaxCurrentAgeStatus
wordpress-hpawordpress deployment1203177dActive

Scaling Metrics:

  • CPU: 56% / 80% target (168m current usage)
  • Memory: 1000Mi target
  • Behavior: Scales wordpress read replicas based on CPU/memory usage
  • Current Status: Healthy - operating within normal range

The HPA automatically scales the wordpress deployment between 1-20 replicas based on resource utilization.

Services​

NameTypeCluster IPPortsPurpose
wordpressClusterIP10.29.141.14080Read traffic endpoint
wordpress-writeClusterIP10.29.31.20180Write traffic endpoint
varnishClusterIP10.29.218.13180Cache layer frontend
wordpress-diskClusterIP10.29.108.1122049, 20048, 111NFS storage

Traffic Flow​

External Traffic (via Ingress)
    ↓
Varnish Cache (10.29.218.131:80)
    ↓
    ├─→ WordPress Read (10.29.141.140:80) [3 replicas] ← Read requests
    │
    └─→ WordPress Write (10.29.31.201:80) [1 replica] ← Write/Admin requests
            ↓
    WordPress Disk NFS (10.29.108.112:2049)

Access & Management​

View all resources:​

kubectl get all -n diag-website-wordpress

Check pod status:​

kubectl get pods -n diag-website-wordpress -o wide

View logs:​

# WordPress read pods
kubectl logs -f deployment/wordpress -n diag-website-wordpress

# WordPress write pod
kubectl logs -f deployment/wordpress-write -n diag-website-wordpress

# Varnish cache
kubectl logs -f deployment/varnish -n diag-website-wordpress

Execute commands in pods:​

# Access WordPress read pod
kubectl exec -it deployment/wordpress -n diag-website-wordpress -- /bin/bash

# Access WordPress write pod
kubectl exec -it deployment/wordpress-write -n diag-website-wordpress -- /bin/bash

HPA Management:​

# View HPA status
kubectl get hpa -n diag-website-wordpress

# Describe HPA details
kubectl describe hpa wordpress-hpa -n diag-website-wordpress

# Edit HPA (adjust min/max replicas or targets)
kubectl edit hpa wordpress-hpa -n diag-website-wordpress

# Disable HPA temporarily (scale manually)
kubectl delete hpa wordpress-hpa -n diag-website-wordpress

Manual Scaling:​

# Manual scaling (only if HPA is disabled)
kubectl scale deployment wordpress -n diag-website-wordpress --replicas=5

# Note: HPA will override manual scaling if active
# Note: Don't scale wordpress-write beyond 1 replica

Restart workloads:​

# Restart all read pods
kubectl rollout restart deployment/wordpress -n diag-website-wordpress

# Restart write pod
kubectl rollout restart deployment/wordpress-write -n diag-website-wordpress

# Restart varnish cache
kubectl rollout restart deployment/varnish -n diag-website-wordpress

Monitoring​

Resource usage:​

kubectl top pods -n diag-website-wordpress

Events:​

kubectl get events -n diag-website-wordpress --sort-by='.lastTimestamp'

Persistent volumes:​

kubectl get pvc -n diag-website-wordpress
kubectl get pv | grep diag-website-wordpress

Performance Considerations​

  • Varnish Cache: Acts as reverse proxy, caching static and dynamic content
  • Read Replicas: 3 replicas distribute read traffic for better performance
  • Write Instance: Single instance for consistency in write operations
  • NFS Storage: Shared storage accessible by all WordPress pods

Recommendations​

  1. Auto-Scaling (HPA):

    • HPA configured: 1-20 replicas based on CPU/memory
    • Current scaling: 3 replicas (healthy)
    • Consider reviewing HPA thresholds:
      • CPU target: 80% (currently at 56%)
      • Memory target: 1000Mi
    • Monitor HPA behavior during traffic spikes

  2. High Availability:

    • WordPress read: Auto-scales 1-20 replicas (currently 3)
    • x Varnish: 1 replica (consider 2+ for HA, add HPA)
    • x WordPress-write: 1 replica (acceptable for writes, but consider backup strategy)

  3. Monitoring: Implement monitoring for:

    • HPA scaling events and patterns
    • Cache hit rate (Varnish)
    • Response times
    • Database connection pool usage
    • Storage capacity
    • Resource usage trends (CPU/Memory)

  4. Backups: Ensure regular backups of:

    • WordPress database
    • Persistent volume data
    • WordPress configuration

  5. Security:

    • Keep WordPress and plugins updated
    • Implement network policies
    • Regular security audits

Troubleshooting​

Cache issues:​

# Clear Varnish cache
kubectl exec -it deployment/varnish -n diag-website-wordpress -- varnishadm "ban req.url ~ ."

Database connection issues:​

# Check WordPress logs
kubectl logs -f deployment/wordpress -n diag-website-wordpress | grep -i "database\|mysql"

Storage issues:​

# Check NFS service
kubectl describe statefulset wordpress-disk -n diag-website-wordpress
kubectl logs -f statefulset/wordpress-disk -n diag-website-wordpress

HPA not scaling:​

# Check HPA status and events
kubectl describe hpa wordpress-hpa -n diag-website-wordpress

# Check metrics server is running
kubectl top nodes
kubectl top pods -n diag-website-wordpress

# View HPA events
kubectl get events -n diag-website-wordpress --sort-by='.lastTimestamp' | grep HorizontalPodAutoscaler

# Check if metrics are available
kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes
kubectl get --raw /apis/metrics.k8s.io/v1beta1/pods

Unexpected scaling behavior:​

# Check current resource usage
kubectl top pods -n diag-website-wordpress

# Review HPA configuration
kubectl get hpa wordpress-hpa -n diag-website-wordpress -o yaml

# Check recent scaling events
kubectl get events -n diag-website-wordpress --field-selector involvedObject.name=wordpress-hpa

# Temporarily disable HPA if needed
kubectl delete hpa wordpress-hpa -n diag-website-wordpress