Containers, Dockers and Kubernetes

With Virtualization we have these shortcomings

Potential OS overheads: These OS has Capex and Opex costs. Each OS also consumes resources from the physical server. Each OS is potential attack vector.

• License costs
• Admin
• Patching
• Updates
• AV and more

These Leads us to containers.

Containers:

Only one operating system. Take a physical server and store an operating system, and then essentially we carve and slice that OS into secure containers. Then inside the containers we can an app. This means we got more free space to spin off more containers and more apps for the business. These containers are so fast and ideal for the situation likes tearing things down and bring up on demand because there’s no virtual machine and no extra Operating system to boot before your app can start. In container model, only one base OS is there and it’s already running. So all of the apps are in containers are securely sharing a single OS. Most containerised apps spin up in probably less than a second. From Admin perspective we need to manage only one OS.

Containers are the standardised way for you to package your application, it’s configuration and dependencies together into a single logical object.

What are applications?

Application are software programs that are developed to perform specific tasks and execute on a computer.

To computers, applications are the binary instructions for a computer to execute tasks known as a process.

Container leverages Linux Kernel Features:

• Namespaces
• Control Groups (cgroups)

Namespaces allow the operating system to limit what a process can see, such as other processes, the file system, and more. Process isolation and file system isolation are two of key components.

Cgroups on the other hand limit what resources a process can do or use, how much CPU, how much memory and so on.

Basically what docker or container runtime will do is take the root filesystem that you give them in the form of a Docker image and run that with a whole bunch of Namespaces around it and optionally with some of these CPU and

Memory constraints around it as well.

Finally we have container image which contains the binary that we want to run, as well as any associated files or dependencies needed.

A registry is simply a collection or a repository of images.

To pull a image form public or private registry we use a docker command along with pull sub command

Contianer Demo:

Container can run on VM, server, BM or laptop. Only the thing is machine should be running Docker. 

Docker on Windows runs only windows app and docker on Linux runs only Linux apps. It may be possible to run your Linux apps on Docker on Windows. 

Download a single image to the Docker host

Docker image is a pre-packed application or kind of a VM template. Basically it got everything wrapped up into a single bundle that you need to run an application. It can contain a web server that runs some static content. To fire up a container from this image we use this command.

Docker container run -d —name web -p 8000:8080 <Image name>

This will create a unique id which represent the container.

Doing this we exposed our Docker host ip with port 8080.

We can also stop the container by running 

Docker stop web

To start again 

Docker container start web 

Microservices and Cloud native:

Legacy apps or monolithic apps, as called sometimes these are those monstrous apps where everything that the app does is pretty much baked into a single binary(program). So everything is lumped into a single program.

May be your app has web front end, search, auth, stock, check out services. Its just a nightmare from developer view point if you want update or fix, let’s say just the search part of the app, it is a whole big exercise on the entire code base. So you’re hacking the entire app, and you’re testing and you’re recompiling the whole thing. And on the operations front, if you got an issue, let’s say if with same search functionality again, the only way to roll out the fix is to take the entire app down as everything is lumped into a single program. 

Fortunately micro services and cloud native on the other hand break out all of those different components and make each service its own little mini app or mini service. Still they all will talk to each other to make full app experience, but updating that search fix now become way easier for the developer and operator. Now the developer only needs to touch the search code when it update the search feature. And from operations perspective they need to only roll out a new version of the search service.

So the main intention here is build, deploy and manage apps in a way that lends itself to modern business requirements or cloud computing requirements as we often call them.

So it isn’t really anything to do with deploying on the cloud. You can absolutely run a cloud native app in your on-prem data center. Cloud native is all about how the app’s built and managed, so we can do things like scale the front end independent of the back end. Also you can integrate on each feature independently.

So containers improve on nearly everything offered by hypervisors, and they pave the way for more modern cloud native and Microservices applications.

Docker the Company:

