mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-07-24 07:16:26 +00:00
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.
This commit is contained in:
@@ -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
|
||||
```
|
||||
|
||||
]
|
||||
|
||||
Reference in New Issue
Block a user