Change:
kubectl describe services example-service ``` <del> which should produce output like this: </del> <ins> which should produce output similar to: </ins> <del> ```bash Name:                   example-service Namespace:              default Labels:                 <none> Annotations:            <none> Selector:               app=example Type:                   LoadBalancer IP:                     10.67.252.103 LoadBalancer Ingress:   192.0.2.89 Port:                   <unnamed> 80/TCP NodePort:               <unnamed> 32445/TCP Endpoints:              10.64.0.4:80,10.64.1.5:80,10.64.2.4:80 Session Affinity:       None Events:                 <none> </del> <ins> ``` Name:                     example-service Namespace:                default Labels:                   app=example Annotations:              <none> Selector:                 app=example Type:                     LoadBalancer IP Families:              <none> IP:                       10.3.22.96 IPs:                      10.3.22.96 LoadBalancer Ingress:     192.0.2.89 Port:                     <unset>  8765/TCP TargetPort:               9376/TCP NodePort:                 <unset>  30593/TCP Endpoints:                172.17.0.3:9376 Session Affinity:         None External Traffic Policy:  Cluster Events:                   <none> </ins> ``` <del> The IP address is listed next to `LoadBalancer Ingress`. </del> <ins> The load balancer's IP address is listed next to `LoadBalancer Ingress`. </ins> {{< note >}} If you are running your service on Minikube, you can find the assigned IP address and port with: <del> {{< /note >}} </del> ```bash minikube service example-service --url ``` <ins> {{< /note >}} </ins> ## Preserving the client source IP <del> Due to the implementation of this feature, the source IP seen in the target container is *not the original source IP* of the client. To enable preservation of the client IP, the following fields can be configured in the service spec (supported in GCE/Google Kubernetes Engine environments): * `service.spec.externalTrafficPolicy` - denotes if this Service desires to route external traffic to node-local or cluster-wide endpoints. There are two available options: Cluster (default) and Local. Cluster obscures the client source IP and may cause a second hop to another node, but should have good overall load-spreading. Local preserves the client source IP and avoids a second hop for LoadBalancer and NodePort type services, but risks potentially imbalanced traffic spreading. * `service.spec.healthCheckNodePort` - specifies the health check node port (numeric port number) for the service. If `healthCheckNodePort` isn't specified, the service controller allocates a port from your cluster's NodePort range. You can configure that range by setting an API server command line option, `--service-node-port-range`. It will use the user-specified `healthCheckNodePort` value if specified by the client. It only has an effect when `type` is set to LoadBalancer and `externalTrafficPolicy` is set to Local. Setting `externalTrafficPolicy` to Local in the Service configuration file activates this feature. </del> <ins> By default, the source IP seen in the target container is *not the original source IP* of the client. To enable preservation of the client IP, the following fields can be configured in the `.spec` of the Service: * `.spec.externalTrafficPolicy` - denotes if this Service desires to route external traffic to node-local or cluster-wide endpoints. There are two available options: `Cluster` (default) and `Local`. `Cluster` obscures the client source IP and may cause a second hop to another node, but should have good overall load-spreading. `Local` preserves the client source IP and avoids a second hop for LoadBalancer and NodePort type Services, but risks potentially imbalanced traffic spreading. * `.spec.healthCheckNodePort` - specifies the health check node port (numeric port number) for the service. If you don't specify `healthCheckNodePort`, the service controller allocates a port from your cluster's NodePort range. You can configure that range by setting an API server command line option, `--service-node-port-range`. The Service will use the user-specified `healthCheckNodePort` value if you specify it, provided that the Service `type` is set to LoadBalancer and `externalTrafficPolicy` is set to `Local`. Setting `externalTrafficPolicy` to Local in the Service manifest activates this feature. For example: </ins> ```yaml apiVersion: v1

Discussion:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: mentions: (see ) Weights aren't built in to Service / Endpoints / EndpointSlice / Ingress but you can indicate weighting with annotations and similar mechanisms. For example: https://kubernetes- Proposed Solution: Remove the text: Revise to explain that each implementation uses its own mechanisms for weighting and that these are not standardized. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: v1.19 Additional Information: /language en /sig network
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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
/reopen /remove-lifecycle rotten
Reopened this issue.

<detailsIn response to : /reopen /remove-lifecycle rotten 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
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]: