diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml index 13c094b34e44..8102033a1baa 100644 --- a/_topic_maps/_topic_map.yml +++ b/_topic_maps/_topic_map.yml @@ -1332,8 +1332,6 @@ Name: Networking Dir: networking Distros: openshift-enterprise,openshift-origin Topics: -- Name: About networking - File: about-networking - Name: Understanding networking File: understanding-networking - Name: Zero trust networking diff --git a/modules/nw-load-balancing-about.adoc b/modules/nw-load-balancing-about.adoc new file mode 100644 index 000000000000..fc4e001185ea --- /dev/null +++ b/modules/nw-load-balancing-about.adoc @@ -0,0 +1,23 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-load-balancing-about_{context}"] += Supported load balancers + +Load balancing distributes incoming network traffic across multiple servers to maintain the health and efficiency of your clusters by ensuring that no single server bears too much load. Load balancers are devices that perform load balancing. They act as intermediaries between clients and servers to manage and direct traffic based on predefined rules. + +{product-title} supports the following types of load balancers: + +* Classic Load Balancer (CLB) +* Elastic Load Balancing (ELB) +* Network Load Balancer (NLB) +* Application Load Balancer (ALB) + +ELB is the default load-balancer type for AWS routers. CLB is the default for self-managed environments. NLB is the default for Red Hat OpenShift Service on AWS (ROSA). + +[IMPORTANT] +==== +Use ALB in front of an application but not in front of a router. Using an ALB requires the AWS Load Balancer Operator add-on. This operator is not supported for all {aws-first} regions or for all {product-title} profiles. +==== \ No newline at end of file diff --git a/modules/nw-load-balancing-configure-define-type.adoc b/modules/nw-load-balancing-configure-define-type.adoc new file mode 100644 index 000000000000..178e733d54ec --- /dev/null +++ b/modules/nw-load-balancing-configure-define-type.adoc @@ -0,0 +1,24 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-load-balancing-configure-define-type_{context}"] += Define the default load balancer type + +When installing the cluster, you can specify the type of load balancer that you want to use. The type of load balancer you choose at cluster installation gets applied to the entire cluster. + +This example shows how to define the default load-balancer type for a cluster deployed on {aws-short}.You can apply the procedure on other supported platforms. + +[source,yaml] +---- +apiVersion: v1 +kind: Network +metadata: + name: cluster +platform: + aws: <1> + lbType: classic <2> +---- +<1> The `platform` key represents the platform on which you have deployed your cluster. This example uses `aws`. +<2> The `lbType` key represents the load balancer type. This example uses the Classic Load Balancer, `classic`. \ No newline at end of file diff --git a/modules/nw-load-balancing-configure-specify-behavior.adoc b/modules/nw-load-balancing-configure-specify-behavior.adoc new file mode 100644 index 000000000000..0420ac3ed7d4 --- /dev/null +++ b/modules/nw-load-balancing-configure-specify-behavior.adoc @@ -0,0 +1,35 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-load-balancing-configure-specify-behavior_{context}"] += Specify load balancer behavior for an Ingress Controller + +After you install a cluster, you can configure your Ingress Controller to specify how services are exposed to external networks, so that you can better control the settings and behavior of a load balancer. + +[NOTE] +==== +Changing the load balancer settings on an Ingress Controller might override the load balancer settings you specified at installation. +==== + +[source,yaml] +---- +apiVersion: v1 +kind: Network +metadata: + name: cluster +endpointPublishingStrategy: + loadBalancer: <1> + dnsManagementPolicy: Managed + providerParameters: + aws: + classicLoadBalancer: <2> + connectionIdleTimeout: 0s + type: Classic + type: AWS + scope: External + type: LoadBalancerService +---- +<1> The `loadBalancer' field specifies the load balancer configuration settings. +<2> The `classicLoadBalancer` field sets the load balancer to `classic` and includes settings specific to the CLB on {aws-short}. \ No newline at end of file diff --git a/modules/nw-load-balancing-configure.adoc b/modules/nw-load-balancing-configure.adoc new file mode 100644 index 000000000000..b4d50bdfafc4 --- /dev/null +++ b/modules/nw-load-balancing-configure.adoc @@ -0,0 +1,9 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-load-balancing-configure_{context}"] += Configuring Load balancers + +You can define your default load-balancer type during cluster installation. After installation, you can configure your ingress controller to behave in a specific way that is not covered by the global platform configuration that you defined at cluster installation. \ No newline at end of file diff --git a/modules/nw-understanding-networking-choosing-service-types.adoc b/modules/nw-understanding-networking-choosing-service-types.adoc new file mode 100644 index 000000000000..cc26f952937d --- /dev/null +++ b/modules/nw-understanding-networking-choosing-service-types.adoc @@ -0,0 +1,34 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-choosing-service-types_{context}"] += Choosing between service types and API resources + +Service types and API resources offer different benefits for exposing applications and securing network connections. By leveraging the appropriate service type or API resource, you can effectively manage how your applications are exposed and ensure secure, reliable access for both internal and external clients. + +{product-title} supports the following service types and API resources: + +* Service Types + +** `ClusterIP` is intended for internal-only exposure. It is easy to set up and provides a stable internal IP address for accessing services within the cluster. `ClusterIP` is suitable for communication between services within the cluster. + +** `NodePort` allows external access by exposing the service on each node's IP at a static port. It is straightforward to set up and useful for development and testing. `NodePort` is good for simple external access without the need for a load balancer from the cloud provider. + +** `LoadBalancer` automatically provisions an external load balancer to distribute traffic across multiple nodes. +It is ideal for production environments where reliable, high-availability access is needed. + +** `ExternalName` maps a service to an external DNS name to allow services outside the cluster to be accessed using the service's DNS name. It is good for integrating external services or legacy systems with the cluster. + +** Headless service is a DNS name that returns the list of pod IPs without providing a stable `ClusterIP`. This is ideal for stateful applications or scenarios where direct access to individual pod IPs is needed. + +* API Resources + +** `Ingress` provides control over routing HTTP and HTTPS traffic, including support for load balancing, SSL/TLS termination, and name-based virtual hosting. It is more flexible than services alone and supports multiple domains and paths. `Ingress` is ideal when complex routing is required. + +** `Route` is similar to `Ingress` but provides additional features, including TLS re-encryption and passthrough. It simplifies the process of exposing services externally. `Route` is best for when you need advanced features, such as integrated certificate management. + +If you need a simple way to expose a service to external traffic, `Route` or `Ingress` might be the best choice. These resources can be managed by a namespace admin or developer. The easiest approach is to create a route, check its external DNS name, and configure your DNS to have a CNAME that points to the external DNS name. + +For HTTP/HTTPS/TLS, `Route` or `Ingress` should suffice. Anything else is more complex and requires a cluster admin to ensure ports are accessible or MetalLB is configured. `LoadBalancer` services are also an option in cloud environments or appropriately configured bare-metal environments. \ No newline at end of file diff --git a/modules/nw-understanding-networking-common-practices.adoc b/modules/nw-understanding-networking-common-practices.adoc new file mode 100644 index 000000000000..de0ce2ed8a6c --- /dev/null +++ b/modules/nw-understanding-networking-common-practices.adoc @@ -0,0 +1,13 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-common-practices_{context}"] += Common practices for networking services + +In {product-title}, services create a single IP address for clients to use, even if multiple pods are providing that service. This abstraction enables seamless scaling, fault tolerance, and rolling upgrades without affecting clients. + +Network security policies manage traffic within the cluster. Network controls empower namespace administrators to define ingress and egress rules for their pods. By using network administration policies, cluster administrators can establish namespace policies, override namespace policies, or set default policies when none are defined. + +Egress firewall configurations control outbound traffic from pods. These configuration settings ensure that only authorized communication occurs. The ingress node firewall protects nodes by controlling incoming traffic. Additionally, the Universal Data Network manages data traffic across the cluster. \ No newline at end of file diff --git a/modules/nw-understanding-networking-concepts-components.adoc b/modules/nw-understanding-networking-concepts-components.adoc new file mode 100644 index 000000000000..e23c509e363a --- /dev/null +++ b/modules/nw-understanding-networking-concepts-components.adoc @@ -0,0 +1,27 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-concepts-components_{context}"] += Networking concepts and components + +Networking in {product-title} uses several key components and concepts. + +* Pods and services are the smallest deployable units in Kubernetes, and services provide stable IP addresses and DNS names for sets of pods. Each pod in a cluster is assigned a unique IP address. Pods use IP addresses to communicate directly with other pods, regardless of which node they are on. The pod IP addresses will change when pods are destroyed and created. Services are also assigned unique IP addresses. A service is associated with the pods that can provide the service. When accessed, the service IP address provides a stable way to access pods by sending traffic to one of the pods that backs the service. + +* Route and Ingress APIs define rules that route HTTP, HTTPS, and TLS traffic to services within the cluster. {product-title} provides both Route and Ingress APIs as part of the default installation, but you can add third-party Ingress Controllers to the cluster. + +* The Container Network Interface (CNI) plugin manages the pod network to enable pod-to-pod communication. + +* The Cluster Network Operator (CNO) CNO manages the networking plugin components of a cluster. Using the CNO, you can set the network configuration, such as the pod network CIDR and service network CIDR. + +* DNS operators manage DNS services within the cluster to ensure that services are reachable by their DNS names. + +* Network controls define how pods are allowed to communicate with each other and with other network endpoints. These policies help secure the cluster by controlling traffic flow and enforcing rules for pod communication. + +* Load balancing distributes network traffic across multiple servers to ensure reliability and performance. + +* Service discovery is a mechanism for services to find and communicate with each other within the cluster. + +* The Ingress Operator uses {product-title} Route to manage the router and enable external access to cluster services. \ No newline at end of file diff --git a/modules/nw-understanding-networking-controls.adoc b/modules/nw-understanding-networking-controls.adoc new file mode 100644 index 000000000000..547a7211bb8b --- /dev/null +++ b/modules/nw-understanding-networking-controls.adoc @@ -0,0 +1,15 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-controls_{context}"] += Network controls + +Network controls define rules for how pods are allowed to communicate with each other and with other network endpoints. Network controls are implemented at the network level to ensure that only allowed traffic can flow between pods. This helps secure the cluster by restricting traffic flow and preventing unauthorized access. + +* Admin network policies (ANP): ANPs are cluster-scoped custom resource definitions (CRDs). As a cluster administrator, you can use an ANP to define network policies at a cluster level. You cannot override these policies by using regular network policy objects. These policies enforce strict network security rules across the entire cluster. ANPs can specify ingress and egress rules to allow administrators to control the traffic that enters and leaves the cluster. + +* Egress firewall: The egress firewall restricts egress traffic leaving the cluster. With this firewall, administrators can limit the external hosts that pods can access from within the cluster. You can configure egress firewall policies to allow or deny traffic to specific IP ranges, DNS names, or external services. This helps prevent unauthorized access to external resources and ensures that only allowed traffic can leave the cluster. + +* Ingress node firewall: The ingress node firewall controls ingress traffic to the nodes in a cluster. With this firewall, administrators define rules that restrict which external hosts can initiate connections to the nodes. This helps protect the nodes from unauthorized access and ensures that only trusted traffic can reach the cluster. \ No newline at end of file diff --git a/modules/nw-understanding-networking-dns-example.adoc b/modules/nw-understanding-networking-dns-example.adoc new file mode 100644 index 000000000000..b2a2c78452f3 --- /dev/null +++ b/modules/nw-understanding-networking-dns-example.adoc @@ -0,0 +1,106 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: PROCEDURE +[id="nw-understanding-networking-dns-example_{context}"] += Example: DNS use case + +For this example, a front-end application is running in one set of pods and a back-end service is running in another set of pods. The front-end application needs to communicate with the back-end service. You create a service for the back-end pods that gives it a stable IP address and DNS name. The front-end pods use this DNS name to access the back-end service regardless of changes to individual pod IP addresses. + +By creating a service for the back-end pods, you provide a stable IP and DNS name, `backend-service.default.svc.cluster.local`, that the front-end pods can use to communicate with the back-end service. This setup would ensure that even if individual pod IP addresses change, the communication remains consistent and reliable. + +The following steps demonstrate an example of how to configure front-end pods to communicate with a back-end service using DNS. + +. Create the back-end service. + +.. Deploy the back-end pods. ++ +[source, yaml] +---- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: backend-deployment + labels: + app: backend +spec: + replicas: 3 + selector: + matchLabels: + app: backend + template: + metadata: + labels: + app: backend + spec: + containers: + - name: backend-container + image: your-backend-image + ports: + - containerPort: 8080 +---- + +.. Define a service to expose the back-end pods. ++ +[source, yaml] +---- +apiVersion: v1 +kind: Service +metadata: + name: backend-service +spec: + selector: + app: backend + ports: + - protocol: TCP + port: 80 + targetPort: 8080 +---- + +. Create the front-end pods. + +.. Define the front-end pods. ++ +[source, yaml] +---- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: frontend-deployment + labels: + app: frontend + spec: + replicas: 3 + selector: + matchLabels: + app: frontend + template: + metadata: + labels: + app: frontend + spec: + containers: + - name: frontend-container + image: your-frontend-image + ports: + - containerPort: 80 +---- + +.. Apply the pod definition to your cluster. ++ +[source,terminal] +---- +$ oc apply -f frontend-deployment.yaml +---- + +. Configure the front-end to communicate with the back-end. ++ +In your front-end application code, use the DNS name of the back-end service to send requests. For example, if your front-end application needs to fetch data from the back-end pod, your application might include the following code: ++ +[source, JavaScript] +---- +fetch('http://backend-service.default.svc.cluster.local/api/data') + .then(response => response.json()) + .then(data => console.log(data)); +---- \ No newline at end of file diff --git a/modules/nw-understanding-networking-dns-terms.adoc b/modules/nw-understanding-networking-dns-terms.adoc new file mode 100644 index 000000000000..4611f512ed15 --- /dev/null +++ b/modules/nw-understanding-networking-dns-terms.adoc @@ -0,0 +1,19 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-dns-terms_{context}"] += Key DNS terms + +* CoreDNS: CoreDNS is the DNS server and provides name resolution for services and pods. + +* DNS names: Services are assigned DNS names based on their namespace and name. For example, a service named `my-service` in the `default` namespace would have the DNS name `my-service.default.svc.cluster.local`. + +* Domain names: Domain names are the human-friendly names used to access websites and services, such as `example.com`. + +* IP addresses: IP addresses are numerical labels assigned to each device connected to a computer network that uses IP for communication. An example of an IPv4 address is `192.0.2.1`. An example of an IPv6 address is `2001:0db8:85a3:0000:0000:8a2e:0370:7334`. + +* DNS servers: DNS servers are specialized servers that store DNS records. These records map domain names to IP addresses. When you type a domain name into your browser, your computer contacts a DNS server to find the corresponding IP address. + +* Resolution process: A DNS query is sent to a DNS resolver. The DNS resolver then contacts a series of DNS servers to find the IP address associated with the domain name. The resolver will try using the name with a series of domains, such as `.svc.cluster.local`, `svc.cluster.local`, and `cluster.local`. This process stops at the first match. The IP address is returned to your browser and then connects to the web server using the IP address. diff --git a/modules/nw-understanding-networking-dns.adoc b/modules/nw-understanding-networking-dns.adoc new file mode 100644 index 000000000000..aa062fa907d2 --- /dev/null +++ b/modules/nw-understanding-networking-dns.adoc @@ -0,0 +1,11 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-dns_{context}"] += The Domain Name System (DNS) + +The Domain Name System (DNS) is a hierarchical and decentralized naming system used to translate human-friendly domain names, such as www.example.com, into IP addresses that identify computers on a network. DNS plays a crucial role in service discovery and name resolution. + +{product-title} provides a built-in DNS to ensure that services can be reached by their DNS names. This helps maintain stable communication even if the underlying IP addresses change. When you start a pod, environment variables for service names, IP addresses, and ports are created automatically to enable the pod to communicate with other services. \ No newline at end of file diff --git a/modules/nw-understanding-networking-exposing-applications.adoc b/modules/nw-understanding-networking-exposing-applications.adoc new file mode 100644 index 000000000000..211dbc0eb5c9 --- /dev/null +++ b/modules/nw-understanding-networking-exposing-applications.adoc @@ -0,0 +1,11 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-exposing-applications_{context}"] += Exposing applications + +ClusterIP exposes services on an internal IP within the cluster to make the cluster accessible only to other services within the cluster. The NodePort service type exposes the service on a static port on each node's IP. This service type allows external traffic to access the service. Load balancers are typically used in cloud or bare-metal environments that use MetalLB. This service type provisions an external load balancer that routes external traffic to the service. On bare-metal environments, MetalLB uses VIPs and ARP announcements or BGP announcements. + +Ingress is an API object that manages external access to services, such as load balancing, SSL/TLS termination, and name-based virtual hosting. An Ingress Controller, such as NGINX or HAProxy, implements the Ingress API and handles traffic routing based on user-defined rules. \ No newline at end of file diff --git a/modules/nw-understanding-networking-features.adoc b/modules/nw-understanding-networking-features.adoc new file mode 100644 index 000000000000..1804efe0ad91 --- /dev/null +++ b/modules/nw-understanding-networking-features.adoc @@ -0,0 +1,35 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-features_{context}"] += Networking features + +{product-title} offers several networking features and enhancements. These features and enhancements are listed as follows: + +* Ingress Operator and Route API: {product-title} includes an Ingress Operator that implements the Ingress Controller API. This component enables external access to cluster services by deploying and managing HAProxy-based Ingress Controllers that support advanced routing configurations and load balancing. {product-title} uses the Route API to translate upstream Ingress objects to route objects. Routes are specific to networking in {product-title}, but you can also use third-party Ingress Controllers. + +* Enhanced security: {product-title} provides advanced network security features, such as the egress firewall and and the ingress node firewall. ++ +** Egress firewall: The egress firewall controls and restricts outbound traffic from pods within the cluster. You can set rules to limit which external hosts or IP ranges with which pods can communicate. +** Ingress node firewall: The ingress node firewall is managed by the Ingress Firewall Operator and provides firewall rules at the node level. You can protect your nodes from threats by configuring this firewall on specific nodes within the cluster to filter incoming traffic before it reaches these nodes. ++ +[NOTE] +==== +{product-title} also implements services, such as Network Policy, Admin Network Policy, and Security Context Constraints (SCC) to secure communication between pods and enforce access controls. +==== + +* Role-based access control (RBAC): {product-title} extends Kubernetes RBAC to provide more granular control over who can access and manage network resources. RBAC helps maintain security and compliance within the cluster. + +* Multi-tenancy support: {product-title} offers multi-tenancy support to enable multiple users and teams to share the same cluster while keeping their resources isolated and secure. + +* Hybrid and multi-cloud capabilities: {product-title} is designed to work seamlessly across on-premise, cloud, and multi-cloud environments. This flexibility allows organizations to deploy and manage containerized applications across different infrastructures. + +* Observability and monitoring: {product-title} provides integrated observability and monitoring tools that help manage and troubleshoot network issues. These tools include role-based access to network metrics and logs. + +* User-defined networks (UDN): UDNs allow administrators to customize network configurations. UDNs provide enhanced network isolation and IP address management. + +* Egress IP: Egress IP allows you to assign a fixed source IP address for all egress traffic originating from pods within a namespace. Egress IP can improve security and access control by ensuring consistent source IP addresses for external services. For example, if a pod needs to access an external database that only allows traffic from specific IP adresses, you can configure an egress IP for that pod to meet the access requirements. + +* Egress router: An egress router is a pod that acts as a bridge between the cluster and external systems. Egress routers allow traffic from pods to be routed through a specific IP address that is not used for any other purpose. With egress routers, you can enforce access controls or route traffic through a specific gateway. \ No newline at end of file diff --git a/modules/nw-understanding-networking-how-pods-communicate.adoc b/modules/nw-understanding-networking-how-pods-communicate.adoc new file mode 100644 index 000000000000..f53f1923be01 --- /dev/null +++ b/modules/nw-understanding-networking-how-pods-communicate.adoc @@ -0,0 +1,9 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-how-pods-communicate_{context}"] += How pods communicate + +Pods use IP addresses to communicate and a Dynamic Name System (DNS) to discover IP addresses for pods or services. Clusters use various policy types that control what communication is allowed. Pods communicate in two ways: pod-to-pod and service-to-pod. \ No newline at end of file diff --git a/modules/nw-understanding-networking-ingress.adoc b/modules/nw-understanding-networking-ingress.adoc new file mode 100644 index 000000000000..e063492f2747 --- /dev/null +++ b/modules/nw-understanding-networking-ingress.adoc @@ -0,0 +1,14 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-ingress_{context}"] += Ingress + +Ingress is a resource that provides advanced routing capabilities, including load balancing, SSL/TLS termination, and name-based virtual hosting. Here are some key points about Ingress: + +* HTTP/HTTPS routing: You can use Ingress to define rules for routing HTTP and HTTPS traffic to services within the cluster. +* Load balancing: Ingress Controllers, such as NGINX or HAProxy, manage traffic routing and load balancing based on user-defined defined rules. +* SSL/TLS termination: SSL/TLS termination is the process of decrypting incoming SSL/TLS traffic before passing it to the backend services. +* Multiple domains and paths: Ingress supports routing traffic for multiple domains and paths. \ No newline at end of file diff --git a/modules/nw-understanding-networking-networking-in-OpenShift.adoc b/modules/nw-understanding-networking-networking-in-OpenShift.adoc new file mode 100644 index 000000000000..b1ce91277422 --- /dev/null +++ b/modules/nw-understanding-networking-networking-in-OpenShift.adoc @@ -0,0 +1,16 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-networking-in-OpenShift_{context}"] += Networking in {product-title} + +{product-title} ensures seamless communication between various components within the cluster and between external clients and the cluster. Networking relies on the following core concepts and components: + +* Pod-to-pod communication +* Services +* DNS +* Ingress +* Network controls +* Load balancing \ No newline at end of file diff --git a/modules/nw-understanding-networking-nodes-clients-clusters.adoc b/modules/nw-understanding-networking-nodes-clients-clusters.adoc new file mode 100644 index 000000000000..2265afb6b9e4 --- /dev/null +++ b/modules/nw-understanding-networking-nodes-clients-clusters.adoc @@ -0,0 +1,9 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-nodes-clients-clusters_{context}"] += Networking with nodes, clients, and clusters + +A node is a machine in the cluster that can run either control-plane components, workload components, or both. A node is either a physical server or a virtual machine. A cluster is a collection of nodes that run containerized applications. Clients are the tools and users that interact with the cluster. \ No newline at end of file diff --git a/modules/nw-understanding-networking-pod-to-pod-example.adoc b/modules/nw-understanding-networking-pod-to-pod-example.adoc new file mode 100644 index 000000000000..c6d410a904e2 --- /dev/null +++ b/modules/nw-understanding-networking-pod-to-pod-example.adoc @@ -0,0 +1,32 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-pod-to-pod-example_{context}"] += Example: Controlling pod-to-pod communication + +In a microservices-based application with multiple pods, a frontend pod needs to communicate with the a backend pod to retrieve data. By using pod-to-pod communication, either directly or through services, these pods can efficiently exchange information. + +To control and secure pod-to-pod communication, you can define network controls. These controls enforce security and compliance requirements by specifying how pods interact with each other based on labels and selectors. + +[source, yaml] +---- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-some-pods + namespace: default +spec: + podSelector: + matchLabels: + role: app + ingress: + - from: + - podSelector: + matchLabels: + role: backend + ports: + - protocol: TCP + port: 80 +---- diff --git a/modules/nw-understanding-networking-pod-to-pod.adoc b/modules/nw-understanding-networking-pod-to-pod.adoc new file mode 100644 index 000000000000..a4bcffecbeb6 --- /dev/null +++ b/modules/nw-understanding-networking-pod-to-pod.adoc @@ -0,0 +1,11 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-pod-to-pod_{context}"] += Pod-to-pod communication + +Pod-to-pod communication is the ability of pods to communicate with each other within the cluster. This is crucial for the functioning of microservices and distributed applications. + +Each pod in a cluster is assigned a unique IP address that they use to communicate directly with other pods. Pod-to-pod communication is useful for intra-cluster communication where pods need to exchange data or perform tasks collaboratively. For example, Pod A can send requests directly to Pod B using Pod B's IP address. Pods can communicate over a flat network without Network Address Translation (NAT). This allows for seamless communication between pods across different nodes. \ No newline at end of file diff --git a/modules/nw-understanding-networking-routes-ingress-example.adoc b/modules/nw-understanding-networking-routes-ingress-example.adoc new file mode 100644 index 000000000000..816e832a56ac --- /dev/null +++ b/modules/nw-understanding-networking-routes-ingress-example.adoc @@ -0,0 +1,137 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: PROCEDURE +[id="nw-understanding-networking-routes-ingress-example_{context}"] += Example: Configuring routes and ingress to expose a web application + +A web application is running on your {product-title} cluster. You want to make the application accessible to external users. The application should be accessible through a specific domain name, and the traffic should be securely encrypted using TLS. The following example shows how to configure both routes and ingress to expose your web application to external traffic securely. + +[id="nw-understanding-networking-routes-ingress-example-routes_{context}"] +== Configuring Routes + +. Create a new project. ++ +[source, terminal] +---- +$ oc new-project webapp-project +---- + +. Deploy the web application. ++ +[source, terminal] +---- +$ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git --name=webapp +---- + +. Expose the service with a Route. ++ +[source, terminal] +---- +$ oc expose svc/webapp --hostname=webapp.example.com +---- + +. Secure the Route with TLS. + +.. Create a TLS secret with your certificate and key. ++ +[source, terminal] +---- +$ oc create secret tls webapp-tls --cert=path/to/tls.crt --key=path/to/tls.key +---- + +.. Update the route to use the TLS secret. ++ +[source, terminal] +---- +$ oc patch route/webapp -p '{"spec":{"tls":{"termination":"edge","certificate":"path/to/tls.crt","key":"path/to/tls.key"}}}' +---- + +[id="nw-understanding-networking-routes-ingress-example-ingress_{context}"] +== Configuring ingress + +. Create an ingress resource. ++ +Ensure your ingress Controller is installed and running in the cluster. + +. Create a service for the web application. If not already created, expose the application as a service. ++ +[source, yaml] +---- +apiVersion: v1 +kind: Service +metadata: + name: webapp-service + namespace: webapp-project +spec: + selector: + app: webapp + ports: + - protocol: TCP + port: 80 + targetPort: 8080 +---- + +. Create the ingress resource. ++ +[source, yaml] +---- +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: webapp-ingress + namespace: webapp-project + annotations: + kubernetes.io/ingress.class: "nginx" +spec: + rules: + - host: webapp.example.com + http: + paths: + - path: / + pathType: Prefix + backend: + service: + name: webapp-service + port: + number: 80 +---- + +. Secure the ingress with TLS. + +.. Create a TLS secret with your certificate and key. ++ +[source, terminal] +---- +$ oc create secret tls webapp-tls --cert=path/to/tls.crt --key=path/to/tls.key -n webapp-project +---- + +.. Update the ingress resource to use the TLS secret. ++ +[source, yaml] +---- +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: webapp-ingress + namespace: webapp-project +spec: + tls: <1> + - hosts: + - webapp.example.com + secretName: webapp-tls <2> + rules: + - host: webapp.example.com + http: + paths: + - path: / + pathType: Prefix + backend: + service: + name: webapp-service + port: + number: 80 +---- +<1> The `TLS` section specifies TLS settings. +<2> The `secretName` field is the name of Kubernetes secret that contains the TLS certificate and key. \ No newline at end of file diff --git a/modules/nw-understanding-networking-routes-ingress.adoc b/modules/nw-understanding-networking-routes-ingress.adoc new file mode 100644 index 000000000000..0bb89800d5bc --- /dev/null +++ b/modules/nw-understanding-networking-routes-ingress.adoc @@ -0,0 +1,9 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-routes-ingress_{context}"] += Routes and ingress + +Routes and ingress are both used to expose applications to external traffic. However, they serve slightly different purposes and have different capabilities. \ No newline at end of file diff --git a/modules/nw-understanding-networking-routes-vs-ingress.adoc b/modules/nw-understanding-networking-routes-vs-ingress.adoc new file mode 100644 index 000000000000..f873e4f203e0 --- /dev/null +++ b/modules/nw-understanding-networking-routes-vs-ingress.adoc @@ -0,0 +1,9 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-routes-vs-ingress_{context}"] += Comparing Routes and ingress + +Routes provide more flexibility and advanced features compared to ingress. This makes routes suitable for complex routing scenarios. Routes are simpler to set up and use, especially for basic external access needs. Ingress is often used for simpler, straightforward external access. Routes are used for more complex scenarios that require advanced routing and SSL/TLS termination. \ No newline at end of file diff --git a/modules/nw-understanding-networking-routes.adoc b/modules/nw-understanding-networking-routes.adoc new file mode 100644 index 000000000000..0e5b0299a944 --- /dev/null +++ b/modules/nw-understanding-networking-routes.adoc @@ -0,0 +1,12 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-routes_{context}"] += Routes + +Routes are specific to {product-title} resources that expose a service at a host name so that external clients can reach the service by name. + +Routes map a host name to a service. Route name mapping allows external clients to access the service using the host name. +Routes provide load balancing for the traffic directed to the service. The host name used in a route is resolved to the IP address of the router. Routes then forward the traffic to the appropriate service. Routes can also be secured using SSL/TLS to encrypt traffic between the client and the service. \ No newline at end of file diff --git a/modules/nw-understanding-networking-securing-connections.adoc b/modules/nw-understanding-networking-securing-connections.adoc new file mode 100644 index 000000000000..0aec88276ecb --- /dev/null +++ b/modules/nw-understanding-networking-securing-connections.adoc @@ -0,0 +1,17 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-securing-connections_{context}"] += Securing connections + +Ingress Controllers manage SSL/TLS termination to decrypt incoming SSL/TLS traffic before passing it to the backend services. SSL/TLS termination offloads the encryption/decryption process from the application pods. You can use TLS certificates to encrypt traffic between clients and your services. You can manage certificates with tools, such as `cert-manager`, to automate certificate distribution and renewal. + +Routes pass TLS traffic to a pod if it has the SNI field. This process allows services that run TCP to be exposed using TLS and not only HTTP/HTTPS. A site administrator can manage the certificates centrally and allow application developers to read private keys even without permission. + +The Route API enables encryption of router-to-pod traffic with cluster-managed certificates. This ensures external certificates are centrally managed while the internal leg remains encrypted. Application developers receive unique private keys for their applications. These keys can be mounted as a secret in the pod. + +Network controls define rules for how pods can communicate with each other and other network endpoints. This enhances security by controlling traffic flow within the cluster. These controls are implemented at the network plugin level to ensure that only allowed traffic flows between pods. + +Role-based access control (RBAC) manages permissions and control who can access resources within the cluster. Service accounts provide identity for pods that access the API. RBAC allows granular control over what each pod can do. diff --git a/modules/nw-understanding-networking-security-example.adoc b/modules/nw-understanding-networking-security-example.adoc new file mode 100644 index 000000000000..ef80c695aae4 --- /dev/null +++ b/modules/nw-understanding-networking-security-example.adoc @@ -0,0 +1,78 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: PROCEDURE +[id="nw-understanding-networking-security-example_{context}"] += Example: Exposing applications and securing connections + +In this example, a web application running in your cluster needs to be accessed by external users. + +. Create a service and expose the application as a service using a service type that suits your needs. ++ +[source,yaml] +---- +apiVersion: v1 +kind: Service +metadata: + name: my-web-app +spec: + type: LoadBalancer + selector: + app: my-web-app + ports: + - port: 80 + targetPort: 8080 +---- + +. Define an `Ingress` resource to manage HTTP/HTTPS traffic and route it to your service. ++ +[source,yaml] +---- +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: my-web-app-ingress + annotations: + kubernetes.io/ingress.class: "nginx" +spec: + rules: + - host: mywebapp.example.com + http: + paths: + - path: / + pathType: Prefix + backend: + service: + name: my-web-app + port: + number: 80 +---- + +. Configure TLS for your ingress to ensure secured, encrypted connections. ++ +[source,yaml] +---- +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: my-web-app-ingress + annotations: + kubernetes.io/ingress.class: "nginx" +spec: + tls: + - hosts: + - mywebapp.example.com + secretName: my-tls-secret + rules: + - host: mywebapp.example.com + http: + paths: + - path: / + pathType: Prefix + backend: + service: + name: my-web-app + port: + number: 80 +---- \ No newline at end of file diff --git a/modules/nw-understanding-networking-security.adoc b/modules/nw-understanding-networking-security.adoc new file mode 100644 index 000000000000..874e3d02785e --- /dev/null +++ b/modules/nw-understanding-networking-security.adoc @@ -0,0 +1,9 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-security_{context}"] += Security and traffic management + +Administrators can expose applications to external traffic and secure network connections using service types, such as `ClusterIP`, `NodePort`, and `LoadBalaner` and API resources such as `Ingress` and `Route`. The Ingress Operator and Cluster Network Operator (CNO) help configure and manage these services and resources. The Ingress Operator deploys and manages one or more Ingress Controllers. These controllers route external HTTP and HTTPS traffic to services within the cluster. A CNO deploys and manages the cluster network components, including pod networks, service networks, and DNS. \ No newline at end of file diff --git a/modules/nw-understanding-networking-service-to-pod-example.adoc b/modules/nw-understanding-networking-service-to-pod-example.adoc new file mode 100644 index 000000000000..af57d39699d9 --- /dev/null +++ b/modules/nw-understanding-networking-service-to-pod-example.adoc @@ -0,0 +1,52 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: PROCEDURE +[id="nw-understanding-networking-service-to-pod-example_{context}"] += Example: Controlling service-to-pod communication + +A cluster is running a microservices-based application with two components: a front-end and a backend. The front-end needs to communicate with the backend to fetch data. + +.Procedure + +. Create a backend service. ++ +[source, yaml] +---- +apiVersion: v1 +kind: Service +metadata: + name: backend +spec: + selector: + app: backend + ports: + - protocol: TCP + port: 80 + targetPort: 8080 +---- + +. Configure backend pods. ++ +[source, yaml] +---- +apiVersion: v1 +kind: Pod +metadata: + name: backend-pod + labels: + app: backend +spec: + containers: + - name: backend-container + image: my-backend-image + ports: + - containerPort: 8080 +---- + +. Establish front-end communication. ++ +The front-end pods can now use the DNS name `backend.default.svc.cluster.local` to communicate with the backend service. The service ensures that the traffic is routed to one of the backend pods. + +Service-to-pod communication abstracts the complexity of managing pod IPs and ensures reliable and efficient communication within the cluster. diff --git a/modules/nw-understanding-networking-service-to-pod.adoc b/modules/nw-understanding-networking-service-to-pod.adoc new file mode 100644 index 000000000000..c1c770a1ef98 --- /dev/null +++ b/modules/nw-understanding-networking-service-to-pod.adoc @@ -0,0 +1,56 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-service-to-pod_{context}"] += Service-to-pod communication + +Service-to-pod communication ensures that services can reliably route traffic to the appropriate pods. Services are objects that define a logical set of pods and provide a stable endpoint, such as IP addresses and DNS names. Pod IP addresses can change. Services abstract pod IP addresses to provide a consistent way to access the application components even as IP addresses change. + +Key concepts of service-to-pod communication include: + +* Endpoints: Endpoints define the IP addresses and ports of the pods that are associated with a service. + +* Selectors: Selectors use labels, such as key-value pairs, to define the criteria for selecting a set of objects that a service should target. + +* Services: Services provide a stable IP address and DNS name for a set of pods. This abstraction allows other components to communicate with the service rather than individual pods. + +* Service discovery: DNS makes services discoverable. When a service is created, it is assigned a DNS name. Other pods discover this DNS name and use it to communicate with the service. + +* Service Types: Service types control how services are exposed within or outside the cluster. + +** ClusterIP exposes the service on an internal cluster IP. It is the default service type and makes the service only reachable from within the cluster. + +** NodePort allows external traffic to access the service by exposing the service on each node's IP at a static port. + +** LoadBalancer uses a cloud provider's load balancer to expose the service externally. + +Services use selectors to identify the pods that should receive the traffic. The selectors match labels on the pods to determine which pods are part of the service. Example: A service with the selector `app: myapp` will route traffic to all pods with the label `app: myapp`. + +Endpoints are dynamically updated to reflect the current IP addresses of the pods that match the service selector. {product-name} maintains these endpoints and ensures that the service routes traffic to the correct pods. + +The communication flow refers to the sequence of steps and interactions that occur when a service in Kubernetes routes traffic to the appropriate pods. The typical communication flow for service-to-pod communication is as follows: + +* Service creation: When you create a service, you define the service type, the port on which the service listens, and the selector labels. ++ +[source, yaml] +---- + apiVersion: v1 + kind: Service + metadata: + name: my-service + spec: + selector: + app: myapp + ports: + - protocol: TCP + port: 80 + targetPort: 8080 +---- + +* DNS resolution: Each pod has a DNS name that other pods can use to communicate with the service. For example, if the service is named `my-service` in the `my-app` namespace, its DNS name is `my-service.my-app.svc.cluster.local`. + +* Traffic routing: When a pod sends a request to the service’s DNS name, {product-title} resolves the name to the service’s ClusterIP. The service then uses the endpoints to route the traffic to one of the pods that match its selector. + +* Load balancing: Services also provide basic load balancing. They distribute incoming traffic across all the pods that match the selector. This ensures that no single pod is overwhelmed with too much traffic. diff --git a/modules/nw-understanding-networking-what-is-a-client.adoc b/modules/nw-understanding-networking-what-is-a-client.adoc new file mode 100644 index 000000000000..99789245a3f7 --- /dev/null +++ b/modules/nw-understanding-networking-what-is-a-client.adoc @@ -0,0 +1,9 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-what-is-a-client_{context}"] += Understanding external clients + +An external client is any entity outside the cluster that interacts with the services and applications running within the cluster. External can include end users, external services, and external devices. End users are people who access a web application hosted in the cluster through their browsers or mobile devices. External services are other software systems or applications that interact with the services in the cluster, often through APIs. External devices are any hardware outside the cluster network that needs to communicate with the cluster services, such as the Internet of Things (IoT) devices. \ No newline at end of file diff --git a/modules/nw-understanding-networking-what-is-a-cluster.adoc b/modules/nw-understanding-networking-what-is-a-cluster.adoc new file mode 100644 index 000000000000..3da3dd10545a --- /dev/null +++ b/modules/nw-understanding-networking-what-is-a-cluster.adoc @@ -0,0 +1,9 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-what-is-a-cluster_{context}"] += Understanding clusters + +A cluster is a collection of nodes that work together to run containerized applications. These nodes include control plane nodes and compute nodes. \ No newline at end of file diff --git a/modules/nw-understanding-networking-what-is-a-node.adoc b/modules/nw-understanding-networking-what-is-a-node.adoc new file mode 100644 index 000000000000..6aeefd91cd25 --- /dev/null +++ b/modules/nw-understanding-networking-what-is-a-node.adoc @@ -0,0 +1,9 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-understanding-networking-what-is-a-node_{context}"] += What is a node? + +Nodes are the physical or virtual machines that run containerized applications. Nodes host the pods and provide resources, such as memory and storage for running the applications. Nodes enable communication between pods. Each pod is assigned an IP address. Pods within the same node can communicate with each other using these IP addresses. Nodes facilitate service discovery by allowing pods to discover and communicate with services within the cluster. Nodes help distribute network traffic among pods to ensure efficient load balancing and high availability of applications. Nodes provide a bridge between the internal cluster network and external networks to allowing external clients to access services running on the cluster. \ No newline at end of file diff --git a/networking/about-networking.adoc b/networking/about-networking.adoc deleted file mode 100644 index d9e1ead66a68..000000000000 --- a/networking/about-networking.adoc +++ /dev/null @@ -1,30 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -[id="about-networking"] -= About networking -include::_attributes/common-attributes.adoc[] -:context: about-networking - -toc::[] - -{openshift-networking} is an ecosystem of features, plugins and advanced networking capabilities that extend Kubernetes networking with the advanced networking-related features that your cluster needs to manage its network traffic for one or multiple hybrid clusters. This ecosystem of networking capabilities integrates ingress, egress, load balancing, high-performance throughput, security, inter- and intra-cluster traffic management and provides role-based observability tooling to reduce its natural complexities. - - -The following list highlights some of the most commonly used {openshift-networking} features available on your cluster: - -- Primary cluster network provided by either of the following Container Network Interface (CNI) plugins: - * xref:../networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc#about-ovn-kubernetes[OVN-Kubernetes network plugin], the default plugin - * xref:../networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc#about-ovn-kubernetes[About the OVN-Kubernetes network plugin] -- Certified 3rd-party alternative primary network plugins -- Cluster Network Operator for network plugin management -- Ingress Operator for TLS encrypted web traffic -- DNS Operator for name assignment -- MetalLB Operator for traffic load balancing on bare metal clusters -- IP failover support for high-availability -- Additional hardware network support through multiple CNI plugins, including for macvlan, ipvlan, and SR-IOV hardware networks -- IPv4, IPv6, and dual stack addressing -- Hybrid Linux-Windows host clusters for Windows-based workloads -- {SMProductName} for discovery, load balancing, service-to-service authentication, failure recovery, metrics, and monitoring of services -- {sno-caps} -- Network Observability Operator for network debugging and insights -- link:https://catalog.redhat.com/software/container-stacks/detail/5f0c67b7ce85fb9e399f3a12[Submariner] for inter-cluster networking -- link:https://docs.redhat.com/en/documentation/red_hat_service_interconnect/[Red Hat Service Interconnect] for layer 7 inter-cluster networking diff --git a/networking/understanding-networking.adoc b/networking/understanding-networking.adoc index b1b505c15b7b..548c3025bd60 100644 --- a/networking/understanding-networking.adoc +++ b/networking/understanding-networking.adoc @@ -5,24 +5,77 @@ include::_attributes/common-attributes.adoc[] :context: understanding-networking toc::[] -Cluster Administrators have several options for exposing applications that run inside a cluster to external traffic and securing network connections: -* Service types, such as node ports or load balancers +Understanding the fundamentals of networking in {product-title} ensures efficient and secure communication within your clusters and is essential for effective network administration. Key elements of networking in your environment include understanding how pods and services communicate, the role of IP addresses, and the use of DNS for service discovery. -* API resources, such as `Ingress` and `Route` +// Introduction +include::modules/nw-understanding-networking-networking-in-OpenShift.adoc[leveloffset=+1] -By default, Kubernetes allocates each pod an internal IP address for applications running within the pod. Pods and their containers can network, but clients outside the cluster do not have networking access. When you expose your application to external traffic, giving each pod its own IP address means that pods can be treated like physical hosts or virtual machines in terms of port allocation, networking, naming, service discovery, load balancing, application configuration, and migration. +include::modules/nw-understanding-networking-common-practices.adoc[leveloffset=+2] -[NOTE] -==== -Some cloud platforms offer metadata APIs that listen on the 169.254.169.254 IP address, a link-local IP address in the IPv4 `169.254.0.0/16` CIDR block. +include::modules/nw-understanding-networking-features.adoc[leveloffset=+2] -This CIDR block is not reachable from the pod network. Pods that need access to these IP addresses must be given host network access by setting the `spec.hostNetwork` field in the pod spec to `true`. +// Nodes, clusters, clients +include::modules/nw-understanding-networking-nodes-clients-clusters.adoc[leveloffset=+1] -If you allow a pod host network access, you grant the pod privileged access to the underlying network infrastructure. -==== +include::modules/nw-understanding-networking-what-is-a-node.adoc[leveloffset=+2] -include::modules/nw-ne-openshift-dns.adoc[leveloffset=+1] -include::modules/nw-ne-openshift-ingress.adoc[leveloffset=+1] -include::modules/nw-ne-comparing-ingress-route.adoc[leveloffset=+2] -include::modules/nw-networking-glossary-terms.adoc[leveloffset=+1] +include::modules/nw-understanding-networking-what-is-a-cluster.adoc[leveloffset=+2] + +include::modules/nw-understanding-networking-what-is-a-client.adoc[leveloffset=+2] + +// Concepts and components +include::modules/nw-understanding-networking-concepts-components.adoc[leveloffset=+1] + +//Pod communication +include::modules/nw-understanding-networking-how-pods-communicate.adoc[leveloffset=+1] + +include::modules/nw-understanding-networking-pod-to-pod.adoc[leveloffset=+2] + +include::modules/nw-understanding-networking-pod-to-pod-example.adoc[leveloffset=+3] + +include::modules/nw-understanding-networking-service-to-pod.adoc[leveloffset=+2] + +include::modules/nw-understanding-networking-service-to-pod-example.adoc[leveloffset=+3] + +//Load balancing + +include::modules/nw-load-balancing-about.adoc[leveloffset=+1] + +include::modules/nw-load-balancing-configure.adoc[leveloffset=+2] + +include::modules/nw-load-balancing-configure-define-type.adoc[leveloffset=+3] + +include::modules/nw-load-balancing-configure-specify-behavior.adoc[leveloffset=+3] + +//DNS +include::modules/nw-understanding-networking-dns.adoc[leveloffset=+1] + +include::modules/nw-understanding-networking-dns-terms.adoc[leveloffset=+2] + +include::modules/nw-understanding-networking-dns-example.adoc[leveloffset=+2] + +//Controls +include::modules/nw-understanding-networking-controls.adoc[leveloffset=+1] + +//Routes and Ingress +include::modules/nw-understanding-networking-routes-ingress.adoc[leveloffset=+1] + +include::modules/nw-understanding-networking-routes.adoc[leveloffset=+2] + +include::modules/nw-understanding-networking-ingress.adoc[leveloffset=+2] + +include::modules/nw-understanding-networking-routes-vs-ingress.adoc[leveloffset=+2] + +include::modules/nw-understanding-networking-routes-ingress-example.adoc[leveloffset=+2] + +// Security +include::modules/nw-understanding-networking-security.adoc[leveloffset=+1] + +include::modules/nw-understanding-networking-exposing-applications.adoc[leveloffset=+2] + +include::modules/nw-understanding-networking-securing-connections.adoc[leveloffset=+2] + +include::modules/nw-understanding-networking-security-example.adoc[leveloffset=+2] + +include::modules/nw-understanding-networking-choosing-service-types.adoc[leveloffset=+2] \ No newline at end of file