Company Docker, Inc is the main sponsor behind the container technology with the same name. Initially it was a company called dotCloud that provided a developer platform on top of Amazon Web Services. They’d been using containers to build their platform on top of AWS. They came up with new tool to help them spin up and manage their containers. That in-house tech was Docker. Name is deriver from dock + worker

Docker the technology:

Containers are like fast lightweight virtual machines, and Docker makes running our apps inside of containers really easy. Docker is open-source and lives in Git-hub

Docker community Edition

• Open source
• Lots of contributors
• Quick release cycle

Enterprise Ediiton (EE)

• Slower release cycle
• Additional features
• Official support

Demo:

Build the docker image on Docker installed host.

Docker image build -t <imagename> .

All docker doing here is taking our source code and doing all the hard work to package it as a container or is an image actually. An image is like a stopped container

Check for image

Docker image ls <imagename>

All our source code is packaged and ready to use as a container.

Now we will push this image to the registry or Docker Hub. You can have your own on-prem or private registries.

Docker image push <image_name>

Now run it as container, give it a name, make it available on the network

Docker container run -d —name web -p 8000:8080 <image_name>

The Docker workflow involves several key steps and concepts that enable developers to create, deploy, and manage containerized applications efficiently. Here's an explanation of the Docker workflow along with the main components and processes involved:

1. **Dockerfile**:

   - The Dockerfile is a text-based script that defines the instructions for building a Docker image. It specifies the base image, environment variables, dependencies, commands, and configurations needed to create a containerized application.

2. **Docker Image**:

   - A Docker image is a lightweight, standalone, executable package that contains everything needed to run a containerized application, including the application code, runtime environment, libraries, and dependencies. Images are built from Dockerfiles using the `docker build` command.

3. **Docker Container**:

   - A Docker container is a running instance of a Docker image. Containers are isolated, portable, and can be deployed consistently across different environments. They encapsulate the application and its dependencies, ensuring consistency and reproducibility.

4. **Docker Registry**:

   - A Docker registry is a repository that stores Docker images. Public registries like Docker Hub provide a centralized location to share and discover Docker images, while private registries can be used for storing proprietary or sensitive images within an organization.

Now, let's walk through the Docker workflow:

1. **Write Dockerfile**:

   - Developers start by writing a Dockerfile that defines the build instructions for their application. This includes specifying the base image, copying files, setting environment variables, installing dependencies, and defining the container's entry point.

2. **Build Docker Image**:

   - Once the Dockerfile is ready, developers use the `docker build` command to build a Docker image based on the instructions in the Dockerfile. This command creates a new image layer by layer, caching intermediate layers for faster builds.

   ```bash

   docker build -t myapp-image:v1 .

   ```

3. **Run Docker Container**:

   - After building the Docker image, developers can run a Docker container using the `docker run` command. This command starts a new container based on the specified image, assigns resources (e.g., CPU, memory), exposes ports, mounts volumes, and sets runtime options.

   ```bash

   docker run -d -p 8080:80 --name myapp-container myapp-image:v1

   ```

4. **Manage Docker Containers**:

   - Developers can manage Docker containers using various Docker CLI commands. This includes starting, stopping, restarting, pausing, and removing containers as needed. Docker provides commands like `docker ps`, `docker start`, `docker stop`, `docker rm`, etc., for container management.

   ```bash

   docker ps -a                # List all containers

   docker start myapp-container   # Start a stopped container

   docker stop myapp-container    # Stop a running container

   docker rm myapp-container      # Remove a container

   ```

5. **Push/Pull Docker Images**:

   - Docker images can be shared and distributed using Docker registries. Developers can push their local images to a registry using the `docker push` command and pull images from a registry using the `docker pull` command.

   ```bash

   docker login                     # Log in to Docker Hub or private registry

   docker push myusername/myapp-image:v1   # Push image to registry

   docker pull myusername/myapp-image:v1   # Pull image from registry

   ```

