###### tags: `mis-notas` `k8s`
# Kubernetes with nana

* Oficial definition of Kubernetes:
* Open source container orchestration tool.
* Developed by Google
* Hleps you manage containerized application in different deployment environmets.
* physical
* virtual
* cloud
* hibrid

What problems does Kubernetes solve?
R.-

What are the tasks of an orchestration tool?
R.-


## The need for a container orchestration tool
- Trend from Monolith to Microservices
- Increased usage of containers
- Demand for a proper way of managing those hundreds of containers

What features do orchestration tools offer?
- High availability or no downtime
- That means your app has no downtime, so always is accesible by users
- Scalability or high performance
- The users have a very high response rate from the app
- Disaster recovery - backup and restore
- If infra has some problems like: data is lost o the servers explode or sth like that with the server center. The infrastructure has to have some kind of mechanism to pick up the data and restore it to the latest state. So the app doesn't loose any data.

# K8s COMPONENTS


-> Explanation of each of those components

## Node and Pod

### worker node or node
R.- simple server, physical or virtual machine and the basic component or the smallest unit of K8s is a `pod`

## POD
R.-
> sMALLEST UNIT OF k8s
> Abstraction over container
> Usually 1 app per Pod
> Each Pod gets its own IP address


## ephemeral = they can die very easily.
And when that happens and we lose a database container because container crashed beacuse the app crashed inside or because the nodes the server that i am running them on ran out resources the Pod will die and a new one will get created in its place and when that happens it will get assigned a new IP address.


This is incovenient if you are communicating with the database using the IP address because now you have to adjust it every time pod restarts and because of that another component of K8s called SERVICE


## SERVICE AND INGRESS


Service: Is a permanent IP address that can be attached to each Pod. So to say to each Pod.

- my-app will have its own service and
- DB will have its own service

The GOOD thing here is the LIFECYCLE of `service` and the `Pod` are not connected so even if the Pod dies the service and its IP address will stay.
-> don't have to change that endpoint anymore.

## We want our app to be accesible through a browser
R.- For this we would have to create an external service.
## External service
R.- is a service that opens the communication from exernal sources . BUT obviously you wouldn't want your DB to be open to the public requests. And for that you would create an EXTERNAL SERVICE.


## INTERNAL SERVICE
TYPE OF SERVICE THAT YOU SPECY WHEN CREATING ONE.

### for a secure protocol and friendly domain


For that there is another cmponent of Kubernetes called ingress.
So instead of service the request goes first to ingress and it does the forwarding to the service.


## SUMMARY:
we have 1 server and a couple of containers running and some services.

- Pod comunnicate each other using services

My app will have
- a DB endpoint (mongo-bd-service) that uses to communicate with the database
- Database URL usually in the build application

## ConfigMap
your external configuration of your application
- Contain
- Configuration like URLs of DB 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 configMaps contains
- Part of external configuration can also be DB username and password which may also change in the application deployment process but PUTTIN passwords or any credentials in a configMap, in a plain text format would be insecure, even though it's an external configuration


For this purpose Kuberntes has antoher component called SECRETS
(**)
And now if you change the name of the service the endpoint of the service you just adjust the configMap and that's it, YOU DON'T HAVE TO BUILD A NEW IMAGE AND HAVE TO GO THROUGH THIS WHOLE CYCLE.

(**)

## SECRETS

Is just like ConfigMap but the difference is that it's used to store
- secret data,
- credentials
- passwords
- certificates

is not stored in a plain text format but in base 64 encoded

Secrets can contain things like credentials
put it
- DB_USER=mongo-user
- BD_PWD=mongo-pwd

`The configMap you just connect it to your pod so that Pod can actually see those data and read from the secret.`


You can actually use the data from configMap or secret inside of your application Pod using for example
- Environmental variables or
- even a properties file

## VOLUMES