Work around bug in kubectl logs

kubectl logs -l ... --tail ... is buggy.
(It always returns 10 lines of output instead
of the requested number.)

This works around the problem, by adding extra
explanations of the issue and providing a shell
function as a workaround.

See kubernetes/kubernetes#70554 for details.

slides/k8s/daemonset.md

@@ -279,6 +279,46 @@ It appears that *all the pods* are serving requests at the moment.
 
 ---
 
+## Working around `kubectl logs` bugs
+
+- That last command didn't show what we needed
+
+- We mentioned earlier that regression affecting `kubectl logs` ...
+
+  (see [#70443](https://github.com/kubernetes/kubernetes/issues/70554) for more details)
+
+- Let's work around the issue by executing `kubectl logs` one pod at a time
+
+- For convenience, we'll define a little shell function
+
+---
+
+## Our helper function
+
+- The function `ktail` below will:
+
+  - list the names of all pods matching a selector
+  - display the last line of log for each pod
+
+.exercise[
+
+- Define `ktail`:
+  ```bash
+    ktail () {
+      kubectl get pods -o name -l $1 |
+        xargs -rn1 kubectl logs --tail 1
+    }
+  ```
+
+- Try it:
+  ```bash
+  ktail app=rng
+  ```
+
+]
+
+---
+
 ## The magic of selectors
 
 - The `rng` *service* is load balancing requests to a set of pods

slides/k8s/kubectlrun.md

@@ -290,6 +290,20 @@ Unfortunately, `--follow` cannot (yet) be used to stream the logs from multiple
 
 ---
 
+## `kubectl logs -l ... --tail N`
+
+- With Kubernetes 1.12 (and up to at least 1.12.2), the last command shows multiple lines
+
+- This is a regression when `--tail` is used together with `-l`/`--selector`
+
+- It always shows the last 10 lines of output for each container
+
+  (instead of the number of lines specified on the command line)
+
+- See [#70554](https://github.com/kubernetes/kubernetes/issues/70554) for details
+
+---
+
 ## Aren't we flooding 1.1.1.1?
 
 - If you're wondering this, good question!
@@ -300,5 +314,6 @@ Unfortunately, `--follow` cannot (yet) be used to stream the logs from multiple
 
   (Source: https://blog.cloudflare.com/announcing-1111/)
 
+
 - It's very unlikely that our concerted pings manage to produce
   even a modest blip at Cloudflare's NOC!