Docker V/S Kubernetes:-

Scaling Containers: Docker allows manual scaling of containers, while Kubernetes provides
automated scaling based on defined criteria, making it easier to scale pods up or down.

Updating Images: Docker supports updating container images, but Kubernetes offers more robust
strategies for rolling updates with minimal downtime, facilitated through resources like
Deployments.

Accessing Applications: Docker containers can be accessed from outside, but Kubernetes provides
advanced mechanisms, such as services and Ingress controllers, to manage external access routes
to applications.

Load Balancing: Docker supports basic load balancing, but Kubernetes offers advanced load
balancing capabilities through its services, which distribute incoming traffic among pods for
improved reliability and performance.

Core Concept
=====================================================================================

Kubernetes Definition

Kubernetes is an open source container orchestration tool for automating deployment, scaling,
healing, load balancing and management of containerized applications.

Architecture of Kubernetes Cluster

[Master Node or Control plane] [Worker Node]

ETCD Kube-Proxy

Controller Scheduler Kubelet

Manager Manager
POD
Container
Container
Runtime
Kube-API server Engine

Kubelet

Admin/dev/user
Kubernetes Exists in two parts –

Master Node or Control plane and Worker Node.

Master Node

The master node in OpenShift (and Kubernetes) typically runs the control plane components,
including the API server, controller manager, scheduler, and etcd, as static pods.

Component of Master Node:- KUBE-API SERVER, KUBE-CONTROLLER MANAGER, KUBE-

SCHEDULER, KUBE-ETCD.

1) Kube-API server:- Kube-API server is frontend of control plane. It is responsible for handling
external and internal requests. When a user sends a request to the API server to create a pod, the
API server first performs authentication and authorization checks to determine if the user has the
appropriate permissions for pod creation.

2) Kube-Etcd:- Etcd is key value database that contains database about your cluster, nodes, pods,
configs , secrets, accounts, roles, rolebindings etc.
Node:- ETCD service listens on by default port 2379.
3) Kube-Scheduler:- The Kubernetes scheduler assigns pods to nodes based on factors like label
selectors, node affinity rules, and storage requirements specified in the pod's configuration.

Kube-Scheduler schedule the pods onto node by first it filterout the nodes then schedule based on
ranking.

4) Kube-Controller:- Kube-Controller is responsible for ensuring that the current state of nodes,
pods, services etc matches the desired state defined in the cluster's configuration.
4.1) Node Controller:- The Node Controller continuously monitors the status of worker nodes,
checking their health every 5 seconds. If the Node Controller determines that a node is
unresponsive for a duration of 40 seconds, it marks the node as "unreachable" or “NotReady”.

Subsequently, the Kube-scheduler observes the state of nodes for up to 5 minutes. If a worker
node remains in an unhealthy state during this period, the scheduler takes action and reschedules
pods to other healthy worker nodes to maintain application availability.

4.2) Replication Controller:- Replication controller is responsible for ensures that the desired
number of pods are available at all time within the sets. If pods die it create another one.

Worker Node

Worker node maintaining the running pods and providing kubernetes runtime environment.

1^)Kubelet:- The Kubelet listens to instructions from the Kube-API server and takes care of pod
management tasks such as creating, deleting, and monitoring pods. Additionally, it shares the
current state of pods with the Kube-API server.

Note:

Running Pods: When a pod is scheduled to run on a node, the kubelet on that node is responsible for
ensuring that the containers within the pod are started and running as specified in the pod's
configuration. The kubelet communicates with the container runtime (e.g., Docker, containerd) to
start and manage the containers.

Restarting Pods: If a pod's containers fail or exit for any reason (e.g., due to a crash or resource
constraints), the kubelet can be configured to restart the pod based on the pod's restart policy.
Common restart policies include Always, OnFailure, and Never. The kubelet monitors the pod's
containers and takes action according to the restart policy.

Deleting Pods: When a pod is deleted, either explicitly by a user or as part of a scaling operation or
deployment update, the kubelet on the node where the pod is running receives instructions from the
Kubernetes control plane to terminate the pod and its associated containers. The kubelet ensures
that the containers are gracefully terminated, allowing them to clean up resources and execute any
termination scripts if necessary.
2^) Kubeproxy:- kube-proxy is a crucial component for managing networking within a Kubernetes
cluster, facilitating communication between pods and nodes and providing load balancing for
services.
Note: Pods get their IP by Container Network Plugin like Calico and Flannel.

