diff --git a/slides/k8s/apilb.md b/slides/k8s/apilb.md
new file mode 100644
index 00000000..bdec57a8
--- /dev/null
+++ b/slides/k8s/apilb.md
@@ -0,0 +1,89 @@
+# API server availability
+
+- When we set up a node, we need the address of the API server:
+
+  - for kubelet
+
+  - for kube-proxy
+
+  - sometimes for the pod network system (like kube-router)
+
+- How do we ensure the availability of that endpoint?
+
+  (what if the node running the API server goes down?)
+
+---
+
+## Option 1: external load balancer
+
+- Set up an external load balancer
+
+- Point kubelet (and other components) to that load balancer
+
+- Put the node(s) running the API server behind that load balancer
+
+- Update the load balancer if/when an API server node needs to be replaced
+
+- On cloud infrastructures, some mechanisms provide automation for this
+
+  (e.g. on AWS, an Elastic Load Balancer + Auto Scaling Group)
+
+- [Example in Kubernetes The Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/docs/08-bootstrapping-kubernetes-controllers.md#the-kubernetes-frontend-load-balancer)
+
+---
+
+## Option 2: local load balancer
+
+- Set up a load balancer (like NGINX, HAProxy...) on *each* node
+
+- Configure that load balancer to send traffic to the API server node(s)
+
+- Point kubelet (and other components) to `localhost`
+
+- Update the load balancer configuration when API server nodes are updated
+
+---
+
+## Updating the local load balancer config
+
+- Distribute the updated configuration (push)
+
+- Or regularly check for updates (pull)
+
+- The latter requires an external, highly available store
+ 
+  (it could be an object store, an HTTP server, or even DNS...)
+
+- Updates can be facilitated by a DaemonSet
+
+  (but remember that it can't be used when installing a new node!)
+
+---
+
+## Option 3: DNS records
+
+- Put all the API server nodes behind a round-robin DNS
+
+- Point kubelet (and other components) to that name
+
+- Update the records when needed
+
+- Note: this option is not officially supported
+
+  (but since kubelet supports reconnection anyway, it *should* work)
+
+---
+
+## Option 4: ....................
+
+- Many managed clusters expose a high-availability API endpoint
+
+  (and you don't have to worry about it)
+
+- You can also use HA mechanisms that you're familiar with
+
+  (e.g. virtual IPs)
+
+- Tunnels are also fine
+
+  (e.g. k3s uses a tunnel to allow each node to contact the API server)
diff --git a/slides/kube-admin-one.yml b/slides/kube-admin-one.yml
index 6c3dea9d..9ae83d17 100644
--- a/slides/kube-admin-one.yml
+++ b/slides/kube-admin-one.yml
@@ -25,8 +25,6 @@ chapters:
 - - k8s/multinode.md
   - k8s/cni.md
   - k8s/apilb.md
-  - k8s/kuberouter.md
-  - k8s/interco.md
   #FIXME: check le talk de Laurent Corbes pour voir s'il y a d'autres choses utiles à mentionner
   #BONUS: intégration CoreDNS pour résoudre les noms des clusters des voisins
 - - k8s/setup-managed.md