In my previous blog, I summarized my understanding of the Kubernetes Architecture. In this one, I would like to discuss the different objects that make K8s into a functioning unit.
Nodes
Nodes are the computers (real or virtual) that do the heavy lifting in a Kubernetes cluster. They run your applications inside pods. Each node has a few key pieces: the kubelet (which takes orders from the kube-api-server), the container runtime (like Docker, rkt, etc.), and the kube-proxy (which handles networking).
Pods
Pods are like little boats that carry your containers in Kubernetes. They’re the smallest units you can manage in K8s. A pod can hold one or more containers that need to work together. Think of a pod as a single unit of your microservice.
For example:
apiVersion: v1 # Specifies the API version used to create this object
kind: Pod # Specifies that this is a Pod object
metadata:
name: example-pod # The name of the Pod
labels:
app: myapp # Labels are key/value pairs that can be used to identify and organize Pods
spec:
containers:
- name: myapp-container # The name of the container within the Pod
image: nginx:latest # The Docker image to use for this container
ports:
- containerPort: 80 # Exposes port 80 from the container to the Pod
Namespace
A Namespace is like a folder that helps you organize your stuff in Kubernetes. It’s a way to separate different projects or environments (like testing and production) within the same cluster. This makes it easier to manage resources and access.
Example:
apiVersion: v1 # Specifies the API version used to create this object
kind: Namespace # Specifies that this is a Namespace object
metadata:
name: example-namespace # The name of the Namespace
labels:
environment: dev # Labels are key/value pairs that can be used to identify and organize Namespaces
ReplicaSet
A ReplicaSet is like a babysitter for your pods. It keeps an eye on them to make sure you always have the right number running. If one pod goes down, the ReplicaSet quickly starts a new one. It’s there to ensure your application is always available.
Example:
apiVersion: apps/v1 # Specifies the API version used to create this object
kind: ReplicaSet # Specifies that this is a ReplicaSet object
metadata:
name: example-replicaset # The name of the ReplicaSet
labels:
app: myapp # Labels are key/value pairs that can be used to identify and organize ReplicaSets
spec:
replicas: 3 # The number of Pod replicas to maintain
selector:
matchLabels:
app: myapp # Selects Pods with the label "app: myapp"
template: # Template for the Pods to be created by this ReplicaSet
metadata:
labels:
app: myapp # Labels to apply to the Pods created by this ReplicaSet
spec:
containers:
- name: myapp-container # The name of the container within the Pod
image: nginx:latest # The Docker image to use for this container
ports:
- containerPort: 80 # Exposes port 80 from the container to the Pod
Deployment
A Deployment is like the manager for your application updates. It helps you roll out new versions, scale up or down, and go back to previous ones if something goes wrong. It takes care of creating and managing ReplicaSets for you.
Example:
apiVersion: apps/v1 # Specifies the API version used to create this object
kind: Deployment # Specifies that this is a Deployment object
metadata:
name: example-deployment # The name of the Deployment
labels:
app: myapp # Labels are key/value pairs that can be used to identify and organize Deployments
spec:
replicas: 3 # The number of Pod replicas to create
selector:
matchLabels:
app: myapp # Selects Pods with the label "app: myapp"
template: # Template for the Pods to be created by this Deployment
metadata:
labels:
app: myapp # Labels to apply to the Pods created by this Deployment
spec:
containers:
- name: myapp-container # The name of the container within the Pod
image: nginx:latest # The Docker image to use for this container
ports:
- containerPort: 80 # Exposes port 80 from the container to the Pod
Service
A Service is like a traffic director for your pods. It gives them a stable IP address and DNS name so that other parts of your application can find and talk to them easily, even if the pods move around or change.
Example:
apiVersion: v1 # Specifies the API version used to create this object
kind: Service # Specifies that this is a Service object
metadata:
name: example-service # The name of the Service
labels:
app: myapp # Labels are key/value pairs that can be used to identify and organize Services
spec:
selector:
app: myapp # Selects Pods with the label "app: myapp"
ports:
- protocol: TCP # The protocol used by the Service (TCP/UDP)
port: 80 # The port that will be exposed by the Service
targetPort: 80 # The port on the Pod that the Service will forward traffic to
type: ClusterIP # The type of the Service (ClusterIP, NodePort, LoadBalancer, etc.)
ConfigMap
A ConfigMap is a way to keep your configuration settings separate from your application code. It stores key-value pairs that your pods can use, making it easy to change settings without having to rebuild your containers. This keeps your setup flexible.
Example:
apiVersion: v1 # Specifies the API version used to create this object
kind: ConfigMap # Specifies that this is a ConfigMap object
metadata:
name: example-configmap # The name of the ConfigMap
labels:
app: myapp # Labels are key/value pairs that can be used to identify and organize ConfigMaps
data:
# Key-value pairs of configuration data
database_url: "mongodb://localhost:27017/mydb"
database_user: "admin"
database_password: "secret"
Secrets
Secrets are like ConfigMaps but for sensitive data. They securely store things like passwords, tokens, and keys so that they aren’t exposed in plain text. This helps keep your important information safe.
For example:
apiVersion: v1 # Specifies the API version used to create this object
kind: Secret # Specifies that this is a Secret object
metadata:
name: example-secret # The name of the Secret
labels:
app: myapp # Labels are key/value pairs that can be used to identify and organize Secrets
type: Opaque # The type of Secret; Opaque is a common type for arbitrary user-defined data
data:
# Key-value pairs of secret data, base64-encoded
username: YWRtaW4= # "admin" base64-encoded
password: c2VjcmV0 # "secret" base64-encoded
DaemonSets
A DaemonSet makes sure that a specific pod runs on every node in your cluster. This is useful for tasks like logging or monitoring, where you need the same thing running everywhere. When new nodes join, the DaemonSet makes sure they get the pod too.
Example:
apiVersion: apps/v1 # Specifies the API version used to create this object
kind: DaemonSet # Specifies that this is a DaemonSet object
metadata:
name: example-daemonset # The name of the DaemonSet
labels:
app: myapp # Labels are key/value pairs that can be used to identify and organize DaemonSets
spec:
selector:
matchLabels:
app: myapp # Selects Pods with the label "app: myapp"
template: # Template for the Pods to be created by this DaemonSet
metadata:
labels:
app: myapp # Labels to apply to the Pods created by this DaemonSet
spec:
containers:
- name: myapp-container # The name of the container within the Pod
image: nginx:latest # The Docker image to use for this container
ports:
- containerPort: 80 # Exposes port 80 from the container to the Pod
Static Pods
Static Pods are a bit special because they’re managed directly by the node’s kubelet, not by the central Kubernetes system. They’re defined in a file on the node and are usually used for essential system tasks. They’re not for most user applications but are important for certain administrative jobs.
Example:
This YAML file is needed to run on the individual node as the kube-api-server will have no idea of its existence.
apiVersion: v1 # Specifies the API version used to create this object
kind: Pod # Specifies that this is a Pod object
metadata:
name: example-static-pod # The name of the Pod
labels:
app: myapp # Labels are key/value pairs that can be used to identify and organize Pods
spec:
containers:
- name: myapp-container # The name of the container within the Pod
image: nginx:latest # The Docker image to use for this container
ports:
- containerPort: 80 # Exposes port 80 from the container to the Pod