Pod-to-Pod Communication (all pods can communicate with each other on all node): Kube-proxy
helps facilitate communication between all pods within the cluster, whether they are running on the
same node or different nodes. This means that any pod can communicate with any other pod using
their IP addresses.

Node-to-Pod Communication(all nodes can communicate with all pods): Kube-proxy also plays a
role in allowing nodes within the cluster to communicate with pods. This is important for various
cluster-level services, such as the kubelet on each node, which communicates with pods to manage
their lifecycle.

3^) Container runtime engine:- The container runtime creates a container within a pod based on
the instructions provided by the Kubelet. (Pulling and Pushing images.)
Liveness Probe:

Liveness Probe check the state of container and ensure that container always keep in live state.

Readiness Probe:

Readiness Probe heck the state of container and ensure that container always ready to accept
traffic.

Startup Probe:

We configure Startup Probe for containers, those running databases or other services that need
more time to start.

============================================================================

Master Node Components

<>API Server(App) <>ETCD(App) <>Controller Manager(App) <>Scheduller Manager(App) <>Core
DNS(App) <>CNI Driver(App) <>Kubelet(Agent) <>Docker Engine(DeamonD) <>Kube-Proxy(App)

Worker Node Components

<>Kubelet(Agent) <>Kube-Proxy(App) <>Continer Runtime Engine(DeamonD) <>CNI Driver(App)

============================================================================
==

Pod:- Pod is group of one or containers with shared storage, network resources and specification
for how to run the containers.

Pods Restart Policies:

Always (default):

With the "Always" restart policy, the kubelet will restart containers within the pod whenever they
exit, regardless of the exit status or reason.

This is the default policy, and it's commonly used for applications where continuous availability is
critical.

OnFailure:

With the "OnFailure" restart policy, the kubelet will only restart containers within the pod if they
exit with a non-zero status or encounter an error.

This policy is useful for applications that can tolerate occasional failures or errors and should be
restarted in such cases.

Never:

The "Never" restart policy indicates that the kubelet should never automatically restart containers
within the pod, regardless of their exit status.

This policy is typically used for batch jobs or applications that should not be restarted
automatically.

Work Flow of Pod creation

Cluster:- Cluster is a set of nodes (servers) that work together to run containerized applications. A
cluster consists of a master node and one or more worker nodes. The master node is responsible for
managing the cluster, while the worker nodes are responsible for running the containerized
applications.

Note: When you use kubectl to apply a deployment in YAML format, kubectl converts the YAML file
into JSON format internally. After converting it to JSON, kubectl sends a request to the
Kubernetes API server to create a pod based on the provided deployment configuration.

Scheduling
=====================================================================================

1) Deployments:- Deployments is use to tell kubernetes how to create or modify instances of

pods.

Declarative Configuration: You define the desired state of your application in a Deployment
manifest, typically written in YAML or JSON. This includes specifying which container images to
use, how many replicas (copies) of the pods should be running, and how to update the application
when changes are needed.
Rolling Updates: Deployments support rolling updates and rollbacks. When you make changes to the
Deployment configuration (e.g., updating the container image version), Kubernetes automatically
manages the transition from the old version to the new version, ensuring minimal downtime.

Replica Sets: Under the hood, Deployments use Replica Sets to maintain a specified number of pod
replicas. The Replica Set ensures that the desired number of pods is running and replaces any pods
that fail.

Scaling: You can easily scale the number of replicas up or down using the Deployment configuration,
allowing you to adjust the application's capacity based on demand.

Self-healing: Deployments automatically replace failed pods with new ones to maintain the desired
state, helping to ensure the application's availability.

Version Control: Deployments can manage multiple versions (revisions) of your application. This
allows you to roll back to a previous version if needed.

Desired State Reconciliation: Kubernetes continuously monitors the cluster to make sure the actual
state matches the desired state defined in the Deployment. If there are discrepancies, Kubernetes
takes actions to reconcile them.

2) Namespace:- Namespace are a way to organize cluster into virtual sub-cluster.

Namespace for Application Categorization: By utilizing namespaces, you can categorize your
applications based on their functionality, teams, or any other relevant criteria. This segregation
makes it easier to monitor and manage the state of pods within each namespace. For instance, you
can quickly check the status and health of pods deployed in a specific namespace without having to
sift through all the resources in the cluster.

