User Tools

Site Tools


k8s:core:kind

Kubernetes ''kind'' Field — Complete Guide

Overview

In Kubernetes, every resource manifest (written in YAML or JSON) must declare four top-level fields:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  ...

The kind field tells Kubernetes what type of resource you are creating or managing. It maps to a specific API object within Kubernetes, and each kind has its own schema, behavior, and lifecycle.


Core Resource Kinds

1. Pod

The smallest deployable unit in Kubernetes. A Pod wraps one or more containers that share network and storage.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.25
      ports:
        - containerPort: 80
Field Description
kind Pod — declares a single pod resource
metadata Name and labels for identifying the pod
spec.containers List of containers inside the pod
Note: Pods are rarely created directly. Use Deployments or StatefulSets instead for resilience.

2. Deployment

Manages a ReplicaSet to ensure a specified number of Pod replicas are running at all times. Supports rolling updates and rollbacks.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web
          image: nginx:1.25
          ports:
            - containerPort: 80
Field Description
kind Deployment — manages a set of identical pods
replicas Number of desired Pod instances
selector Labels used to identify which Pods belong here
template Pod template used to create new Pods

3. Service

Exposes a set of Pods as a stable network endpoint. Handles load balancing across all matching Pods.

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP
Service Type Description
ClusterIP Default. Internal cluster access only
NodePort Exposes on each node's IP at a static port
LoadBalancer Creates an external load balancer (cloud providers)
ExternalName Maps to an external DNS name

4. ConfigMap

Stores non-sensitive configuration as key-value pairs, decoupling config from container images.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: production
  APP_PORT: "8080"
  log_level: info

Use in a Pod:

envFrom:
  - configMapRef:
      name: app-config

5. Secret

Like ConfigMap, but for sensitive data (passwords, tokens, TLS certs). Values are base64-encoded.

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=        # base64 of "admin"
  password: cGFzc3dvcmQ=   # base64 of "password"
Security note: base64 is encoding, not encryption. Use tools like Sealed Secrets or Vault for production.

6. StatefulSet

Like Deployment, but designed for stateful applications (databases, message queues) that need:

  • Stable, persistent network identity
  • Ordered, graceful deployment and scaling
  • Persistent storage per pod
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql"
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - name: mysql
          image: mysql:8.0
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: "secret"
          volumeMounts:
            - name: data
              mountPath: /var/lib/mysql
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 10Gi

7. DaemonSet

Ensures a copy of a Pod runs on every node (or selected nodes). Used for cluster-level services like log collectors, monitoring agents, or network plugins.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      containers:
        - name: fluentd
          image: fluent/fluentd:v1.16

8. Job

Runs a one-off task to completion. Kubernetes ensures the Pod runs successfully at least once.

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration
spec:
  template:
    spec:
      containers:
        - name: migrate
          image: myapp:latest
          command: ["python", "manage.py", "migrate"]
      restartPolicy: OnFailure

9. CronJob

Runs Jobs on a scheduled (cron) basis.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-job
spec:
  schedule: "0 2 * * *"   # Every day at 2:00 AM
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: backup
              image: backup-tool:latest
              command: ["/bin/sh", "-c", "run-backup.sh"]
          restartPolicy: OnFailure

10. Namespace

Creates a virtual cluster within a Kubernetes cluster, providing isolation between teams or environments.

apiVersion: v1
kind: Namespace
metadata:
  name: staging

11. PersistentVolumeClaim (PVC)

Requests persistent storage from the cluster for a Pod.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-storage
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

12. Ingress

Manages external HTTP/HTTPS access to services, routing rules, TLS termination.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Summary Table

Kind API Version Purpose
Pod v1 Smallest deployable unit
Deployment apps/v1 Stateless app, rolling updates
StatefulSet apps/v1 Stateful app with stable identity
DaemonSet apps/v1 One pod per node
Job batch/v1 One-off task
CronJob batch/v1 Scheduled recurring task
Service v1 Network endpoint for pods
Ingress networking.k8s.io/v1 HTTP routing / TLS termination
ConfigMap v1 Non-sensitive config data
Secret v1 Sensitive config data
Namespace v1 Cluster isolation
PersistentVolumeClaim v1 Request for persistent storage

How ''kind'' Connects to ''apiVersion''

The apiVersion determines which API group and version handles your kind:

apiVersion Kinds included
v1 Pod, Service, ConfigMap, Secret, Namespace, PVC
apps/v1 Deployment, StatefulSet, DaemonSet, ReplicaSet
batch/v1 Job, CronJob
networking.k8s.io/v1 Ingress, NetworkPolicy
rbac.authorization.k8s.io/v1 Role, ClusterRole, RoleBinding

Here's the relationship diagram.

Hierarchy flows top-down:

Deployment → ReplicaSet → Pod (Deployment manages replicas, which manage pods)

StatefulSet and DaemonSet go straight to their own Pods

CronJob → Job (CronJob triggers Jobs on a schedule)

Networking routes traffic inward:

Ingress → Service → Pod (external HTTP traffic funneled down to running containers)

NetworkPolicy applies traffic rules at the Pod level

Config and Storage are mounted into Pods:

ConfigMap and Secret are injected as env vars or volume mounts (dashed lines)

PVC (PersistentVolumeClaim) binds to a PV (PersistentVolume) and mounts into Pods

Everything lives inside a `Namespace for isolation.

See Also

k8s/core/kind.txt · Last modified: by phong2018