Topology aware routing of services

[m1093782566]

Feature Description

• One-line feature description (can be used as a release note):
  Implement "local service", say "topology aware routing of service". Local means "same topology level", e.g. same node, same rack, same failure zone, same failure region and whatever users like.

• Primary contact (assignee):
  @m1093782566

• Responsible SIGs:
  /sig network

• Design proposal link (community repo):
  KEP: Topology-aware service routing #640

• KEP: https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/536-topology-aware-routing

• Link to e2e and/or unit tests:

• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
  @thockin @quinton-hoole @kevin-wangzefeng

• Approver (likely from SIG/area to which feature belongs):
  @thockin

• Feature target (which target equals to which milestone):

  • Alpha release target (1.15)
  • Beta release target (x.y)
  • Stable release target (x.y)

PRs

• Service Topology implementation for Kubernetes kubernetes#72046

[m1093782566]

/assign

[m1093782566]

After discussing in today's sig-network meeting, we are targeting it Alpha in v1.10.

cc @kubernetes/sig-network-misc

[bowei]

The design discussion has not been resolved, this looks like now targeted for v1.11? Please update if not so.

[m1093782566]

It seems we have missed the v1.10 time window. I will present it on next SIG-Network meeting to see if it can get a v1.11 ticket?

[justaugustus]

@m1093782566
Any plans for this in 1.11?

If so, can you please ensure the feature is up-to-date with the appropriate:

• Description
• Milestone
• Assignee(s)
• Labels:
  • stage/{alpha,beta,stable}
  • sig/*
  • kind/feature

cc @idvoretskyi

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[m1093782566]

/remove-lifecycle stale

[m1093782566]

/wg policy

[justaugustus]

This feature current has no milestone, so we'd like to check in and see if there are any plans for this in Kubernetes 1.12.

If so, please ensure that this issue is up-to-date with ALL of the following information:

• One-line feature description (can be used as a release note):
• Primary contact (assignee):
• Responsible SIGs:
• Design proposal link (community repo):
• Link to e2e and/or unit tests:
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
• Approver (likely from SIG/area to which feature belongs):
• Feature target (which target equals to which milestone):
  • Alpha release target (x.y)
  • Beta release target (x.y)
  • Stable release target (x.y)

Set the following:

• Description
• Assignee(s)
• Labels:
  • stage/{alpha,beta,stable}
  • sig/*
  • kind/feature

Once this feature is appropriately updated, please explicitly ping @justaugustus, @kacole2, @robertsandoval, @rajendar38 to note that it is ready to be included in the Features Tracking Spreadsheet for Kubernetes 1.12.

---

Please note that Features Freeze is tomorrow, July 31st, after which any incomplete Feature issues will require an Exception request to be accepted into the milestone.

In addition, please be aware of the following relevant deadlines:

• Docs deadline (open placeholder PRs): 8/21
• Test case freeze: 8/28

Please make sure all PRs for features have relevant release notes included as well.

Happy shipping!

P.S. This was sent via automation

[kacole2]

Hi @m1093782566
This enhancement has been tracked before, so we'd like to check in and see if there are any plans for this to graduate stages in Kubernetes 1.13. This release is targeted to be more ‘stable’ and will have an aggressive timeline. Please only include this enhancement if there is a high level of confidence it will meet the following deadlines:
Docs (open placeholder PRs): 11/8
Code Slush: 11/9
Code Freeze Begins: 11/15
Docs Complete and Reviewed: 11/27

Please take a moment to update the milestones on your original post for future tracking and ping @kacole2 if it needs to be included in the 1.13 Enhancements Tracking Sheet

We are also now encouraging that every new enhancement aligns with a KEP. If a KEP has been created, please link to it in the original post or take the opportunity to develop a KEP.

Thanks!

[johnbelamaric]

Per sig-network we are looking at getting a revised KEP in for the 1.13 timeframe but not the code.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[m1093782566]

/remove-lifecycle stale

[claurence]

@m1093782566 Hello - I’m the enhancement’s lead for 1.14 and I’m checking in on this issue to see what work (if any) is being planned for the 1.14 release. Enhancements freeze is Jan 29th and I want to remind that all enhancements must have a KEP

[JamesLaverack]

/remove-stage alpha
/milestone v1.22

[salaxander]

Hey @robscott - 1.22 enhancements team here! I've got a couple questions to clarify for the release. Is the current plan to postpone deprecation if #2433 doesn't end up making the release? Also, would you be able to update the kep.yaml to have latest-milestone: "v1.22" before enhancements freeze on 5/13?

[robscott]

Hey @salaxander, thanks for checking in! I think the only thing that's left to do for this enhancement in 1.22 is remove the code. I believe it was deprecated in the last cycle and #2433 went alpha in 1.21 as well. Since this feature only ever made it to alpha, I don't think we need to wait for #2433 to make it to alpha before removing this one (though #2433 may make it to beta in 1.22). With that said, does this still require the latest-milestone update if we're just removing the code?

[salaxander]

Thanks for the reply @robscott! @JamesLaverack, @annajung, or @kikisdeliveryservice, would you be able to confirm if we would still need the latest-milestone updated for the deprecation?

Thanks everyone! ☺️

[chino]

So #2433 is replacing this?

[robscott]

@chino yep, #2433 is replacing this one.

[jethrogb]

It seems reasonable to me to keep this until #2433 hits alpha.

[johnbelamaric]

When it comes to it, feel free to assign me as PRR approver. Should be all N/A pretty much for PRR but the validations will kick in.

[robscott]

Sorry for the confusion on this one, I meant to say "I don't think we need to wait for #2433 to make it to beta". It's already in alpha and therefore can serve as a replacement for this since that's as far as this feature went.

[johnbelamaric]

I think it makes sense to update the latest-milestone to indicate that that is when the code was removed.

[PI-Victor]

Heya @robscott, Docs release lead for 1.22, this KEP did not opt-in for docs changes for this release, however i have one question, does this KEP deprecate ServiceTopology feature gate? As i understand it, this would be replaced by Topology Aware Hints

Please correct me if i'm wrong, but I believe it needs to be moved in the documentation to the deprecated features table from the feature gates table where it currently resides.
If so, could you or a member of the team please open a PR to rectify that?

thank you!

[robscott]

Hey @PI-Victor, you're right that we'll need to update the docs to note that this feature has been deprecated. The API deprecation actually already happened in 1.21 and we'll be working on removing the functionality in 1.22: kubernetes/kubernetes#96736.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[george-angel]

/remove-lifecycle stale

[thockin]

@robscott Time to close this one?

[robscott]

Yep, I think so, looks like everything's been removed. @andrewsykim can probably correct me if I missed anything.

/close

[k8s-ci-robot]

@robscott: Closing this issue.

In response to this:

Yep, I think so, looks like everything's been removed. @andrewsykim can probably correct me if I missed anything.

/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.