User Access Control: Kubernetes allows you to grant specific users or teams access to namespaces,
and you can tailor their permissions accordingly. This fine-grained access control enables you to
assign roles to users within a namespace. For example, you can create a user who has permissions
limited to deploying and deleting applications within a particular namespace, ensuring a level of
isolation and security.

Horizontal Pod Autoscaling (HPA): HPA is a powerful feature that helps manage application
performance and resource utilization. Within a namespace, you can configure HPA to dynamically
scale the number of pods in response to varying traffic loads. For instance, if your namespace
currently has three pods running and experiences a surge in incoming traffic, HPA can automatically
scale up the pod count to handle the increased load. Conversely, it can also scale down when the load
decreases, ensuring optimal resource utilization.

Resource Quotas: Kubernetes allows you to define resource quotas at the namespace level. This
means you can allocate specific resource limits, such as CPU and memory, to a particular namespace.
This is particularly useful for ensuring fair resource distribution among different teams or
projects, preventing one namespace from monopolizing cluster resources and impacting the
performance of other namespaces.
Limit Ranges: Limit ranges can be set within namespaces to further control resource consumption.
These limits are applied to objects like containers (Pods) running inside the namespace. By
specifying limit ranges, you can establish constraints on the CPU and memory usage of individual
pods, preventing them from exceeding defined limits and potentially causing resource contention
issues.

3) Services:- Services in Kubernetes enable communication between frontend and backend

pods and provide load balancing for incoming traffic from frontend pods to backend pods
(Services uses TCP bydefault).

StaticIP address can be used for communication between frontend and backend pods, but it's
typically used for external access to the service.

When a client sends a request to the Service, the Service distributes the incoming traffic evenly
among the pods that match the specified label selector.

Type of Services:
NodePort:

 NodePort provides a range of ports from 30000 to 32767 for external access to
applications within the same network.
 You can access your application by using the Node's IP address along with the specified
NodePort on any node within the same network.
 For example, if the IP address of one of your nodes is 192.168.1.100 and you have a
NodePort service that listens on port 31000, you can access your application by going to
http://192.168.1.100:31000 in a web browser or using a tool like curl.
CluserIP: Frontend pods in a Kubernetes cluster can communicate with backend pods by making
requests to the ClusterIP and port of the Service within the same cluster.

Load-Balancer: When a client sends a request to the Service, the Service distributes the incoming
traffic evenly among the pods that match the specified label selector.
ExternalName Service: With an ExternalName Service in Kubernetes, your pods can communicate
with external resources using a DNS name rather than the IP addresses of the pods.

Label Selector:- Selecting kubernetes object with the help of labels are called label selector.

Taint and Toleration:-

 Taint and Toleration work together to ensure that pods are not scheduled onto unscheduled
onto inappropriate nodes.
 One or more taints are applied to a node.
 Taints are applied to the nodes and tolerations are applied to pods.

Type or Taints – NoSchedule, Prefer NoSchedule and NoExcute

Apply Taints and Toleration

Note: When using labels and selectors, pods can be scheduled on any node, whether labeled or
unlabeled. However, when employing taints and tolerations, a pod will only be scheduled on nodes
with matching tolerations for the corresponding taints, allowing for more fine-grained control over
pod placement.

Node Affinity: - Node affinity ensure that pods are hosted on particular nodes.

Resource Limit and Request

Limit:- Resource limit means set the maximum amount of RAM or CPU for pods.

Request:- Resource request means set the minimum amount of RAM or CPU for pods.

DaemonSets:- DaemonSets ensures that all nodes run a copy of a pod. As nodes are added to the
cluster, pod are added to them. As nodes are removed from the cluster, those pods are garbage
collected. Deleting a daemonsets will clean up the pods it created.

Example: kube-proxy
Use case: Monitoring Solutions

Static Pods: These critical Kubernetes components, including kube-scheduler, kube-controller-

manager, kube-etcd, kube-proxy, and network plugins like Calico, are run as static pods to ensure
their availability and independence from the control plane. Static pods are managed directly by
kubelet on each node, enabling them to start even if the control plane is offline, enhancing cluster
resilience and reliability.

They are defined by manifest files placed in a specific directory on the node and are automatically
started and managed by the Kubelet.

Use Cases: Static pods are commonly used for running essential infrastructure components like
CNI plugins, storage drivers, and other node-level services that need to start as soon as the node
boots.

- command: oc debug node/ip-10-0-233-181.us-east-2.compute.internal

