It's been over five years since Google open-sourced the Kubernetes project. Even so, you might still be wondering what Kubernetes is and how you can get started using it. Well, you're in the right place! In this post, I'm going to explain the basics you need to know to get started with Kubernetes. And I won't just be throwing concepts at you—I'll give you real code examples that will help you get a better idea of why you might need to use Kubernetes if you're thinking about using containers.

Getting Started With Hands-On Exercises

Before we dive into the core concepts of Kubernetes, you're going to want to brew a pot of coffee.

Now, let's get started by setting up your local environment. I'm not sure about you, but I learn more quickly by doing rather than just reading or memorizing concepts. Kubernetes's learning curve is significant, and sometimes you can get overwhelmed with all the ecosystem that surrounds this popular container-orchestration system. But once you have a solid knowledge base, you'll see that Kubernetes only happens to have a lot of pieces that you need to put together to create something cool.

If you don't want to go through the process of installing Kubernetes right away, there's a playground you can use called Play with Kubernetes (PWK). I'd recommend you take the PWK approach only if installing Kubernetes becomes complicated with your current computer. There are a lot of options to install and use Kubernetes, but I'll focus only on the local environment.

Installing the Kubernetes Command Line

Before installing Kubernetes, you need to install the command line (CLI) tool called kubectl (pronounced: cube-cuttle). Kubectl is the CLI you'll use to interact with any Kubernetes cluster, not just the local one. If you don't want to have a local Kubernetes installation, but you want to operate a Kubernetes cluster, you'll only use kubectl.

Installing kubectl is very simple, and the instructions vary depending on your OS. It's supported for Linux, Windows, or Mac. You can follow the detailed instructions in the official docs page. Run the following command to verify the installation:

kubectl version

Now continue with the local installation of Kubernetes.

Installing Kubernetes Locally

You start by installing Docker. Kubernetes does support other container systems, but I think using Docker is the easiest way to learn Kubernetes.

Depending on your OS, I'd recommend a specific install method:

• If Linux, the preferred method is to install minikube. You'll need a hypervisor like VirtualBox or KVM.
• If Windows or Mac, the preferred method is to install the latest version of Docker for desktop. You might need to enable Kubernetes if you are already using the newest version.

The installation process might take a while, so take this time to grab another cup of coffee.

Verify that Kubernetes is running with the following command:

kubectl get svc

If you don't have an error, that's it! You now have Kubernetes running locally. If you want to have a graphic interface, you can install it very quickly. In this guide, I'll only use the CLI, but it's good to have the GUI just in case you want to have a graphic view of all the components.

Kubernetes Core Concepts

You interact with Kubernetes using the API (typically via the kubectl CLI) with the purpose of setting up the desired state of your applications. That means that you tell Kubernetes how your application should run. Kubernetes will make sure that the application is running in the state you specify, even if there was a failure in the cluster or the load increase and you need to scale out the resources.

The way you set the desired state is by creating objects in Kubernetes. We'll take a look at some of the core objects that you'll need to deploy with zero-downtime a resilient application. You define these objects in a YAML format, and that's what I'll use to practice the concepts.

Pods

A pod is the smallest compute unit object you create in Kubernetes, and it's how you group one or more containers. You might know that containers have only one responsibility. But the reason why a pod has more than one container is for performance and co-scheduling purposes. Containers in a pod share the same networking, the same storage, and are scheduled in the same host.

For example, a web app could be a container that writes the logs to a storage device. Another container that collects logs in files could use the same storage device as the web app container. That way, you don't have more than one responsibility into a container. So you should think of a pod as if it was a representation of a virtual machine, but it isn't.

You create a pod object with a YAML file definition named pod.yaml, like the following:

apiVersion: v1
kind: Pod
metadata:
    name: helloworld
    labels:
        app: helloworld
spec:
    containers:
    - name: helloworld
      image: christianhxc/helloworld:1.0
      ports:
      - containerPort: 80
      resources:
        requests:
            cpu: 50m
        limits:
            cpu: 100m

Now you create the pod by running the following command:

kubectl apply -f pod.yaml

You then verify that the pod is running with this command:

$ kubectl get pods
NAME         READY     STATUS    RESTARTS   AGE
helloworld   1/1       Running   0          41s

If for some reason the pod dies, you don't have to tell Kubernetes to create the pod again. Kubernetes will recreate one automatically because the pod's state is not the same as the one you defined. Let's take a look at the following object then.

