Radek's answer is very good, but I would like to pitch in from my experience, you will almost never use an object with the kind pod, because that doesn't make any sense in practice.

Because you need a deployment object - or other Kubernetes API objects like a replication controller or replicaset - that needs to keep the replicas (pods) alive (that's kind of the point of using kubernetes).

What you will use in practice for a typical application are:

1. Deployment object (where you will specify your apps container/containers) that will host your app's container with some other specifications.

2. Service object (that is like a grouping object and gives it a so-called virtual IP (cluster IP) for the pods that have a certain label - and those pods are basically the app containers that you deployed with the former deployment object).

You need to have the service object because the pods from the deployment object can be killed, scaled up and down, and you can't rely on their IP addresses because they will not be persistent.

So you need an object like a service, that gives those pods a stable IP.

Just wanted to give you some context around pods, so you know how things work together.

Hope that clears a few things for you, not long ago I was in your shoes :)

Kubernetes has three Object Types you should know about:

• Pods - runs one or more closely related containers
• Services - sets up networking in a Kubernetes cluster
• Deployment - Maintains a set of identical pods, ensuring that they have the correct config and that the right number of them exist.

Pods:

• Runs a single set of containers
• Good for one-off dev purposes
• Rarely used directly in production

Deployment:

• Runs a set of identical pods
• Monitors the state of each pod, updating as necessary
• Good for dev
• Good for production

And I would agree with other answers, forget about Pods and just use Deployment. Why? Look at the second bullet point, it monitors the state of each pod, updating as necessary.

So, instead of struggling with error messages such as this one:

Forbidden: pod updates may not change fields other than spec.containers[*].image

So just refactor or completely recreate your Pod into a Deployment that creates a pod to do what you need done. With Deployment you can change any piece of configuration you want to and you need not worry about seeing that error message.

Pod is container instance.

That is the output of replicas: 3

Think of one deployment can have many running instances(replica).

//deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: tomcat-deployment222
spec:
  selector:
    matchLabels:
      app: tomcat
  replicas: 3
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:9.0
        ports:
        - containerPort: 8080

Pod is a collection of containers and basic object of Kuberntes. All containers of pod lie in same node.

• Not suitable for production
• No rolling updates

Deployment is a kind of controller in Kubernetes.

Controllers use a Pod Template that you provide to create the Pods for which it is responsible.

Deployment creates a ReplicaSet which in turn make sure that, CurrentReplicas is always same as desiredReplicas .

Advantages :

• You can rollout and rollback your changes using deployment
• Monitors the state of each pod
• Best suitable for production
• Supports rolling updates

I want to add some informations from Kubernetes In Action book, so you can see all picture and connect relation between Kubernetes resources like Pod, Deployment and ReplicationController(ReplicaSet)

Pods

are the basic deployable unit in Kubernetes. But in real-world use cases, you want your deployments to stay up and running automatically and remain healthy without any manual intervention. For this the recommended approach is to use a Deployment, which under the hood create a ReplicaSet.

A ReplicaSet, as the name implies, is a set of replicas (Pods) maintained with their Revision history.

(ReplicaSet extends an older object called ReplicationController -- which is exactly the same but without the Revision history.)

A ReplicaSet constantly monitors the list of running pods and makes sure the running number of pods matching a certain specification always matches the desired number.

Removing a pod from the scope of the ReplicationController comes in handy
when you want to perform actions on a specific pod. For example, you might 
have a bug that causes your pod to start behaving badly after a specific amount 
of time or a specific event.

A Deployment

is a higher-level resource meant for deploying applications and updating them declaratively.

When you create a Deployment, a ReplicaSet resource is created underneath (eventually more of them). ReplicaSets replicate and manage pods, as well. When using a Deployment, the actual pods are created and managed by the Deployment’s ReplicaSets, not by the Deployment directly

Let’s think about what has happened. By changing the pod template in your Deployment resource, you’ve updated your app to a newer version—by changing a single field!

Finally, Roll back a Deployment either to the previous revision or to any earlier revision so easy with Deployment resource.

These images are from Kubernetes In Action book, too.

Try to avoid Pods and implement Deployments instead for managing containers as objects of kind Pod will not be rescheduled (or self healed) in the event of a node failure or pod termination.

A Deployment is generally preferable because it defines a ReplicaSet to ensure that the desired number of Pods is always available and specifies a strategy to replace Pods, such as RollingUpdate.

In kubernetes Pods are the smallest deployable units. Every time when we create a kubernetes object like Deployments, replica-sets, statefulsets, daemonsets it creates pod.

As mentioned above deployments create pods based on desired state mentioned in your deployment object. So for example you want 5 replicas of a application, you mentioned replicas: 5 in your deployment manifest. Now deployment controller is responsible to create 5 identical replicas (no less, no more) of given application with all metadata like RBAC policy, networks policy, labels, annotations, health check, resource quotas, taint/tolerations and others and associate with each pods it creates.

There are some cases when you wants to create pod, for example if you are running a test sidecar where you don't need to run application forever, you don't need multiple replicas, and you run application when you wants to execute in that case pod is suitable. For example helm test, which is a pod definition that specifies a container with a given command to run.