diff --git a/slides/_redirects b/slides/_redirects index 66af9915..c2d8340a 100644 --- a/slides/_redirects +++ b/slides/_redirects @@ -1 +1 @@ -/ /kube-halfday.yml.html 200 +/ /kube-90min.yml.html 200 diff --git a/slides/common/prereqs.md b/slides/common/prereqs.md index 5bf1bc57..8202497f 100644 --- a/slides/common/prereqs.md +++ b/slides/common/prereqs.md @@ -1,46 +1,4 @@ -# Pre-requirements - -- Be comfortable with the UNIX command line - - - navigating directories - - - editing files - - - a little bit of bash-fu (environment variables, loops) - -- Some Docker knowledge - - - `docker run`, `docker ps`, `docker build` - - - ideally, you know how to write a Dockerfile and build it -
- (even if it's a `FROM` line and a couple of `RUN` commands) - -- It's totally OK if you are not a Docker expert! - ---- - -class: title - -*Tell me and I forget.* -
-*Teach me and I remember.* -
-*Involve me and I learn.* - -Misattributed to Benjamin Franklin - -[(Probably inspired by Chinese Confucian philosopher Xunzi)](https://www.barrypopik.com/index.php/new_york_city/entry/tell_me_and_i_forget_teach_me_and_i_may_remember_involve_me_and_i_will_lear/) - ---- - -## Hands-on sections - -- The whole workshop is hands-on - -- We are going to build, ship, and run containers! - -- You are invited to reproduce all the demos +## Hands-on - All hands-on sections are clearly identified, like the gray rectangle below @@ -50,53 +8,10 @@ Misattributed to Benjamin Franklin - Go to @@SLIDES@@ to view these slides -- Join the chat room: @@CHAT@@ - - - ] ---- - -class: in-person - -## Where are we going to run our containers? - ---- - -class: in-person, pic - -![You get a cluster](images/you-get-a-cluster.jpg) - ---- - -class: in-person - -## You get a cluster of cloud VMs - - Each person gets a private cluster of cloud VMs (not shared with anybody else) -- They'll remain up for the duration of the workshop - -- You should have a little card with login+password+IP addresses - -- You can automatically SSH from one VM to another - -- The nodes have aliases: `node1`, `node2`, etc. - ---- - -class: in-person - -## Why don't we run containers locally? - -- Installing that stuff can be hard on some machines - - (32 bits CPU or OS... Laptops without administrator access... etc.) - -- *"The whole team downloaded all these container images from the WiFi! -
... and it went great!"* (Literally no-one ever) - - All you need is a computer (or even a phone or tablet!), with: - an internet connection @@ -109,201 +24,18 @@ class: in-person class: in-person -## SSH clients - -- On Linux, OS X, FreeBSD... you are probably all set - -- On Windows, get one of these: - - - [putty](http://www.putty.org/) - - Microsoft [Win32 OpenSSH](https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH) - - [Git BASH](https://git-for-windows.github.io/) - - [MobaXterm](http://mobaxterm.mobatek.net/) - -- On Android, [JuiceSSH](https://juicessh.com/) - ([Play Store](https://play.google.com/store/apps/details?id=com.sonelli.juicessh)) - works pretty well - -- Nice-to-have: [Mosh](https://mosh.org/) instead of SSH, if your internet connection tends to lose packets - ---- - -class: in-person, extra-details - -## What is this Mosh thing? - -*You don't have to use Mosh or even know about it to follow along. -
-We're just telling you about it because some of us think it's cool!* - -- Mosh is "the mobile shell" - -- It is essentially SSH over UDP, with roaming features - -- It retransmits packets quickly, so it works great even on lossy connections - - (Like hotel or conference WiFi) - -- It has intelligent local echo, so it works great even in high-latency connections - - (Like hotel or conference WiFi) - -- It supports transparent roaming when your client IP address changes - - (Like when you hop from hotel to conference WiFi) - ---- - -class: in-person, extra-details - -## Using Mosh - -- To install it: `(apt|yum|brew) install mosh` - -- It has been pre-installed on the VMs that we are using - -- To connect to a remote machine: `mosh user@host` - - (It is going to establish an SSH connection, then hand off to UDP) - -- It requires UDP ports to be open - - (By default, it uses a UDP port between 60000 and 61000) - ---- - -class: in-person - ## Connecting to our lab environment .exercise[ - Log into the first VM (`node1`) with your SSH client - - - Check that you can SSH (without password) to `node2`: ```bash ssh node2 ``` - Type `exit` or `^D` to come back to `node1` - - ] If anything goes wrong — ask for help! - ---- - -## Doing or re-doing the workshop on your own? - -- Use something like - [Play-With-Docker](http://play-with-docker.com/) or - [Play-With-Kubernetes](https://medium.com/@marcosnils/introducing-pwk-play-with-k8s-159fcfeb787b) - - Zero setup effort; but environment are short-lived and - might have limited resources - -- Create your own cluster (local or cloud VMs) - - Small setup effort; small cost; flexible environments - -- Create a bunch of clusters for you and your friends - ([instructions](https://@@GITREPO@@/tree/master/prepare-vms)) - - Bigger setup effort; ideal for group training - ---- - -class: self-paced - -## Get your own Docker nodes - -- If you already have some Docker nodes: great! - -- If not: let's get some thanks to Play-With-Docker - -.exercise[ - -- Go to http://www.play-with-docker.com/ - -- Log in - -- Create your first node - - - -] - -You will need a Docker ID to use Play-With-Docker. - -(Creating a Docker ID is free.) - ---- - -## We will (mostly) interact with node1 only - -*These remarks apply only when using multiple nodes, of course.* - -- Unless instructed, **all commands must be run from the first VM, `node1`** - -- We will only checkout/copy the code on `node1` - -- During normal operations, we do not need access to the other nodes - -- If we had to troubleshoot issues, we would use a combination of: - - - SSH (to access system logs, daemon status...) - - - Docker API (to check running containers and container engine status) - ---- - -## Terminals - -Once in a while, the instructions will say: -
"Open a new terminal." - -There are multiple ways to do this: - -- create a new window or tab on your machine, and SSH into the VM; - -- use screen or tmux on the VM and open a new window from there. - -You are welcome to use the method that you feel the most comfortable with. - ---- - -## Tmux cheatsheet - -[Tmux](https://en.wikipedia.org/wiki/Tmux) is a terminal multiplexer like `screen`. - -*You don't have to use it or even know about it to follow along. -
-But some of us like to use it to switch between terminals. -
-It has been preinstalled on your workshop nodes.* - -- Ctrl-b c → creates a new window -- Ctrl-b n → go to next window -- Ctrl-b p → go to previous window -- Ctrl-b " → split window top/bottom -- Ctrl-b % → split window left/right -- Ctrl-b Alt-1 → rearrange windows in columns -- Ctrl-b Alt-2 → rearrange windows in rows -- Ctrl-b arrows → navigate to other windows -- Ctrl-b d → detach session -- tmux attach → reattach to session diff --git a/slides/common/sampleapp.md b/slides/common/sampleapp.md index 0e76edef..21b37de1 100644 --- a/slides/common/sampleapp.md +++ b/slides/common/sampleapp.md @@ -94,61 +94,6 @@ class: extra-details --- -## Service discovery in container-land - -- We do not hard-code IP addresses in the code - -- We do not hard-code FQDN in the code, either - -- We just connect to a service name, and container-magic does the rest - - (And by container-magic, we mean "a crafty, dynamic, embedded DNS server") - ---- - -## Example in `worker/worker.py` - -```python -redis = Redis("`redis`") - - -def get_random_bytes(): - r = requests.get("http://`rng`/32") - return r.content - - -def hash_bytes(data): - r = requests.post("http://`hasher`/", - data=data, - headers={"Content-Type": "application/octet-stream"}) -``` - -(Full source code available [here]( -https://@@GITREPO@@/blob/8279a3bce9398f7c1a53bdd95187c53eda4e6435/dockercoins/worker/worker.py#L17 -)) - ---- - -class: extra-details - -## Links, naming, and service discovery - -- Containers can have network aliases (resolvable through DNS) - -- Compose file version 2+ makes each container reachable through its service name - -- Compose file version 1 did require "links" sections - -- Network aliases are automatically namespaced - - - you can have multiple apps declaring and using a service named `database` - - - containers in the blue app will resolve `database` to the IP of the blue database - - - containers in the green app will resolve `database` to the IP of the green database - ---- - ## What's this application? -- diff --git a/slides/kube-90min.yml b/slides/kube-90min.yml new file mode 100644 index 00000000..8534486c --- /dev/null +++ b/slides/kube-90min.yml @@ -0,0 +1,52 @@ +title: | + Kubernetes 101 + +#chat: "[Slack](https://dockercommunity.slack.com/messages/C7GKACWDV)" +#chat: "[Gitter](https://gitter.im/jpetazzo/training-20180413-paris)" +chat: "In person!" + +gitrepo: github.com/jpetazzo/container.training + +slides: http://container.training/ + +exclude: +- self-paced +- extra-details + +chapters: +- common/title.md +- logistics.md +#- kube/intro.md +- common/about-slides.md +- common/toc.md +- - common/prereqs.md + - kube/versions-k8s.md + - common/sampleapp.md +# Bridget doesn't go into as much depth with compose + #- common/composescale.md + - common/composedown.md + - kube/concepts-k8s.md +# - common/declarative.md + - kube/declarative.md +# - kube/kubenet.md + - kube/kubectlget.md + - kube/setup-k8s.md +- - kube/kubectlrun.md + - kube/kubectlexpose.md + - kube/ourapponkube.md + #- kube/kubectlproxy.md +- - kube/dashboard.md + - kube/kubectlscale.md + - kube/daemonset.md + - kube/rollout.md +# Stern is interesting but can be skipped +#- - kube/logs-cli.md +# Bridget hasn't added EFK yet + #- kube/logs-centralized.md + - kube/helm.md + - kube/namespaces.md + - kube/whatsnext.md + - kube/links.md +# Bridget-specific +# - kube/links-bridget.md + - common/thankyou.md diff --git a/slides/kube/concepts-k8s.md b/slides/kube/concepts-k8s.md index bcc9ffb3..7ca6e8ce 100644 --- a/slides/kube/concepts-k8s.md +++ b/slides/kube/concepts-k8s.md @@ -171,11 +171,7 @@ class: pic --- -## Do we need to run Docker at all? - -No! - --- +## Default container runtime - By default, Kubernetes uses the Docker Engine to run containers @@ -185,42 +181,6 @@ No! (like CRI-O, or containerd) ---- - -## Do we need to run Docker at all? - -Yes! - --- - -- In this workshop, we run our app on a single node first - -- We will need to build images and ship them around - -- We can do these things without Docker -
- (and get diagnosed with NIH¹ syndrome) - -- Docker is still the most stable container engine today -
- (but other options are maturing very quickly) - -.footnote[¹[Not Invented Here](https://en.wikipedia.org/wiki/Not_invented_here)] - ---- - -## Do we need to run Docker at all? - -- On our development environments, CI pipelines ... : - - *Yes, almost certainly* - -- On our production servers: - - *Yes (today)* - - *Probably not (in the future)* - .footnote[More information about CRI [on the Kubernetes blog](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes)] --- @@ -235,6 +195,7 @@ Yes! - node (a machine — physical or virtual — in our cluster) - pod (group of containers running together on a node) + - IP addresses are associated with *pods*, not with individual containers - service (stable network endpoint to connect to one or multiple containers) - namespace (more-or-less isolated group of things) - secret (bundle of sensitive data to be passed to a container) @@ -246,25 +207,3 @@ Yes! class: pic ![Node, pod, container](images/k8s-arch3-thanks-weave.png) - ---- - -class: pic - -![One of the best Kubernetes architecture diagrams available](images/k8s-arch4-thanks-luxas.png) - ---- - -## Credits - -- The first diagram is courtesy of Weave Works - - - a *pod* can have multiple containers working together - - - IP addresses are associated with *pods*, not with individual containers - -- The second diagram is courtesy of Lucas Käldström, in [this presentation](https://speakerdeck.com/luxas/kubeadm-cluster-creation-internals-from-self-hosting-to-upgradability-and-ha) - - - it's one of the best Kubernetes architecture diagrams available! - -Both diagrams used with permission. diff --git a/slides/kube/daemonset.md b/slides/kube/daemonset.md index 08fc06e2..5afbf307 100644 --- a/slides/kube/daemonset.md +++ b/slides/kube/daemonset.md @@ -212,34 +212,6 @@ daemonset.apps/rng 2 2 2 2 2 --- -## Too many pods - -- If we check with `kubectl get pods`, we see: - - - *one pod* for the deployment (named `rng-xxxxxxxxxx-yyyyy`) - - - *one pod per node* for the daemon set (named `rng-zzzzz`) - - ``` - NAME READY STATUS RESTARTS AGE - rng-54f57d4d49-7pt82 1/1 Running 0 11m - rng-b85tm 1/1 Running 0 25s - rng-hfbrr 1/1 Running 0 25s - [...] - ``` - --- - -The daemon set created one pod per node, except on the master node. - -The master node has [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) preventing pods from running there. - -(To schedule a pod on this node anyway, the pod will require appropriate [tolerations](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/).) - -.footnote[(Off by one? We don't run these pods on the node hosting the control plane.)] - ---- - ## What are all these pods doing? - Let's check the logs of all these `rng` pods @@ -344,162 +316,6 @@ The replica set selector also has a `pod-template-hash`, unlike the pods in our --- -# Updating a service through labels and selectors - -- What if we want to drop the `rng` deployment from the load balancer? - -- Option 1: - - - destroy it - -- Option 2: - - - add an extra *label* to the daemon set - - - update the service *selector* to refer to that *label* - --- - -Of course, option 2 offers more learning opportunities. Right? - ---- - -## Add an extra label to the daemon set - -- We will update the daemon set "spec" - -- Option 1: - - - edit the `rng.yml` file that we used earlier - - - load the new definition with `kubectl apply` - -- Option 2: - - - use `kubectl edit` - --- - -*If you feel like you got this💕🌈, feel free to try directly.* - -*We've included a few hints on the next slides for your convenience!* - ---- - -## We've put resources in your resources - -- Reminder: a daemon set is a resource that creates more resources! - -- There is a difference between: - - - the label(s) of a resource (in the `metadata` block in the beginning) - - - the selector of a resource (in the `spec` block) - - - the label(s) of the resource(s) created by the first resource (in the `template` block) - -- You need to update the selector and the template (metadata labels are not mandatory) - -- The template must match the selector - - (i.e. the resource will refuse to create resources that it will not select) - ---- - -## Adding our label - -- Let's add a label `isactive: yes` - -- In YAML, `yes` should be quoted; i.e. `isactive: "yes"` - -.exercise[ - -- Update the daemon set to add `isactive: "yes"` to the selector and template label: - ```bash - kubectl edit daemonset rng - ``` - -- Update the service to add `isactive: "yes"` to its selector: - ```bash - kubectl edit service rng - ``` - -] - ---- - -## Checking what we've done - -.exercise[ - -- Check the most recent log line of all `run=rng` pods to confirm that exactly one per node is now active: - ```bash - kubectl logs -l run=rng --tail 1 - ``` - -] - -The timestamps should give us a hint about how many pods are currently receiving traffic. - -.exercise[ - -- Look at the pods that we have right now: - ```bash - kubectl get pods - ``` - -] - ---- - -## Cleaning up - -- The pods of the deployment and the "old" daemon set are still running - -- We are going to identify them programmatically - -.exercise[ - -- List the pods with `run=rng` but without `isactive=yes`: - ```bash - kubectl get pods -l run=rng,isactive!=yes - ``` - -- Remove these pods: - ```bash - kubectl delete pods -l run=rng,isactive!=yes - ``` - -] - ---- - -## Cleaning up stale pods - -``` -$ kubectl get pods -NAME READY STATUS RESTARTS AGE -rng-54f57d4d49-7pt82 1/1 Terminating 0 51m -rng-54f57d4d49-vgz9h 1/1 Running 0 22s -rng-b85tm 1/1 Terminating 0 39m -rng-hfbrr 1/1 Terminating 0 39m -rng-vplmj 1/1 Running 0 7m -rng-xbpvg 1/1 Running 0 7m -[...] -``` - -- The extra pods (noted `Terminating` above) are going away - -- ... But a new one (`rng-54f57d4d49-vgz9h` above) was restarted immediately! - --- - -- Remember, the *deployment* still exists, and makes sure that one pod is up and running - -- If we delete the pod associated to the deployment, it is recreated automatically - ---- - ## Deleting a deployment .exercise[ @@ -524,63 +340,3 @@ rng-xbpvg 1/1 Running 0 11m ``` Ding, dong, the deployment is dead! And the daemon set lives on. - ---- - -## Avoiding extra pods - -- When we changed the definition of the daemon set, it immediately created new pods. We had to remove the old ones manually. - -- How could we have avoided this? - --- - -- By adding the `isactive: "yes"` label to the pods before changing the daemon set! - -- This can be done programmatically with `kubectl patch`: - - ```bash - PATCH=' - metadata: - labels: - isactive: "yes" - ' - kubectl get pods -l run=rng -l controller-revision-hash -o name | - xargs kubectl patch -p "$PATCH" - ``` - ---- - -## Labels and debugging - -- When a pod is misbehaving, we can delete it: another one will be recreated - -- But we can also change its labels - -- It will be removed from the load balancer (it won't receive traffic anymore) - -- Another pod will be recreated immediately - -- But the problematic pod is still here, and we can inspect and debug it - -- We can even re-add it to the rotation if necessary - - (Very useful to troubleshoot intermittent and elusive bugs) - ---- - -## Labels and advanced rollout control - -- Conversely, we can add pods matching a service's selector - -- These pods will then receive requests and serve traffic - -- Examples: - - - one-shot pod with all debug flags enabled, to collect logs - - - pods created automatically, but added to rotation in a second step -
- (by setting their label accordingly) - -- This gives us building blocks for canary and blue/green deployments diff --git a/slides/kube/dashboard.md b/slides/kube/dashboard.md index 65e1ed33..8fdf86c4 100644 --- a/slides/kube/dashboard.md +++ b/slides/kube/dashboard.md @@ -10,9 +10,6 @@ 3) bypass authentication for the dashboard --- - -There is an additional step to make the dashboard available from outside (we'll get to that) -- @@ -148,58 +145,6 @@ The dashboard will then ask you which authentication you want to use. --- -## Exposing the dashboard over HTTPS - -- We took a shortcut by forwarding HTTP to HTTPS inside the cluster - -- Let's expose the dashboard over HTTPS! - -- The dashboard is exposed through a `ClusterIP` service (internal traffic only) - -- We will change that into a `NodePort` service (accepting outside traffic) - -.exercise[ - -- Edit the service: - ```bash - kubectl edit service kubernetes-dashboard - ``` - -] - --- - -`NotFound`?!? Y U NO WORK?!? - ---- - -## Editing the `kubernetes-dashboard` service - -- If we look at the [YAML](https://goo.gl/Qamqab) that we loaded before, we'll get a hint - --- - -- The dashboard was created in the `kube-system` namespace - --- - -.exercise[ - -- Edit the service: - ```bash - kubectl -n kube-system edit service kubernetes-dashboard - ``` - -- Change `ClusterIP` to `NodePort`, save, and exit - -- Check the port that was assigned with `kubectl -n kube-system get services` - -- Connect to https://oneofournodes:3xxxx/ (yes, https) - -] - ---- - ## Running the Kubernetes dashboard securely - The steps that we just showed you are *for educational purposes only!* diff --git a/slides/kube/kubectlget.md b/slides/kube/kubectlget.md index f910dfb5..f1e41513 100644 --- a/slides/kube/kubectlget.md +++ b/slides/kube/kubectlget.md @@ -1,3 +1,5 @@ +class: extra-details + # First contact with `kubectl` - `kubectl` is (almost) the only tool we'll need to talk to Kubernetes @@ -79,6 +81,8 @@ --- +class: extra-details + ## What's available? - `kubectl` has pretty good introspection facilities diff --git a/slides/kube/kubectlrun.md b/slides/kube/kubectlrun.md index 2850f85a..d5ade2d5 100644 --- a/slides/kube/kubectlrun.md +++ b/slides/kube/kubectlrun.md @@ -81,6 +81,8 @@ Note: as of 1.10.1, resource types are displayed in more detail. --- +class: extra-details + ## Our `pingpong` deployment - `kubectl run` created a *deployment*, `deployment.apps/pingpong` @@ -133,6 +135,8 @@ pod/pingpong-7c8bbcd9bc-6c9qz 1/1 Running 0 10m --- +class: extra-details + ## Streaming logs in real time - Just like `docker logs`, `kubectl logs` supports convenient options: @@ -223,6 +227,8 @@ We could! But the *deployment* would notice it right away, and scale back to the --- +clas: extra-details + ## Viewing logs of multiple pods - When we specify a deployment name, only one single pod's logs are shown @@ -246,6 +252,8 @@ Unfortunately, `--follow` cannot (yet) be used to stream the logs from multiple --- +class: extra-details + ## Aren't we flooding 1.1.1.1? - If you're wondering this, good question! diff --git a/slides/kube/links.md b/slides/kube/links.md index 2a54ed54..1a03bbbe 100644 --- a/slides/kube/links.md +++ b/slides/kube/links.md @@ -1,19 +1,10 @@ # Links and resources -All things Kubernetes: - - [Kubernetes Community](https://kubernetes.io/community/) - Slack, Google Groups, meetups -- [Kubernetes on StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes) -- [Play With Kubernetes Hands-On Labs](https://medium.com/@marcosnils/introducing-pwk-play-with-k8s-159fcfeb787b) -All things Docker: +- [Azure Kubernetes Service](https://docs.microsoft.com/azure/aks/) -- [Docker documentation](http://docs.docker.com/) -- [Docker Hub](https://hub.docker.com) -- [Docker on StackOverflow](https://stackoverflow.com/questions/tagged/docker) -- [Play With Docker Hands-On Labs](http://training.play-with-docker.com/) - -Everything else: +- [Cloud Developer Advocates](https://developer.microsoft.com/advocates/) - [Local meetups](https://www.meetup.com/) diff --git a/slides/kube/ourapponkube.md b/slides/kube/ourapponkube.md index e19227f5..f5a65275 100644 --- a/slides/kube/ourapponkube.md +++ b/slides/kube/ourapponkube.md @@ -4,6 +4,8 @@ Our app on Kube --- +class: extra-details + ## What's on the menu? In this part, we will: @@ -130,6 +132,8 @@ We should see: --- +class: extra-details + ## Testing our local registry - We can retag a small image, and push it to the registry @@ -151,6 +155,8 @@ We should see: --- +class: extra-details + ## Checking again what's on our local registry - Let's use the same endpoint as before diff --git a/slides/kube/rollout.md b/slides/kube/rollout.md index 84955778..44559e69 100644 --- a/slides/kube/rollout.md +++ b/slides/kube/rollout.md @@ -192,7 +192,6 @@ class: extra-details ## Checking the dashboard during the bad rollout -If you haven't deployed the Kubernetes dashboard earlier, just skip this slide. .exercise[ diff --git a/slides/kube/setup-k8s.md b/slides/kube/setup-k8s.md index b53e94a0..600013ea 100644 --- a/slides/kube/setup-k8s.md +++ b/slides/kube/setup-k8s.md @@ -24,23 +24,6 @@ --- -## `kubeadm` drawbacks - -- Doesn't set up Docker or any other container engine - -- Doesn't set up the overlay network - -- Doesn't set up multi-master (no high availability) - --- - - (At least ... not yet!) - --- - -- "It's still twice as many steps as setting up a Swarm cluster 😕" -- Jérôme - ---- ## Other deployment options diff --git a/slides/kube/whatsnext.md b/slides/kube/whatsnext.md index 263da980..d5ccee5a 100644 --- a/slides/kube/whatsnext.md +++ b/slides/kube/whatsnext.md @@ -1,45 +1,3 @@ -# Next steps - -*Alright, how do I get started and containerize my apps?* - --- - -Suggested containerization checklist: - -.checklist[ -- write a Dockerfile for one service in one app -- write Dockerfiles for the other (buildable) services -- write a Compose file for that whole app -- make sure that devs are empowered to run the app in containers -- set up automated builds of container images from the code repo -- set up a CI pipeline using these container images -- set up a CD pipeline (for staging/QA) using these images -] - -And *then* it is time to look at orchestration! - ---- - -## Namespaces - -- Namespaces let you run multiple identical stacks side by side - -- Two namespaces (e.g. `blue` and `green`) can each have their own `redis` service - -- Each of the two `redis` services has its own `ClusterIP` - -- `kube-dns` creates two entries, mapping to these two `ClusterIP` addresses: - - `redis.blue.svc.cluster.local` and `redis.green.svc.cluster.local` - -- Pods in the `blue` namespace get a *search suffix* of `blue.svc.cluster.local` - -- As a result, resolving `redis` from a pod in the `blue` namespace yields the "local" `redis` - -.warning[This does not provide *isolation*! That would be the job of network policies.] - ---- - ## Stateful services (databases etc.) - As a first step, it is wiser to keep stateful services *outside* of the cluster @@ -172,17 +130,3 @@ Sorry Star Trek fans, this is not the federation you're looking for! - Synchronize resources across clusters - Discover resources across clusters - ---- - -## Developer experience - -*I've put this last, but it's pretty important!* - -- How do you on-board a new developer? - -- What do they need to install to get a dev stack? - -- How does a code change make it from dev to prod? - -- How does someone add a component to a stack?