API reference loadBalancerSourceRanges: "More info" points to doc without info about SourceRanges

[Kumm-Kai]

This is a Bug Report

Problem:
Since 1.22 the API reference for loadBalancerSourceRanges points to https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/ for more information.
But that documentation doesn't contain any information about SourceRanges.

Before 1.22 the reference pointed to https://kubernetes.io/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/ which was removed due to #20232 and #21459.

Proposed Solutions:

• Adding documentation about the SourceRanges to https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/
• Remove the More info: https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/ part of the API reference.
• Think about adding Configure Your Cloud Provider's Firewalls back to the documentation, removing the third party content and updating the link in the API reference. Also renaming the documentation to better fit the scope.
• Pointing to https://kubernetes.io/docs/concepts/services-networking/service/#aws-nlb-support, but that would be even more provider specific and shallow on the information part. And I would guess that it will also be removed in the future.

Page to Update:

• https://kubernetes.io/docs/reference/kubernetes-api/service-resources/service-v1/#ServiceSpec
• https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#servicespec-v1-core
• Output of kubectl explain

[sftim]

/sig docs network

Which is the web page that doesn't look right @Kumm-Kai?

/language en

It sounds like the fix might need to happen within the k/kubernetes repository - if that turns out to be the case, SIG Docs can provide pointers on how and where to fix that. We add that kind of detail so that people picking up the work are clear about the steps to follow when proposing a fix.

[Kumm-Kai]

@sftim

I've added the webpages to the issue.
Also, did I understand correctly that the https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/ page is generated from api-ref-assets/api/swagger.json, which is copied from k/kubernetes/api/openapi-spec/swagger.json. So the source of truth for the API reference lives in k/kubernetes?

If there is work that needs to be done in the k/kubernetes repo depends on the solution we decide on.
My first proposal would be the easiest to implement as we would only need to update the Create an External Load Balancer documentation.
For the other proposals there would be work in k/kubernetes needed.
So basically do we want to add information about SourceRanges to the documentation behind the link or do we want to change the link.

If we choose any of the other proposals the files in k/kubernetes to update should be the same as in #102223.

[sftim]

Thanks, that clears things up.

I think it makes sense to add text similar to

When using a Service with `.spec.type` set to `LoadBalancer`, you can specify the IP address ranges that are allowed to access the load balancer,  by setting `.spec.loadBalancerSourceRanges`. This field takes a list of IP CIDR ranges, which Kubernetes will use to configure firewall exceptions.

This field will be ignored if the cloud provider does not support the feature.

into https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/

/triage accepted

[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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 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 rotten

[sftim]

/remove-triage rotten

[k8s-ci-robot]

@sftim: Those labels are not set on the issue: triage/rotten

In response to this:

/remove-triage rotten

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.

[sftim]

/remove-lifecycle rotten

[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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 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 rotten

[sftim]

/remove-lifecycle rotten

[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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 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 rotten

[k8s-triage-robot]

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

This bot triages issues 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages issues 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

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.