Features
- CI/CD
- containerized infrastructure
- Auto-scalable infrastructure
- Environment consistency across dev/testing/prod
- Loosely coupled infrastructure
Main components
- Master components (control plane)
- etcd
- stores the configuration information that can be used by each node
- is accessible only by API server
- kubernetes backing store
- API Server
- exposes kubernetes API
- provides all the operation on cluster via API
- entrypoint to k8s cluster
- Controller Manager
- regulates the state of cluster and performs a task
- runs in nonterminating loop and is responsible for collecting and sending info to API server
- keeps track of what’s happening in the cluster
- handles multiple nodes
- Scheduler
- distributes the workload
- tracks utilization of working load on cluster nodes
- places the workload on which resources are available and accept the workload
- allocates pods to available nodes
- ensures pods placement
- Node (multiple) components
- Docker
- runs the encapsulated application containers
- Kubelet Service (kubelet)
- relays information to and from control plane service
- interacts with etcd store to read configuration details and write values
- communicates with the master component to receive commands and work
- maintains the state of work and the node server
- manages network rules, port forwarding, etc.
- runs on each node
- Kubernetes Proxy Service (kube-proxy)
- makes services available to the external host
- forwards the request to correct containers and is capable of performing primitive load balancing
- manages pods on node, volumes, secrets, creating new containers’ health checkup, etc.
More components explanation
- Node
- a single machine, can be physical, VM or a cloud instance
- have multiple pods e.g. my-app pod / DB pod
- in k8s you only work with the pod’s
- Container Runtime
- responsible for running containers in pod
- Kubernetes supports several runtimes: Docker, containerd, CRI-O, and any implementation of the Kubernetes CRI (Container Runtime Interface).
- Service
- can be defined as a logical set of pods
- an abstraction on the top of the pod which provides a single IP address and DNS name by which pods can be accessed
- manages load balancing configuration
- has a permanent IP address (not like pod)
- a load balancer
- lifecycle of pod and service not connected
- you specify the type of service on creation - external / internal (default)
- Pod
- is the smallest unit
- gets new IP address on creation
- a collection of container(s), it can be Single container pod / Multi container pod
- its storage inside a node
- is possible to create a pod with multiple containers inside it
- e.g. keeps a DB container and data container in the same pod
- Replication Controller
- manages the pod lifecycle
- makes sure that the specified number of pod replicas are running at any point of time
- is used in time when one wants to make sure that the specified number of pod or at lease one pod is running
- has the capability to bring up or down the specified pod
- Replica Sets
- ensures how many replica of pod should berunning
- a replacement of replication controller
- an upgraded version of the replication controller
Key difference between Replication Controller and Replica Sets: the replication controller only supports equality-based selector whereas the replica set supports set-based selector
- Equality-based Selectors: They allow filtering by key and value. Matching objects should satisfy all the specified labels
- Set-based Selectors: Set-based selectors allow filtering of keys according to a set of values.
- Deployments
- are upgraded and higher version of replication controller
- updates the replica set and are also capable of rolling back to the previous version
- Kubernetes Volumes (not Docker Volumes)
- a directory
- is accessible to the containers in a pod
- isn’t the same as Docker Volumes (as soon as the life of a pod ended, the volume was also lost)
- the volumes that are created through Kubernetes is not limited to any container
- supports any or all the containers deployed inside the pod
- supports different kind of storage wherein the pod can use multiple of them at the same time
- Secrets
- sotres sensitive data such as user name and password with encryption
- external configuration
- ConfigMap
- StatefulSet
- Network Policy
- defines how the pods will communicate with each other and the network endpoint
- uses labels to select the pods and defines rules to allow traffic to a specific pod
- Ingress
- route traffic into cluster
Diagram for core components
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ ┃
┃ Kubernetes Cluster ┃
┃ ┃
┃ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃
┃ ┃ ┃ ┃
┃ ┃ Control Plane (Master) ┃ ┃
┃ ┃ ┃ ┃
┃ ┃ ┏━━━━━━━━┓ ┏━━━━━━━━━━━┓ ┃ ┃
┃ ┃ ┃ etcd ┃ ┃ scheduler ┃ ┃ ┃
┃ ┃ ┗━━━━┳━━━┛ ┗━━━━━┳━━━━━┛ ┃ ┃
┃ ┃ ┏━━━━┻━━━━━━━━━━━┻━━━━━┓ ┃ ┏━━━━━━━━━┓ ┃
┃ ┃ ┃ ┣━━━╋━━━━┫ kubectl ┃ ┃
┃ ┃ ┃ API Server ┃ ┃ ┗━━━━━━━━━┛ ┃
┃ ┃ ┃ ┣━━━╋━━┓ ┃
┃ ┃ ┗━━━━━━━━━━━┳━━━━━━━━━━┛ ┃ ┃ ┃
┃ ┃ ┏━━━━━━━━━━━┻━━━━━━━━━━┓ ┃ ┃ ┃
┃ ┃ ┃ Controller Manager ┃ ┃ ┃ ┃
┃ ┃ ┗━━━━━━━━━━━━━━━━━━━━━━┛ ┃ ┃ ┃
┃ ┃ ┃ ┃ ┃
┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ┃ ┃
┃ ┃ ┃
┃ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ ┃
┃ ┃ ┃ ┃ ┃
┃ ┃ Node 1 (Worker) ┃ ┃ ┃
┃ ┃ ┃ ┃ ┃
┃ ┃ ┏━━━━━━━━━━━━━━━━━┓ ┃ ┃ ┃
┃ ┃ ┃ kubelet ┣━━━━━━╋━━━━┛ ┃
┃ ┃ ┗━━━━━━━━┳━━━━━━━━┛ ┃ ┃
┃ ┃ ┏━━━━━━━━┻━━━━━━━━┓ ┃ ┃
┃ ┃ ┃ container ┃ ┃ ┃
┃ ┃ ┃ runtime ┃ ┃ ┏━━━━━━━━━━━━━━┓ ┏━━━━━━━━━━━━━━┓ ┃
┃ ┃ ┗━━━━━━━━━━━━━━━━━┛ ┃ ┃ ┃ ┃ ┃ ┃ ┏━━━━━━━━━━━┓
┃ ┃ ┏━━━━━━━━━━━━━━━━━┓ ┃ ┃ Service ┃ ┃ Ingress ┃ ┃ ┃ Load ┃ ┏━━━━━━━━┓
┃ ┃ ┃ kube-proxy ┣━━━━━━╋━━━┫ Cluster IP ┣━━┫ Controller ┣━━━━━╋━━━━┫ Balancer ┣━━━━┫ Client ┃
┃ ┃ ┃ ┣━━┓ ┃ ┃ (1:N nodes) ┃ ┃ ┃ ┃ ┃ ┃ ┗━━━━━━━━┛
┃ ┃ ┗━━━━━━━━━━━━━━━━━┛ ┃ ┃ ┃ ┃ ┃ ┃ ┃ ┗━━━━━━━━━━━┛
┃ ┃ ┃ ┃ ┗━━━━━━━━━━━━━━┛ ┗━━━━━━┳━━━━━━━┛ ┃
┃ ┃ ┏━━━━━━━━━━━━━━━━━┓ ┃ ┃ ┏━━━━━━┻━━━━━━━┓ ┃
┃ ┃ ┃ Pod 1 ┃ ┃ ┃ ┃ Ingress ┃ ┃
┃ ┃ ┃ ┏━━━━━━━━━━━━━┓ ┣━━┫ ┃ ┃ (route rules)┃ ┃
┃ ┃ ┃ ┃ container 1 ┃ ┃ ┃ ┃ ┗━━━━━━━━━━━━━━┛ ┃
┃ ┃ ┃ ┗━━━━━━━━━━━━━┛ ┃ ┃ ┃ ┃
┃ ┃ ┃ ┏━━━━━━━━━━━━━┓ ┃ ┃ ┃ ┃
┃ ┃ ┃ ┃ container 2 ┃ ┃ ┃ ┃ ┃
┃ ┃ ┃ ┗━━━━━━━━━━━━━┛ ┃ ┃ ┃ ┃
┃ ┃ ┗━━━━━━━━━━━━━━━━━┛ ┃ ┃ ┃
┃ ┃ ┏━━━━━━━━━━━━━━━━━┓ ┃ ┃ ┃
┃ ┃ ┃ Pod 2 ┃ ┃ ┃ ┃
┃ ┃ ┃ ┏━━━━━━━━━━━━━┓ ┣━━┛ ┃ ┃
┃ ┃ ┃ ┃ container 1 ┃ ┃ ┃ ┃
┃ ┃ ┃ ┗━━━━━━━━━━━━━┛ ┃ ┃ ┃
┃ ┃ ┃ ┏━━━━━━━━━━━━━┓ ┃ ┃ ┃
┃ ┃ ┃ ┃ container 2 ┃ ┃ ┃ ┃
┃ ┃ ┃ ┗━━━━━━━━━━━━━┛ ┃ ┃ ┃
┃ ┃ ┗━━━━━━━━━━━━━━━━━┛ ┃ ┃
┃ ┃ ┃ ┃
┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ┃
┃ ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
Basis
- k8s doesn’t manage data persistance
- DB can’t be replicated via deployment because DB has states (its data)
Advanced
(TODO)
Setup
(TODO)
- Install docker engine, etcd 2.0
- Configure kube-apiserver, controller manager, node configuration
Configuration
Each configuration file has 3 parts
- metadata
- specification
- “apiVersion”, “kind”, “spec”
- Attributes of “spec” are specific to the kind
- status
- Automatically generated and added by k8s
fields
- apiVersion
- kind: Deployment or Service
- metadata
- spec
- replicas
- selector
- template
Example
apiVersion: apps/v1
kind: Deployment # a template for creating pods
metadata:
name: my-app
labels:
app: my-app
spec:
replicas: 2 # create 2 replica pods called my-app
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers: # each pod replica has a container based on my-image
- name: my-app
image: my-image
env: # environment variable
- name: USER_NAME
valueFrom:
secretKeyRef:
name: mongo-secret
key: mongo-user
ports: # ports configuration of this container
- containerPort: 3000
ref: