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

[feature] Can we use one headless service for one job? #1030

Open
gaocegege opened this issue Jun 21, 2019 · 11 comments
Open

[feature] Can we use one headless service for one job? #1030

gaocegege opened this issue Jun 21, 2019 · 11 comments

Comments

@gaocegege
Copy link
Member

We have ps/worker/chief for one TFJob. And now we create one headless service for one replica. I think we can use one headless service for easy-to-use.

After that, we could use {tfjob_name}-{replica_type}-{index}.{service_name}.svc.cluster.local in the code.

WDYT @johnugeorge @richardsliu

@issue-label-bot
Copy link

Issue-Label Bot is automatically applying the label improvement/enhancement to this issue, with a confidence of 0.70. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

@jtfogarty
Copy link

/area engprod
/priority p2

@stale
Copy link

stale bot commented Apr 24, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot closed this as completed May 1, 2020
@tenzen-y
Copy link
Member

/reopen
We should take this to improve cluster performance.

@google-oss-prow
Copy link

@tenzen-y: Reopened this issue.

In response to this:

/reopen
We should take this to improve cluster performance.

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.

@google-oss-prow google-oss-prow bot reopened this Jul 18, 2023
@tenzen-y
Copy link
Member

I realized this need by Aldo's comment.

cc: @kubeflow/wg-training-leads

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@tenzen-y
Copy link
Member

/lifecycle frozen

@kannon92
Copy link
Contributor

@tenzen-y brought this up in brainstorming around jobset/kubeflow.

We have implemented a few ways to customize network names.

@kannon92
Copy link
Contributor

type Network struct {
	// EnableDNSHostnames allows pods to be reached via their hostnames.
	// Pods will be reachable using the fully qualified pod hostname:
	// <jobSet.name>-<spec.replicatedJob.name>-<job-index>-<pod-index>.<subdomain>
	// +optional
	EnableDNSHostnames *bool `json:"enableDNSHostnames,omitempty"`

	// Subdomain is an explicit choice for a network subdomain name
	// When set, any replicated job in the set is added to this network.
	// Defaults to <jobSet.name> if not set.
	// +optional
	Subdomain string `json:"subdomain,omitempty"`
}

Was what we used to control service creation for the jobset.

@gaocegege
Copy link
Member Author

The suffix will differ from .svc.cluster.local according to the cluster settings. Maybe we could use a CLI parameter to config it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants