Once you have kubectl set up, the full power of Kubernetes is at your fingertips! There’s a lot to learn before you can build exascale applications to serve bajillions of requests per second, though. In this post, we’ll get familiar with pods.

Create a pod

The term pod is k8s-ese for container, basically. Technically, a pod can have multiple containers in it, but usually it just has one. Pods are pretty much the only reason K8s exists; everything else about K8s revolves around getting traffic to and from pods. Let’s create one! Put the following into a file named myfirstpod.yml:

apiVersion: v1
kind: Pod
metadata:
  name: myfirstpod
  labels:
    name: myfirstpod
spec:
  containers:
  - name: myfirstpod
    image: nginx
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"
    ports:
      - containerPort: 80

(Bonus points if you used the pod snippet from the Kubernetes VS Code plugin. Don’t try to memorize all of that syntax!)

Then create that pod by applying the file to the cluster:

kubectl -n <your-ns-name> apply -f myfirstpod.yml # use tab completion!

Now check to see if it’s running…

kubectl -n <your-ns-name> get pods # tab complete is your friend!

The status might say ContainerCreating for a little while, but eventually it will say Running if you keep checking the status. A nice trick for a very simple status monitor is to run watch kubectl -n <your-ns-name> get all, which uses the watch command to show everything in your namespace every two seconds.

Great! It’s running! So how do we use it?

Port-forward the pod to your local machine

The nginx pod is listening on port 80 (extra credit: what IP does it have in the cluster? Use kubectl describe), but you can’t just get to any IP and port in the cluster. You have to use an ingress to actually get to the pod from outside the cluster, but we’re not ready to talk about ingresses yet.

Well, it turns out you actually can get to the pod with kubectl port-forward, but you should only do this for testing and debugging. We’ll talk about how to do it the “right way” with ingresses in a later post. Here’s the kubectl port-forward syntax:

kubectl -n <your-ns-name> port-forward <your-pod-name> <local-port>:<pod-port>

It creates a magical wormhole that connects the pod’s port to a port on your local machine! Try it:

kubectl -n <your-ns-name> port-forward myfirstpod 8080:80

Then use your browser to navigate to http://localhost:8080. You connected to the pod running in the cluster!

That pod isn’t particularly useful, so let’s get rid of it:

kubectl -n <your-ns-name> delete -f myfirstpod.yml

Now your namespace is empty and clean again. Nice and simple.

There’s a drawback to this simplicity, though. It’s fragile! You deleted the pod yourself when you were done with it, which is fine, but what if something had gone wrong? What if the node that the pod was running on caught fire? The pod would be gone, and you would have to re-create it manually! Fortunately, Kubernetes has plans to keep your pods running even when bad things happen, and it involves the topic of the next post: deployments.

Conclusion

A pod is the basic work unit in Kubernetes, and the vast majority of the time, “pod” is synonymous with “container”–though a pod can actually have multiple containers in some cases. You can use kubectl port-forward to get to a pod for development/debugging purposes.