6. **Continuous Integration/Continuous Deployment (CI/CD)**:

   - Docker is often integrated into CI/CD pipelines to automate the build, test, and deployment processes. Tools like Jenkins, GitLab CI/CD, and GitHub Actions can trigger Docker builds, run tests in containers, and deploy Dockerized applications to production environments.

This Docker workflow enables developers to create portable, scalable, and consistent environments for their applications, streamlining the development, testing, and deployment lifecycle.

Kuberneters:

Google was running search and stuff on containers from 90’s. Every google search runs on its own container this means spinning up billions of containers. So to make it possible they built a couple of in-house systems to help.

Initially they built something called Borg then Omega and finally Kubernetes. So Kubernetes came out of google and its open source and these days it is star project for the cloud native computing Foundation.

All major cloud players AWS, google and Azure offer hosted Kubernetes services and so does IBM and bunch of others. We can also get Kubernetes for On-prem.

It is one of the most extensive platform like it does stateless, stateful, batch work, long running, security, storage, networking, serverless, or Functions as a service, machine learning.

All of  these stuff it can do anywhere, in the cloud and on-prem and on your data center and even in your laptop when you are developing. The name Kubernetes is Greek for helmsman or captain, the person who steers the ship.

Docker provides the mechanics for starting and stopping individual containers, pretty lower level stuff. Kubernetes on there hand doesn’t care about low-level stuff like that. Kubernetes care about higher-level stuff, like how many containers to run in, maybe which nodes to run them on, and things like knowing when to scale them up or down even how to update your containers without downtime.

Like conductor in orchestra, Kubernetes is a conductor which is issuing commands to Docker instances, telling them when to start and stop containers and how to run them.

Comparing to Vmware we can think of Docker as ESXI, the low level hypervisor and Kubernetes can be considered as vCenter that sits above a bunch of hypervisors.

We have Kubernetes cluster to host applications, and it can be anywhere. Each of these nodes is running some Kubernetes software and a container runtime. Usually the container runtime’s Docker or Containers, but others do exist. Sitting above all of this is the brains of Kubernetes(K8’s control plane), and that’s making the decisions like the conductor int he orchestra.

Consider we have a web app with front end and back end. The web front ed maybe containerised Nginx, and lets say its containerised MySQL on the back end. We can say Kubernetes to get one container in back end and 2 container in front end and Kubernetes deploys it. And One more thing it decide is which nodes to run stuff on. Lets say if load on front end increases and two containers are not enough then based on the situation it spins up two more and it does it without human intervene. Literally when load goes up in front end Kubernetes has enough intelligence to spin up more containers. Same holds good when load decrease or node goes down. It’s come up with new node also called self healing.

Point to remember is Docker’s doing all the low-level container spinning up, spinning down stuff, but it only does it when Kubernetes tells it to, meaning Kubernetes is managing a bunch of Docker nodes.

Kubernetes is the absolute business for decoupling your applications from the underlying infrastructure. 

Suitable Workloads:

Stateless:

- Doesn’t remember stuff

Stateful:

- Has to remember stuff  

Clouds are providing the infrastructure and Docker and Kubernetes are providing the tools for building the apps.

With containers it is possible to deploy some of our legacy apps directly inside of containers. Containers are great for new modern apps, the stateless and stateful bits.

Docker the company and Docker the technology have been around for a while. The company started as dotCloud in around 2010 but then it rebranded itself as Docker Inc around 2013.

Orchestration:

Apps Comprise:

• Multiple parts (services)
• Multiple requirements

Game Plan

• Describe the app

Document Game plan in version control system

Key to automation

• Ordered startups
• Intelligent scheduling

Give Game plan to orchestrator (K8s)

Let orchestrator deploy and manage app.

As these apps keeps growing, scale make things very complex. So this cannot be done manually so we need some solid system to deploy and manage these apps.

So the core of the container orchestration is define our app, how all parts interact, provision the infrastructure, and then deploy and manage the app. Thats orchestration.

This all can be done using orchestrator mostly Kubernetes and let the orchestrator deploy the app and manage it.