output: |
sh-4.4# cd /etc/kubernetes/manifests/
sh-4.4# ls
demo-static-pod.yaml
sh-4.4# exit
- command: oc get po
output: |
nginx-pod-ip-10-0-233-181.us-east-2.compute.internal 1/1 Running 0 7m23s

Multiple Schedulers: Kubernetes allows you to add custom schedulers alongside the default
scheduler. This is useful when you have specialized requirements that the default scheduler might
not address. Custom schedulers are implemented as independent components or controllers within
the Kubernetes control plane. They watch for unscheduled pods and, when one appears, they decide
which node to place it on.

Rollout:- Rollout have ability to deploy application to latest minor version.

kubectl create deployment nginx-deploy --image=nginx:1.14.1

deployment.apps/nginx-deploy created
[lab-user@bastion ~]$
[lab-user@bastion ~]$ kubectl set image deploy nginx-deploy nginx=httpd --record=true
kubectl set image deploy nginx-deploy nginx=alpine
deployment.apps/nginx-deploy image updated
[lab-user@bastion ~]$ kubectl rollout history deploy/nginx-deploy
deployment.apps/nginx-deploy
REVISION CHANGE-CAUSE
1 <none>
2 kubectl set image deploy nginx-deploy nginx=httpd --record=true
3 kubectl set image deploy nginx-deploy nginx=httpd --record=true

Rollback:- Rollback have ability to restore application to older working version.

[lab-user@bastion ~]$ kubectl rollout undo deploy/nginx-deploy --to-revision=2

deployment.apps/nginx-deploy rolled back
[lab-user@bastion ~]$ kubectl rollout history deploy/nginx-deploy
deployment.apps/nginx-deploy
REVISION CHANGE-CAUSE
1 <none>
3 kubectl set image deploy nginx-deploy nginx=httpd --record=true
4 kubectl set image deploy nginx-deploy nginx=httpd --record=true

Note: We can also do changes in deployment my editing the deployment

Kubectl edit deployment/deployment-name

Command and Arguments:

Command: Primary command executed by a container.

Args: Additional parameters passed to the command.

Example: command: ["echo"], args: ["Hello"] outputs "Hello".

[lab-user@bastion ~]$ cat date-logger-pod.yaml

apiVersion: v1
kind: Pod
metadata:
name: date-logger-pod
spec:
containers:
- name: date-logger-container
image: ubuntu:latest # You can use any Linux-based image
command: ["/bin/sh", "-c"]
args:
- |
while true; do
date
sleep 60 # Sleep for 60 seconds (1 minute)
done

[lab-user@bastion ~]$
[lab-user@bastion ~]$ kubectl apply -f date-logger-pod.yaml
pod/date-logger-pod created
[lab-user@bastion ~]$ kubectl logs -f date-logger-pod
Thu Sep 21 19:58:23 UTC 2023
Thu Sep 21 19:59:23 UTC 2023
^C
[lab-user@bastion ~]$

Environment Variables: Environment Variables are key-value pairs used to configure, customize,
and pass information to containers, enhancing application flexibility and portability.

controlplane $ cat Dockerfile

FROM nginx
Run apt-get update
ENV WORDPRESS_VERSION 4.2.2 # This is Environment Variable
ENV WORDPRESS_USER admin # This is Environment Variable
EXPOSE 80
controlplane $

Exposing Pod information to the containers through environment variables.

There are two ways to expose pod and container fields to a runing containers.
 Environment Variables
 Volume Files
Note: These are also called as a Downward API.

Environment Variables
Pod level fields Container level fields
(fieldRef) (resourceFieldRef)

metadata.name metadata.labels['<KEY>'] resource: limits.cpu

the pod's name the text value of the A container's CPU limit
pod's label named <KEY> (for
example, metadata.labels['mylabel'
metadata.namespace resource: requests.cpu
])
the pod's namespace A container's CPU request
spec.nodeName
metadata.uid resource: limits.memory
the name of the node where the Pod is
the pod's unique ID executing A container's memory limit

metadata.annotations['<KEY>'] status.podIP resource: requests.memory

