<p>Most software tech has a &quot;Hello World&quot; type example to get started on. With Kubernetes this seems to be lacking.</p>
<p>My scenario cannot be simpler. I have a simple hello world app made with Spring-Boot with one Rest controller that just returns: &quot;Hello Hello!&quot;</p>
<p>After I create my docker file, I build an image like this :</p>
<pre><code>docker build -t helloworld:1.0 .
</code></pre>
<p>Then I run it in a container like this :</p>
<pre><code>docker run -p 8080:8080 helloworld:1.0
</code></pre>
<p>If I open up a browser now, I can access my application here :</p>
<pre><code>http://localhost:8080/hello/
</code></pre>
<p>and it returns :</p>
<pre><code>&quot;Hello Hello!&quot;
</code></pre>
<p><em>Great! So far so good.</em></p>
<p>Next I tag it (my docker-hub is called ollyw123, and the ID of my image is 776...)</p>
<pre><code>docker tag 7769f3792278 ollyw123/helloworld:firsttry
</code></pre>
<p>and push :</p>
<pre><code>docker push ollyw123/helloworld
</code></pre>
<p>If I log into Docker-Hub I will see</p>
<p><a href="https://i.stack.imgur.com/c1CCO.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/c1CCO.png" alt="enter image description here" /></a></p>
<p>Now I want to connect this to Kubernetes. This is where I have plunged deep into the a state of confusion.</p>
<p>My thinking is, I need to create a <strong>cluster</strong>. Somehow I need to connect this cluster to my <strong>image</strong>, and as I understand, I just need to use the URL of the image to connect to (ie.
<a href="https://hub.docker.com/repository/docker/ollyw123/helloworld" rel="nofollow noreferrer">https://hub.docker.com/repository/docker/ollyw123/helloworld</a>)</p>
<p>Next I would have to create a <strong>service</strong>. This service would then be able to expose my &quot;Hello World!&quot; rest call through some port. This is my logical thinking, and for me this would seem like a very simple thing to do, but the tutorials and documentation on Kubernetes is a mine field of confusion and dead ends.</p>
<p>Following on from the spring-boot kubernetes tutorial (<a href="https://spring.io/guides/gs/spring-boot-kubernetes/" rel="nofollow noreferrer">https://spring.io/guides/gs/spring-boot-kubernetes/</a>) I have to create a deployment object, and then a service object, and then I have to &quot;apply&quot; it :</p>
<pre><code>kubectl create deployment hello-world-dep --image=ollyw123/helloworld --dry-run -o=yaml &gt; deployment.yaml

kubectl create service clusterip hello-world-dep --tcp=8080:8080 --dry-run -o=yaml &gt;&gt; deployment.yaml

kubectl apply -f deployment.yaml
</code></pre>
<p>OK. Now I see a service :</p>
<p><a href="https://i.stack.imgur.com/8O9TY.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/8O9TY.png" alt="enter image description here" /></a></p>
<p>But now what???</p>
<p>How do I push this to the cloud? (eg. gcloud) Do I need to create a cluster first, or is this already a cluster?</p>
<p>What should my next step be?</p>

Oliver Watkins
<p>There are a couple of concepts that we need to go through regarding your question.</p>
<p>The first would be about the &quot;Hello World&quot; app in Kubernetes. Even this existing (as mentioned by Limido in the comments [<a href="https://kubernetes.io/docs/tutorials/hello-minikube/" rel="nofollow noreferrer">link</a>]), the app itself is not a Kubernetes app, but an app created in the language of your choice, which was containerized and it is deployed in Kubernetes.</p>
<p>So I would call it (in your case) a Dockerized SpringBoot HelloWorld app.</p>
<p>Okay, now that we have a container we could simply deploy it running docker, but what if your container dies, or you need to scale it up and down, manage volumes, network traffic and a bunch of other things, this starts to become complicated (imagine a real life scenario, with hundreds or even thousands of containers running at the same time). That's exactly where the Container Orchestration comes into place.</p>
<p>Kubernetes helps you managing this complexity, in a single place.</p>
<p>The third concept that I'd like to talk, is the <code>create</code> and <code>apply</code> commands. You can definitely find a more detailed explanation in <a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/object-management/" rel="nofollow noreferrer">here</a>, but both of then can be used to create the resource in Kubernetes.</p>
<p>In your case, the <code>create</code> command is not creating the resources, because you are using the <code>--dry-run</code> and adding the output to your deployment file, which you <code>apply</code> later on, but the following command would also create your resource:</p>
<pre><code>kubectl create deployment hello-world-dep --image=ollyw123/helloworld

kubectl create service clusterip hello-world-dep --tcp=8080:8080
</code></pre>
<p>Note that even this working, if you need to share this deployment, or commit it in a repository you would need to get it:</p>
<pre><code>kubectl get deployment hello-world-dep -o yaml &gt; your-file.yaml
</code></pre>
<p>So having the definition file is really helpful and recommended.</p>
<p>Great... Going further...</p>
<p>When you have a deployment you will also have a number of replicas that is expected to be running (even when you don't define it - the default value is 1). In your case your deployment is managing one <a href="https://kubernetes.io/docs/concepts/workloads/pods/" rel="nofollow noreferrer">pod</a>.</p>
<p>If you run:</p>
<pre><code>kubectl get pods -o wide
</code></pre>
<p>You will get your pod hello-world-dep-hash and an IP address. This IP is the IP of your container and you can access your application using it, but as pods are ephemeral, if your pod dies, Kubernetes will create a new one for you (automatically) with a new IP address, so if you have for instance a backend and its IP is constantly changing, you would need to manage this change in the frontend every time you have a new backend pod.</p>
<p>To solve that, Kubernetes has the <a href="https://kubernetes.io/docs/concepts/services-networking/service/" rel="nofollow noreferrer">Service</a>, which will expose the deployment in a persistent way. So if your pod dies and a new one comes back, the address of your service will continue the same, and all the traffic will be automatically routed to your new pod.</p>
<p>When you have more than one replica of your deployment, the service also load balance the load across all the available pods.</p>
<p>Last but not least, your question!</p>
<p>You have asked, now what?</p>
<p>So basically, once you have your application containerized, you can deploy it almost anywhere. There are N different places you can get it. In your case you are running it locally, but you could get your deployment.yaml file and deploy your application in <a href="https://cloud.google.com/kubernetes-engine" rel="nofollow noreferrer">GKE</a>, <a href="https://learn.microsoft.com/en-us/azure/aks/" rel="nofollow noreferrer">AKS</a>, <a href="https://aws.amazon.com/eks/" rel="nofollow noreferrer">EKS</a>, just to quote the biggest ones, but all cloud providers have some type of Kubernetes service available, where you can spin up a cluster and start playing around.</p>
<p>Actually, to play around I'd recommend <a href="https://www.katacoda.com/courses/kubernetes" rel="nofollow noreferrer">Katakoda</a>, as they have scenarios for free, and you can use the cluster to play around.</p>
<p>Wow... That was a long answer...</p>
<p>Just to finish, I'd recommend the <a href="https://www.katacoda.com/courses/kubernetes/networking-introduction" rel="nofollow noreferrer">Network Introduction in Katakoda</a>, as there are different types of Services, depending on your scenario or what you need, and the tutorial is goes through the different types in a hands-on approach.</p>
