I'd like to use these YAML files without having to tell people
to explicitly check a specific branch. So I'm merging the YAML
files right away. I'm not merging the Markdown content so that
it can be reviewed further.
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.
In a few places, we were using 'Persistent Volume' the
wrong way. This was fixed.
Also added a whole chapter showing how to use local
persistent volumes, with an actually persistent
Consul cluster.
This will use a more recent Debian-based image, instead of the
older alpine image. It also sets a couple of env vars to
avoid spurious messages. And it removes a lot of defaults
and useless parameters to make the YAML file more readable.
This is a concatenation of the files found in this directory:
https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy/1.8%2B
... but with extra args added to the metrics server process,
to use InternalIP to contact the nodes, disable TLS cert validation
and reduce the polling interval to 5s.
Now that we have this file here, we can refer to it in the deployment
scripts to create clusters that have metrics-server pre-installed.
Consul 1.4 introduces Cloud auto-join, which finds the
IP addresses of the other nodes by querying an API (in
that case, the Kubernetes API).
This involves creating a service account and granting
permissions to list and get pods. It is a little bit
more complex, but it reuses previous notions (like RBAC)
so I like it better.
This was a request by @abuisine, so I'm flagging him for review :-)
This section explains the challenges associated with self-hosting
the control plane; and segues into static pods. It also mentions
bootkube and the Pod Checkpointer. There is an exercise showing
how to run a static pod.
Committing straight to master since this file
is not used by @bridgetkromhout, and people use
that file by cloning the repo (so it has to be
merged in master for people to see it).
HASHTAG YOLO
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.
In this section, we setup Portworx to have a dynamic provisioner.
Then we use it to deploy a PostgreSQL Stateful Set.
Finally we simulate a node failure and observe the failover.
- explain the reason why we have stateful sets
- explain the relationship between volumes, persistent volumes,
persistent volume claims, volume claim templates
- show how to run a Consul cluster with a stateful set
- volumes (general overview)
- building with the docker engine (bind-mounting the docker socket)
- building with kaniko (and init containers)
- managing configuration (configmaps, downward api)
Also added a new-content.yml file with just the new content
(for easier review), containing my plans for future chapters.
