Git-Mirrors/backend-and-orchestration-toolkit
1
0
Fork 0
mirror of https://github.com/autistic-symposium/backend-and-orchestration-toolkit.git synced 2025-06-28 00:17:07 -04:00
Code Issues Projects Releases Packages Wiki Activity

add old code

Browse source
This commit is contained in:
Mia Steinkirch 2019-10-12 16:44:34 -07:00
parent e0cfb7a74b
commit 39be22e724
1 changed files with 21 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

28
README.md
View file

@ -1,13 +1,28 @@
# Resources for Kubernetes
--------------
# Tools
## What's K8s
## Minikube
A Kubernetes cluster consists of **Nodes**, which can be equated to servers, be they bare-metal or virtual machines running in a cloud.
Nodes run **Pods**, which are collections of Docker containers. A Pod is the unit of deployment in Kubernetes. All containers in a Pod share the same network and can refer to each other as if they were running on the same host. There are many situations in which it is advantageous to run more than one container in a Pod. Typically, you will run your application container as the main one in the Pod, and if needed one or more so-called "sidecar" containers, for functionality such as logging or monitoring. One particular case of sidecar containers is an "init container" which is guaranteed to run first, and which can be used for housekeeping tasks, for example for running database migrations (12-factor principle: “Admin processes: Run admin/management tasks as one-off processes”)
An application will typically use more than one Pod for fault tolerance and performance purposes. The Kubernetes object responsible for launching and maintaining the desired number of pods is called a **Deployment**.
For Pods to communicate with other Pods, Kubernetes provides another kind of object called a **Service**. Services are tied to Deployments through Selectors and Labels. Services are also exposed to external clients either by exposing a **NodePort** as a static port on each Kubernetes node or by creating a **LoadBalancer** object, corresponding to an actual load balancer if it is supported by the cloud provider running the Kubernetes cluster.
For managing sensitive information such as passwords, API keys, and other credentials, Kubernetes provides the **Secret** object.
For one-off tasks, Kubernetes provides the **Job** object. A Job can use the same ConfigMap and Secret objects already in place for regular Deployments and Pods. The Job will run a given Pod once, then stop.
--------------
## Tools
### Minikube
[Minikube](https://github.com/kubernetes/minikube) implements a local Kubernetes cluster on macOS, Linux, and Windows. You can install it following [this instructions](https://minikube.sigs.k8s.io/docs/start/).
## Kubectl
### Kubectl
Kubectl is a command line interface for running commands against Kubernetes clusters. You can install it [here](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
@ -36,13 +51,12 @@ Get more information about a pod:
$ kubectl describe pod --namespace=<ns-name> <pod name>
```
## Other Tools
### AWS Tools
* [AWS IAM authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator).
-----
## Learning Examples
### Learning Examples
* [Spin up a node server example](https://github.com/bt3gl/Learning_Kubernetes/tree/master/node-server-example).