<p>I'm overwhelmed with the number of options in Kubernetes.</p>
<p>There is a typical(the most suggested) way of deploying microservices: you create a deployment yaml that contains what type of image to pull, the number of replicas, listening ports of the app, etc. Then you might want to create more yaml's to expose the app, for example, using a service yaml.</p>
<p>Helm charts, it is said, provide an easier way, giving you a preconfigured package. However, after installing a couple of apps from bitnami I see that some have a deployment yalm, some don't. Instead, some represented as pod yamls. I've read pod yamls are not ideal in a production environment.</p>
<p>What should be used when I need <em>just</em> to deploy a couple of apps on a node, the easiest(yet not stupid) way possible?</p>

Mike
<p>Deployments do the OPs job for you while you drink coffee. What I mean by this is that a Deployment ensures that the desired state defined in your deployment manifest is maintained automatically (best effort). So, if a pod crashes, deployment will bring it up without human intervention.</p>
<p>However, using a POD YAML to deploy application, you have to ensure that your pod is always up (if needed).</p>
<p>If you have  deployed a production grade app, you may know that running an app requires lots of things not just a deployment. You may need to create secrets,  configMaps, Services, Deployments etc. This is where HELM lends a helping hand by combining all the required descriptors in one deployable  package. This makes it very simple to maintain the state of the whole app as  a single unit.</p>
<p>So, the HELM chart that has POD yaml and not the deployment, it really depends on the use-case. It may have an &quot;<a href="https://kubernetes.io/docs/concepts/extend-kubernetes/operator/" rel="nofollow noreferrer">operator</a>&quot; that is handling the OPs part for you.</p>
<p><strong>Helm is the recommended way of deploying to Production.</strong></p>
