We won't always have a kubeconfig with a TLS cert in it.
Let's break down different methods to analyze kubeconfig
depending on whether there is a TLS cert or a token in it.
'keys' does not handle special keys (like ^J) anymore.
Instead, we should use `key`, which will pass its entire
argument to tmux, without any processing. It is therefore
possible to do something like:
```key ^C```
Or
```key Escape```
Most (if not all) calls to special keys have been
converted to use 'key' instead of 'keys'.
Action ```copypaste``` has been deprecated in favor
of three separate actions:
```copy REGEX``` (searches the regex in the active pane,
and if found, places it in an internal clipboard)
```paste``` (inserts the content of the clipboard as
keystrokes)
```check``` (forces a status check)
Also, a 'tmux' command has been added. It allows to
do stuff like:
```tmux split-pane -v```
This is a rather convoluted example, showing step by
step how to build a system where each user gets a
ServiceAcccount and token with limited access, and
can use this token to submit a CSR that will give
them a short-lived certificate.
Even if this is not a 100% realistic scenario,
the general idea (using a "long-term" password
or token to obtain a "short-term" token) is used
by many other systems, so it makes sense to get
acquainted with the various moving parts.
kubectl run is being deprecated as a multi-purpose tool.
This PR replaces 'kubectl run' with 'kubectl create deployment'
in most places (except in the very first example, to reduce the
cognitive load; and when we really want a single-shot container).
It also updates the places where we use a 'run' label, since
'kubectl create deployment' uses the 'app' label instead.
NOTE: this hasn't gone through end-to-end testing yet.
Jérôme Petazzoni
AJ Bowen
djalal
djalalandGitHub