Scrap page: things to investigate
All in K8 is RESTful with an unique HTTP path
Storage: persistent volume shouldn’t be on local storage! (can be still…)
Health check: several kind of health check are possible, liveness and readiness
Endpoint: service without cluster IP (like external service (p.83 and following))
AAA
Remote storage vs local: security benefits, cost issue
Session handling with replicaset: load balancing or microservices and/or RESTful and/or with DB
Cloud DB: managed (AWS), specialised (PostGres k8s), “regular”, key-value
Structure
General overview
Bare metal vs VM vs container vs orchestrated container
Why container are better adapted for cloud application
Security concern, a short overview
VM isolation vs containerization -> introduction to cgroups
Images can be compromised: VM can be created from a Linux distribution
Once created, VM by themselves can be more at risk (images are immutables)
Creating an image
Short introduction to CD/CI
Docker and docker-compose
K8s
With sample: Seek (1st) from current docker image/compose to simple pod to full deployment to helm/kustomize
Link to section
Storage on the cloud: scalability, issue of desynchronization, where to push the data.
Pod - Replica Sets - Deployments- DaemonSets
Decoupled applications can gain a lot, strongly coupled might not gain anything. Same for DB<->Application.
Volumes and why they are often not a good solution (aside for DB operators)
Different cases
We consider an application that need several containers: at minima one application and one database. Our example will evolve to cover a full data management application, with object storage, jobs, reverse-proxy.
1 pod with all
It is possible to set-up the containers to run in one pod, i.e. not decouple anything. It is the closest configuration to a docker compose installation and the one that will offer no benefit - only added complexity - over docker compose. Thus it should only be used as a starting point to learn Kubernetes, and basically is the use case we need to break down.
1 node with all
While 1 pod with all applications is rarely desirable, 1 node with all applications is the standard situation if you use Kubernetes on one machine only (so the node). It is also suitable for application that do not need to scale, do not store a lot of data, do not expect a lot of trafic, do not need to have redundancy. So a light web-application or a simple service will often need only one node.
1 node with 1 external DB
1..* nodes with simple load balancing, 1 external DB
1..* nodes with simple load balancing, 1 DB on 1st Node
1..* nodes with simple load balancing -> Daemon set for action on all nodes
1..* nodes with simple load balancing -> Object storage -> local HD on 1st Node, S3 instance
1..* nodes with load balancing, Redis
1..* nodes with load balancing -> DB managed by operator
1..* nodes with load balancing
– Then introduce an assembly
Vocabulary
How to debug & Troubleshooting
If possible a section with step by step troubleshooting instructions
kubectl exec –stdin –tty bare-seek-7dc954955d-h2xd8 – /bin/bash
inside container: more/vi/vim/ps -edf/check user/links/logs
Remove a deployment:
kubectl get deployments –all-namespaces
kubectl delete -n NAMESPACE deployment DEPLOYMENT_NAME
Not enough ressources allocated: one of the application process can be killed by the Linux watchdog (Out Of Memory (OOM) killer). In our case the main executable:
[1]+ Killed bundle exec puma -C docker/puma.rb
Do the simplest setup-> from a docker command line use docker to docker-compose. If possible it is better than to try from a complex docker compose. Then kompose.
Using kompose probably a good idea to remove env variable then extract them later (to check more)