mirror of
https://github.com/ION606/learn.git
synced 2026-05-14 21:06:56 +00:00
initial commit
This commit is contained in:
@@ -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**
|
||||
@@ -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*
|
||||
@@ -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
|
||||
@@ -0,0 +1,7 @@
|
||||
# https://kubernetes.io/docs/concepts/configuration/configmap/
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: mongo-config
|
||||
data:
|
||||
mongo-url: mongo-service
|
||||
@@ -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==
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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*
|
||||
@@ -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*
|
||||
Reference in New Issue
Block a user