Kubernetes Fundamentals

Containers: Packages to get software to run reliably

Docker is the most popular container run time engine.

Why use Containers?

Containers allow standardisation, reduction of resource utilisation, fault isolation and immutability.

Benefits:

Self-contained: We can have package where all libraries and application bundle together in a single container image.

Portable: we can ship this image to different environment and we can be sure that it will work the same way.

Platform agnostic: 

Lightweight: as it doesn’t contain full blown OS

No Guest OS

Fault isolation: means if you have security vulnerability within a single image you can be sure that vulnerability can be kept within the image itself and that doesn’t effect other container images.

Immutable: If you have a problem with container image, you can destroy and recreate it from a single base image.The newly created image will work the same way as when it was first being created.

What is Kubernetes?

Kubernetes is portable, extensible, open-source platform for managing containerised workloads and services.

Short form of Kubernetes is K8s

Kubernetes is portable and cloud agnostic which means that you can be running your Kubernetes workload in google cloud today and ship it to the cloud providers like, Microsoft azure and AWS or even on-prem environment in vSphere relatively easily with minimal changes.

This is because all major cloud providers support Kubernetes. Because of multiple and hybrid cloud concepts it has become really difficult to manage but from VMware perspective we have come up with VMware Tanzu as a single management console that sits between all these different providers.

Instead of different user interface customer can use Vmware Tanzu to interact with multiple providers.

Kubernetes also enables a micro services way of building applications. This is because as nature of container is everything is in small building blocks.

Key features:

Portability: Faster speed to market

Ability to deploy anywhere and focus on delivery increase speed to market.

Scalability - Autoscaling

Kubernetes automatically detect the workload and it will scale up and down automatically by enabling micro services approach way of building applications.

High Availability - self healing

Kubernetes constantly does health check to match desired state. Also does load balancing and traffic routing intelligently.

Kubernetes Architecture:

kubectl: command line utility tool responsible for communicating with the Kubernetes back end services. 

Master node which is control plane of entire cluster.

Master node Components:

API server:

Entry point of the cluster

Validates requests that are going through it

Orchestrating all operations within the cluster.

Scheduler:

Selects optimal node to run pods(workloads) based on defined configurations

Selects where the pods should go, does not start the pod. For starting the pod, Kubelet component is responsible

Controller Manager:

Different controllers with different functions

Onboard new nodes, responsible for noticing and responding when nodes goes down.

Ensure that the correct number of pods are running.

etcd:

Stores data in key-value format

What resources are available, state of the cluster

Does not store application data

Backups of cluster state information are stored here.

Worker node Components:

kubelet:

Agent that communicates with Kube-Apiserver

Manages all activities of the worker node

Kube-Proxy

Network proxy that allows network communication for your pods

Maintains network rules

Worker node: receive instructions from the master node to run workloads.

Container Runtime(Docker): Software to run containers. 

Workload means Pods: Workloads are scheduled by schedular to run on worker nodes

Clusters: a set of nodes group together.

Yaml files are used to define declarative configurations

Pods:

The smallest object that you can create in Kubernetes.

Command to execute the yaml file

kubectl create -f webapp-pod.yaml

kubectl get pods

kubectl describe pod webapp-pod

ReplicaSet:

Construct that runs multiple instances of the same pod

Self-heals according to desired state

Desired state is defined by yaml file

ReplicaSet scales up and down automatically to the traffic

ReplicaSet helps you to be highly available and achieve zero down time

Label & Selectors

Helps to identify and associate different objects

kubectl get replicates

kubectl describe replicates replicates-1

Deployment:

A deployment is a higher level construct that helps to manage replicaSet

When we create ReplicaSet it automatically creates Pods as well, and its role is to make sure that Pods are highly available.

Some of additional features of Deployment are 

• Rolling Update
• Rollback changes
• Pause and resume deployment

To execute deployment yaml

kubectl  create -f delpoyment-1.yaml ### declaratively 

