Briefing Document: Kubernetes Concepts and Objects
I. Introduction
This document summarizes key concepts and objects within Kubernetes, as presented in the provided "Kubernetes Guide by sushant.pdf" excerpts. The guide covers fundamental elements for deploying and managing applications within a Kubernetes cluster.
II. Core Benefits of Kubernetes
The guide highlights several core advantages of using Kubernetes:
Automated Container Management: "Auto start of container" This signifies that Kubernetes automatically handles container startup and lifecycle management.
Health Checks & Auto-Healing: "Health check" and "Auto-healing" show Kubernetes monitors application health and automatically restarts failed containers or pods.
Scalability & Load Balancing: "Autoscaling" and "Load balancing" indicate that Kubernetes can automatically adjust the number of application instances based on demand and distribute traffic evenly.
Network Management: "Network" points to Kubernetes' capabilities in managing complex networking needs within and outside the cluster.
Node Allocation: "Auto-node allocating" shows Kubernetes can automatically allocate resources to new nodes.
Deployment Management: "Updates/new release/deployment" Highlights Kubernetes' ability to manage application updates and new deployments.
Secure Configuration: "Secrete / config (master node)" Indicates that Kubernetes provides methods for managing sensitive data and configurations.
III. Key Kubernetes Objects
The document provides detailed explanations and examples of various Kubernetes objects, which are essential for building and managing applications.
1. Pod
Definition: "The smallest and simplest Kubernetes object, representing a single instance of a running process in your cluster."
Purpose: Groups one or more containers that share the same network namespace and storage volumes.
Key Features:
Containers within a pod share an IP address and port space.
Pods are ephemeral; they can be deleted, and new ones are created with a different IP.
Example: The provided example shows a basic pod definition using apiVersion: v1, kind: Pod, and defining a container running an Nginx image.
2. Service
Definition: "A stable, permanent endpoint to access one or more pods."
Purpose: Provides load balancing and service discovery for pods, abstracting away the dynamic nature of Pod IPs.
Key Features: * Types: "ClusterIP (default), NodePort, LoadBalancer, ExternalName." * Abstracts the dynamic nature of pod IPs.
Example: The example defines a service using apiVersion: v1 and kind: Service. It includes a selector to target specific pods with the label app: my-app and specifies port mappings. It uses type ClusterIP
3. Volume
Definition: "A way to provide persistent storage to containers running inside a pod."
Purpose: Allows data to persist beyond the lifetime of a pod and share data between containers in a pod.
Key Features:Types include: "emptyDir, hostPath, NFS, ConfigMap, Secret, PersistentVolume, PersistentVolumeClaim."
Decouples storage from pod lifecycle.
Example: The example in the document demonstrates mounting an emptyDir volume, named my-volume, to /data directory in the container.
4. Network
Definition: "Refers to Kubernetes networking objects and policies that manage communication within and outside the cluster."
Purpose: Enables communication between pods, services, and external resources.
Key Features:Each pod gets a unique IP address.
Supports network policies for controlling traffic flow using CNI plugins (e.g., Calico, Flannel).
Example: The example shows a Network Policy that allows traffic to a pod labelled app: my-app from pods labelled app: allowed-app
5. ConfigMap
Definition: "Stores configuration data as key-value pairs."
Purpose: Separates configuration from application code.
Key Features: * Data injected as environment variables, command-line arguments, or mounted files. * Non-sensitive data storage
Example: The example shows a basic configmap using apiVersion: v1, kind: ConfigMap, storing simple key-value pairs.
6. Ingress
Definition: "Manages external HTTP/S access to services within the cluster."
Purpose: Acts as a reverse proxy and load balancer, providing custom URLs and SSL/TLS termination.
Key Features: * Provides routing rules based on hostnames and paths. * Requires an ingress controller.
Example: The document provides an example of defining ingress rules using apiVersion: networking.k8s.io/v1, kind: Ingress for directing traffic based on a hostname and path.
IV. Kubernetes Installation
The guide outlines a basic installation process for a master and worker node using kubeadm:
Prepare Nodes: Launch two Ubuntu servers, a master node and a worker node.
Install Dependencies: Update packages and install docker.io, kubectl, kubeadm, and kubelet.
Initialize Master: Run kubeadm init on the master node.
Configure kubectl: Configure kubectl on the master node by copying the admin config file.
Install CNI: Apply a CNI like Calico for networking.
Generate Join Command: Create a token for worker nodes to join the cluster.
Join Worker Nodes: Use the kubeadm join command on worker nodes.
V. Pod Creation and Management
The guide demonstrates basic pod management using kubectl:
Create a pod using a YAML file (kubectl apply -f).
View pod details with kubectl get pods, kubectl describe pod, and kubectl logs pod_name.
Execute commands inside a pod using kubectl exec -it.
VI. Services: NodePort and Load Balancing
NodePort: A basic service type that exposes the service on each node's IP at a static port (e.g., 30001).
Load Balancing: Implemented using cloud provider load balancers (e.g., in AWS) to distribute traffic across multiple nodes. The guide outlines creating a target group to connect to the service.
VII. ReplicationController
Purpose: Ensures a specified number of pod replicas are running.
Functionality: Automatically recreates pods if they fail. Demonstrates scaling using kubectl scale rc.
The guide shows practical exercises for manipulating replication controllers including deleting and scaling pods.
VIII. ReplicaSet
Purpose: Similar to ReplicationController but more flexible with selector usage. It supports set-based selectors.
The document shows how to apply replicaset yaml files, and also how to use selectors to show pods
IX. Deployment
Purpose: A higher-level object to manage ReplicaSets.
Key Features: Provides rolling updates, batch updates, and rollback functionalities.
Functionality: Rolling updates using kubectl set image and kubectl rollout history. Shows how to rollback using the undo command and annotate the deployments.
Health Checks: Introduction of liveness, readiness, and startup probes is introduced.
X. Health Probes
Liveness Probe: Determines when to restart a container if it's unresponsive.
Readiness Probe: Determines when a container is ready to accept traffic.
Startup Probe: Validates that an application is started.
XI. Namespace
Purpose: Provides isolation of resources within a cluster.
Key Features: Names of resources must be unique within a namespace, but not across namespaces.
Demonstrates namespace management using kubectl create namespace, kubectl apply -f and switching namespaces via contexts using kubectl config.
XII. Volumes: Detailed Types
The guide elaborates on various volume types:
emptyDir: Temporary storage created when a pod is assigned to a node, useful for caching.
hostPath: Mounts a file or directory from the host node, useful for accessing host resources.
nfs: Networked file storage, useful for sharing data across multiple pods.
PersistentVolume (PV) and PersistentVolumeClaim (PVC): PVs are storage resources and PVCs request them.
ConfigMap: Stores configuration data as key-value pairs.
Secret: Stores sensitive information such as passwords, API keys, certificates.
XIII. DaemonSet
Purpose: Ensures a copy of a pod runs on every eligible node in the cluster.
Use cases: Deploy system-level workloads like logging and monitoring agents.
XIV. Job
Purpose: Manages one or more pods until a specified number complete successfully.
Use cases: Batch or one-time tasks, such as data processing.
XV. StatefulSet
Purpose: Manages stateful applications requiring stable network identities and persistent storage.
Key Features: Stable pod identities, stable storage, ordered scaling, graceful rollouts, and DNS management.
XVI. Horizontal Pod Autoscaling (HPA)
Purpose: Automatically scales pods based on metrics such as CPU or memory utilization.
Functionality: Monitors resource usage and scales workloads automatically.
XVII. Ingress (Revisited)
Purpose: Manages external access to services.
Key Benefits: Single entry point, load balancing, TLS/SSL termination, path-based routing, name-based virtual hosting.
