• December 6, 2018

Kubernetes 101

Mickey Boxell
Product Management

I am new to Kubernetes. I wanted to share some concepts, helpful commands, and gotchas that I have come across during my first few months using the service. If you are also new to Kubernetes, chances are some of these may come in handy for you as well.

Since you are reading this article, you probably have some awareness of the open source container management tool, Kubernetes. In a nutshell, Kubernetes simplifies the process of managing containerized workloads and services by orchestrating the provisioning of computing, networking, and storage resources. Kubernetes uses a command line tool called kubectl for running commands against clusters. All of the commands mentioned below will be performed with the use of kubectl.


Key Terms

To begin with, I wanted to spend time highlighting a few key terms related to Kubernetes. There is a more exhaustive list available on the Kubernetes Standardized Glossary page.

  • A cluster is a set of machines individually referred to as nodes used to run containerized applications managed by Kubernetes.

  • A node is either a virtual or physical machine. A cluster consists of a master node and a number of worker nodes.

  • A container is an image that contains software and its dependencies.

  • A pod is a single container or a set of containers running on your Kubernetes cluster.

  • A deployment is an object that manages replicated applications represented by pods. Pods are deployed onto the nodes of a cluster.

  • A replicaset ensures that a specified number of pod replicas are running at one time.

  • A service describes how to access applications represented by a set of pods. Services typically describe ports and load-balancers and can be used to control internal and external access to a cluster.



Maybe you have Kubernetes installed on your desktop or you decided to use a managed provider, such as Oracle Container Engine for Kubernetes (OKE). Regardless of how you are accessing Kubernetes it is important to be able to check your context. Context is another term for the Kubernetes cluster to which you are currently connected. As the number of clusters you have access to grows you will need to understand how to change from one to another.

kubectl config current-context will show you your current context.

kubectl config view will display the contents of your Kubernetes config file.

kubectl config view -o jsonpath='{.contexts[*].name}' will list out the available contexts.

To change your context export the Kubeconfig file for the cluster you plan to connect to: export KUBECONFIG=~/.kube/config and then run:kubectl config use-context [context name]



Now that you have verified and perhaps changed your context, what if you want to create something on your cluster? Kubernetes uses manifest files written in YAML or JSON to define the resources that it will provision. Multiple resources can be defined in the same manifest file as long as they are separated by "---". The resources will be created in the order they appear in the file. People will typically group resources related to the same microservice or application in the same file.

When it comes time to deploy a service, you can either reference the .yaml, .yml, or .json file sitting locally: kubectl create -f target/app.yaml

Or you can specify a URL kubectl create -f https://github.com/karthequian/docker-helloworld/blob/master/deployment.yml.

When it comes to deploying more complex applications in Kubernetes, many people turn to the package management tool, Helm. Helm provides a method for repeatable application installation through the use of charts, packages that contain Kubernetes manifest files and helpful metadata. There is a curated list of charts for software commonly used with Kubernetes in the Helm stable charts repository. For more information about Helm, check out our overview here.

Namespaces are helpful to keep in mind when it comes to organizing resources. For instance if you wanted to sort resources into a group like DevOps you could use the devops namespace and use it for tools like Prometheus for monitoring. By default Kubernetes will deploy everything onto your default namespace. Additional namespaces can be created with kubectl create namespace [name]. You can list the current namespaces with kubectl get namespaces. When deploying resources, pass the namespace flag --namespace [name] in with your deployment command. For instance, kubectl create -f target/app.yaml --namespace [name]. After associating resources with a namespace, it becomes easier to organize them by project or group.


Viewing Resource Information

It is important to have insight into the resources deployed on your cluster. You can do so very broadly by running kubectl get all. This command will grab all of the pods, services, deployments, and replicasets in your cluster. In order to be more specific with the information that is returned, you can search for resources one at a time:

  • kubectl get services or kubectl get svc will return all of the services in your cluster
  • kubectl get pods or kubectl get po will return all of the pods in your cluster
  • kubectl get deployments will return all of the deployments in your cluster
  • kubectl get replicasets will return all of the replicasets in your cluster

If you know the name of a resource, you can search specifically for that resource with kubectl get [resource type] [resource name].

As the number of resources deployed in your cluster grow, there are plenty of helpful commands to help sort the information returned by these commands. For instance, adding the -o wide flag after your search will provide additional details and adding --sort-by=.metadata.name will list resources alphabetically by name.

One thing to keep in mind is that commands such as kubectl get pods, used to view your existing pods, will only return data from your default namespace. In order to view data for all of your namespaces you must run the command with the --all-namespaces flag added.


Interacting with Deployed Resources

After deploying resources to your cluster it can be helpful to be able to quickly edit them. You can edit resources directly from the command line by entering kubectl edit [resource type] [resource name]. This will open up a text editor in your command line allowing you to modify the manifest files describing your resources.

Another helpful feature of Kubernetes is the ability to get access to the shell of your running containers. You can do so with kubectl exec -it [pod name] -- /bin/bash. This can be useful if you have the need to run commands directly on your container. If your pod has more than one running container on it, you can pass the --container flag followed by the container name to specify which container to access.

I have also found it very useful to create port forwards for pods running in my cluster. This can be accomplished with kubectl port-forward [pod name] 8080:8080. In this example we are listening on port 8080 on the local machine and forwarding to port 8080 on [pod name].



If a pod is not deploying in a reasonable amount of time or something else seems off about it, it can be helpful to get more information about what is happening. kubectl describe [pod name] returns configuration information and current status information about the containers and the pods. Here is a good source for additional information about application introspection and debugging.

Kubernetes also includes a logging tool that can help you debug and monitor your cluster. Kubernetes logs write to standard output and standard error. To pull logs for a pod use kubectl logs [pod name]. If there is more than one container on a pod, you will be prompted to pass in that container name. For a more thorough look at logging, check out this article on using the EFK (Elastic Search, FluentD, Kibana) stack.



Resources can be deleted one at a time with commands such as kubectl delete [resource type] [resource name]. For faster clean up, all of the resources created by a manifest file can be deleted by referencing that file in the delete command: kubectl delete -f target/app.yaml. You may find yourself wondering why it is that your kubectl delete pod command did not seem to work because the pod is still listed when you run kubectl get po. Remember that deployments and replicasets often contain settings that will redeploy pods that fail or are deleted. You will need to update or delete the deployment or replicaset to ensure your pod is not inadvertently resurrected after it has been deleted.


Next Steps

It goes without saying that there are many more advanced things possible when it comes to interacting with your Kubernetes cluster. Some that come to mind are secrets, tagging, scaling, patching, updating, and authentication. There is great information available in the official Kubernetes Documentation page for those who are ready to learn more.


Helpful Resources

Kubernetes Documentation

kubectl Cheat Sheet



Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.