Same thing can be achieved imperatively using

kubectl create deployment <deployment-name> -image=nginx:1.18.0

Services:

An abstract way to expose an application running on a set of pods via an endpoint

• Stable IP address
• Load balancing
• Provides loose coupling between pods

3 types of services

• clusterIP: mainly used for the internal communication. It refers to the traffic going on within the cluster itself. 
• NodePort: If an external system want to communicate with internal resource in cluster, instead of communicating directly it will talk to service called NodePort
• LoadBalancer: 

Create service yaml file

kubectl create -f <yaml file>

To get list of services

Kubectl get service <my-service>

kubectl get endpoint

Namespaces:

Are a way to divide cluster resources via multiple users

Characteristics of Namespaces:

• Names of resources need to be unique within a namespace, but not across namespaces
• Cannot be nested inside one another
• Each resource can only be in one namespace

Secrets:

Stores sensitive data, eg passwords

2 steps process

• Create secret
• Inject into pods

Volumes:

Pods are ephemeral 

can be stopped or destroyed

built or replaced

each pod has its own IP address

Persistent Volumes - Interface to the actual storage

Cluster level resource that is used to manage your storage centrally

Persistent Volume Claims

1. Pod request for storage volume via PVC
2. PVC tries to find the most suitable volume in the cluster
3. PV is claimed by the PVC, and the Phase the storage backend

K8s Admins and K8s user

K8s Admin setup and maintains the cluster

• Manage and allocate resources for users (eg. Developer)
• Manage security of the cluster
• Storage provisioning

K8s user deploy apps in the cluster

• Deploys app in the cluster directly or through CI/CD pipeline
• Configure the apps to use the persistent volume through persistent volume claim

Kubernetes

It is an open source container orchestration framework

Developed by Google.

Helps you to manage contenarized application in different deployment environments 

What Kubernetes solve?

Container are perfect to host small applications like micro-services. Rise of technology now leads to 100 to thousands of containers 

Increased usage of containers in different environment is difficult to manage using scripts or some tools

That specific scenario caused to have a proper technology to maintain these containers

What feature orchestration tool offer?

High availability or no downtime of application

Scalability or high performance. Scale down or scale up application as per the user load. This provides more flexibility 

Disaster recovery - backup and restore. In case of break down of infrastructure there should be some mechanism to pick up the data, restore the data to the latest state.

So that application does not loose any data. Also, the containerised application can ran from the latest state after the recovery. 

All of above functionalities are offered by Kubernetes.

Kubernetes architecture

Kubernetes cluster is at least made of one master node and connected to couple of worker nodes.

Node can be a virtual or a physical machine

Each node has Kubelet process(node agent) running on it.

Kubelet is a kubernetes process that makes it possible for the cluster to communicate to each other and execute some tasks on those nodes like running some application process.

Each worker node has container of different applications deployed on it. So depending on how workload is distributed you will have different number of docker container running on worker nodes.

Worker nodes are the one where actual work is happening. On worker nodes your applications are running.

Master node runs several Kubernetes processes that are absolutely necessary to run manage the cluster properly

One of such process is an API server which also is a container. An API server is actually the entry point to the Kubernetes cluster so this is the process which the different Kubernetes clients will talk to

Like UI if you’re using Kubernetes dashboard an api if you’re using some scripts and automating technologies and command line tool.

So all of these will talk to API server. 

Another process that is running on master node is a controller manager which basically keeps an overview of what is happening in the cluster whether something needs to be repaired or maybe if a container died and it needs to be fixed.

Another process is Schedular basically responsible for scheduling containers on different nodes the workload and the available server resources on each nodes so its ’s an intelligent process that decides on which worker node the next container should be scheduled based on the available resources the worker nodes and the load that container needs 

And another very important component of whole cluster is an etcd key value storage which basically holds at any time the current state of the Kubernetes cluster so it has all the configuration data inside and all the status data of each node and each container inside of that node and the backup and restore that we mentioned earlier is actually made from these etcd snapshots because you can recover the whole cluster state using that etcd snapshot.