the value of the pod's annotation named <KEY> (for the pod's primary IP address (usually, its A container's memory request
example, metadata.annotations['myannotation IPv4 address)
'])

Now we’ll pass these fields to container as environment variables.

controlplane $ cat envars-2.yaml

apiVersion: v1
kind: Pod
metadata:
name: env-var-2
labels:
purpose: demonstrate-env-var-2
spec:
containers:
- name: env-var
image: wordpress
env:
- name: WORDPRESS_VERSION
value: "5.2.2"
- name: WORDPRESS_USER
value: "ubuntu"
 command: ["echo"]
args: ["$(WORDPRESS_VERSION) $(WORDPRESS_USER)"]
controlplane $ k get po
NAME READY STATUS RESTARTS AGE
env-var-2 0/1 Completed 2 (47s ago) 3m2s
controlplane $ k logs env-var-2
5.2.2 ubuntu
controlplane $

ConfigMap:- ConfigMap in Kubernetes is an API resource that allows you to store and manage
configuration data separately from your container images and pods. ConfigMaps are commonly used
to decouple configuration settings from application code, making it easier to manage configuration
across different environments and to update configuration without modifying container images.

Use Cases for ConfigMaps:

Environment Configuration: Store environment-specific configuration settings like database

connection strings, API endpoints, or feature flags. This allows you to use the same container image
in different environments (e.g., development, staging, production) with environment-specific
settings.

Configuration Files: Store configuration files that are mounted as volumes in pods. For example, you
can use ConfigMaps to store configuration files for web servers, proxy settings, or application-
specific settings.

Command-Line Arguments: Pass command-line arguments to containers running in pods using

environment variables defined in a ConfigMap. This makes it easy to modify the behavior of your
containers without changing the container images.

Secrets Decoupling: In some cases, ConfigMaps are used to store non-sensitive configuration data,
while secrets are used for sensitive data like passwords and API keys. This separation enhances
security by allowing different access controls and handling of sensitive and non-sensitive data.

Centralized Configuration: Centralize configuration management by using ConfigMaps across

multiple applications or microservices, ensuring consistency and easier maintenance.

Example Use Case:

Let's say you have a web application running in Kubernetes, and you want to configure its API
endpoint URL. Instead of hardcoding the URL in your application code or Docker image, you can
create a ConfigMap that stores the API URL and then reference that ConfigMap in your
application's deployment. This way, you can change the API URL without rebuilding the image or
modifying the application code, making it more flexible and adaptable to different environments.

Secret:- Secrets in Kubernetes are resources used to store sensitive information, such as
passwords, API keys, and tokens. They allow you to securely manage and distribute confidential
data to pods and containers without exposing them in the configuration files or environment
variables.

Use Cases:

Database Credentials: Storing usernames and passwords for databases used by applications.

API Keys and Tokens: Safely managing authentication tokens and API keys required for
communication with external services.

===========================================================================================

ConfigMaps stores non-sensitive configuration data, like application configurations and commands, in
key-value pairs or plaintext. Configmap separates application configuration and commands from the
application code and allows for easy updates to the configuration without disrupting the running
application.

Secret stores sensitive data such as API keys, tokens, and credentials in base-64 encoded.
Applications can use Secrets during authentication processes, for example, when pulling images
from private repositories.

===========================================================================================

TLS Certificates: TLS provide secure communication during transfering data from one server to
another server.

SSH Keys: ssh store private key and provide authentication during taking access of remote server.
Note: Secrets and ConfigMaps in Kubernetes are scoped to a single namespace.

Networking

Path-Based Routing:

 Path-based routing is the most common type of routing used in Ingress.

 It allows you to route traffic to different services based on the URL path of the incoming
request.
 For example, you can route requests to http://mycourses.com/courses to one service and
requests to http://mycourses.com /blogs to another service.

Host-Based Routing:

Ingress resources can define rules for host-based routing, allowing you to route traffic to
different services based on the hostname (domain name) in the HTTP request's Host header.

For example, you can route requests for http://exams.mycourses.com to one service and requests
for http://books.mycourses.com to another service.
TLS/SSL Termination:

 Ingress resources can specify SSL/TLS certificates, enabling secure HTTPS connections.
 The Ingress controller can terminate SSL/TLS at the edge and then route traffic to the
appropriate backend service over HTTP.
Network Policies:

Network Policies allow you to control both incoming and outgoing traffic to and from pods. They
define rules and restrictions for how pods can communicate with each other, adding an additional
layer of security to your containerized applications.

As per the below snapshoot we will create a network policy for Database pod then we’ll define which
pod will communicate with our database pod by which port and we can can also define how outgoing
traffic will go to which pod with which port.

Different scenarios and Cases of Network Policy:

By the below network policy, all backend pods with same label can communicate with database pod
which is running in the same namespace where the Network Policy is created.

If I create a NetworkPolicy in a specific namespace with a podSelector that matches a certain

label, it will only control traffic to pods within that same namespace that have that label.

If your backend pods are running in one namespace, and your database (db) pods are running in a
different namespace, then you may need to specify the namespaceSelector field in the
NetworkPolicy YAML file to allow communication between these namespaces.

By using the ipBlock field in Kubernetes Network Policies, we can allow pods within the cluster to
communicate with external destinations, including pods or IP ranges outside of the cluster, by
specifying CIDR ranges.
StatefullSet

StatefulSets are used to manage stateful applications, such as databases and other distributed
systems, where each pod in the set needs to have a stable and unique network identity and
persistent storage.
StatefulSets include running databases like MySQL, PostgreSQL, or MongoDB, as well as
distributed systems like Apache Kafka, Apache ZooKeeper, and Elasticsearch, where each node
needs a unique identity and persistent storage.

What happened if we deploy stateful application with deployment.

We have deployed three stateless pods and three stateful pods using Deployments and
StatefulSets. When a stateless pod requests to write data to a stateful pod through a service, the
service connects to one of the stateful pods. However, when the stateless pod attempts to read
data from the stateful pod at a later time, the service might connect to a different stateful pod
that does not have the most up-to-date data.

Stable Network Identity: StatefulSets in Kubernetes provide stable hostnames to pods, which
helps establish a stable network identity for each pod.
For example, if you have a StatefulSet named "web," the pods within that StatefulSet might have
hostnames like "web-0," "web-1," "web-2," and so on.

Headless Services: Headless Service provides DNS entries for each pod in the StatefulSet, with
stable DNS names based on the pod's ordinal index. For example, if you have a StatefulSet named
"web" and it creates pods "web-0," "web-1," and "web-2," the Headless Service will provide DNS
entries like "web-0," "web-1," and "web-2," allowing other pods in the cluster to discover and
communicate with each individual pod using its stable DNS name.

Stable IP address of Pods:

When pods are created as part of a StatefulSet, the network plugin is responsible for assigning
them stable IP addresses. This assignment is often based on the pod's name and position within the
StatefulSet. For example, if you have a StatefulSet named "web" with pods "web-0," "web-1," and
"web-2," the network plugin might assign IP addresses in a predictable manner like 10.0.0.1, 10.0.0.2,
and 10.0.0.3.
 Storge

Volume(Directory):-

 Volume is directory inside our containers.

 We can access volume of a stop container.
 We have to declare a directory as a volume only while creating container.
 We can share one volume across any number of containers.
 We can share volume in two ways containers to containers and host to containers.

Note:
Storing application logs within a pod poses a risk: if the storage becomes unavailable, it could lead
to pod crashes and potential data loss.

When we store application logs on the node where the application is running, if the pod gets
rescheduled to a different node, it loses access to its previous log data.

PV (Persistent Volume) and PVC (Persistent Volume Claim):

PV: Persistent Volumes (PVs) in Kubernetes are used to provide storage to pods, enabling them to
store data persistently. PVs also allow pods to claim and use storage resources beyond the lifetime
of a pod. This means that data stored in a PV remains available even if the pod is terminated or
rescheduled to a different node.

Persistent Volume Reclaim Policy:-

Retain – User can delete PVC but not PV.

Delete – User can delete PVC and PV both.

Recycle – User can recycle PVC and PV both.

PVC: Persistent Volume Claims (PVCs) in Kubernetes are used to claim storage resources (data) for
pods. PVCs allow pods to request and use storage from Persistent Volumes (PVs).

Persistent Volume Access Modes:-

ReadWriteOne – Read write by single node.

ReadOnlyMany –Read only by many nodes.

ReadWriteMany – Read write by many nodes.

Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) in Kubernetes are bound based on a
combination of factors, including:

 Size: The requested storage size in the PVC must not exceed the available storage size in
the PV.
 Access Mode Policy: The access modes specified in the PVC must match or be compatible
with the access modes defined in the PV.
 Storage Class: PVs and PVCs can be associated with a Storage Class, which can affect the
binding process by specifying dynamic provisioning rules.
 Labels and Selectors: Labels on PVs and selectors in PVCs can be used to match and bind the
appropriate PV to a PVC based on specific criteria.
 Volume Modes: PVs and PVCs should match in terms of volume mode, which can be either
"Filesystem" or "Block."

Storage Class:- StorageClass in Kubernetes allows users to request a specific type of storage for
their workloads without needing to pre-create PersistentVolumes (PVs). It provides dynamic
provisioning, meaning that when a user creates a PersistentVolumeClaim (PVC), Kubernetes
automatically provisions a matching PV based on the StorageClass configuration.

StorageClass Volume Binding Mode: This specifies how Persistent Volumes (PVs) are bound to
Persistent Volume Claims (PVCs). Common options are "Immediate" (PV is provisioned immediately
when the PVC is created) and "WaitForFirstConsumer" (PV is provisioned when a pod using the PVC
is scheduled).

Dynamic provisioning V/S Static provisioning

In dynamic provisioning, users do not need to pre-create PersistentVolumes (PVs). When they
create a PersistentVolumeClaim (PVC) with a StorageClass that supports dynamic provisioning,
Kubernetes automatically creates a matching PV based on the PVC's specifications. Users only need
to define the PVC, and Kubernetes takes care of provisioning the underlying storage.

In static provisioning, users must pre-create PersistentVolumes (PVs) before they create
PersistentVolumeClaims (PVCs). Users select an existing PV that matches their requirements when
creating a PVC. This means that administrators or users need to manage the PVs and ensure that
they are available and properly configured before the PVCs can be used.
Note: Persistent Volume Controller (part of the Kubernetes control plane) will automatically create
a Persistent Volume (PV) based on the storage requirements specified in the PVC.

CSI (Container Storage Interface):- CSI define how an orchestration solution communicates with
container runtime.

CSI has to major plug-in, Controller plug-in runs on master node and node plug-in runs on worker
nodes.

MultiContainer: A multi-container pod is a pod that contains more than one container. Containers
within the same pod share the same network namespace, storage volumes, and are scheduled to run
on the same node. This design allows these containers to communicate with each other more easily
and share data without needing to set up complex networking configurations.

1) Sidecar Helper Container: You can deploy a helper container alongside your main application
container to act as a logging and monitoring agent. This helper container will collect your
application logs and store them in a designated storage location.
2) Adapter Helper Container: An adapter container reads and formats the logs generated by
the main application container. Its primary purpose is to take the raw logs produced by the
main application container and convert them into a specific format that is more suitable for
consumption by various logging and monitoring tools.
3) Ambassador Helper Container: Ambassador container works as a proxy to establish secure
connection using localhost between databases and main container.

