..
Kubernetes TLDR
Kubernetes TLDR
Reference
Kuberenetes
It helps manage containerized applications in a much more organized way.
It’s known for
- High availability
- Stability and high performance
- Disaster recovery
Pods
- Smallest unit of K8
- Contains a docker container
- Usually 1 application per Pod
- Each Pod gets its own IP address
- Pods are ephemeral
- We don’t create them directly, instead manage them with deployments
Service
- Permanent IP address that can be attached to pod
- Works as a load balancer and forwards the request to the least busy pod
- A service identifies its pods using
selectors - Types of services
- ClusterIP
- Handles request from Ingress or other pods/services
- Internal load balancer
- Can have multiple ports
- Only accessible within the cluster
- Headless
- K8 allows DNS lookup for service
- Set the clusterIP to None, so that k8 does not assign any specific IP to the service which helps with Pod discovery
- NodePort
- Lets external work access a fixed port on the worker node
- ClusterIP service is also created automatically
- Not very secure
- LoadBalancer service
- Extension of NodePort
- Becomes accessible externally through cloud providers lb service
- Port of the load balancer service is only accessible through cloud providers lb
- ClusterIP
Ingress
- Reference
- External service can be used to access k8 eg: load balancer
- Ingress is another component in front of external service that routes the services to different internal services
- External services should not be used in prod
- Ingress controller pod: evaluates all the rules and manages redirection
minikube addons enable ingress- Can also define multiple paths
Volumes
- Can be local or remote
- K8s doesn’t manage data persistence
- Persistent Volume
- Not namespaced
- Need to add a configuration file
- They should already be there when setting up the cluster
- Persistent volume claim: Needs a configuration file to claim the persistence volume
- Storage Class
- Provisions persistant volumes dynamically
Nodes
- Each Node has multiple Pods in it
- 3 processes: Should be on every node
- Container runtime (eg: Docker)
- Kubelet
- Interacts with both the container & node
- Starts the pod with container inside
- Kube proxy
Deployment
- Specify how many pods you require
- Abstraction of pods
- DBs can’t be replicated using Deployment
- Replicaset is managing the replicas of a pod, in practice we don’t work with it
StatefulSet
- For stateful apps like DBs, use this
- Databases/Applications that store data
- Stateless applications are deployed via deployment, stateful applications are deployed using StatefulSet
- Replicating stateful apps is more difficult
- Not all stateful pods are same, they can be either master (read/write) or worker (read)
- Each pod accesses a replica of the data storage
- StatefulSet pods get sticky identity, name stays same but IP changes
- Containers are good for stateless applications
Master nodes
- 4 processes
- API server
- Cluster gateway
- Can be CLI tool
- Scheduler
- Where to put the Pod?
- Just decides, does not executes
- Controller manager
- Detects cluster state changes and calls scheduler when a pod dies
- etcd
- Cluster changes get stored in the key value store
- Cluster brain
- Application data is not stored here
- API server
- Can have multiple master nodes
- Need less resources then worker nodes
- Minikube
- One node cluster: Master and Worker processes run on single node
- Creates virtual box
- 1 node K8 cluster for testing purpose
Command References
- kubectl
- CLI for managing K8s cluster
kubectl apply -f config-file.yamlTo deploy the deployment/servicekubectl describe pod <pod-name>
- Basic commands for installation and running
kubectl get all | grep <app name>
Configuration files
- Deployments and service will have a (separate) configuration file
- YAML: Multiple documents in 1 file possible with
---separator - Deployment
- metadata
- specification
- Attributes specific to the kind of config file
- template
- config file inside a config file
- applies to pod
- status
- Automatically generated by k8
- Service
- selector: To connect to pod through label
- ports: service port and target port (for pod)
- loadbalancer
- To access the deployment from the external world, we need to create a service of type loadbalancer
- 2 Backlinks
- External service can be used to access k8 eg: loadbalancer
- To start a service and connect with the outside world loadbalancer
- Secret
- Reference
- Secret must be created before the deployment
- Secrets can be referenced inside the k8 deployment configuration file
- ConfigMap
- external configuration which is centralized
- ConfigMap must already be in the k8 cluster when referencing it
- Namespace
- Cluster inside a cluster
- 4 namespaces by default
- kube-system: System processes
- kube-public: Publicly accessible data
- kube-node-lease: determines the availability of nodes
- default
- Use case
- Group resources under name spaces eg: Database, Monitoring, Elastic Stack etc.
- Group different environment under name spaces eg: Staging, development
- Blue/Green Deployment
eg: Production Blue/Production Green
- Can help in using share resources
- Access management control Avoid conflicts b/w teams
- Not helpful for smaller projects
- Some components can’t be accessed from other namespaces
- Volume and nodes can’t be bounded to namespaces
- Can provide namespace inside Configuration files
Helm
- Package manager for Kubernete
- Templating engine for configuration files
- Also helps in Release management