<p>I am trying to deploy my Docker images using Kubernetes orchestration tools.When I am reading about Kubernetes, I am seeing documentation and many YouTube video tutorial of working with Kubernetes. In there I only found that creation of pods, services and creation of that .yml files. Here I have doubts and I am adding below section,</p>

<ol>
<li>When I am using Kubernetes, how I can create clusters and nodes ?</li>
<li>Can I deploy my current docker-compose build image directly using pods only? Why I need to create services yml file?</li>
</ol>

<p>I new to containerizing, Docker and Kubernetes world.</p>

<ol>
<li><p>My favorite way to create clusters is <a href="https://github.com/kubernetes-incubator/kubespray#readme" rel="nofollow noreferrer">kubespray</a> because I find <a href="https://github.com/ansible/ansible#readme" rel="nofollow noreferrer">ansible</a> very easy to read and troubleshoot, unlike more monolithic &quot;run this binary&quot; mechanisms for creating clusters. The kubespray repo has a <a href="https://www.vagrantup.com" rel="nofollow noreferrer">vagrant</a> configuration file, so you can even try out a full cluster on your local machine, to see what it will do &quot;for real&quot;</p>
<p>But with the popularity of kubernetes, I'd bet if you ask 5 people you'll get 10 answers to that question, so ultimately pick the one you find easiest to reason about, because almost without fail you will need to <em>debug</em> those mechanisms when something inevitably goes wrong</p>
</li>
<li><p>The short version, as Hitesh said, is &quot;yes,&quot; but the long version is that one will need to be careful because local docker containers and kubernetes clusters are trying to solve different problems, and (as a general rule) one could not easily swap one in place of the other.</p>
<p>As for the second part of your question, a <code>Service</code> in kubernetes is designed to decouple the current provider of some networked functionality from the long-lived &quot;promise&quot; that such functionality will exist and work. That's because in kubernetes, the Pods (and Nodes, for that matter) are disposable and subject to termination at almost any time. It would be severely problematic if the consumer of a networked service needed to constantly update its IP address/ports/etc to account for the coming-and-going of Pods. This is actually the exact same problem that AWS's Elastic Load Balancers are trying to solve, and kubernetes will cheerfully provision an ELB to represent a <code>Service</code> if you indicate that is what you would like (and similar behavior for other cloud providers)</p>
</li>
</ol>
<p>If you are not yet comfortable with containers and docker as concepts, then I would strongly recommend starting with those topics, and moving on to understanding how kubernetes interacts with those two things after you have a solid foundation. Else, a lot of the terminology -- and even the problems kubernetes is trying to solve -- may continue to seem opaque</p>
