From 614f10432e3fbe5b7f1ef2b7333ef759fc3baeea Mon Sep 17 00:00:00 2001 From: Jerome Petazzoni Date: Mon, 26 Feb 2018 17:52:06 -0600 Subject: [PATCH] Mostly reformatting so that slides are nice and tidy --- slides/kube/daemonset.md | 16 +++++++++++++++- slides/kube/dashboard.md | 26 +++++++++++++++++++------- slides/kube/kubectlget.md | 3 ++- slides/kube/setup-k8s.md | 2 ++ 4 files changed, 38 insertions(+), 9 deletions(-) diff --git a/slides/kube/daemonset.md b/slides/kube/daemonset.md index 5d8be5e8..fbb3b9d2 100644 --- a/slides/kube/daemonset.md +++ b/slides/kube/daemonset.md @@ -4,16 +4,30 @@ - We want one (and exactly one) instance of `rng` per node -- If we just scale `deploy/rng` to the number of worker nodes in our cluster, nothing guarantees that the rng processes will be distributed evenly across the cluster +- What if we just scale up `deploy/rng` to the number of nodes? + + - nothing guarantees that the `rng` containers will be distributed evenly + + - if we add nodes later, they will not automatically run a copy of `rng` + + - if we remove (or reboot) a node, one `rng` container will restart elsewhere - Instead of a `deployment`, we will use a `daemonset` +--- + +## Daemon sets in practice + - Daemon sets are great for cluster-wide, per-node processes: - `kube-proxy` + - `weave` (our overlay network) + - monitoring agents + - hardware management tools (e.g. SCSI/FC HBA agents) + - etc. - They can also be restricted to run [only on some nodes](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#running-pods-on-only-some-nodes) diff --git a/slides/kube/dashboard.md b/slides/kube/dashboard.md index 6ca02517..4a8aae67 100644 --- a/slides/kube/dashboard.md +++ b/slides/kube/dashboard.md @@ -89,18 +89,30 @@ The goo.gl URL expands to: - Connect to https://oneofournodes:3xxxx/ - - Yes, https. If you use http it will say: - - This page isn’t working - sent an invalid response. - ERR_INVALID_HTTP_RESPONSE - - - You will have to work around the TLS certificate validation warning +- You will have to work around the TLS certificate validation warning ] +The dashboard will then ask you which authentication you want to use. + +.warning[Make sure that you use `https`! Otherwise, you'll get this error:] + +``` +This page isn’t working + sent an invalid response. +ERR_INVALID_HTTP_RESPONSE +``` + +.warning[Chrome 63 (and later) as well as recent versions of Edge will refuse to connect.] + +We do not know how to work around that issue for the moment. + +--- + +## Dashboard authentication + - We have three authentication options at this point: - token (associated with a role that has appropriate permissions) diff --git a/slides/kube/kubectlget.md b/slides/kube/kubectlget.md index c3087d98..11424db9 100644 --- a/slides/kube/kubectlget.md +++ b/slides/kube/kubectlget.md @@ -136,7 +136,8 @@ There is already one service on our cluster: the Kubernetes API itself. ``` - `-k` is used to skip certificate verification - - Make sure to replace 10.96.0.1 with the CLUSTER-IP shown by `$ kubectl get svc` + + - Make sure to replace 10.96.0.1 with the CLUSTER-IP shown by `kubectl get svc` ] diff --git a/slides/kube/setup-k8s.md b/slides/kube/setup-k8s.md index 2e5d540a..cb296bd6 100644 --- a/slides/kube/setup-k8s.md +++ b/slides/kube/setup-k8s.md @@ -50,6 +50,8 @@ - If you are on AWS: [EKS](https://aws.amazon.com/eks/) + or + [kops](https://github.com/kubernetes/kops) - On a local machine: [minikube](https://kubernetes.io/docs/getting-started-guides/minikube/),