Another very important component which enables both master and worker nodes to talk to each other is virtual network that spans on all the nodes that are part of the cluster and in simple words virtual network actually turns all the nodes inside of the cluster into one powerful machine that has the sum of all the resources of individual nodes 

Actually worker nodes bear higher load as they are running applications on inside of it usually are much bigger and have more resources because they will be running hundreds of containers inside them whereas master node will be running just a handful of master processes like we  like we discussed earlier.

However master node is much more important than the individual nodes because for example if you lose a master node access you will not be able to access the cluster anymore and that means you should have backup of your master at any time so in production environments usually you would have at least two masters inside of your Kubernetes cluster but in more cases of course you’re going to have multiple masters where if one master node is down the cluster continues to function smoothly because you have other master available.

In summary:

API server: Entrypoint to K8s cluster

Controller Manager: Keeps track of what’s happening in the cluster

Scheduler: ensures Pods replacement

Etcd: Kubernetes backing store

Control Plane Nodes: handful of master process but of more important

Worker nodes: higher workload, much bigger and more resources

Main Kubernetes components:

Considering web app and data base as example.

Pod: 

smallest unit in Kubernetes

It is abstraction over container. Basically what pod does is it creates this running environment or a layer on top of the container and the reason is because Kubernetes wants to abstract away from the container runtime or container technologies so that you can replace them if you want to and also you don’t have to directly work with docker or whatever container technology you use in a Kubernetes so you can only interact with the Kubernetes layer so we have an application pod which is our own application and that will maybe use a database pod with its won container and this is also important concept here as pod is usually meant to run one application container inside it. You can also run multiple containers inside one pod but basically its only the case if you have one main application container and the helper container or some side service that has to run inside of that pod.Kubernetes offered out of the box virtual network which means that each pod gets its own IP address not the container.

And each pod can communicate with each other using that IP address which is an internal IP address not public so my application container can communicate with database using the IP address.

Summary:

Smallest unit in Kubernetes

Abstraction over container

Usually 1 application per pod

Each pod gets own its own IP address.

New IP address on re-creation

Service and Ingress:

In case of pod die/crash, new one will get created in its place and when that happens it will get assigned a new ip address which is obviously inconvenient if you are communicating with the database using the IP address because you have to adjust it every time pod restarts and  because of that another component of Kubernetes called service is used. So service is basically a static IP address or permanent IP address that can be attached so to say to each pod my app will have its own service and database pod will have its own service so even if pod dies the service and its IP address will stay so you don’t have to change that endpoint anymore.

Now to access the web app we have to create an external service. It is basically a service that opens the communication from external resources but again you wouldn’t want your database to be open to public requests and for that you would create something called internal service so this is a type of service that you specify when creating one 

There is another component of Kubernetes called ingress so instead of service the request first goes to ingress and it does the forwarding to service.

Summary:

Permanent ip address

Life cycle of Pod and service not connected

ConfigMap & Secret:

As we said pods communicate with each other using service so my application will have database endpoint say mongoldb service that it uses to communicate with the database but whether you configure usually this database url or endpoint in some application properties files or external environmental variable. Usually its inside of the built image of the application but problem is if endpoint service name or something change to mongoldb you would have to adjust that url in the application 

So usually you have to re-built the application with new version and have to push it to the repository and have to pull new image in pod and restart thing but this is tedious task for small change.

Like database url so for this purpose Kubernetes has a component called config map, it’s basically your external configuration to your application so configMap would usually contain configuration data like urls of a database or some other services that you use

And in Kubernetes you just connect it to the pod so that pod actually gets the data that config map contains.

It has another component called secret to store secret data credentials for example not in a plain text format but in base 64 in encoded format 

And to encrypt that there are tools deployed in Kubernetes that will make secrets secure.

Summary:

External configuration of your application

Configmap is for non-confidential data only

