Kubernetes CrashLoopBackOff where attempting to upgrade from mysql 5.7.x to 8.0.34

Hi folks,

We've been running various flavours of mysql 5.7.x for a few years, and now one of the items we're hosting requires 8.0.34 (prior release was 5.7.39).

In attempting to upgrade the deployment, it seems that the /usr/local/bin/docker-entrypoint.sh runs once as root and then attempts to run as the user mysql.. this latter step fails.. and then we have no logging to advise why (despite passing --verbose to /usr/local/bin/docker-entrypoint.sh)..

The /usr/local/bin/docker-entrypoint.sh, is loaded within our images own entrypoint and per the below:

{
    {
        if [ -f /usr/local/bin/docker-entrypoint.sh ]
        then
            /bin/echo "Running /usr/local/bin/docker-entrypoint.sh..."
            /bin/bash -x /usr/local/bin/docker-entrypoint.sh mysqld --verbose 2>&1
        else
            /bin/echo "ERROR: Cannot find /usr/local/bin/docker-entrypoint.sh..."
        fi
    } | /usr/bin/tee -a "${debugFile}"
}

Prior to upgrading, we're gracefully shutting down mysql 5.7 via mysqladmin.

I'm just a little stumped as no real helpful logs to advise what the issue is, so help appreciated!

Start with the reported startMySQL wrapper and /usr/local/bin/docker-entrypoint.sh invocation, including the switch from root to mysql and the --verbose output. Compare the MySQL 5.7 and 8.0.34 upgrade behavior in the Kubernetes deployment, then document a reproducible cause and the logs or diagnostics that explain the CrashLoopBackOff.