Understanding Basic Kubernetes Components

Introduction

In our previous article, we setup our Kubernetes cluster and setup Cilium as the CNI. Today, we will understand the basic components of Kubernetes by deploying our first pods and services. You can choose whatever service you want to deploy, but for the sake of this guide i chose paperless-ngx as our demo service, so let’s get started.

There are numerous Kubernetes components, and we’ll go though all of them in due time. To start off, we’ll look over a diagram of an almost comprehensive Kubernetes setup. note that everything that is colored in this diagram represents a Kubernetes component, so the only thing you don’t define or configure in YAML are the containers themselves, but we’ll get into that in a bit.

![[k8s-componments.png]]

Now i know this is a lot, but we’ll take all of this in piece-meal, so let’s get started with a high level view of our diagram:

We can categorize everything in our diagram into the following:

• Namespace

• Runtime related components:

  • Pod
  • Service *
  • Volume Claims (PVC and VolumeClaimTemplates)
  • HostPath
  • Deployment
  • StatefulSet
  • DaemonSet
  • Job
  • CronJob
  • Secret
  • ConfigMap

[!NOTE] A big thing with Kubernetes is abstraction:

• Pods abstract containers; Pods can orchestrate multiple containers.
• Deployments, StatefulSets and DaemonSets orchestrate and abstract Pods, as well as services.

• Networking:

  • Service *
  • Ingress
  • IngressController

• IAM:

  • ServiceAccount
  • Rolebinding
  • NetworkPolicy

• Scaling:

  • HorizontalPodAutoscaler
  • KEDA *

• Storage:

  • StorageClass

*1 : The Service component can technically be considered both a networking and a runtime component. *2 : KEDA is a bit advanced and will not be covered in this guide, but may garner it’s own guide in the future. we will focus on HPA.

To start, We’ll go over the components we need to deploy our service.

Understanding The layout of Our Deployment.

First off, let’s list off the components we will need today:

• Pod components to configure or containers.
• Service components to configure connectivity between pods.
• Deployment components to configure our pod-service combos.
• A ConfigMap component to house non-secret configuration options.
• A Secret component to house secrets.
• Ingress and IngressController components to handle incoming traffic.
• StorageClass and PersistentVolume components to create persistent disks for our pods to use.

Now, all Kubernetes components share the same starting YAML snippet, containing apiVersion, Kind and Metadata, and looks like this:

apiVersion: v1
Kind: <Component Type>
metadata:
  name: <Component Name>
# This line is component specific, but almost always either data: or spec:
spec:

Let’s get started with the simplest components: ConfigMap and Secret.

ConfigMap and Secret

99% of apps need to have configuration properties passed into them almost always as environment variables. The most common case of this are database credentials and/or connection strings, and that’s the job that ConfigMap and Secret were made to handle.

• ConfigMap stores configuration options that don’t contain sensitive data, and it’s template looks like this:

apiVersion: v1
Kind: ConfigMap
metadata:
  name: <Component Name>
data:
  <KEY>: <VALUE>

• Secret is much like ConfigMap, but obscures whatever properties it contains, so it’s useful for sensitive data like passwords and the like. It’s template looks like this:

apiVersion: v1
Kind: Secret
metadata:
  name: <Component Name>
data:
  <KEY>: <VALUE>

Deployments

Like we already mentioned, Deployment, StatefulSets and DaemonSets are all components that orchestrate pods, but they are different types of pods, so most of this code can apply to each of them, with some important caveats.

Usually, Deployments contain configurations for Pods, their corresponding services, their persistent storage as well as other things.