Change:
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]:

Discussion:
weight: 80 --- <!-- overview --> <del> This page shows how to create an External Load Balancer. {{< note >}} This feature is only available for cloud providers or environments which support external load balancers. {{< /note >}} </del> <ins> This page shows how to create an external load balancer. </ins> <del> When creating a service, you have the option of automatically creating a cloud network load balancer. This provides an externally-accessible IP address that sends traffic to the correct port on your cluster nodes </del> <ins> When creating a {{< glossary_tooltip text="Service" term_id="service" >}}, you have the option of automatically creating a cloud load balancer. This provides an externally-accessible IP address that sends traffic to the correct port on your cluster nodes, </ins> _provided your cluster runs in a supported environment and is configured with the correct cloud load balancer provider package_. <del> For information on provisioning and using an Ingress resource that can give services externally-reachable URLs, load balance the traffic, terminate SSL etc., please check the [Ingress](/docs/concepts/services-networking/ingress/) </del> <ins> You can also use an {{< glossary_tooltip term_id="ingress" >}} in place of Service. For more information, check the [Ingress](/docs/concepts/services-networking/ingress/) </ins> documentation. ## {{% heading "prerequisites" %}} <del> * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} </del> <ins> {{< include "task-tutorial-prereqs.md" >}} Your cluster must be running in a cloud or other environment that already has support for configuring external load balancers. </ins> <!-- steps --> <del> ## Configuration file </del> <ins> ## Create a Service ### Create a Service from a manifest </ins> To create an external load balancer, add the following line to your <del> [service configuration file](/docs/concepts/services-networking/service/#loadbalancer): </del> <ins> Service manifest: </ins> ```yaml type: LoadBalancer ``` <del> Your configuration file might look like: </del> <ins> Your manifest might then look like: </ins> ```yaml apiVersion: v1

type: LoadBalancer ``` <del> ## Using kubectl </del> <ins> ### Create a Service using kubectl </ins> You can alternatively create the service with the `kubectl expose` command and its `--type=LoadBalancer` flag: ```bash <del> kubectl expose rc example --port=8765 --target-port=9376  </del> <ins> kubectl expose deployment example --port=8765 --target-port=9376  </ins> --name=example-service --type=LoadBalancer ``` <del> This command creates a new service using the same selectors as the referenced resource (in the case of the example above, a replication controller named `example`). </del> <ins> This command creates a new Service using the same selectors as the referenced resource (in the case of the example above, a {{< glossary_tooltip text="Deployment" term_id="deployment" >}} named `example`). </ins> For more information, including optional flags, refer to the [`kubectl expose` reference](/docs/reference/generated/kubectl/kubectl-commands/#expose).

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

type: LoadBalancer ``` <del> ## Garbage Collecting Load Balancers </del> <ins> ### Caveats and limitations when preserving source IPs Load balancing services from some cloud providers do not let you configure different weights for each target. With each target weighted equally in terms of sending traffic to Nodes, external traffic is not equally load balanced across different Pods. The external load balancer is unaware of the number of Pods on each node that are used as a target. Where `NumServicePods <<  _NumNodes` or `NumServicePods >> NumNodes`, a fairly close-to-equal distribution will be seen, even without weights. Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods. ## Garbage collecting load balancers </ins> {{< feature-state for_k8s_version="v1.17" state="stable" >}}

This prevents dangling load balancer resources even in corner cases such as the service controller crashing. <del> ## External Load Balancer Providers </del> <ins> ## External load balancer providers </ins> It is important to note that the datapath for this functionality is provided by a load balancer external to the Kubernetes cluster. When the Service `type` is set to LoadBalancer, Kubernetes provides functionality equivalent to `type` equals ClusterIP to pods <del> within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the Kubernetes pods. The Kubernetes service controller automates the creation of the external load balancer, health checks (if needed), firewall rules (if needed) and retrieves the external IP allocated by the cloud provider and populates it in the service object. ## Caveats and Limitations when preserving source IPs GCE/AWS load balancers do not provide weights for their target pools. This was not an issue with the old LB kube-proxy rules which would correctly balance across all endpoints. With the new functionality, the external traffic is not equally load balanced across pods, but rather equally balanced at the node level (because GCE/AWS and other external LB implementations do not have the ability for specifying the weight per node, they balance equally across all target nodes, disregarding the number of pods on each node). We can, however, state that for NumServicePods << NumNodes or NumServicePods >> NumNodes, a fairly close-to-equal distribution will be seen, even without weights. Once the external load balancers provide weights, this functionality can be added to the LB programming path. *Future Work: No support for weights is provided for the 1.4 release, but may be added at a future date* Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods. </del> <ins> within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the nodes hosting the relevant Kubernetes pods. The Kubernetes control plane automates the creation of the external load balancer, health checks (if needed), and packet filtering rules (if needed). Once the cloud provider allocates an IP address for the load balancer, the control plane looks up that external IP address and populates it into the Service object. ## {{% heading "whatsnext" %}} * Read about [Service](/docs/concepts/services-networking/service/) * Read about [Ingress](/docs/concepts/services-networking/ingress/) * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) </ins>