Is this difference a problem for your use case? Kubernetes does do more work before a pod starts. If you need low-latency execution you'll have to use long-running worker processes of some form. Once it's started, it should be just as fast.
On Fri, Jun 2, 2017 at 2:13 PM Diego Lapiduz <di...@lapiduz.com> wrote: > This is a very short lived task (just runs `echo hello`) so the only thing > I really care about is getting that `hello` back. > > This is what I did in text format: > > ``` > ➜ eval $(minikube docker-env) > > ➜ time docker run dlapiduz/hello-world > > hello > docker run dlapiduz/hello-world 0.07s user 0.02s system 30% cpu 0.318 > total > ➜ time kubectl run --image=dlapiduz/hello-world test --attach > --restart=Never > Waiting for pod default/test to be running, status is Pending, pod ready: > false > hello > kubectl run --image=dlapiduz/hello-world test --attach --restart=Never > 0.09s user 0.02s system 7% cpu 1.357 total > ``` > > On Thu, Jun 1, 2017 at 11:27 PM, 'Tim Hockin' via Kubernetes user > discussion and Q&A <kubernetes-users@googlegroups.com> wrote: > >> It runs faster or it starts faster? The gif clear too quickly for me to >> see. >> >> On Thu, Jun 1, 2017 at 9:09 PM, Diego Lapiduz <di...@lapiduz.com> wrote: >> >>> Hi y'all, (k8s noob here so forgive me if this is something that I am >>> doing obviously wrong) >>> >>> I am trying to run a short lived task and I am trying to move from >>> Docker Swarm to Kubernetes. An interesting issue that I am finding is that >>> running the same Docker image on the same minikube cluster is much faster >>> using the docker cli tool (or docker api) than kubectl. >>> >>> Here is a quick screen cap: I know that I am probably doing something >>> off, any idea what it could be? Thanks! >>> >>> >>> >>> <https://d2ppvlu71ri8gs.cloudfront.net/items/120h333e0Z0f3Z3X3K0i/Screen%20Recording%202017-06-01%20at%2010.55%20PM.gif?v=97833b20> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Kubernetes user discussion and Q&A" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to kubernetes-users+unsubscr...@googlegroups.com. >>> To post to this group, send email to kubernetes-users@googlegroups.com. >>> Visit this group at https://groups.google.com/group/kubernetes-users. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Kubernetes user discussion and Q&A" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/kubernetes-users/MArCwIOYWo0/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> kubernetes-users+unsubscr...@googlegroups.com. >> > >> To post to this group, send email to kubernetes-users@googlegroups.com. >> Visit this group at https://groups.google.com/group/kubernetes-users. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "Kubernetes user discussion and Q&A" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kubernetes-users+unsubscr...@googlegroups.com. > To post to this group, send email to kubernetes-users@googlegroups.com. > Visit this group at https://groups.google.com/group/kubernetes-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
