presented by @ryanj, Developer Advocate at Red Hat
# Kubernetes
(an ops tool)
When used as directed, provides relief for the following:
- standardized terminology & packaging - containers, volumes, podspecs, charts
- load balancing - services
- scaling automation - replica sets
- delivery automation - deployments
- high availability - automated health checking and replacement
- distributed scheduling and resource management - RBAC, namespaces, labels, federation
- ???
### How should we be talking to Developers about
# Kubernetes?
A Case Study: Enterprise Records, Inc.
The Ops team has heard great things about Kubernetes, and is interested in giving it a try - but they're having difficulty convincing other teams of the value
Product team needs:
More
(always more)
The web team is confused by all the new terminology, and is under a lot of pressure to focus on delivering new tracks to customers
# 1. The Easy Part
is
minikube start
* Staging down?
* Ops not Ready?
No Excuses!
Minikube
# 2. Share What You Know
and model your I/O
### Share What You Know `--dry-run`
Generate kubernetes `deployment` and `service` specifications, both named `metrics-review`:
```bash
kubectl run metrics-review --image=quay.io/ryanj/metrics-k8s \
--expose --port=2015 --service-overrides='{ "spec": { "type": "NodePort" } }' \
--dry-run -o yaml > metrics-review.yaml
```
### Share What You Know `--dry-run`
Test your generated spec:
```bash
kubectl create -f metrics-review.yaml
```
Minikube users will be able to open the resulting service in their browser by running:
```bash
minikube service metrics-review
```
### Example Repo
Create a local clone of this `metrics-k8s` repo:
```bash
git clone http://github.com/ryanj/metrics-k8s
```
### Preview - local files
Next, share your local repo contents with minikube:
```bash
cd metrics-k8s
minikube mount $(pwd):/var/www/html
```
### Preview - hostPath
Then, produce a new deployment spec that includes (minimal) support for live development workflows:
1. `cp metrics-review.yaml metrics-dev.yaml`
2. replace `metrics-review` with `metrics-dev` (global)
2. Add a `hostPort` volume to access your local repo:
```diff
spec:
containers:
- image: quay.io/ryanj/metrics-k8s
name: metrics-dev
ports:
- containerPort: 2015
resources: {}
+ volumeMounts:
+ - mountPath: /var/www/html
+ name: metrics-src
+ volumes:
+ - name: metrics-src
+ hostPath:
+ path: /var/www/html
status: {}
```
### Share what you know
The resulting file should look just like the included [metrics-dev.yaml](https://raw.githubusercontent.com/ryanj/metrics-k8s/master/metrics-dev.yaml) file from the `metrics-k8s` git repo.
Try launching it with:
```bash
kubectl create -f metrics-dev.yaml
```
### Share what you know - Rollout Testing
Eval this
```bash
minikube docker-env
```
to send newly-built images to minikube's docker daemon:
```bash
docker build .
```
# 3. The Hard Part
Keeping it simple, and choosing the right tools for the job
The future is already here — it's just not very evenly distributed. (W.Gibson)
Typical container adoption path:
- docker
- volumes, PVs
- minikube
- k8s modeling and scalability via spec files, pods, and other abstractions
- charts, openshift templates, or hand-rolled manifest / spec templating
- monocular, kubeapps, ServiceCatalog
- PaaS?
Draft
Make it easy to get started
draft.sh
Easy, right?
## More Learning Opportunities
1. Kubernetes.io Tutorials https://kubernetes.io/docs/tutorials/
2. Katacoda https://katacoda.com/courses/kubernetes
4. RyanJ's K8s-workshops http://bit.ly/k8s-workshops
3. Interactive learning for OpenShift: http://learn.openshift.com
Include the whole team:
- Developers: Want to get ahead? Model your I/O, and Share What You Know!
- Architects: Figure out who owns manifest creation, maintanence, and distribution
- QA folks: look forward to saying: "can't repro - works fine on my Kubernetes"
- Ops: provide cloud resources grants to teams, make sure prod has enough IaaS, ensure platform uptime, upgrades, logging, and metrics
- Security & Compliance: RBAC, config and secrets management; Secret rotation policies; Monitor for CVEs and apply security patches from upstream
Join the community on Slack in #kubernetes-users, and in #SIG-Apps!
Share What You Know: Help us develop a range of solutions that expose and/or hide kubernetes in appropriate ways
Learn to deliver consistently using containers
then get back to making gold records