Change:
Page to be updated: What needs to be done? section needs to be updated per and For technical accuracy and/or reference, you may also check PR /sig network /help /good-first-issue cc:
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Page to be updated: For technical accuracy and/or reference, you may also check PR /help /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I am beginner and i want to contribute on this issue. Can you please guide me for this issue??
Sure, Please read and . After going through both of the resources, please could you let us know what more information would you need from our side to begin working on this issue?
can I work on this issue?
Hello everyone! Anyone looking at the issue - please note that you do not need my/anyone else's permission to work on an issue. If you are signing the and abide by the please feel free to pick up the issue. Additionally, please note that for every issue under sig docs it's always OK for anyone to open a pull request to work on it, including this one. If starting work, it's nevertheless polite to try to liaise with anyone who has already opened a PR or otherwise expressed an intention to work on the issue.
/triage accepted /priority backlog
i checked the both and . but i haven’t find any difference in actual documentation. it seems correct to me. would you like elaborate me.
Both those comments point to a change that is required in the Kubernetes Network Model section. The current phrasing is not technically accurate. For reference, you ALSO need to check the PR because it will give you the correct phrasing.
/assign
/assign
/assign
/assign

Discussion:
## The Kubernetes network model <del> Every [`Pod`](/docs/concepts/workloads/pods/) in a cluster gets its own unique cluster-wide IP address. </del> <ins> Every [`Pod`](/docs/concepts/workloads/pods/) in a cluster gets its own unique cluster-wide IP address (one address per IP address family). </ins> This means you do not need to explicitly create links between `Pods` and you almost never need to deal with mapping container ports to host ports. This creates a clean, backwards-compatible model where `Pods` can be treated

* agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node <del> Note: For those platforms that support `Pods` running in the host network (e.g. Linux), when pods are attached to the host network of a node they can still communicate with all pods on all nodes without NAT. </del> <ins> {{< note >}} For those platforms that support `Pods` running in the host network (such as Linux), when pods are attached to the host network of a node they can still communicate with all pods on all nodes without NAT. {{< /note >}} </ins> This model is not only less complex overall, but it is principally compatible with the desire for Kubernetes to enable low-friction porting of apps from VMs