December 26, 2022
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 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.
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.
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
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.
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.