..

  ~4 min read

Kubernetes TLDR

Kubernetes TLDR

Reference

Kuberenetes

It helps manage containerized applications in a much more organized way.

It’s known for

  1. High availability
  2. Stability and high performance
  3. 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

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
  • 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

Reference

  • kubectl - CLI for managing K8s cluster - kubectl apply -f config-file.yaml To deploy the deployment/service - kubectl describe pod <pod-name&gt
  • Basic commands for installation and running - kubectl get all | grep <app name&gt

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