increase Max Upload Size & Memory Limit for WordPress Sites in the Nginx Ingress Controller Kubernetes - HostExpert

Previously I had installed wordpress pods on Kubernetes and it made it very easy to administer and add multiple sites fowr clients. However, as time went on they started getting more aggressive in the different themes they were uploading. To solve the problem required configuration changes in two places.

• The Ingress Controller
• The PHP file on the WordPress pod itself.

Ingress Controller

The first clue that the ingress controller was having issues was that the wordpress pods I’m running are using Apache. So I knew it was something in the Nginx Ingress controller because the error stated:

413 Request Entity Too Large

Fixing this was a matter of changing the nginx configmap for the ingress controller. To do this it’s a simple matter of typing the following:

kubectl edit cm -n ingress-nginx nginx-configuration

Once in here, I noticed that there was no customization so I had to create a data section. I used the following values, which probably increased it a little too much and so I brought them lower. Here is the example:

apiVersion: v1
data:
  client-body-buffer-size: 32M
  proxy-body-size: 1G
  proxy-buffering: "off"
  proxy-read-timeout: "600"
  proxy-send-timeout: "600"
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  name: nginx-configuration
  namespace: ingress-nginx

Increasing the read and write timeouts allows larger files more time to upload. Increasing the body size is what really allows large files. You probably want something less than 1Gb. The client-body-buffer-size allows us to use more memory instead of writing temp files while the file is uploaded.

With this in place the client was able to try uploading again, but now was confronted with a problem on the actual wordpress pod.

Updating PHP params on wordpress

By examining the logs in wordpress we saw:

PHP Warning:  POST Content-Length of 14982910 bytes exceeds the limit of 8388608 bytes

Here we are running into a PHP limit. Through trial and error I saw I needed to increase two different parameters:

• upload_max_filesize – the max size the upload could be
• post_max_size – the max size the body could be.

If we weren’t using Kubernetes, it would be simple to go into each server, change the param in the php.ini file and then restart, but that’s not how we work in the container world. We need it to be reproducible. Similarly for using ConfigMaps in the Nginx Ingress controller, we can use ConfigMaps in our WordPress application as well.

Create custom-ini ConfigMap

We are using the container for our wordpress instances called wordpress:5.2-apache. We can see where the config files are by logging into the server:

kubectl exec -it -n wordpress wordpress-6bc44c5c69-zjr6z -- /bin/bash

After we can run the env | grep PHP we see that PHP_INI_DIR is set to /usr/local/etc/php. So all we need to do is create a custom.ini file and put it into the ./conf.d directory in that path and our changes will be activated. Our configMap code is below:

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-ini
  namespace: wordpress
data:
  custom.ini: |
    upload_max_filesize = 60M
    post_max_size = 60M
    file_uploads = On
    memory_limit = 1024M
    max_execution_time = 300
    max_input_time = 1000

We are using the wordpress namespace and calling this configMap custom-ini.

Updating the Deployment

In our deployment file we will add this configMap as a mount option. We are using secrets files for keeping the passwords to connect to the MySQL pod as well, so there are more than one configMaps in here, but that is a post for another time. The important parts are the following:

       volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
        - name: config-volume
          mountPath: /usr/local/etc/php/conf.d/custom.ini
          subPath: custom.ini

We mount the wordpress blog in persistent storage so changes persist on reboots. Under this we add a new volumeMount and call it our config-volume. This will show the path where this file is to be mounted. The subPath option allows us to use this configMap to have other configurations elsewhere in the pod.

The config-volume still needs to reference the ConfigMap it is referring to, so we need the following:

volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wp-pv-claim
      - name: config-volume
        configMap:
          name: custom-ini

The persistentVolumeClaim was already there, but underneath we add the configMap to reference the settings.

Now with a simple apply we can update the container. The container will reset but all changes will still remain because we use persistent volumes.

kubectl apply -f custom-ini.yaml
kubectl apply -f wordpress-deployment.yaml

The changes should now be seen in the new container if you log in and the user can now upload their giant themes.