Comprehensive Kubernetes Guide

Table of Contents

1. Introduction to Kubernetes
2. Kubernetes Architecture
3. Core Components
4. Kubernetes Object Hierarchy
5. Kubernetes Objects and Resources
   • Pods
   • ReplicaSets
   • Deployments
   • Services
   • ConfigMaps and Secrets
   • Volumes, PVs and PVCs
   • Horizontal Pod Autoscaler (HPA)
6. Identity and Access Management
7. Essential kubectl Commands
8. Networking in Kubernetes
9. Best Practices

Introduction to Kubernetes

Kubernetes (K8s) is an open-source container orchestration platform for automating deployment, scaling, and management of containerized applications. It was originally developed by Google and is now maintained by the Cloud Native Computing Foundation (CNCF).

Key Features of Kubernetes

• Automated deployment and rollbacks
• Service discovery and load balancing
• Self-healing capabilities
• Horizontal scaling
• Configuration management
• Storage orchestration
• Secret and configuration management

Kubernetes Architecture

Kubernetes follows a client-server architecture composed of master components (control plane) and node components.

Control Plane Components

The control plane manages the worker nodes and the Pods in the cluster. Components include:

1. kube-apiserver: Exposes the Kubernetes API, the front-end to the Kubernetes control plane
2. etcd: Consistent and highly-available key-value store used as Kubernetes' backing store
3. kube-scheduler: Watches for newly created Pods with no assigned node, and selects a node for them
4. kube-controller-manager: Runs controller processes like node controller, endpoints controller, etc.
5. cloud-controller-manager: Interfaces with the underlying cloud providers (if applicable)

Node Components

Components that run on every node, maintaining running Pods and providing runtime environment:

1. kubelet: Ensures containers are running in a Pod
2. kube-proxy: Maintains network rules on nodes for forwarding network traffic to Pods
3. Container Runtime: Software responsible for running containers (Docker, containerd, CRI-O)

Core Components

kube-apiserver

The kube-apiserver is the front end for the Kubernetes control plane that exposes the Kubernetes API. It's designed to scale horizontally by deploying more instances.

Responsibilities:

• REST operations and validating API requests
• API registration and discovery
• Implements authentication and authorization
• Central hub for all cluster operations

etcd

etcd is a distributed key-value store that provides reliable storage for all cluster data. It serves as the single source of truth for the entire Kubernetes cluster.

Key features:

• Strong consistency guarantees
• Watch mechanism for changes
• TTL-based key expiration
• Distributed consensus using Raft algorithm
• Secure communication via TLS

kube-scheduler

The kube-scheduler is responsible for assigning newly created Pods to nodes based on resource requirements, constraints, and other factors.

Scheduling process:

1. Filter nodes that meet Pod requirements
2. Rank and score remaining nodes
3. Select the best node and bind the Pod
4. Considers resources, node selector, affinity/anti-affinity, taints/tolerations

kube-controller-manager

The kube-controller-manager runs controller processes that regulate the state of the system. Each controller is a separate process, but they are compiled into a single binary and run in a single process for simplicity.

Some important controllers:

• Node Controller: Monitors node health
• ReplicaSet Controller: Ensures correct number of Pods
• Deployment Controller: Manages deployment lifecycle
• Service Controller: Creates load balancers for Services
• Endpoint Controller: Populates Endpoints objects

cloud-controller-manager

The cloud-controller-manager interfaces with the underlying cloud provider's API to manage cloud-specific resources.

Responsibilities:

• Node Controller: Updates node information from cloud provider
• Route Controller: Sets up routes in cloud infrastructure
• Service Controller: Creates, updates, and deletes cloud provider load balancers

Kubernetes Object Hierarchy

Kubernetes has a clear hierarchy of resources and objects.

A more detailed view of container-pod-node hierarchy:

Kubernetes Objects and Resources

Pods

Pods are the smallest deployable units in Kubernetes that can be created and managed. A Pod represents a single instance of a running process in your cluster and contains one or more containers.

Key features:

• Shared network namespace (containers can communicate via localhost)
• Shared storage volumes
• Always scheduled on the same node
• Ephemeral - not designed to survive failures

Example Pod YAML:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.19
    ports:
    - containerPort: 80

ReplicaSets

ReplicaSets ensure that a specified number of Pod replicas are running at any given time. It's the mechanism behind self-healing in Kubernetes.

Key features:

• Ensures a specified number of replicas are running
• Uses a selector to identify which Pods to manage
• Creates new Pods if existing ones are deleted or terminated
• Usually managed by Deployments

Example ReplicaSet YAML:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19

Deployments

Deployments provide declarative updates for Pods and ReplicaSets. They allow you to describe an application's lifecycle, including upgrades, rollbacks, scaling, and more.

Key features:

• Declarative updates
• Rolling updates and rollbacks
• Scaling
• Pause and resume
• Revision history

Example Deployment YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19
        ports:
        - containerPort: 80

Services

Services define a logical set of Pods and a policy for accessing them. They enable network access to a set of Pods, providing stable endpoints.

Service types:

• ClusterIP: Internal only, accessible within the cluster
• NodePort: Exposes the service on each Node's IP at a static port
• LoadBalancer: Exposes service externally using cloud provider's load balancer
• ExternalName: Maps service to an external name via DNS

Example Service YAML:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

ConfigMaps and Secrets

ConfigMaps and Secrets store configuration data separately from application code.

ConfigMaps

ConfigMaps store non-sensitive configuration data in key-value pairs.