Init Containers: Init containers run before the main container to perform various tasks such as
cloning code from GitHub, installing libraries, establishing database connections, preloading data,
and generating configuration files.
Once init container have reached the Completed state, Kubernetes will start the main container in
the pod.

 Cloning Code from GitHub: Init containers can be used to fetch application code from a
version control system like GitHub, ensuring that the code is available before the main
container starts.
  Library Installation: You can use init containers to install necessary libraries, dependencies,
or packages required by the main application.
 Database Connection Establishment: Init containers can be used to establish connections
with databases or other external services. This ensures that the main container doesn't
start until the required database connections are ready.
 Data Preloading: Init containers can populate shared volumes or database tables with initial
data needed by the main application.
 Configuration File Generation: They can generate configuration files based on environment
variables or external configuration sources, which the main container will later use.

Networking
==================================================================

DNS (Domain Name System):- DNS turns domain into IP address, which allows browsers to get to
websites and other internet resources.

Core DNS:- Core DNS is a flexible, extensible and Kubernetes cluster DNS server.

Network Namespace:- Network Namespace setting up containers on virtual environments.

Docker Networking:- Docker networking allow a container to attach with many networks.

CNI (Container Networking Interface):- Pods can communicate with each other even when they
are scheduled on different worker nodes, and this communication is made possible by the Container
Network Interface (CNI) plugin

