From f30a8984f6f4e131139ab4d20b4e61955dbc5905 Mon Sep 17 00:00:00 2001 From: windsonsea Date: Wed, 18 Sep 2024 17:39:36 +0800 Subject: [PATCH] Clean up services-networking/_index.md --- .../concepts/services-networking/_index.md | 152 +++++++++--------- 1 file changed, 73 insertions(+), 79 deletions(-) diff --git a/content/en/docs/concepts/services-networking/_index.md b/content/en/docs/concepts/services-networking/_index.md index 0307b77c5c172..b3b3cf9a5ee60 100644 --- a/content/en/docs/concepts/services-networking/_index.md +++ b/content/en/docs/concepts/services-networking/_index.md @@ -9,58 +9,53 @@ description: > The Kubernetes network model is built out of several pieces: - * Each [Pod](/docs/concepts/workloads/pods/) in a cluster gets its - own unique cluster-wide IP address. - - * A pod has its own private network namespace which is shared by - all of the containers within the pod. Processes running in - different containers in the same pod can communicate with each - other over `localhost`. - - * The _pod network_ (also called a cluster network) handles communication - between pods. It ensures that (barring intentional network - segmentation): - - * All pods can communicate with all other pods, whether they are - on the same [node](/docs/concepts/architecture/nodes/) or on - different nodes. Pods can communicate with each other - directly, without the use of proxies or address translation - (NAT). - - * (On Windows, this rule does not apply to host-network pods.) - - * Agents on a node (such as system daemons, or kubelet) can - communicate with all pods on that node. - - * The [Service](/docs/concepts/services-networking/service/) API - lets you provide a stable (long lived) IP address or hostname for a service implemented - by one or more backend pods, where the individual pods making up - the service can change over time. - - * Kubernetes automatically manages - [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/) - objects to provide information about the pods currently - backing a Service. - - * A service proxy implementation monitors the `Service` and - `EndpointSlice` objects, and programs the data plane to route - service traffic to its backends, by using operating system or - cloud provider APIs to intercept or rewrite packets. - - * The [Gateway](/docs/concepts/services-networking/gateway/) API - (or its predecessor, - [Ingress](/docs/concepts/services-networking/ingress/)) allows - you to make Services accessible to clients that are outside the cluster. - - * A simpler, but less-configurable, mechanism for cluster - ingress is available via the Service API's [`type: - LoadBalancer`](/docs/concepts/services-networking/service/#loadbalancer), - when using a supported {{< glossary_tooltip term_id="cloud-provider">}}. - - * [NetworkPolicy](/docs/concepts/services-networking/network-policies) is a built-in - Kubernetes API that - allows you to control traffic between pods, or between pods and - the outside world. +* Each [pod](/docs/concepts/workloads/pods/) in a cluster gets its + own unique cluster-wide IP address. + + * A pod has its own private network namespace which is shared by + all of the containers within the pod. Processes running in + different containers in the same pod can communicate with each + other over `localhost`. + +* The _pod network_ (also called a cluster network) handles communication + between pods. It ensures that (barring intentional network segmentation): + + * All pods can communicate with all other pods, whether they are + on the same [node](/docs/concepts/architecture/nodes/) or on + different nodes. Pods can communicate with each other + directly, without the use of proxies or address translation (NAT). + + On Windows, this rule does not apply to host-network pods. + + * Agents on a node (such as system daemons, or kubelet) can + communicate with all pods on that node. + +* The [Service](/docs/concepts/services-networking/service/) API + lets you provide a stable (long lived) IP address or hostname for a service implemented + by one or more backend pods, where the individual pods making up + the service can change over time. + + * Kubernetes automatically manages + [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/) + objects to provide information about the pods currently backing a Service. + + * A service proxy implementation monitors the `Service` and + `EndpointSlice` objects, and programs the data plane to route + service traffic to its backends, by using operating system or + cloud provider APIs to intercept or rewrite packets. + +* The [Gateway](/docs/concepts/services-networking/gateway/) API + (or its predecessor, [Ingress](/docs/concepts/services-networking/ingress/)) + allows you to make Services accessible to clients that are outside the cluster. + + * A simpler, but less-configurable, mechanism for cluster + ingress is available via the Service API's + [`type: LoadBalancer`](/docs/concepts/services-networking/service/#loadbalancer), + when using a supported {{< glossary_tooltip term_id="cloud-provider">}}. + +* [NetworkPolicy](/docs/concepts/services-networking/network-policies) is a built-in + Kubernetes API that allows you to control traffic between pods, or between pods and + the outside world. In older container systems, there was no automatic connectivity between containers on different hosts, and so it was often necessary @@ -76,36 +71,35 @@ For the other parts, Kubernetes defines the APIs, but the corresponding functionality is provided by external components, some of which are optional: - * Pod network namespace setup is handled by system-level software - implementing the [Container Runtime - Interface](/docs/concepts/architecture/cri.md). - - * The pod network itself is managed by a [pod network - implementation](/docs/concepts/cluster-administration/addons/#networking-and-network-policy). - On Linux, most container runtimes use the - {{< glossary_tooltip text="Container Networking Interface (CNI)" term_id="cni" >}} - to interact with the pod network implementation, so these - implementations are often called _CNI plugins_. - - * Kubernetes provides a default implementation of service proxying, - called {{< glossary_tooltip term_id="kube-proxy">}}, but some pod - network implementations instead use their own service proxy that - is more tightly integrated with the rest of the implementation. - - * NetworkPolicy is generally also implemented by the pod network - implementation. (Some simpler pod network implementations don't - implement NetworkPolicy, or an administrator may choose to - configure the pod network without NetworkPolicy support. In these - cases, the API will still be present, but it will have no effect.) - - * There are many [implementations of the Gateway - API](https://gateway-api.sigs.k8s.io/implementations/), some of - which are specific to particular cloud environments, some more - focused on "bare metal" environments, and others more generic. +* Pod network namespace setup is handled by system-level software implementing the + [Container Runtime Interface](/docs/concepts/architecture/cri.md). + +* The pod network itself is managed by a + [pod network implementation](/docs/concepts/cluster-administration/addons/#networking-and-network-policy). + On Linux, most container runtimes use the + {{< glossary_tooltip text="Container Networking Interface (CNI)" term_id="cni" >}} + to interact with the pod network implementation, so these + implementations are often called _CNI plugins_. + +* Kubernetes provides a default implementation of service proxying, + called {{< glossary_tooltip term_id="kube-proxy">}}, but some pod + network implementations instead use their own service proxy that + is more tightly integrated with the rest of the implementation. + +* NetworkPolicy is generally also implemented by the pod network + implementation. (Some simpler pod network implementations don't + implement NetworkPolicy, or an administrator may choose to + configure the pod network without NetworkPolicy support. In these + cases, the API will still be present, but it will have no effect.) + +* There are many [implementations of the Gateway API](https://gateway-api.sigs.k8s.io/implementations/), + some of which are specific to particular cloud environments, some more + focused on "bare metal" environments, and others more generic. ## {{% heading "whatsnext" %}} -The [Connecting Applications with Services](/docs/tutorials/services/connect-applications-service/) tutorial lets you learn about Services and Kubernetes networking with a hands-on example. +The [Connecting Applications with Services](/docs/tutorials/services/connect-applications-service/) +tutorial lets you learn about Services and Kubernetes networking with a hands-on example. [Cluster Networking](/docs/concepts/cluster-administration/networking/) explains how to set up networking for your cluster, and also provides an overview of the technologies involved.