API Server performs all the administrative tasks on the master node. A user sends the rest commands to the API server, which then validates the requests, then processes and executes them.

Non-terminating control loops that regulate the state of the Kubernetes cluster is managed by the Control Manager. Now, each one of these control loops knows about the desired state of the object it manages, and then they look at their current state through the API servers.

saves the resulting state of the cluster as a distributed key-value store.

schedules the work to different worker nodes. It has the resource usage information for each worker node. Then the scheduler schedules the work in terms of pods and services.

A worker node is a virtual or physical server that runs the applications and is controlled by the master node.

The pods are scheduled on the worker nodes, which have the necessary tools to run and connect them
By default, the Pod is only accessible by its internal IP address within the Kubernetes cluster

It listens to the API server for each service point creation or deletion. For each service point, kube-proxy sets the routes so that it can reach to it.

Kubelet is basically an agent that runs on each worker node and communicates with the master node making sure the containers are running in a pod

Vulnerability in the configuration of a pod can let the attacker get into a container and probe for weaknesses in a network, process, controls or file system.

Kubelets expose HTTPS endpoints which grant powerful control over the node and containers and by default Kubelets allow unauthenticated access to this API.

running on the same address as the kubernetes master
has a proxy namespace specifier (kube-dns)
The domain name service (DNS) is typically used for scheduling purposes (e.g. at Pods or Service level) within the cluster.

runs on the same address as the master but with a fully qualified namespace (kubernetes-dashboard) to uniquely distinguish it from the other services currently running.

Minikube creates a VM on your local machine and deploys a simple cluster containing only one node.
The minikube CLI provides basic bootstrapping operations such as: start, stop, status and delete.

minikube start
minikube dashboard
minikube dashboard --url

On minikube, the LoadBalancer type (which is the type that we need to expose a container as a kubernetes service) makes the Service accessible through the minikube service command.
minikube service podName

One way to create a Deployment using a .yaml file like the one above is to use the kubectl apply command in the kubectl command-line interface, passing the .yaml file as an argument.

kubectl apply -f dep-file.yaml

It is a Kubernetes controller that matches the current state of your cluster to the desired state mentioned in the Deployment manifest

used to manage stateful applications. It manages the deployment and scaling of a set of Pods, and provides guarantee about the ordering and uniqueness of these Pods.

it doesn’t create ReplicaSet rather itself creates the Pod with a unique naming convention. e.g. If you create a StatefulSet with name counter, it will create a pod with name counter-0, and for multiple replicas of a statefulset, their names will increment like counter-0, counter-1, counter-2, etc

A DaemonSet is a controller that ensures that the pod runs on all the nodes of the cluster. If a node is added/removed from a cluster, DaemonSet automatically adds/deletes the pod.

useful in case of Databases especially when we need Highly Available Databases in production as we create a cluster of Database replicas with one being the primary replica and others being the secondary replicas. The primary will be responsible for read/write operations and secondary for read only operations and they will be syncing data with the primary one.

usually used for stateless applications. However, you can save the state of deployment by attaching a Persistent Volume to it and make it stateful, but all the pods of a deployment will be sharing the same Volume and data across all of them will be same.

Create a service
By default, the Pod is only accessible by its internal IP address within the Kubernetes cluster.
to make the pod/container accessible from outside the kubernetes virtual net > we have to expose as kubernetes service

kubectl expose deployment hello-node --type=LoadBalancer --port=8080
type=LoadBlanacer indicates that we want to expose our service outside of the cluster

kubectl cluster-info

create a deployment that manages a pod
example >
kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4
kubectl get pods
kubectl get events
kubectl config view

retrieving yaml files from deployments/statefulets..
example
kubectl get statefulset
kubectl describe statefulset deplymentName > file.yaml
kubectl get configType configName -o yaml > file.yaml

most efficient as he the does the initial setup,and operator will then manage the running prometheus setup
no config is needed out of the box deployment

node_exporter being a daemonset
is component which runs on every worker node of kubernetes

using an operator (kubernetes operatorss )
we can think of it as manager of ts prometheus componenents
for example as we know statfulsets and and deploymenys will manage their pod replicas (restarting when they die. making them accessible .. etc ) in the same way operator manage combination of statefulsets and deploymets.. that make prometheus as one unit

we just need to find a prometheus operatr and deploy it as one unit

creating all configs in yaml files ourself

• prometheus
• alertmanager
• grafana
  configs maps and secrets that we need in the right order for the reason of dependencies
  not so many use cases and we need to know that we are doing

The main entry point into the kubernetes cluster

Overlay Network

container inherits the IP given to the pod that belongs to

• containers within same pod communicate with each other through the localhost
• container accross diffrent pods communicate using the IP they inherited within through pod network

is the standard way to expose a service1 to the internet. willl generate a load balancer and give us an IP address and forward all traffic to this service
spec:type: loadbalancer
spec:ports:-name:http/port:80/targetport:8080/protocol:TCP

to authenticate users to the given kubernetes cluster. accounts are authenticated by the API server

authenticate machine lvel processes running in the pod to get authenticated ro get access to the kubernetes cluster and are also authenticated by the API server

Non-terminating control loops that regulate the state of the Kubernetes cluster is managed by the Control Manager. Now, each one of these control loops knows about the desired state of the object it manages, and then they look at their current state through the API servers.

schedules the work to different worker nodes. It has the resource usage information for each worker node. Then the scheduler schedules the work in terms of pods and services.

The pods are scheduled on the worker nodes, which have the necessary tools to run and connect them
By default, the Pod is only accessible by its internal IP address within the Kubernetes cluster

It listens to the API server for each service point creation or deletion. For each service point, kube-proxy sets the routes so that it can reach to it.

Kubelet is basically an agent that runs on each worker node and communicates with the master node making sure the containers are running in a pod

Kubelets expose HTTPS endpoints which grant powerful control over the node and containers and by default Kubelets allow unauthenticated access to this API.

A worker node is a virtual or physical server that runs the applications and is controlled by the master node.

API Server performs all the administrative tasks on the master node. A user sends the rest commands to the API server, which then validates the requests, then processes and executes them.

saves the resulting state of the cluster as a distributed key-value store.

are the containers that should run along with the main container in the pod. This sidecar pattern extends and enhances the functionality of current containers without changing them.

Non-terminating control loops that regulate the state of the Kubernetes cluster is managed by the Control Manager. Now, each one of these control loops knows about the desired state of the object it manages, and then they look at their current state through the API servers.

schedules the work to different worker nodes. It has the resource usage information for each worker node. Then the scheduler schedules the work in terms of pods and services.

The pods are scheduled on the worker nodes, which have the necessary tools to run and connect them
By default, the Pod is only accessible by its internal IP address within the Kubernetes cluster

It listens to the API server for each service point creation or deletion. For each service point, kube-proxy sets the routes so that it can reach to it.

Kubelet is basically an agent that runs on each worker node and communicates with the master node making sure the containers are running in a pod

Kubelets expose HTTPS endpoints which grant powerful control over the node and containers and by default Kubelets allow unauthenticated access to this API.

A worker node is a virtual or physical server that runs the applications and is controlled by the master node.

are the containers that should run along with the main container in the pod. This sidecar pattern extends and enhances the functionality of current containers without changing them.

API Server performs all the administrative tasks on the master node. A user sends the rest commands to the API server, which then validates the requests, then processes and executes them.

saves the resulting state of the cluster as a distributed key-value store.

ETCd has its own certificate.