Cluster Networking:- Cluster networking allows communication between different pods.

Container Network:-

 Container to container communication on same pod happens through local host within the
containers.
 Pod to pod communication on same worker node happens through Pod IP.

Security

===========================================================================================

RBAC(Role Back Access Control):- Role back access control define who has access of
Kubernetes cluster and what permissions they have.

Who: You can specify which users, groups, or service accounts have access to your Kubernetes
cluster.
What: RBAC defines what actions (verbs) these users, groups, or service accounts can perform
within the cluster, such as creating, deleting, or modifying resources like pods, services, config
maps, and more.

Authentication: During the authentication process in Kubernetes, the API server is responsible
for checking the identity of the user and service account (user-administrator and developer,
service account-bots and all application which is access cluster to retrieve data like monitoring
application) that is trying to perform a task within the cluster and determining whether that
entity is valid or not.

Authorization methods:

Certificate Authentication: You can authenticate to the Kubernetes cluster by providing a client
certificate and key pair. This method is often used for user authentication and is considered
secure.

Bearer Token Authentication: Kubernetes allows users and service accounts to authenticate by
providing a bearer token. These tokens can be stored in files or provided as part of an HTTP
request's authorization header.

Password Authentication: While less common, some Kubernetes setups do support password-based
authentication. However, it's typically not recommended for production environments due to
security concerns

