notes.txt

For any kind of networking for a component we have to use some services 
Types of services
  clusterIP - exposes a set of ports to other components in kubernetis cluster
  NodePort - exposes a set of port to outside world (development purpose)
  LoadBalancer 
  Ingres 


kubectl apply -f k8s - build all config file inside the directory k8s

worker deployment dosen't need a service component of type CLusterIp, because no other object needs to connect
to the worker. But worker has to connect to other objects.

kubectl logs <obect-name eg: pod-name> - give logs created by that pod 

 
volume - unlike in docker volume in kubernetis is and object that allows container to store data on a pod level 
volume and PVC are different 
volumes in kubernetis will live a container restart
But if a pods itself is recreated the pod will just dies off. So we don't usualyy use normal volume in kubernetis 

But persistence volume on the other hand reside outside the Pods and can live 


PVC - persistence volume claim 
whenever we want a persistent volume for our pods 
There are two types that are normally available to us. 

Persistent volume claim is like an advertisment where they show some predefined storage option
Statically provishoned persistent volume (if it is already defiend by kubernetis)
Dynamically provishoned persistent volume 


Inside PersistenceVolumeClaim component 
We can see AccessModes 
  ReadWriteOnce - can be used by a single NodePort
  ReadOnlyMany - multiple nodes can read from this 
  ReadWriteMany - Can be read and written to by many nodes 


We will define the password in secret in imperative way. Because if if write password in config file. That would defeat the purpose

CREATING A SECRET COMMAND 
kubectl create secret generic <secret-name> --from-literal key=value 
kubectl create secret generic pgpassword --from-literal PGPASSWORD=1234asdf

generic - It's a type of secret -- other available (docker-registry, tls)
--from-literal - we are giving secret key value pair at the time of writing this command rather than writing that inside a file. 


ingres setup will vay on local and on all cloud providers 

when traffic hit it hits the ingres controller + thing that route traffic routes to distinated services 

workflow 
traffic goes to Google cloud load balancer -> it forwards it to loadBalancer service(kubernetis service) which passes it to 
nginx pod created to ingres controller which then routes to different services 

when ingres is setup a default backend deployment is setup by default 
for health check purposes

we are using this way rather than builting a custom nginx because it knows most of kubernetis related stuffs and it also routes directly to pod in 
some instances rather than to services. 

// apply a ingres - nginx config file on the current cluster 
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml

travis installation inside docker 

gem install travis