Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Liveness/Readiness check for external Endpoints Services #77738

Closed
MartinEmrich opened this issue May 10, 2019 · 4 comments
Closed

Liveness/Readiness check for external Endpoints Services #77738

MartinEmrich opened this issue May 10, 2019 · 4 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. sig/network Categorizes an issue or PR as relevant to SIG Network. triage/unresolved Indicates an issue that can not or will not be resolved.

Comments

@MartinEmrich
Copy link

What would you like to be added:

Liveness/Readiness checks for external Endpoints.

As I understand, kube-proxy does load-balancing over Endpoints with multiple targets like

apiVersion: v1
kind: Endpoints
metadata:
  name: someClusterOfAServiceOutsideOfTheKubernetesCluster
subsets:
- addresses:
  - ip: 10.32.123.456
  - ip: 10.32.234.567
  - ip: 10.32.345.678
  ports:
  - port: 1234

But the documentation is not clear (to me) what happens if one of these three backends does not work, but I assume that addresses with the port closed are excluded from load balancing? But what about retry intervals or check intervals?

Why would this be nice:

Adding liveness/readiness probes to Endpoints would make this configurable, e.g. to check either simple reachability (TCP) or periodically calling a liveness route (e.g. HTTP call to /myservice/alive an checking for 200 OK).

This might look like:

apiVersion: v1
kind: Endpoints
metadata:
  name: someClusterOfAServiceOutsideOfTheKubernetesCluster
subsets:
- addresses:
  - ip: 10.32.123.456
  - ip: 10.32.234.567
  - ip: 10.32.345.678
  ports:
  - port: 1234
  readinessProbe:
    httpGet:
      path: /myservice/alive
    periodSeconds: 15

Maybe this would be out of scope for Kubernetes (and best practice would be to use a loadbalancer like haproxy in a small pod), but maybe the Idea is not bad?

@MartinEmrich MartinEmrich added the kind/feature Categorizes issue or PR as related to a new feature. label May 10, 2019
@k8s-ci-robot k8s-ci-robot added the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label May 10, 2019
@MartinEmrich
Copy link
Author

@k8s-ci-robot Here you go :)

/sig network

@k8s-ci-robot k8s-ci-robot added sig/network Categorizes an issue or PR as relevant to SIG Network. and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels May 10, 2019
@athenabot
Copy link

/triage unresolved

Comment /remove-triage unresolved when the issue is assessed and confirmed.

🤖 I am a bot run by vllry. 👩‍🔬

@k8s-ci-robot k8s-ci-robot added the triage/unresolved Indicates an issue that can not or will not be resolved. label May 10, 2019
@vllry
Copy link
Contributor

vllry commented May 12, 2019

Only ready pods have an endpoint added to the Endpoints object (there is no concept of health checks at the service/endpoint level). This allows consumers of endpoints to avoid the need to health check. So I'm afraid this would be out-of-scope feature request.

There's lots of ways you could accomplish this, your best bet would be a load balancer rather than external Endpoints. But there's many ways you could customize things like adding a service-equivalent controller with this functionality, etc. ;)

/close

@k8s-ci-robot
Copy link
Contributor

@vllry: Closing this issue.

In response to this:

Only ready pods have an endpoint added to the Endpoints object (there is no concept of health checks at the service/endpoint level). This allows consumers of endpoints to avoid the need to health check. So I'm afraid this would be out-of-scope feature request.

There's lots of ways you could accomplish this, your best bet would be a load balancer rather than external Endpoints. But there's many ways you could customize things like adding a service-equivalent controller with this functionality, etc. ;)

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. sig/network Categorizes an issue or PR as relevant to SIG Network. triage/unresolved Indicates an issue that can not or will not be resolved.
Projects
None yet
Development

No branches or pull requests

4 participants