From af843e8ca1675c0c07c8b02869f58bbfd7c89752 Mon Sep 17 00:00:00 2001 From: UDIT GAURAV <35391335+uditgaurav@users.noreply.github.com> Date: Mon, 3 Feb 2020 04:21:20 +0530 Subject: [PATCH] (refactor): Corrections (grammatical) in service.md file (#18944) * Update service.md * Fixed the invaild changes Signed-off-by: Udit Gaurav --- .../concepts/services-networking/service.md | 21 ++++++++++--------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index f1a210d56b..c568b36231 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -225,7 +225,8 @@ There are a few reasons for using proxying for Services: In this mode, kube-proxy watches the Kubernetes master for the addition and removal of Service and Endpoint objects. For each Service it opens a port (randomly chosen) on the local node. Any connections to this "proxy port" -is proxied to one of the Service's backend Pods (as reported via +are +proxied to one of the Service's backend Pods (as reported via Endpoints). kube-proxy takes the `SessionAffinity` setting of the Service into account when deciding which backend Pod to use. @@ -276,9 +277,9 @@ state. When accessing a Service, IPVS directs traffic to one of the backend Pods. The IPVS proxy mode is based on netfilter hook function that is similar to -iptables mode, but uses hash table as the underlying data structure and works +iptables mode, but uses a hash table as the underlying data structure and works in the kernel space. -That means kube-proxy in IPVS mode redirects traffic with a lower latency than +That means kube-proxy in IPVS mode redirects traffic with lower latency than kube-proxy in iptables mode, with much better performance when synchronising proxy rules. Compared to the other proxy modes, IPVS mode also supports a higher throughput of network traffic. @@ -310,7 +311,7 @@ about Kubernetes or Services or Pods. If you want to make sure that connections from a particular client are passed to the same Pod each time, you can select the session affinity based -on client's IP addresses by setting `service.spec.sessionAffinity` to "ClientIP" +on the client's IP addresses by setting `service.spec.sessionAffinity` to "ClientIP" (the default is "None"). You can also set the maximum session sticky time by setting `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` appropriately. @@ -421,7 +422,7 @@ Pods in other Namespaces must qualify the name as `my-service.my-ns`. These name will resolve to the cluster IP assigned for the Service. Kubernetes also supports DNS SRV (Service) records for named ports. If the -`"my-service.my-ns"` Service has a port named `"http"` with protocol set to +`"my-service.my-ns"` Service has a port named `"http"` with the protocol set to `TCP`, you can do a DNS SRV query for `_http._tcp.my-service.my-ns` to discover the port number for `"http"`, as well as the IP address. @@ -506,7 +507,7 @@ For example, if you start kube-proxy with the `--nodeport-addresses=127.0.0.0/8` If you want a specific port number, you can specify a value in the `nodePort` field. The control plane will either allocate you that port or report that the API transaction failed. -This means that you need to take care about possible port collisions yourself. +This means that you need to take care of possible port collisions yourself. You also have to use a valid port number, one that's inside the range configured for NodePort use. @@ -549,7 +550,7 @@ status: Traffic from the external load balancer is directed at the backend Pods. The cloud provider decides how it is load balanced. For LoadBalancer type of Services, when there is more than one port defined, all -ports must have the same protocol and the protocol must be one of `TCP`, `UDP` +ports must have the same protocol and the protocol must be one of `TCP`, `UDP`, and `SCTP`. Some cloud providers allow you to specify the `loadBalancerIP`. In those cases, the load-balancer is created @@ -677,7 +678,7 @@ SSL, the ELB expects the Pod to authenticate itself over the encrypted connection, using a certificate. HTTP and HTTPS selects layer 7 proxying: the ELB terminates -the connection with the user, parse headers and inject the `X-Forwarded-For` +the connection with the user, parses headers, and injects the `X-Forwarded-For` header with the user's IP address (Pods only see the IP address of the ELB at the other end of its connection) when forwarding requests. @@ -849,7 +850,7 @@ traffic. Nodes without any Pods for a particular LoadBalancer Service will fail the NLB Target Group's health check on the auto-assigned `.spec.healthCheckNodePort` and not receive any traffic. -In order to achieve even traffic, either use a DaemonSet, or specify a +In order to achieve even traffic, either use a DaemonSet or specify a [pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) to not locate on the same node. @@ -1182,7 +1183,7 @@ virtual IP address will simply transport the packets there. The Kubernetes project intends to improve support for L7 (HTTP) Services. The Kubernetes project intends to have more flexible ingress modes for Services -which encompass the current ClusterIP, NodePort, and LoadBalancer modes and more. +that encompass the current ClusterIP, NodePort, and LoadBalancer modes and more. {{% /capture %}}