I read all the documentation we have about the Command and Args fields inside our .yaml files
I know what they do, what they substitute in the image itself and so on…
I saw we have another ways to list the args fields as well, not only using …
The bigger question is, what is the difference between:
args: [“some arg”]
args:
“some arg”
…
And my next question and what is causing more trouble to me is:
I have my binary inside the image and I’m trying a lot of ways to start him (he has a lot of parameters):
command: [“myBinary”]
args: ["-f -n -s"] or
args:
“-f -n -s”
And the strange thing is, this is not working, my binary keeps telling me the parameters are wrong, but if I start it directly using:
kubectl exec myPod – myBinary -f -n -s
it WORKS!
So I have some doubts about how this args really works…
If I want to start myBinary with just one line (putting all the parameters there) I need to start it using shell? I cannot do it directly?
Args is a list, which is passed into your app as argv or os.Args or
whatever your language uses to parse the commandline. Most
commandline processing libs (not all) support [ “-f”, “5” ] as well as
[ “-f5” ] or [ “-f=5” ], but you can’t just string multiple flags
together in one string.
Hmmm, got you! so it’s not 100% only k8s, it depends as well how my binary is using the args!
I’m using C++ by the way, but I’ll do some tests with this new discovery and will return if I have more problems…
C++ brings args in to main() as main(int argc, char *argv[]), so each k8s args item is one element of argv. When you call your app on the commandline, the shell parses your “-f 5 -n -s 0” into “words” which it passes to the binary. k8s doesn’t impose a shell, and doesn’t try to parse shell-like commandline (quoting rules are hard and vary between shells, for example).
One cheap alternative, if you have a shell in your image is to run command: [ sh], args: [-c, "myapp -f 5 -n -s 0” ]`, but as I said that requires a shell.
But then I was having another problem with this approach (I stopped using shell because of this)…
The problem I was having were:
When I was testing the pod shutdown (killing it using k8s delete or helm del) the SIGTERM wasn’t being sent to my application (as the documentation suggest we should have in the ending lifecycle) causing my binary to not shutdown gracefully…
So I changed to use the binary direct in commands/args to have it working (as I understood k8s wasn’t sending SIGTERM to my binary because it was sending to the shell as it was the first thing started…)
Yes, this is probably correct. Shell and signals are not great friends. You could run “sh”, “-c”, “exec mycommand -f 5 -n -s 0”, but I think you’re better off fixing the real problem