whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

JSON to YAML for external LoadBalancer (#15891)

Browse Source 
* Yaml instead of json for LoadBalancer

* Fixes from style guide

* Improve style

* Remove obsolete fragments
This commit is contained in:
Jakub Warczarek
2019-08-19 02:50:03 +02:00
committed by Kubernetes Prow Robot
parent 535e711f0e
commit d08611b759
1 changed files with 49 additions and 89 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md
+49 -89
View File
@@ -9,6 +9,10 @@ weight: 80
This page shows how to create an External Load Balancer. 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 >}}
When creating a service, you have the option of automatically creating a When creating a service, you have the option of automatically creating a
cloud network load balancer. This provides an externally-accessible IP address cloud network load balancer. This provides an externally-accessible IP address
that sends traffic to the correct port on your cluster nodes that sends traffic to the correct port on your cluster nodes
@@ -35,30 +39,24 @@ documentation.
To create an external load balancer, add the following line to your To create an external load balancer, add the following line to your
[service configuration file](/docs/concepts/services-networking/service/#loadbalancer): [service configuration file](/docs/concepts/services-networking/service/#loadbalancer):
```json ```yaml
"type": "LoadBalancer" type: LoadBalancer
``` ```
Your configuration file might look like: Your configuration file might look like:
```json ```yaml
{ apiVersion: v1
"kind": "Service", kind: Service
"apiVersion": "v1", metadata:
"metadata": { name: example-service
"name": "example-service" spec:
}, selector:
"spec": { app: example
"ports": [{ ports:
"port": 8765, - port: 8765
"targetPort": 9376 targetPort: 9376
}], type: LoadBalancer
"selector": {
"app": "example"
},
"type": "LoadBalancer"
}
}
``` ```
## Using kubectl ## Using kubectl
@@ -118,82 +116,42 @@ minikube service example-service --url
## Preserving the client source IP ## Preserving the client source IP
Due to the implementation of this feature, the source IP seen in the target Due to the implementation of this feature, the source IP seen in the target
container will *not be the original source IP* of the client. To enable 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 preservation of the client IP, the following fields can be configured in the
service spec (supported in GCE/Google Kubernetes Engine environments): service spec (supported in GCE/Google Kubernetes Engine environments):
* `service.spec.externalTrafficPolicy` - denotes if this Service desires to route * `service.spec.externalTrafficPolicy` - denotes if this Service desires to route
external traffic to node-local or cluster-wide endpoints. There are two available external traffic to node-local or cluster-wide endpoints. There are two available
options: "Cluster" (default) and "Local". "Cluster" obscures the client source 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 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 load-spreading. Local preserves the client source IP and avoids a second hop
for LoadBalancer and NodePort type services, but risks potentially imbalanced for LoadBalancer and NodePort type services, but risks potentially imbalanced
traffic spreading. traffic spreading.
* `service.spec.healthCheckNodePort` - specifies the healthcheck nodePort * `service.spec.healthCheckNodePort` - specifies the health check nodePort
(numeric port number) for the service. If not specified, healthCheckNodePort is (numeric port number) for the service. If not specified, `healthCheckNodePort` is
created by the service API backend with the allocated nodePort. It will use the created by the service API backend with the allocated `nodePort`. It will use the
user-specified nodePort value if specified by the client. It only has an user-specified `nodePort` value if specified by the client. It only has an
effect when type is set to "LoadBalancer" and externalTrafficPolicy is set effect when `type` is set to LoadBalancer and `externalTrafficPolicy` is set
to "Local". to Local.
This feature can be activated by setting `externalTrafficPolicy` to "Local" in the Setting `externalTrafficPolicy` to Local in the Service configuration file
Service Configuration file. activates this feature.
```json ```yaml
{ apiVersion: v1
"kind": "Service", kind: Service
"apiVersion": "v1", metadata:
"metadata": { name: example-service
"name": "example-service" spec:
}, selector:
"spec": { app: example
"ports": [{ ports:
"port": 8765, - port: 8765
"targetPort": 9376 targetPort: 9376
}], externalTrafficPolicy: Local
"selector": { type: LoadBalancer
"app": "example"
},
"type": "LoadBalancer",
"externalTrafficPolicy": "Local"
}
}
``` ```
### Feature availability
| K8s version | Feature support |
| :---------: |:-----------:|
| 1.7+ | Supports the full API fields |
| 1.5 - 1.6 | Supports Beta Annotations |
| <1.5 | Unsupported |
Below you could find the deprecated Beta annotations used to enable this feature
prior to its stable version. Newer Kubernetes versions may stop supporting these
after v1.7. Please update existing applications to use the fields directly.
* `service.beta.kubernetes.io/external-traffic` annotation <-> `service.spec.externalTrafficPolicy` field
* `service.beta.kubernetes.io/healthcheck-nodeport` annotation <-> `service.spec.healthCheckNodePort` field
`service.beta.kubernetes.io/external-traffic` annotation has a different set of values
compared to the `service.spec.externalTrafficPolicy` field. The values match as follows:
* "OnlyLocal" for annotation <-> "Local" for field
* "Global" for annotation <-> "Cluster" for field
{{< note >}}
This feature is not currently implemented for all cloudproviders/environments.
{{< /note >}}
Known issues:
* AWS: [kubernetes/kubernetes#35758](https://github.com/kubernetes/kubernetes/issues/35758)
* Weave-Net: [weaveworks/weave/#2924](https://github.com/weaveworks/weave/issues/2924)
{{% /capture %}}
{{% capture discussion %}}
## Garbage Collecting Load Balancers ## Garbage Collecting Load Balancers
In usual case, the correlating load balancer resources in cloud provider should In usual case, the correlating load balancer resources in cloud provider should
@@ -203,7 +161,7 @@ associated Service is deleted. Finalizer Protection for Service LoadBalancers wa
introduced to prevent this from happening. By using finalizers, a Service resource introduced to prevent this from happening. By using finalizers, a Service resource
will never be deleted until the correlating load balancer resources are also deleted. will never be deleted until the correlating load balancer resources are also deleted.
Specifically, if a Service has Type=LoadBalancer, the service controller will attach Specifically, if a Service has `type` LoadBalancer, the service controller will attach
a finalizer named `service.kubernetes.io/load-balancer-cleanup`. a finalizer named `service.kubernetes.io/load-balancer-cleanup`.
The finalizer will only be removed after the load balancer resource is cleaned up. The finalizer will only be removed after the load balancer resource is cleaned up.
This prevents dangling load balancer resources even in corner cases such as the This prevents dangling load balancer resources even in corner cases such as the
@@ -217,14 +175,18 @@ enabling the [feature gate](/docs/reference/command-line-tools-reference/feature
It is important to note that the datapath for this functionality is provided by a load balancer external to the Kubernetes cluster. 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=<ClusterIP>` to pods 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. When the Service `type` is set to LoadBalancer, Kubernetes provides functionality equivalent to `type` equals ClusterIP to pods
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 ## 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 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. kube-proxy rules which would correctly balance across all endpoints.
With the new functionality, the external traffic will not be equally load balanced across pods, but rather 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 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 for specifying the weight per node, they balance equally across all target nodes, disregarding the number of
pods on each node). pods on each node).
@@ -238,5 +200,3 @@ Once the external load balancers provide weights, this functionality can be adde
Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods. Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods.
{{% /capture %}} {{% /capture %}}