RBAC v/s ABAC

RBAC: By Role back access control we can create role and assign with many users.

ABAC: By attribute base access control we can create a policy and assign it to the single user.

RBAC have four objects Role, ClusterRole, Rolebinding and ClusterRoleBinding.

Role: Role allows users, groups, or service accounts to perform actions like "get," "watch," "list,"
and "create" on namespace-wide objects like pods, deployments, services pvc, configmap and
secrets.
ClusterRole: ClusterRole allows users, groups, or service accounts to perform actions like "get,"
"watch," "list," and "create" on cluster-wide objects like Node, Namespace, PV, ClusterRole and
ClusterRoleBinding.

Rolebinding: RoleBinding is used to bind users, groups, or service accounts with roles within a
particular namespace.
ClusterRoleBinding: ClusterRoleBinding is used to bind users, groups, or service accounts with roles
for cluster-wide objects.
ServiceAccount:

When a logging or monitoring application running outside the Kubernetes cluster needs to collect
data from Pods inside the cluster, the following process occurs:

1. The application sends a request to the Kubernetes API server.

2. The Kubernetes API server authenticates the request using a ServiceAccount token, which
serves as a form of identity.
3. Once authenticated, the API server authorizes the request based on predefined roles and
permissions. This authorization is achieved by binding the ServiceAccount to a specific set
of permissions using a RoleBinding or ClusterRoleBinding.

So, to summarize, ServiceAccount and its associated token handle authentication, while the
authorization is managed by binding the ServiceAccount to roles using RoleBinding or
ClusterRoleBinding.

Note: Kubernetes, if you do not specify a ServiceAccount in the configuration of a Pod, Kubernetes
will automatically assign the default ServiceAccount for that namespace to the Pod. Each
namespace in Kubernetes has a default ServiceAccount created by default.
We can get serviceaccount token in this mount path inside pod
/var/run/secrets/kubernetes.io/serviceaccount

Note: If a human user want to perform some task in kubernets so it will need user name with role
and rolebinding but if a application want to perform some task then it will need serviceaccount with
role and rolebinding.

Security Context: Security Context allow us to define and control the security settings and
permissions of containers within a pod. These settings help improve the security and isolation of
containers and workloads running in a Kubernetes cluster.

TLS(Transport Layer Security):- TLS enable encrypted communication between browsers and web
applications.

Security Certificate:-

 PKI certificate secure TLS.

  Client certificate secure API.
 Generate security certificate :- We can generate certificate manually with the help of
easyrsa, openssl and cfssl.

EFK (Elasticsearch, Fluentd and Kibana)

Fluentd (EFK Stack's Log Collector):

 Fluentd runs as a DaemonSet on all nodes, collecting logs and forwarding them to
Elasticsearch or another log storage system.

Elasticsearch (EFK Stack's Storage):

 Elasticsearch stores log data as key-value pairs, making it easy to search and visualize log
information.

Kibana (EFK Stack's Visualization Tool):

 Kibana offers a user-friendly web interface for exploring and visualizing log data with
support for various visualization formats, including charts, graphs, maps, and time-series
data.

Note: We can use Logstash replacement of Fluentd (ELK).

Prometheus: Prometheus collects metrics from various sources, which can include application nodes,
servers, containers, and more. It is a flexible monitoring and alerting system that can collect
metrics from a wide range of targets.

Grafana: Grafana is used to create dashboards and visualize the metrics collected by Prometheus,
as well as other data sources. You can design custom dashboards to display and analyze these
metrics.

Grafana also provides features for setting up alerts based on the consumption of resources or
any other metric of interest. You can define alert rules in Grafana, and when those rules are
triggered, notifications can be sent to alerting channels like email, Slack, or other notification
services.

Dynatrace: Dynatrace is an application performance monitoring (APM) platform that provides

automatic, AI-powered insights into application performance and user experience.

OneAgent continuously monitors log files generated by the applications and services running on the
host. OneAgent provide logs to Dynatrace.