From 7b9f9e23c0a38d4ba78a686c5f7e2924c6a8093e Mon Sep 17 00:00:00 2001 From: Jerome Petazzoni Date: Sun, 8 Apr 2018 11:10:07 -0500 Subject: [PATCH 1/3] Add headless services --- slides/kube/kubectlexpose.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/slides/kube/kubectlexpose.md b/slides/kube/kubectlexpose.md index 1010ca18..fb9b30ce 100644 --- a/slides/kube/kubectlexpose.md +++ b/slides/kube/kubectlexpose.md @@ -53,6 +53,26 @@ The `LoadBalancer` type is currently only available on AWS, Azure, and GCE. --- +## Headless services + +- A "headless service" is a service that doesn't have a virtual IP address + +- Since there is no virtual IP address, there is no load balancer either + +- This is useful if we want to connect directly to the pods + +- We can discover the pod IP addresses: + + - by querying the Kubernetes API + - by querying the internal DNS (if we use `kube-dns`) + - with other custom mechanisms (e.g. running Consul, Zookeeper...) + +- A headless service is obtained by setting the `clusterIP` field to `None` + + (Either with `--cluster-ip=None`, or by providing a custom YAML) + +--- + ## Running containers with open ports - Since `ping` doesn't have anything to connect to, we'll have to run something else From d228222fa6c9c5e3e2367ca69d87ae508d48aeb8 Mon Sep 17 00:00:00 2001 From: Jerome Petazzoni Date: Sun, 8 Apr 2018 17:59:42 -0500 Subject: [PATCH 2/3] Reword headless services Hopefully this explains better the use of headless services. I also added a slide about endpoints, with a couple of simple commands to show them. --- slides/kube/kubectlexpose.md | 85 +++++++++++++++++++++++++++--------- 1 file changed, 65 insertions(+), 20 deletions(-) diff --git a/slides/kube/kubectlexpose.md b/slides/kube/kubectlexpose.md index fb9b30ce..654ff498 100644 --- a/slides/kube/kubectlexpose.md +++ b/slides/kube/kubectlexpose.md @@ -53,26 +53,6 @@ The `LoadBalancer` type is currently only available on AWS, Azure, and GCE. --- -## Headless services - -- A "headless service" is a service that doesn't have a virtual IP address - -- Since there is no virtual IP address, there is no load balancer either - -- This is useful if we want to connect directly to the pods - -- We can discover the pod IP addresses: - - - by querying the Kubernetes API - - by querying the internal DNS (if we use `kube-dns`) - - with other custom mechanisms (e.g. running Consul, Zookeeper...) - -- A headless service is obtained by setting the `clusterIP` field to `None` - - (Either with `--cluster-ip=None`, or by providing a custom YAML) - ---- - ## Running containers with open ports - Since `ping` doesn't have anything to connect to, we'll have to run something else @@ -158,3 +138,68 @@ Note: please DO NOT call the service `search`. It would collide with the TLD. -- Our requests are load balanced across multiple pods. + +--- + +class: extra-details + +## If we don't need a load balancer + +- Sometimes, we want to access our scaled services directly: + + - if we want to save a tiny little bit of latency (typically less than 1ms) + + - if we need to connect over arbitrary ports (instead of a few fixed ones) + + - if we need to communicate over another protocol than UDP or TCP + + - if we want to decide how to balance the requests client-side + + - ... + +- In that case, we can use a "headless service" + +--- + +class: extra-details + +## Headless services + +- A headless service is obtained by setting the `clusterIP` field to `None` + + (Either with `--cluster-ip=None`, or by providing a custom YAML) + +- As a result, the service doesn't have a virtual IP address + +- Since there is no virtual IP address, there is no load balancer either + +- `kube-dns` will return the pods' IP addresses as multiple `A` records + +- This gives us an easy way to discover all the replicas for a deployment + +--- + +class: extra-details + +## Services and endpoints + +- A service has a number of "endpoints" + +- Each endpoint is a host + port where the service is available + +- The endpoints are maintained and updated automatically by Kubernetes + +.exercise[ + +- Check the endpoints that Kubernetes has associated with our `elastic` service: + ```bash + kubectl get service elastic -o wide + kubectl get endpoints elastic + ``` + +- Compare with the pods for the `elastic` service: + ```bash + kubectl get pods -l run=elastic -o wide + ``` + +] From a8378e7e7f3c55563dae83676ef135de0287c7ae Mon Sep 17 00:00:00 2001 From: Jerome Petazzoni Date: Mon, 9 Apr 2018 10:12:22 -0500 Subject: [PATCH 3/3] Clarify endpoints --- slides/kube/kubectlexpose.md | 33 ++++++++++++++++++++++++++------- 1 file changed, 26 insertions(+), 7 deletions(-) diff --git a/slides/kube/kubectlexpose.md b/slides/kube/kubectlexpose.md index 654ff498..391e2144 100644 --- a/slides/kube/kubectlexpose.md +++ b/slides/kube/kubectlexpose.md @@ -193,13 +193,32 @@ class: extra-details - Check the endpoints that Kubernetes has associated with our `elastic` service: ```bash - kubectl get service elastic -o wide - kubectl get endpoints elastic - ``` - -- Compare with the pods for the `elastic` service: - ```bash - kubectl get pods -l run=elastic -o wide + kubectl describe service elastic ``` ] + +In the output, there will be a line starting with `Endpoints:`. + +That line will list a bunch of addresses in `host:port` format. + +--- + +class: extra-details + +## Viewing endpoint details + +- When we have many endpoints, the previous command truncates the list + +- If we want to see the full list, we can use one of the following commands: + ```bash + kubectl describe endpoint elastic + kubectl get endpoint elastic -o yaml + ``` + +- These addresses will show us a list of IP addresses + +- These IP addresses should match the addresses of the corresponding pods: + ```bash + kubectl get pods -l run=elastic -o wide + ```