Deployments

Pods are mortal, and that means that your application is not resilient. A deployment object is how you can give immortality to pods. You define how many pods you want to have running all the time, the scaling policies, and the policy for zero-downtime deployments. If a pod dies, Kubernetes will spin up a new pod. Kubernetes continually verifies that the desired state matches with the object's definition.

Let's create a deployment.yaml file to say that we want to have two pods running all the time, like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld
  labels:
    app: helloworld
spec:
  replicas: 3
  selector:
    matchLabels:
      app: helloworld
  template:
    metadata:
      labels:
        app: helloworld
    spec:
      containers:
      - name: helloworld
        image: christianhxc/helloworld:1.0
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 50m
          limits:
            cpu: 100m

Now let's tell Kubernetes that we want to create the deployment object by running the following command:

$ kubectl apply -f deployment.yaml
deployment.apps/helloworld created

Verify that the deployment exists by running the following command:

$ kubectl get deployments
NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
helloworld   3         3         3            3           40s

You'll see that now you have three pods running plus the one we created previously.

$ kubectl get pods
NAME                          READY     STATUS    RESTARTS   AGE
helloworld                    1/1       Running   0          8h
helloworld-75d8567b94-7lmvc   1/1       Running   0          24s
helloworld-75d8567b94-n7spd   1/1       Running   0          24s
helloworld-75d8567b94-z9tjq   1/1       Running   0          24s

If you want to try killing a pod, run the command "kubectl delete podhelloworld-75d8567b94-7lmvc". You'll see how Kubernetes creates a new pod so that the desired state matches with the deployment definition. Every time you need to update the de container image, you'll change the deployment.yaml file and run the "apply" command. Then, Kubernetes will create new pods with the updated container image version. Until they're running, the pods with the previous version will be terminated. You can configure in much more detail how you want this update to happen, but for now the default behavior works for learning purposes.

Services

At the moment, you can't access the pods through a web browser to verify that they're working—you need to expose them. The recommended way to expose pods is via the service object. Still, other pods in the cluster can communicate between each other by using the internal IP address. But you can't rely on an IP to communicate with pods for its dynamism, which is why the solution is still a service.

A service then is a representation of a load balancer for pods. You can configure the load balancing algorithm, and if Kubernetes is integrated with a cloud provider, you'll use the native load balancers from the cloud provider.

The most straightforward way to define your services is as the following service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: helloworld
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: helloworld

You might notice that we've been using labels and selectors, and that's because that's how a service knows to which pods redirect the requests. In the objects you've been creating, the label chosen is "app: helloworld" in the pod's metadata definition. It doesn't matter how a pod was created. As long as it has that label, it will be "registered" in the service.

Let's run the following command to create the service:

$ kubectl apply -f service.yaml
service/helloworld created

To verify that the service is running, and to get the IP address to test it, run the following command:

$ kubectl get svc
NAME         TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
helloworld   LoadBalancer   10.105.139.72   localhost     80:30299/TCP   21s
kubernetes   ClusterIP      10.96.0.1       <none>        443/TCP        12h

Use the value given for "EXTERNAL-IP" and the "PORT" to test it. In this case, the URL should be http://localhost/api/values for the container image we're using. You might receive different values depending on where you're running Kubernetes. If for some reason port 80 is taken, you can change the port in the service.yaml file and run the "apply" command again.

And that's it! Just by using pods, deployments, and services, you can deploy a resilient stateless app in your local environment.

What's Next?

The next step is to move forward by deploying the same app to the following environment, like the cloud. The process and flow are the same, at least with a simple app like the one I used in the examples.

Even though this guide is a little more advanced than a typical "hello world" app, the app is still straightforward. But that's not usually the reality in today's complex and distributed world. I just scratched the surface—Kubernetes has a lot more concepts. (For example, I didn't talk about other core concepts like volumes, namespaces, ingress, configmap, secrets, jobs, daemonset, and statefulset.) But the concepts I explained and demonstrated here should be a good foundation for your Kubernetes journey.

If you want to continue learning more, the official documentation is a pretty good source, and here are some useful links to start:

• Kubernetes basics from the official docs
• Tutorials for common apps and workflows
• Kubernetes podcast from Google

Get your hands-on experience by practicing; it's the best way you'll learn Kubernetes.