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

updated service page #43548

Closed
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion content/en/docs/concepts/services-networking/service.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,8 @@ expect that an individual Pod is reliable and durable).

Each Pod gets its own IP address (Kubernetes expects network plugins to ensure this).
For a given Deployment in your cluster, the set of Pods running in one moment in
sftim marked this conversation as resolved.
Show resolved Hide resolved
time could be different from the set of Pods running that application a moment later.
time could be different from the set of Pods running that application a moment later
due to scaling, resources or demand.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think Line 38 is optional change

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @aj11anuj
Thanks for the review. I included

due to scaling, resources, or demand.

to clarify potential reasons behind the behavior for improved user understanding. If you believe it's optional, I'm open to your suggestion and can adjust if needed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just adding these factors won't really reduce ambiguity

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi @Gauravpadam ,
Thank you for your feedback and your offer to assist.

I agree with your feedback that Just adding these factors won't make a huge difference in clarity.
I added these factors just to guide the readers so that they could explore the factors in detail, as the resources can be easily found within the Kubernetes documentation.

However, regarding this

This doesn't help much the way it is right now imo.

I intentionally didn't include more info to maintain a clear and focused message.
Providing extensive details might shift the text's primary focus away (from the dynamic nature of Kubernetes and its challenges in maintaining connectivity), potentially making it less effective in conveying the main point.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Gauravpadam
However, your suggestion is highly valued and I am eager to look at your suggestions to replace these factors in a clearer way which is also concise enough to not shift the focus of the reader from the primary message of the documentation text.
Thanks again for taking the time to look into this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


This leads to a problem: if some set of Pods (call them "backends") provides
functionality to other Pods (call them "frontends") inside your cluster,
Expand Down