initial commit

This commit is contained in:
2024-06-07 22:37:18 -04:00
commit 207a38f1e3
41 changed files with 59014 additions and 0 deletions
+65
View File
@@ -0,0 +1,65 @@
## Worker Node
can be a physical server, virtual machine, etc
made up of........
## pods
- a wrapper over a container so that Kubernetes can replace them if necessary
- there is usually 1 application per pod (or 1 application with a helper)
**pods are EPHEMERAL** (they can die very easily)
★ for example, if the app contained in the pod's wrapped container crashes, runs out of resources, etc
when this happens, a new pod is created in it's place, with a new address.
To work with this, we attach a.....
## Service
- a static IP address that is attatched to each pod/app
- an app (stored in a node) will have it's own service/database, and every pod will have it's own service
- the service lifetime is not connected to the pod's, so when the pod is replaced, the same internal IP can be used
- also works as a load balancer when allocating requests to pods
There are **two types of services**
1. internal
- this is the default type
- can not be accessed externally
2. external
- you must specify this when creating a service
- can communicate externally (i.e. via browser for a web app's endpoint)
- can be accessed via http://[node_ip_addr][service_port_number]
what if you want to access something, but it needs to be via some sort of domain?
use.....
## Ingress
- exposes HTTP and HTTPS routes from outside the cluster to services within the cluster
- you set **rules**, which will then decide how requests are routed (forewarded to services or otherwise)
<hr>
## ConfigMap
- external configurations for your application (i.e. database urls)
- connected to pods so that they have access to this data
- this allows you to just change the value in the configMap without re-building the pods
- stored in plaintext
**HOWEVER**
This type of storage is ***NOT*** secure, so kubernetes offers.....
## Secret
- just like configMap, but for secrets (i.e. usernames, passowrd, etc)
- stored in base64-encoded format
- is meant to be encrypted using third-party tools (perhaps given by the cloud provider)
**BOTH** ConfigMap and Secret can be used inside of pods like env vars or as a properties file
<hr>
## Volume
- used for data storage
★ imagine there is a "database" pod. If that pod restarts, your data is gone
- attaches physical storage to a pod
- can be on the same machine the pod is running on or a remote source outside of the cluster
- **kubernetes does not manage data persistance**
+50
View File
@@ -0,0 +1,50 @@
# Communicating with the Master Node
### Format
a request must be in `YAML` format and has:
1. apiVersion
- the api version
2. kind
- the kind of thing this is referring to (Service, Deployement, etc)
3. metadata
- name of component
- matchLabels (labels)
* this is like a tag for that component to be matched by `selectors`
* this is ONLY used by selectors ONE LAYER UP (i.e. service --> deployement/pods)
4. spec (specification)
- any configurations you might need (selector, port, etc)
- this will be `kind` specific
- this section will be expanded on down below
5. status
- this is automatically generated by kubernetes
★ for example, if you put `replicas: 2` under `spec`, kubernetes will add a status that lets it know that only 1 state is currently running, then continuously update it as new replicas are added or removed, change the number of replicas accordingly
- kubernetes gets this data from the `etcd` and compares it to your request
★ YAML is horrid, so consider using a tool like [https://yamlchecker.com/](https://yamlchecker.com/)
## The Spec Field
This gets it's own section because it can contain so many things. For example:
### Pod Blueprints
* stored in the `template` field, these are the blueprints for the pods
* these will have their own `spec` and `metadata` fields in them
* like nested configuration files as pods need their own configuration "files" inside of the **deployement**'s configuration file
### Selectors
* tells the deployement what `label` to match
* this is ONLY used by selectors ONE LAYER DOWN (i.e. deployement/pods --> service)
### Ports
* the **service** has a port where it is accessible at
- this is the `port` variable
* the **service** also needs a protocol which it is accessible by
- this is the `protocol` variable
* the **service** also needs to know what port the pod to be contacted is listening on
- this is the `targetPort` variable
* the **pod** has a port it is listening on
- this is the `containerPort` variable
*Note: these files are ***declarative***, so for example if you specify there must be 3 replicas, kubernetes will try to ensure there are three replicas*
+16
View File
@@ -0,0 +1,16 @@
to avoid downtime, create a......
## Deployement
- a blueprint for for a process-specific pod
- you specify how many replicas of the pod to make
- this is an *abstraction* on top of pods
- can scale up or down
★ if one of the replicated pods dies, the service will simply foreward the request to whatever pod has the lightest load
what if multiple pods want to write to a storage medium? Then we have to use a......
## StatefulSet
- replaces deployements for *stateful* apps (apps that need static information)
★ examples of stateful apps include databases, email, etc
- ensures database reads/writes are synchronized
- very complicated, consider hosting outside of the kubernetes cluster
+7
View File
@@ -0,0 +1,7 @@
# https://kubernetes.io/docs/concepts/configuration/configmap/
apiVersion: v1
kind: ConfigMap
metadata:
name: mongo-config
data:
mongo-url: mongo-service
+9
View File
@@ -0,0 +1,9 @@
# https://kubernetes.io/docs/concepts/configuration/secret/
apiVersion: v1
kind: Secret
metadata:
name: mongo-secret
type: Opaque
data:
mongo-user: bW9uZ291c2Vy
mongo-password: bW9uZ29wYXNzd29yZA==
+47
View File
@@ -0,0 +1,47 @@
# deployement and service for mongodb
# https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
apiVersion: apps/v1
kind: Deployment
metadata:
name: mgongo-deployment
labels:
app: mgongo
spec: # deployement-specific
replicas: 1
selector:
matchLabels:
app: mgongo
template: # deployement for the pods
metadata:
labels:
app: mgongo
spec:
containers: # https://hub.docker.com/_/mongo
- name: mongodb
image: mongo:5.0
ports:
- containerPort: 27017
env: # sameple values for the demo webserver
- name: MONGO_INITDB_ROOT_USERNAME
valueFrom:
secretKeyRef: # get from secrets
name: mongo-secret
key: mongo-user
- name: MONGO_INITDB_ROOT_PASSWORD
valueFrom:
secretKeyRef: # get from secrets
name: mongo-secret
key: mongo-password
--- # "new file"
# https://kubernetes.io/docs/concepts/services-networking/service/
apiVersion: v1
kind: Service
metadata:
name: mongo-service
spec:
selector:
app: mongo
ports:
- protocol: TCP
port: 27017
targetPort: 27017
+33
View File
@@ -0,0 +1,33 @@
## Initial Steps (readying your app)
*Note: I assume you already have a minikube running*
1. check if you have any pods running with `kubectl get pod` and stop them if so
2. create external configurations
- kubectl apply -f mongo-config.yaml
- kubectl apply -f mongo-secret.yaml
★ the -f is for file
3. create connection for the database
- kubectl apply -f mongo.yaml
4. deploy the web app
- kubectl apply -f webapp.yaml
## Kubectl
1. check your pods using `kubectl get all`
2. check your configmap using `kubectl get configmap`
3. check your secrets using `kubectl get secret`
- you can use `kubectl get [component_name]` to get some data for any component or run `kubectl get --help` for help with the `get` subcommand
- you can use `kubectl describe service [service_name]` to get a description of the service
- you can use `kubectl logs [pod_name]` to get the logs for that pod
## Accessing the Application Externally
In our case from the browser
1. use `kubectl get svc` to get the service
2. get the `nodPort`'s ip using `minikube ip`
★ you can access more data using `kubectl get node -o wide`
3. access the ip using the corresponding IP address : port
+54
View File
@@ -0,0 +1,54 @@
# deployement and service for mongodb
# https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp-deployment
labels:
app: webapp
spec: # deployement-specific
replicas: 1
selector:
matchLabels:
app: webapp
template: # deployement for the pods
metadata:
labels:
app: webapp
spec:
containers: # https://hub.docker.com/_/mongo
- name: webapp
image: nanajanashia/k8s-demo-app:v1.0 # demo web app
ports:
- containerPort: 3000
env: #add demo information
- name: USER_NAME
valueFrom:
secretKeyRef: # get from secrets
name: mongo-secret
key: mongo-user
- name: USER_PWD
valueFrom:
secretKeyRef: # get from secrets
name: mongo-secret
key: mongo-password
- name: DB_URL
valueFrom:
configMapKeyRef: # get from configMap
name: mongo-config
key: mongo-url
--- # "new file"
# https://kubernetes.io/docs/concepts/services-networking/service/
apiVersion: v1
kind: Service
metadata:
name: webapp-service
spec:
type: NodePort # external service port type
selector:
app: webapp
ports:
- protocol: TCP
port: 3000
targetPort: 3000
nodePort: 30100 # see https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport for ranges
+18
View File
@@ -0,0 +1,18 @@
you can run using [minicube](https://minikube.sigs.k8s.io/docs/start/?)!
small open-source program where both the master and node both run on one machine
you can interact with the cluster using [cubectl](https://kubernetes.io/docs/tasks/tools/)!
minikube can either start as a container or a virtual machine (make sure you have docker installed)
## Setting it up
you can start minikube by running `minikube start --driver=docker`
## Checking
just use `minikube status`
## Interacting with Minikube
1. get the node using `kubectl get node`
*Note: when creating secrets, you can just use `echo -n datahere | base64` to encode it*
+41
View File
@@ -0,0 +1,41 @@
My notes from https://www.youtube.com/watch?v=s_o8dwzRlu4 and other videos
# What is kubernetes
* an open source container orchestration tool
* helps you manage apps that are made of 100s or 1000s of containers in different dev environments (cloud, local, etc)
## Container Orchestration Tool
* manages many containers
* offers high availability (little to no downtime)
* offers scalability
* offers disaster recovery (backup and restore)
## Kubernetes Cluster Structure
### at least 1 Master Node
has:
* API Server (the entrypoint for the kubernetes cluster), this is what the kubernetes clients (UI, API, CLI, etc) will talk to
* Controller Manager
- keeps track of the cluster (i.e. a container has died, restart it)
* Scheduler
- decides on which node any new container should be scheduled
- it does this based on workload, server resources on each node, etc
* etcd
- key/value storage for the current state of the cluster
- holds the current config data, status data of each node/the node's container, etc
- snapshots of this etcd are used for RECOVERY
**connected to it, there are many smaller**
### Worker Nodes
all of which have:
* a kublet (kubernetes process that talks to other kublets and master node) running on it
* docker containers (which do the work)
### Virtual Network
* spans all the nodes in the cluster
* enables the nodes to talk to each other
*Note: in most prod environments, it's recommended to have more than one master node so that if one of them fails, the process can continue running*