Over time, Kubernetes has become the de facto container orchestration technology and is core to many modern companies’ infrastructure. However, Kubernetes concepts can be a bit overwhelming. This crash course will help guide through Kubernetes (also abbreviated as k8s where 8 represents a number of letters between first and last letters) concepts.
How to use this crash course: Reading every word of this “crash course” will not make you a Kubernetes expert. The goal for this crash course is two-fold: to provide a reference for Kubernetes concepts and to provide a framework for someone to teach themselves Kubernetes relatively quickly. The topics here are presented in a very bare-bones fashion and provide an overview of the basic Kubernetes concepts.
My recommended approach for someone looking to learn Kubernetes is to step through each topic, read it, and then google it if needed to cement their knowledge.
A Node is a machine where containers will be launched by K8s.
A group of nodes. Having a cluster means that one machine failing will not take down the whole application
A node that watches over and orchestrates the other nodes in a cluster
An encapsulation of a container in Kubernetes. A pod is the smallest object that can be created in Kubernetes. In Kubernetes, you do not interact directly with a container; instead, you interact with a pod.
Scaling with Pods
To scale up or down, additional pods are deployed. You do not add additional containers into a pod. Instead, scaling involves adding more pods into nodes.
A pod represents a specific piece of an application or infrastructure. This means that often a pod encapsulates one container. However, this is not a requirement. Multiple containers can be in a pod, but they should be different types of containers. Multiple containers in a pod are linked and share many things, I.E. network, storage, fate (when a pod is destroyed, all the containers in it are destroyed).
Multi-pod containers are a rare use case.
Processes that monitor Kubernetes objects and respond accordingly.
A controller that monitors a pod or set of pods.
A newer replacement for replica controllers.
Replica Set vs Replication Controller
In a replica set, the selector is required to be specified. Whereas in replica controller it is optional. A replica set will maintain the number of replicas in it. If new ones are created, they will be deleted by default and if there is not enough, they will be deleted.
A deployment is a collection of other objects in the hierarchy, such as replica sets.
A rolling update is the default deployment strategy, where replicas are taken down and replaced one by one.
A Kubernetes object for connecting different parts of the Kubernetes infrastructure together. A service functions as a server with a very specific function in Kubernetes with it’s own internal IP address.
A node in Kubernetes has its own network. If you were to ssh into the node, you could access the pod’s Ip addresses. However, these are internal to the node, and by default are inaccessible to external requests. A node port can translate a port on the node to a node-internal IP address attached to a pod.
A NodePort can be used for multiple pods. In this case, it will randomly distribute the load across multiple pods like a built-in load balancer. If the pods are in multiple nodes, the service will span all of them. In this case, you can access the nodes from the NodePort using any IP that the NodePort spans along with the port specified.
Service that creates a virtual IP inside the cluster attached to a group of pods based on a selector. Provides a single, consistent endpoint that can be used to represent a service.
By default in Kubernetes, all Kubernetes objects are able to interact with any other objects in the cluster with an allow-all rule. A network policy is a Kubernetes object that can be attached to pods in Kubernetes that dictates what can be allowed into and out of an object.
To use AND logic in pod selectors, use a dictionary in the YAML file. Rules included under a dash will be treated as an AND. Separate rules with their own dash are treated as an or.
Service that creates a load balancer
A namespace is a group of Kubernetes objects separated from other namespaces. Some features of namespaces include:
- A namespace can have it’s own resource limits.
- A namespace can have it’s own policies.
- Objects in a namespace can reach other objects in the same namespace with just the name of the pod. Objects can also reach other namespaces by appending the name of the namespace
- A namespace can be specified for commands. Such as get pods, which by default only gets pods in the default namespace.
A namespace can also be specified in definition fields for Kubernetes objects.
To set a resource quota for a namespace, create a ResourceQuota Object
The -o flag can be added to any kubectl command to change the output format. The default is a human-readable plain text format. There are 4 options:
- json – json format
- name – resource name and nothing else
- wide – output in plain text with additional information
- yaml output YAML formatted API object