Secret is used to store secret data

Reference secret in deployment/pod. Use it as environmental variables or as a properties file.

Volume:

If database or the pod gets restarted the data would be gone and that’s problematic

So database data or log data to persisted reliably for long term we use component called volume.

So how it works that basically attaches a physical storage on a hard drive to your pod and that storage could be either on local machine meaning on the same server node where the pod is running or it could be on a remote storage ,meaning outside of the Kubernetes cluster can be in cloud storage or could be on-premise storage and just have reference to it.

Kubernetes cluster explicitly doesn’t manage any data persistence which means you as a Kubernetes user is responsible for backing up the data replicating and managing it and making sure it’s kept in a proper hardware.

Summary:

Storage on local machine

Or remote, outside of the K8s cluster

Deployment and StatefulSet:

What happens if my application pod die/crash? To avoid downtime we are replicating everything on multiple servers 

So we would have another node where a replica or clone of our application would run which will also be connected to the service.

As said earlier service is like persistent static IP address but also is a load balancer that will catch the request and forward to whichever part is least busy

In order to create second replica of application pod we don’t create second pod instead we define the blueprint for my application pod and specify how many replicas of that pod you would like to run 

And that component or that blueprint is called deployment. So in reality we will be creating deployment not pods. Deployment is like abstraction of Pods.

What if DB pod dies. We can’t replicate DB pod by deployment as they might be sharing different shared storage.

So this is done using StatefulSet. All data base applications like MySQL, elastic and mongoDB are created using StatefulSet.

This makes sure database read and write are synchronised. As it is difficult to maintain stateful service, most of the time DB are often hosted outside of Kubernetes cluster.

Summary:

Deployment is for stateless apps

StatefulSet is for stateFUL Apps or database

Main Kubernetes Components summarised:

Pod: abstraction of containers

Service: communication

Ingress: route traffic into cluster

ConfigMap and Secret for external communication

Volume for data persistence

Deployment and Stateful for replication.

Kubernetes Configuration:

All the configuration in Kubernetes goes through the master node with the process called api server

Kubernetes client would be ui or an api which could be a script or a curl command or cmd tool like kubectl. And these requests have to be either in yaml or json format.

Every configuration file has 3 parts.

• Metadata
• Specification
• Status: Automatically generated and added by Kubernetes.

The way status works is that Kubernetes will always compare what is the desired state and what is the actual state. If no match then Kubernetes knows there’s something to be fixed and it will try to fix also knows as self-healing feature

Where does K8s get this status data?

From etcd. Etcd holds the current status of any K8s component

Format of the configuration file is yaml. Yaml is human friendly data serialisation standard for all programming languages

Store the config file with your code. It will be part of Infra or own git repository.

MiniKube and Kubectl:

In a production cluster setup 

• we will have multiple worker nodes and master nodes
• Separate virtual or physical machines representing each node

To test something locally on such setup is very tedious or almost impossible.

So Minikube is basically one node cluster where the master processes and the worker processes both run on the one node and this node will have a docker container runtime pre-installed so you will be able to run the containers or pods with container on this node.

Kubectl is a command line tool for Kubernetes cluster. Kubectl is most powerful of all 3 clients(UI,API,CLI)

Kubectl is used to communicate with any type of Kubernetes cluster not only Minikube cluster

Minikube can run either as a container or Virtual Machine on your laptop.

Minikube has docker pre-installed to run the containers in the cluster.

Driver means we are hosting Minikube as a container on our local machine. 

We have 2 layers of Docker:

1. Minikube runs as a docker container
2. Docker inside Minikube to run our application containers.

Kubectl CLI is for configuring the Minikube cluster

Minikube CLI is for start up/deleting the cluster.

For testing web applications and DB app

Create 4 K8s config yaml file.

1. ConfigMAP: MongoDB endpoint
2. Secret: MongoDB user & Pwd
3. Deployment and service: MongoDB application with internal service
4. Deployment and service: Our own WebAPP with external service