It is poor design for a Dockerfile to have two forms of CMD where each is only distinguished from the other by argument formatting.
For people new to Dockerfiles, it's too easy to be oblivious to the fact that the two forms do something differently.
For people who've used Dockerfiles a lot, it's too easy to miss the formatting difference, especially when the two different CMD forms can successfully run what you want it to run.
CMD should have been split into two separate statement types, either completely separate types (e.g. SHELLCMD vs RAWCMD) or two explicit subtypes of CMD (e.g. CMD SHELL vs CMD RAW). Then you couldn't read each of the CMD variants without seeing the difference.
New users would see the difference and think "Why is there a difference? I should look it up." Old users would more easily notice when the shell CMD is used when the raw CMD should be used, and vice versa.
Kubernetes lets you override the dockerfile with "command" and "args".
Always try to be explicit especially in nonstandard/exceptional application images. A shared base image with known proven startup knowledge that is used throughout all applications is easier to manage and more transparent. In more pluriform environments just submit and ensure the configuration of your pod/deployment is as explicit we possible.
For people new to Dockerfiles, it's too easy to be oblivious to the fact that the two forms do something differently.
For people who've used Dockerfiles a lot, it's too easy to miss the formatting difference, especially when the two different CMD forms can successfully run what you want it to run.
CMD should have been split into two separate statement types, either completely separate types (e.g. SHELLCMD vs RAWCMD) or two explicit subtypes of CMD (e.g. CMD SHELL vs CMD RAW). Then you couldn't read each of the CMD variants without seeing the difference.
New users would see the difference and think "Why is there a difference? I should look it up." Old users would more easily notice when the shell CMD is used when the raw CMD should be used, and vice versa.