kubectl:
kubectl is a command-line tool used to interact with Kubernetes clusters. It serves as the primary
interface for developers, administrators, and users to manage and control Kubernetes resources. With
kubectl, we can perform various operations on Kubernetes clusters, such as deploying applications,
scaling resources, debugging, and more.
Kubectl uses the Kubernetes API to communicate with the cluster, so it requires network connectivity to the cluster’s API server.
kube-api server:
It is a crucial component of a Kubernetes cluster and is typically deployed as part of the Kubernetes control plane. The Kubernetes API server acts as the front-end interface for the Kubernetes control plane. It exposesthe Kubernetes API, which allows users, administrators, and other components to interact with the Kubernetes cluster.
Various operations, such as creating or managing pods, services, deployments, namespaces, and other
Kubernetes objects, are carried out through the API server.
kube-scheduler:
It’s a core component of Kubernetes responsible for scheduling pods onto available nodes within the cluster. As part of the Kubernetes control plane, it plays a critical role in optimizing resource utilization and ensuring that pods are placed on appropriate nodes based on various factors and policies.
kube-scheduler is a “single point of truth” for pod scheduling decisions. Once it schedules a pod to a
specific node, it updates the Kubernetes API server with this information, which ensures that all
components of the cluster have consistent knowledge about the pod’s location.
By effectively assigning pods to appropriate nodes, the kube-scheduler contributes to the efficient
utilization of cluster resources and the reliable performance of applications running on Kubernetes.
Kube Controller Manager:
It is one of the core components that make up the Kubernetes control plane & is designed to be highly available and runs as a set of independent processes on the master node(s) of the Kubernetes cluster. Each controller runs as a separate goroutine, making it scalable and efficient.
By managing these controllers, the Controller Manager continuously monitors the state of the cluster,
makes necessary adjustments to ensure the desired state is achieved, and helps maintain the system’s
overall health and stability.
Kubelet:
The Kubelet is an agent running on each node and is responsible for interacting with the Kubernetes master to manage the containers and pods scheduled on that node. It ensures that the containers specified in the pods are running and healthy.
Container Runtime:
The container runtime is responsible for pulling container images from a container registry and running the containers based on the specifications defined in the pod.
Kube-proxy
The kube-proxy is responsible for managing network communications between services and pods within the cluster. It maintains network rules and forwards traffic to the appropriate destination.
ETCD
Etcd is a critical component of the control plane that serves as a distributed key-value store. It is
responsible for storing and managing the configuration data and the state of the Kubernetes cluster.
It is a separate database used to ensure high availability, consistency, and reliability of cluster-wide information. It ensures that the entire cluster maintains a consistent view of its configuration and state,
thereby enabling the reliable and scalable operation of the platform.
Nodes:
Nodes are the individual machines (physical or virtual) that form the underlying compute resources of a
Kubernetes cluster or can say are the worker machines in a Kubernetes cluster where containers are deployed, and form the foundation for running and managing containerized applications within the Kubernetes ecosystem.
Pods:
Pods are the smallest deployable units of computing that we can create & manage in Kubernetes.
A Pod is a group of one or more containers, with shared storage & network resources and a specification
for how to run the containers.
A Pod’s contents are always co-located & co-scheduled & run in a shared context. A Pod models an
application specific “logical host”: it contains one(recommended) or more application containers which
are relatively tightly coupled.
Replicaset:
ReplicaSet purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods.
Deployments:
A Deployment Provides declarative updates for Pods & ReplicaSets.
We describe a desired state in a Deployment & the Deployment Controller changes the actual state to the
desired state at a controlled rate. We can define Deployments to create new ReplicaSets or to remove existing Deployments & adopt all their resources with new Deployments.
Service:
An abstract way to expose an application running on a set of Pods as a network service. With Kubernetes we don’t need to modify our application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their own IP addresses & a single DNS name for a set of Pods & can load balance across them.
Ingress:
An API object that manages external access to the services in a cluster, typically HTTP. Ingress may provide load balancing, SSL termination & name based virtual hosting. Ingress exposes HTTP & HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the ingress resources.
Ingress Class:
In Kubernetes, an Ingress class is a way to specify which Ingress controller should be used to handle
incoming traffic for a particular Ingress resource. Ingress controllers are responsible for implementing
the Ingress rules and managing the incoming external traffic to services in the cluster.
ingressClassName helps in choosing the appropriate Ingress controller to process the Ingress rules
and manage the traffic for that specific Ingress resource. EX: ingressClassName: nginx # Specifies the Ingress class to use (e.g., “nginx”)
Secrets:
Kubernetes Secrets let you store & manage sensitive information such as passwords, API keys, ssh keys,
OAuth tokens and other confidential data. Secrets are base64-encoded and can be used by applications
deployed within a Kubernetes cluster, ensuring that sensitive information is kept secure and not exposed
in plain text.
(FYI – base64 encoding is not encryption, as a result, it’s crucial to manage access to Secrets carefully.)
Secrets are scoped to a specific namespace within a Kubernetes cluster. They can only be accessed by
resources within the same namespace.
Configmap:
A configMap is an API object used to store non-confidential data in key-value pairs. Pods can consume
ConfigMaps as env variables, command-line arguments, or as configuration files in a volume. A configMap allows you to decouple env specific configuration from our containers images, so that our
applications are easily portable.
Note: It doesn’t provide secrecy or encryption.
Namespace:
Namespaces are powerful tools for managing and organizing resources in a Kubernetes cluster, particularly in complex multi-tenant environments where multiple users or teams share the same
infrastructure. Properly using namespaces helps maintain better control, isolation, and resource
allocation within the cluster.
Kustomization:
With kustomization.yaml, we can manage variations of our Kubernetes resources easily, ensuring that
each environment or use case has the appropriate customizations while keeping the base resources
separate and maintainable.
For this we can create separate overlays for other environments like production or staging by creating
additional directories with their respective kustomization.yaml files, containing specific patches or
changes.
Daemonset:
A DaemonSet ensures that all Nodes run a copy of a Pod. As nodes are added to the cluster, pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a DamonSet will clean up the Pod it created.
DaemonSets are especially useful for running cluster-level services like
- log collectors (e.g., Fluentd or Filebeat),
- monitoring agents (e.g., Prometheus Node Exporter), or
- storage daemons (e.g., Ceph RBD),
where it is necessary to have an instance of the pod on every node for monitoring, logging, or storage
purposes.
Job:
A Job creates one or more Pods & will continue retry execution of the Pods until a specified number of
them successfully terminate. As pods successfully complete, the Job tracks the successful completion.
When a specified number of successful completions is reached, the task(i.e., Job) is complete. Deleting a
job will clean up the Pods it created.
Cronjob:
A CronJob creates a Job on a reporting schedule.
ServiceAccount:
Service Accounts are commonly used to control access and permissions for Pods within the cluster. By
associating specific Service Accounts with Pods, we can fine-tune their access to various resources and
services, ensuring that each Pod operates with the least privilege principle.
A Service Account provides an identity for processes that run in a Pod. When we (human) access the cluster (Ex – Using kubectl), we are authenticated by the apiserver as a particular User Account (This is usually admin, unless our cluster admin has customized our cluster.) Processes in containers inside pods can also contact the apiserver. When they do, they are authenticated as a particular Service Account.
Kubernetes uses Role-Based Access Control (RBAC) to define what actions different Service Accounts
are allowed to perform within the cluster. By assigning appropriate roles and permissions to Service
Accounts, you can control access to resources and API endpoints.
ArgoCD:
It’s a declarative, GitOps continuous delivery tool for Kuberentes.
It follows the GitOps pattern of using Git repositories as the source of truth for defining the desired application state. K8s manifest can be specified in one of many ways for different environments & patches can be applied for customization.
Cloud Native Computing Foundation (CNCF):
The Cloud Native Computing Foundation is part of the nonprofit Linux Foundation. According to their site they support the growth and health of cloud native open source software. A few of the projects under CNCF include Kubernetes, Prometheus, and Envoy. Google is one of the top contributors to CNCF.
Container:
Containers are often compared to virtual machines (VMs) as they both offer a way to package an application together with libraries and other dependencies.However, instead of virtualizing the hardware stack like VMs, containers do it at the operating system level. Containers wrap the code of an application as well as the other dependencies it needs when running. An app container is specifically used for running an application as opposed to an init container that runs separately with initialization instructions for an entire workload.
Container Runtime:
The container runtime is software that runs the containers. Kubernetes supports several container runtimes: Docker, containerd, CRI-O, and any implementation of the Kubernetes CRI (Container Runtime Interface). The most popular container runtime today is Docker.
Containerd:
An open-source container runtime that is part of CNCF. It is a daemon for Linux and Windows that manages the container lifecycle of its host system. It takes care of image transfer and storage, container execution and supervision, providing network access, and more. You can read more about it here https://containerd.io/.
Docker
Is the most popular container runtime, a software that runs containerization of applications. Using the resource isolation features of the Linux kernel, namespaces and cgroups, Docker allows independent containers to run within a single Linux instance. When Kubernetes schedules a pod to a node, Docker
is instructed by the kubelet running on that node to launch the containers.
Microservices
This is a strategy for developing software where an application is organized as a group of loosely connected services. It is focused on building simpler modules that make up the entirety of a software application. Implementing microservices allows changes that need to be made to be done in smaller
chunks where some of the modules don’t even need to be touched. You can also scale specific pieces of an application instead of the entire thing.
Cluster
A cluster is a set of nodes, or worker machines, that containerized applications run on. These nodes can be physical machines or virtual machines. If you are running Kubernetes you are running a cluster. A cluster will have at least one node.
Controller
Kubernetes has a group of control loops that monitor the state of your cluster and try to make djustments to keep the cluster as close as possible to the desired state. These are called controllers in Kubernetes. A few of these controllers are located in the control plane and are core to operating Kubernetes. Some examples of these controllers are the deployment controller, daemonset controller, the namespace controller, and the persistent volume controller.
Manifests
A manifest in Kubernetes is typically a JSON or YAML file that is used to specify a desired state of a Kubernetes API object. Once a manifest is applied Kubernetes will maintain the specifications set of the Kubernetes object configured. They are used to create, modify, and delete objects like pods, deployments, services or ingresses.
Workload
An application running on Kubernetes. They are divided into different types, the most popular ones being: Deployments, StatefulSets, DaemonSets, Jobs, and CronJobs.
Kubernetes API
Core to Kubernetes is a RESTful API that is used to handle every operation involving changing objects in your cluster. It is responsible for storing the state of your cluster and provides a declarative way for users to configure their cluster objects. Everything in Kubernetes is treated as an API object. The Kubernetes API can be interacted with directly, but the more popular way of interacting with it is using the command line interface to Kubernetes called Kubectl.
Dynamic Volume Provisioning
Utilizing a Kubernetes API object, StorageClass, storage volumes can be automatically provisioned by user request instead of being pre-provisioned.
Ephemeral Container
These are a newer type of container that can run temporarily in an existing Pod. These shouldn’t be used to run any part of the workload, but can be very helpful for specific use cases. For example, they can be used as a foundation to attach a debugging container to your main process to investigate a problematic
Pod.
Horizontal Pod Autoscaler
Also called HPA, this is an API resource that scales the number of pod replicas. Typically DevOps use CPU and memory thresholds to increase or decrease the number of pod replicas. Horizontal Pod Autoscaler can also use custom metric thresholds as well.
HotAliases
HostAliases is an optional mapping between the IP address and hostname to be injected into a Pod’s host file if specified. They are only valid for non- hostNetwork Pods
Init Container
Sometimes in your cluster it will be important to prepare a pod before app containers deploy to it and start running your application. An initialization container, or init container for short, are perfect for this. They are similar to app containers except that they must complete successfully before app containers are allowed to run. Some use cases for using init containers are waiting a determined amount of time before starting an app container, cloning a git repository into a volume, or registering a Pod with a remote server.
Kubernetes Events
A resource type in Kubernetes that are automatically created when other resources have state changes, errors, or other messages that should broadcast to the system. There isn’t a lot of documentation available for these events, but they are very helpful when debugging issues with your cluster.
Limit Range
Pods run without constraints on the amount of CPU and memory they’ll onsume by default. Meaning any pod in the cluster can use as much CPU and memory on the node that executes that pod. LimitRange allows a user to place resource consumption constraints on containers or pods within a namespace.
Logging
Logs are the list of events that are recorded by a cluster or application. They help us understand how data is flowing through applications as well as spot when and where errors occur. In Kubernetes your application should output logs to stdout and stderr. The kubelet installed on each node will collect them
and combine them into a log file that is managed by Kubernetes.
Netowork Policy
By default, pods in Kubernetes can communicate with each other and receive traffic from any source. Network Policy is a Kubernetes resource that specifies how Pod groups are allowed to communicate with each other and with other network endpoints. Using labels, Pods are selected and traffic is configured to determine what is allowed.
Persistent Volume
In addition to managing containers that are running an application, Kubernetes can manage the application data used by a cluster. Persistent Volume, or PV for short, is a storage resource in the cluster that can outlive the life of a pod. Persistent volumes abstract the storage of data from the underlying storage infrastructure (physical disks, cloud storage, etc.). Since they outlive pods, PVs can be used to create stateful pods.
Persistent Volume Claim
Or PVC, for short, is a request for storage that can be claimed as defined in a PersistentVolume. The PVC becomes mounted as a volume in a container and specifies the amount of storage resources it needs, how it will be accessed, and how the storage resource will be reclaimed.
Pod Disruption Budget
This is also called PDB for short. It allows you to configure the amount of concurrent disruptions that can be tolerated for a class of pods ensuring you always have a determined number of pods available when disruption events occur. Whenever a disruption to a class of pods in a cluster causes the cluster to drop below the budget, the operation is paused until the budget can be maintained again.
Pod Phase
The Pod phase is a high level summary of where a Pod is at in its lifecycle. It is shown in the phase field included in the status field of a PodStatus object. There are five possible phases for a Pod:
- Pending – Kubernetes has accepted the Pod, but is waiting for the required number of Container images to be created.
- Running – All of the Containers have been created and the Pod has
- been attached to a Node. At least one of the Containers in the Pod is
- either running, or working on starting or restarting.
- Succeeded – Every Container in the Pod has successfully terminated
and are not going to restart. - Failed – Every Container in the Pod has terminated, but at least one
of them terminated in failure. It either exited with a non-zero status
or was terminated by the system. - Unknown – The state of the Pod can’t be determined, most likely due
to a failure in communicating with the Pod host.
Pod Lifecycle
There are five possible Pod phases: Pending, Running, Succeeded, Failed, and Unknown. The Pod Lifecycle is the sequence of these states that the Pod enters while it exists
Pod Priority
Some Pods are more important than others in production workloads. This feature allows you to determine the scheduling priority of a Pod giving it preference over less important Pods.
PodPreset
PodPreset is an API object that lets you inject information into Pods when they are created. The presets are managed by Admission Control which applies the Pod presets when creation requests are made. Some examples of information injected into pods with this object are secrets, volumes, volume mounts, and environment variables.
Preemption
After a pod is created it is placed in a queue. With the Pod Priority and Preemption features turned on the Kubernetes Scheduler grabs a pod from the queue and attempts to schedule the pod on a node in the cluster. If a pod cannot be scheduled the Kubernetes Scheduler uses Preemption logic to terminate lower priority Pods to allow the scheduling of the pending Pod
Proxy
In computing, a proxy is a server that acts as an intermediary for a remote service. A client interacts with the proxy, the proxy copies the client’s data to the actual server, the actual server replies to the proxy, the proxy sends the actual server’s reply to the client. In Kubernetes, kube-proxy is a network proxy for performing Kubernetes networking services. It handles network communications in or out of your cluster. Each node contains kube-proxy or an equivalent implementation.
Resource Quotas
Defined by a ResourceQuota object, a Resource Quota declares restrictions that limit the total resource consumption per Namespace. The total quantity of objects allowed in a namespace can be set, in addition to limiting the total amount of memory or CPU consumption in a Namespace. This helps teams
only use their fair share of the resources in a cluster.
Service
A Kubernetes Service groups a set of pods together and offers a way to make them accessible as a network service through the DNS name of the Service. One way you can configure your Service is by using a YAML manifest. There are four types of Services in Kubernetes: ClusterIP, NodePort, LoadBalancer,
and ExternalName.
ServiceAccount
Provides an identity for processes that run in a Pod. When a process inside a Pod wants to interact with the API server it will authenticate through a particular service account. By default a Pod is automatically assigned the same service account in the same Namespace. Service accounts are granted API permissions via RBAC.
Sidecar Container
Extending support of a main container with a utility container in a Pod. Sidecar containers are paired with one or more main containers and they enhance the functionality of those main containers. An example would be using a sidecar container specifically to process system logs, or for monitoring.
StatefulSet
This is a controller in Kubernetes that manages the deployment and scaling of a set of Pods. In a StatefulSet Pods that are managed by the controller are given a unique identity. It uses this same identity when it needs to reschedule Pods.
Static Pod
Static Pods are similar to regular Kubernetes Pods, except that they are managed directly by the kubelet on a node and not the API server. This means they are ignored by the kube-scheduler and won’t be evicted when the node is drained or fails.
Storage Class
A StorageClass gives admins a way to describe the different available storage options. The key fields in a StorageClass specification are the provisioner, parameters, reclaimPolicy, and the volumeBindingMode. These can be used when a Persistent Volume belonging to the specified class needs to be dynamically provisioned. The name of a StorageClass object and be used to request the preferred storage option.
Taint
This is used when you don’t want Pods to run on a specific node or node group. You might want to do this if nodes are reserved with specialized hardware, they aren’t licensed for software running in the cluster, or other reasons. Taints tell the Kubernetes Scheduler that specific nodes are not available. Taints work hand in hand with Tolerations providing a way to take more control over which pods are scheduled to which nodes, if you find yourself needing that functionality.
Toleration
Tolerations provide a way for a pod to ignore a taint that has been applied to nodes. Tolerations are a property of the PodSpec. It is in the format of a key name, operator, a value, and an effect. To set a toleration to a specific taint the key name needs to be set to the same value as the taint’s key. You can also create a Toleration that will ignore any taint by setting operator equal to exists.
Vertical Pod Autoscaler
Also called VPA, is an infrastructure service that scales your cluster by allocating more or less cpu or memory to existing pods as opposed to the orizontal Pod Autoscaler that increases or decreases the amount of pods to scale. It can dynamically adjust based on analysis of historical resource
utilization, amount of resources available in the cluster and real-time events like OOMs.
Kubernetes Security and Organization
Admission Controller
A native Kubernetes security feature that allows you to configure what objects are allowed to run on your cluster. The admission controllers are plugins that regulate how the cluster is used. They check requests to the Kubernetes API server before allowing objects to run.
Annotation
In Kubernetes you can use either labels or annotations to give Kubernetes objects metadata. An annotation is used to apply arbitrary non-identifying metadata to objects using a key-value pair.
Label
A Label in Kubernetes is a key/value pair attached to Kubernetes objects that specify meaningful information about those objects to users. Using Labels will help you organize objects and select subsets of objects.
Name
Every Kubernetes object in your cluster has a unique Name that is a string provided by the user at creation time. These Names are used in resource URLs and can only be used by one object of a given kind at a time. Most pod names are generated by their controller.
Namespace
These act as virtual clusters. A further abstraction that provides a way to divide a physical cluster into multiple virtual clusters. It is also a way to provide organization to objects in a cluster.
Pod Security policy
A Pod Security Policy is a cluster-level resource implemented as an optional admission controller in the cluster. These policies define the conditions a Pod must meet to be allowed into the system.
RBAC
Role-Based Access Control, or RBAC for short, provides a way to manage different levels of access in your Kubernetes cluster through the Kubernetes API. With multiple users or services accessing the cluster they will have different permission needs and should be limited to only the permissions
required to perform their function. RBAC, as the name implies, leverages roles which grant the necessary level of access to sets of users in your cluster.
Secret
Often a Kubernetes Pod will need to leverage sensitive information like passwords, API keys, ssh keys, OAuth tokens, and more. A Secret is a Kubernetes object that stores this confidential information so that Pods can use it without the data being shown. Secrets are exposed to containers either as a
file in a volume mount or through environment variables.
Security Context
Setting the securityContext field defines the access control settings in Kubernetes. This field configures the user that processes run as, the group that processes run as, and privilege settings.Two levels of Security Context exist in Kubernetes: pod level security context, and container level security context.
Setting the security context on the pod level applies to all containers in the Pod. Whereas container level security context settings apply to the specific container.
Selector
A Label in Kubernetes is a key/value pair that is attached to Kubernetes objects that specify meaningful information about those objects to users. Selectors are used when querying or filtering a list of Kubernetes objects based on the labels that have been created.
UID
Short for unique ID, the UID in Kubernetes is a string generated by the system that uniquely identifies every object created in the entire lifetime of the Kubernetes cluster.
Kubernetes Tools and Extensions
Add-ons
These are tools that give Kubernetes additional features. Examples of some popular ones include: Calico, Flannel, Dashboard, and Weave Scope.
Managed Service
A third party maintained resource used by an application. Some examples of Managed Services are AWS EC2, AWS EKS, Azure SQL Database, and GCP Pub/Sub. Many of the managed services useful for a Kubernetes cluster can be provisioned using Service Catalog directly from the native Kubernetes
tooling.
Amazon EKS
Amazon EKS stands for Amazon Elastic Kubernetes Service. It launched in 2018 and is AWS’s managed service of the Kubernetes control plane in your cluster.
Azure Kubernetes Service (AKS)
The managed Kubernetes service offered by Microsoft in Azure
Kubeadm
A toolkit for quickly setting up a minimal viable Kubernetes cluster no matter where you are running them. However, unlike a tool like Kops, it cannot create your infrastructure so is only really useful on existing infrastructure.
Minikube
Minikube is best utilized as a tool to test out and learn about Kubernetes. It is meant for running Kubernetes locally inside a VM on your computer. It runs a single-node cluster on this VM
Container Network Interface (CNI)
Container network interface (CNI) is a container networking specification proposed by CoreOS and adopted by projects like Apache Mesos, Kubernetes, Kurma, and rkt. It is the simplest possible interface between container runtime and network implementation. CNI plugins are a type of network plugin that
adheres to the appc/CNI specification.
Container Runtime Interface (CRI)
The container runtime interface (CRI) is an API which enables kubelet to use a variety of container runtimes without the need to recompile.
Container Storage Interface (CSI)
The Container Storage Interface or CSI is an initiative defining a standard interface to expose storage systems to container orchestrator systems (COs). This allows COs to work with all storage vendors like Ceph, NetApp, Portworx, EBS, and more. It lets storage vendors create custom storage plugins for Kubernetes, and other COs, without specifically adding them to the Kubernetes repository.
CRI-O
According to their site, CRI-O is a “lightweight container runtime for Kubernetes.” It is a tool that allows you to use any Open Container Initiative (OCI) compatible runtimes. It is a lightweight alternative to Docker.
Google Kubernetes Engine (GKE)
GKE is a managed Kubernetes service offered in Google Cloud.
Helm
Is an open source free package manager for Kubernetes. Think of it like Homebrew for Kubernetes. It helps you define, install, and update your Kubernetes application. Helm is maintained by the Helm community and is part of the CNCF incubator.
Helm Chart
A helm chart is the format that Helm uses to package a group of pre- configured Kubernetes resources. A chart could encompass something as simple as a single pre-configured Kubernetes Pod all the way to a full web app stack.
Istio
An open source service mesh and platform, including APIs, that helps simplify running a distributed microservice architecture. It is not specific to Kubernetes. Istio provides core features as a layer of infrastructure between a service and the network. Some of them are: traffic management, security, and
observability into your service mesh deployment.
Kops
Short for Kubernetes operations, kops is a CLI tool that was specifically created by the Kubernetes on AWS community. It allows you to install, upgrade, and manage your Kubernetes cluster. It significantly simplifies cluster creation and operations compared to manually getting started.
