Merge pull request #233 from jpetazzo/master

Bringing event-specific fork up to date
This commit is contained in:
Bridget Kromhout
2018-04-23 12:04:19 -05:00
committed by GitHub
3 changed files with 57 additions and 5 deletions

View File

@@ -73,8 +73,9 @@ thing for now (stay tuned...)</td>
<tr>
<td>April 24th, 2018: GOTO Chicago - Kubernetes 101</td>
<td>&nbsp;</td>
<td><a class="slides" href="http://gotochgo2018.container.training/" /></td>
<td><a class="attend" href="https://gotochgo.com/2018/workshops/88#k8s101" /></td>
<td>&nbsp;</td>
</tr>
<tr>

View File

@@ -256,9 +256,9 @@ The dashboard will then ask you which authentication you want to use.
- It's safe if you use HTTPS URLs from trusted sources
--
- It introduces new failure modes
- Example: the official setup instructions for most pod networks
--
- It introduces new failure modes (like if you try to apply yaml from a link that's no longer valid)

View File

@@ -33,6 +33,23 @@
---
## Checking current rollout parameters
- Recall how we build custom reports with `kubectl` and `jq`:
.exercise[
- Show the rollout plan for our deployments:
```bash
kubectl get deploy -o json |
jq ".items[] | {name:.metadata.name} + .spec.strategy.rollingUpdate"
```
]
---
## Rolling updates in practice
- As of Kubernetes 1.8, we can do rolling updates with:
@@ -141,6 +158,38 @@ Our rollout is stuck. However, the app is not dead (just 10% slower).
---
## What's going on with our rollout?
- Why is our app 10% slower?
- Because `MaxUnavailable=1`, so the rollout terminated 1 replica out of 10 available
- Okay, but why do we see 2 new replicas being rolled out?
- Because `MaxSurge=1`, so in addition to replacing the terminated one, the rollout is also starting one more
---
class: extra-details
## The nitty-gritty details
- We start with 10 pods running for the `worker` deployment
- Current settings: MaxUnavailable=1 and MaxSurge=1
- When we start the rollout:
- one replica is taken down (as per MaxUnavailable=1)
- another is created (with the new version) to replace it
- another is created (with the new version) per MaxSurge=1
- Now we have 9 replicas up and running, and 2 being deployed
- Our rollout is stuck at this point!
---
## Recovering from a bad rollout
- We could push some `v0.3` image
@@ -222,6 +271,8 @@ spec:
minReadySeconds: 10
"
kubectl rollout status deployment worker
kubectl get deploy -o json worker |
jq "{name:.metadata.name} + .spec.strategy.rollingUpdate"
```
]