Example ConfigMap YAML:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_url: "mysql://db:3306/mydb"
  app_mode: "production"
  config.json: |
    {
      "key": "value",
      "logging": true
    }

Secrets

Secrets store sensitive information like passwords, tokens, and keys.

Example Secret YAML:

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=  # base64 encoded "admin"
  password: cGFzc3dvcmQxMjM=  # base64 encoded "password123"

Volumes, Persistent Volumes and Persistent Volume Claims

Volumes

Volumes in Kubernetes provide a way for containers in a Pod to share files and persist data beyond the container lifecycle.

Volume types:

• emptyDir: Empty directory created when a Pod is assigned to a node
• hostPath: Mounts a file or directory from the host node's filesystem
• configMap: Provides a way to inject configuration data
• secret: Used to pass sensitive information to Pods
• persistentVolumeClaim: Claims a PersistentVolume for Pod use

Persistent Volumes and Persistent Volume Claims

PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs) provide storage resources in a cluster that have a lifecycle independent of any Pod.

Example PV YAML:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-storage
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
  hostPath:
    path: "/mnt/data"

Example PVC YAML:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard

Horizontal Pod Autoscaler (HPA)

The Horizontal Pod Autoscaler automatically scales the number of Pods in a deployment, replicaset, or statefulset based on observed CPU utilization or other metrics.

Key features:

• Automatically scales Pods based on metrics
• Supports CPU, memory, and custom metrics
• Configurable scaling behavior (min, max replicas)
• Customizable scaling algorithms

Example HPA YAML:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80

Identity and Access Management

Kubernetes uses a combination of authentication, authorization, and admission control to secure the API server.

Role-Based Access Control (RBAC)

RBAC is a method of regulating access based on the roles of users within the organization.

Key components:

• Role: Permissions within a namespace
• ClusterRole: Cluster-wide permissions
• RoleBinding: Assigns Role to users in a namespace
• ClusterRoleBinding: Assigns ClusterRole to users cluster-wide

Example Role and RoleBinding YAML:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Essential kubectl Commands

kubectl is the command-line tool for interacting with the Kubernetes API.

Cluster Information

# Get cluster info
kubectl cluster-info

# Check component status
kubectl get componentstatuses

# View nodes
kubectl get nodes
kubectl describe node <node-name>

Working with Pods

# List pods
kubectl get pods
kubectl get pods -o wide
kubectl get pods --all-namespaces

# Create a pod from YAML
kubectl apply -f pod.yaml

# Describe pod details
kubectl describe pod <pod-name>

# Execute command in pod
kubectl exec -it <pod-name> -- /bin/bash

# Get pod logs
kubectl logs <pod-name>
kubectl logs <pod-name> -c <container-name>  # For multi-container pods

# Delete pod
kubectl delete pod <pod-name>

Deployments

# Create a deployment
kubectl create deployment nginx --image=nginx

# List deployments
kubectl get deployments

# Scale a deployment
kubectl scale deployment nginx --replicas=3

# Update a deployment
kubectl set image deployment/nginx nginx=nginx:1.19

# Rollback a deployment
kubectl rollout undo deployment/nginx

# Check rollout status
kubectl rollout status deployment/nginx

# View rollout history
kubectl rollout history deployment/nginx

Services

# Create a service
kubectl expose deployment nginx --port=80 --target-port=80

# List services
kubectl get services

# Describe a service
kubectl describe service nginx

# Delete a service
kubectl delete service nginx

ConfigMaps and Secrets

# Create configmap
kubectl create configmap app-config --from-file=config.properties

# Create secret
kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password=password123

# List configmaps and secrets
kubectl get configmaps
kubectl get secrets

Namespaces

# Create namespace
kubectl create namespace development

# Set default namespace
kubectl config set-context --current --namespace=development

# List resources in all namespaces
kubectl get pods --all-namespaces

Context and Configuration

# View kubeconfig
kubectl config view

# Get current context
kubectl config current-context

# Switch context
kubectl config use-context <context-name>

Resource Management

# Apply resources from directory
kubectl apply -f ./dir

# Delete resources
kubectl delete -f ./dir

# Explain resource
kubectl explain pods
kubectl explain pods.spec.containers

Networking in Kubernetes

Kubernetes networking addresses four primary concerns:

1. Pod-to-Pod Communication: Pods on the same node communicate via local interfaces; pods on different nodes communicate through overlay networks
2. Pod-to-Service Communication: Services provide stable endpoints for pods
3. External-to-Service Communication: External traffic reaches services through NodePort, LoadBalancer, or Ingress
4. Node-to-Node Communication: Nodes communicate with each other for pod networking and cluster operations

Network Policies

Network Policies specify how groups of pods are allowed to communicate with each other and other network endpoints.

Example NetworkPolicy YAML:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 80

Best Practices

Resource Management

• Set resource requests and limits for containers
• Implement Horizontal Pod Autoscaling
• Use namespaces to organize resources

Security

• Follow the principle of least privilege using RBAC
• Use network policies to restrict pod communication
• Secure etcd with TLS
• Use Pod Security Policies or Pod Security Standards
• Regularly update and scan your images for vulnerabilities

High Availability

• Deploy multiple replicas of applications
• Use anti-affinity rules to distribute pods across nodes
• Implement readiness and liveness probes
• Design for failure and recovery

Monitoring and Logging

• Implement centralized logging with tools like EFK or ELK
• Set up monitoring with Prometheus and Grafana
• Use distributed tracing for microservices

CI/CD Integration

• Implement GitOps workflow with tools like Flux or ArgoCD
• Automate deployments and rollbacks
• Implement canary deployments or blue-green deployments