From 02c3a93de50af26e0265347de98ec005f7341ee9 Mon Sep 17 00:00:00 2001 From: Daniel Chadwick Date: Tue, 12 Nov 2024 14:37:15 -0500 Subject: [PATCH] osdocs8646 updating networking about page --- modules/nw-ne-comparing-ingress-route.adoc | 2 + modules/nw-ne-openshift-dns.adoc | 13 +-- modules/nw-ne-openshift-improves.adoc | 34 ++++++ .../nw-ne-openshift-kubernetes-openshift.adoc | 18 +++ networking/about-networking.adoc | 30 ----- ...example-ingress-route.adoc[leveloffset=+2] | 107 ++++++++++++++++++ .../nw-ne-openshift-example-dns.adoc | 92 +++++++++++++++ ...exposing-applications.adoc[leveloffset=+2] | 9 ++ ...hift-security-traffic.adoc[leveloffset=+1] | 9 ++ networking/nw-ne-openshift-clients.adoc | 10 ++ networking/nw-ne-openshift-clusters.adoc | 8 ++ .../nw-ne-openshift-concepts-components.adoc | 38 +++++++ networking/nw-ne-openshift-dns-key-terms.adoc | 24 ++++ .../nw-ne-openshift-example-pod-to-pod.adoc | 29 +++++ ...penshift-example-securing-connections.adoc | 76 +++++++++++++ ...w-ne-openshift-example-service-to-pod.adoc | 45 ++++++++ .../nw-ne-openshift-how-pods-communicate.adoc | 8 ++ networking/nw-ne-openshift-ingress.adoc | 20 ++++ ...w-ne-openshift-nodes-clusters-clients.adoc | 8 ++ networking/nw-ne-openshift-nodes.adoc | 10 ++ ...ne-openshift-pod-to-pod-communication.adoc | 10 ++ .../nw-ne-openshift-routes-ingress.adoc | 8 ++ ...penshift-service-to-pod-communication.adoc | 65 +++++++++++ networking/understanding-networking.adoc | 33 ++++-- ...osing-service-types-and-applications.adoc[ | 28 +++++ .../w-ne-openshift-network-policies.adoc | 8 ++ networking/w-ne-openshift-routes.adoc | 17 +++ .../w-ne-openshift-securing-connections.adoc | 11 ++ 28 files changed, 721 insertions(+), 49 deletions(-) create mode 100644 modules/nw-ne-openshift-improves.adoc create mode 100644 modules/nw-ne-openshift-kubernetes-openshift.adoc delete mode 100644 networking/about-networking.adoc create mode 100644 networking/include::modules/nw-ne-example-ingress-route.adoc[leveloffset=+2] create mode 100644 networking/include::modules/nw-ne-openshift-example-dns.adoc create mode 100644 networking/include::modules/nw-ne-openshift-exposing-applications.adoc[leveloffset=+2] create mode 100644 networking/include::modules/nw-ne-openshift-security-traffic.adoc[leveloffset=+1] create mode 100644 networking/nw-ne-openshift-clients.adoc create mode 100644 networking/nw-ne-openshift-clusters.adoc create mode 100644 networking/nw-ne-openshift-concepts-components.adoc create mode 100644 networking/nw-ne-openshift-dns-key-terms.adoc create mode 100644 networking/nw-ne-openshift-example-pod-to-pod.adoc create mode 100644 networking/nw-ne-openshift-example-securing-connections.adoc create mode 100644 networking/nw-ne-openshift-example-service-to-pod.adoc create mode 100644 networking/nw-ne-openshift-how-pods-communicate.adoc create mode 100644 networking/nw-ne-openshift-ingress.adoc create mode 100644 networking/nw-ne-openshift-nodes-clusters-clients.adoc create mode 100644 networking/nw-ne-openshift-nodes.adoc create mode 100644 networking/nw-ne-openshift-pod-to-pod-communication.adoc create mode 100644 networking/nw-ne-openshift-routes-ingress.adoc create mode 100644 networking/nw-ne-openshift-service-to-pod-communication.adoc create mode 100644 networking/w-ne-openshift-echoosing-service-types-and-applications.adoc[ create mode 100644 networking/w-ne-openshift-network-policies.adoc create mode 100644 networking/w-ne-openshift-routes.adoc create mode 100644 networking/w-ne-openshift-securing-connections.adoc diff --git a/modules/nw-ne-comparing-ingress-route.adoc b/modules/nw-ne-comparing-ingress-route.adoc index cc4def642704..a49da887aabb 100644 --- a/modules/nw-ne-comparing-ingress-route.adoc +++ b/modules/nw-ne-comparing-ingress-route.adoc @@ -9,3 +9,5 @@ The Kubernetes Ingress resource in {product-title} implements the Ingress Contro The {product-title} route provides Ingress traffic to services in the cluster. Routes provide advanced features that might not be supported by standard Kubernetes Ingress Controllers, such as TLS re-encryption, TLS passthrough, and split traffic for blue-green deployments. Ingress traffic accesses services in the cluster through a route. Routes and Ingress are the main resources for handling Ingress traffic. Ingress provides features similar to a route, such as accepting external requests and delegating them based on the route. However, with Ingress you can only allow certain types of connections: HTTP/2, HTTPS and server name identification (SNI), and TLS with certificate. In {product-title}, routes are generated to meet the conditions specified by the Ingress resource. + +Ingress provides more flexibility and advanced features compared to Routes, making it suitable for complex routing scenarios. Routes are simpler to set up and use, especially for basic external access needs. Routes are often used for simpler, straightforward external access, while Ingress is used for more complex scenarios requiring advanced routing and SSL termination. \ No newline at end of file diff --git a/modules/nw-ne-openshift-dns.adoc b/modules/nw-ne-openshift-dns.adoc index 3bf03d6c308f..29888d15fead 100644 --- a/modules/nw-ne-openshift-dns.adoc +++ b/modules/nw-ne-openshift-dns.adoc @@ -5,15 +5,6 @@ [id="nw-ne-openshift-dns_{context}"] = {product-title} DNS -If you are running multiple services, such as front-end and back-end services for -use with multiple pods, environment variables are created for user names, -service IPs, and more so the front-end pods can communicate with the back-end -services. If the service is deleted and recreated, a new IP address can be -assigned to the service, and requires the front-end pods to be recreated to pick -up the updated values for the service IP environment variable. Additionally, the -back-end service must be created before any of the front-end pods to ensure that -the service IP is generated properly, and that it can be provided to the -front-end pods as an environment variable. +Domain Name System (DNS) is a hierarchical and decentralized naming system used to translate human-friendly domain names (like www.example.com) into IP addresses that computers use to identify each other on the network. Essentially, DNS acts like the phonebook of the internet. DNS plays a crucial role in service discovery and name resolution. -For this reason, {product-title} has a built-in DNS so that the services can be -reached by the service DNS as well as the service IP/port. +OpenShift 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 a pod is started, environment variables for service names, IPs, and ports are created automatically, enabling the pod to communicate with other services. diff --git a/modules/nw-ne-openshift-improves.adoc b/modules/nw-ne-openshift-improves.adoc new file mode 100644 index 000000000000..f6da8abcddc6 --- /dev/null +++ b/modules/nw-ne-openshift-improves.adoc @@ -0,0 +1,34 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-improves_{context}"] += How networking in OpenShift improves upon networking in Kubernetes + +Red Hat OpenShift Container Platform builds on Kubernetes by adding several unique features and enhancements, especially in the area of networking. Here are some key differences and unique aspects: + +Integrated Networking Solutions:: +OpenShift SDN: OpenShift uses its own implementation of Software-Defined Networking (SDN) called OpenShift SDN. It provides a unified cluster network that enables communication between pods across the OpenShift cluster. +Open vSwitch (OVS): OpenShift SDN uses Open vSwitch to create an overlay network, which simplifies network management and provides high-performance throughput. + +Built-in DNS:: +OpenShift has a built-in DNS service that allows pods to resolve service names to IP addresses. This ensures that pods can communicate with services using stable DNS names, even if the underlying pod IPs change. + +Ingress Operator:: +OpenShift includes an Ingress Operator that implements the IngressController API. This component enables external access to cluster services by deploying and managing HAProxy-based Ingress Controllers. It allows for advanced routing configurations and load balancing. + +Enhanced Security:: +OpenShift provides advanced network security features, such as Network Policies and Security Context Constraints (SCCs), which help in securing communication between pods and enforcing access controls. + +Role-Based Access Control (RBAC):: +OpenShift extends Kubernetes RBAC to provide more granular control over who can access and manage network resources. This helps in maintaining security and compliance within the cluster. + +Multi-Tenancy Support:: +OpenShift offers robust multi-tenancy support, allowing multiple users or teams to share the same cluster while keeping their resources isolated and secure. + +Hybrid and Multi-Cloud Capabilities:: +OpenShift 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:: +OpenShift provides integrated observability and monitoring tools that help in managing and troubleshooting network issues. This includes role-based access to network metrics and logs. +These features make Red Hat OpenShift Container Platform a powerful and flexible platform for managing containerized applications, providing enhanced networking capabilities compared to standard Kubernetes setups. diff --git a/modules/nw-ne-openshift-kubernetes-openshift.adoc b/modules/nw-ne-openshift-kubernetes-openshift.adoc new file mode 100644 index 000000000000..d1dc27dc96e2 --- /dev/null +++ b/modules/nw-ne-openshift-kubernetes-openshift.adoc @@ -0,0 +1,18 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-kubernetes-openshift_{context}"] += Networking in Kubernetes and OpenShift + +Networking in Kubernetes and Red Hat OpenShift Container Platform ensures seamless communication between various components within the cluster and between external clients and the cluster. Both platforms rely on several core concepts and components: +* Pod-to-Pod Communications +* Services +* DNS +* Ingress Controllers +* Network Policies +* Load Balancing + +For more information these concepts and components, see Networking concepts and components . + +In OpenShift (and Kubernetes in general), services are used to expose pods internally and externally, allowing for seamless communication within the cluster and with external clients. Using Network Policies to control and secure traffic flow within the cluster. Utilizing load balancers to distribute traffic and maintain service availability. \ 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/include::modules/nw-ne-example-ingress-route.adoc[leveloffset=+2] b/networking/include::modules/nw-ne-example-ingress-route.adoc[leveloffset=+2] new file mode 100644 index 000000000000..bcbefdd37b5b --- /dev/null +++ b/networking/include::modules/nw-ne-example-ingress-route.adoc[leveloffset=+2] @@ -0,0 +1,107 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +[id="nw-ne-openshift-example-ingress-route_{context}"] += Example: Configuring routes and ingress to expose a web application +Imagine you have a web application running in your OpenShift cluster, and you want to make it accessible to external users. The application should be accessible via a specific domain name, and the traffic should be securely encrypted using TLS. The following example shows you how to configure both Routes and Ingress to expose your web application to external traffic securely. Routes offer a straightforward way to expose applications in OpenShift, while Ingress provides more advanced routing and TLS termination features. + +Configuring Routes + +1. Create a New Project: + [source, terminal] + oc new-project webapp-project + +2. Deploy the Web Application: + [source, terminal] + oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git --name=webapp + +3. Expose the Service with a Route: + [source, terminal] + oc expose svc/webapp --hostname=webapp.example.com + +4. 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"}}}' + +Configuring ingress + +1. Create an Ingress Resource: + + First, ensure your Ingress Controller (e.g., NGINX) is installed and running in the cluster. + +2. 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 + +3. 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 + +4. 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: + - hosts: + - webapp.example.com + secretName: webapp-tls + rules: + - host: webapp.example.com + http: + paths: + - path: / + pathType: Prefix + backend: + service: + name: webapp-service + port: + number: 80 diff --git a/networking/include::modules/nw-ne-openshift-example-dns.adoc b/networking/include::modules/nw-ne-openshift-example-dns.adoc new file mode 100644 index 000000000000..33ae5403f18b --- /dev/null +++ b/networking/include::modules/nw-ne-openshift-example-dns.adoc @@ -0,0 +1,92 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-example-dns_{context}"] += Example: DNS use case + +Imagine you have a front-end application running in one set of pods and a back-end service running in another set of pods. The front-end application needs to communicate with the back-end service. You create a Kubernetes service for the back-end pods, giving it a stable IP 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 Kubernetes 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. To do so, complete the following steps: + +1. Create the back-end service. + +a. Deploy the back-end pods: + +Create a deployment for the back-end application. + [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 + +b. Create the Back-End Service: + +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 + +2. Create the front-end deployment. + +Deploy the front-end pods: + +Create a deployment for the front-end application. + [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 + +3. Configure front-end to communicate with back-end. + +Use the DNS name of the back-end service: + +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, you might have code like this: + [source, JavaScript] + fetch('http://backend-service.default.svc.cluster.local/api/data') + .then(response => response.json()) + .then(data => console.log(data)); diff --git a/networking/include::modules/nw-ne-openshift-exposing-applications.adoc[leveloffset=+2] b/networking/include::modules/nw-ne-openshift-exposing-applications.adoc[leveloffset=+2] new file mode 100644 index 000000000000..27c91ffaf4b4 --- /dev/null +++ b/networking/include::modules/nw-ne-openshift-exposing-applications.adoc[leveloffset=+2] @@ -0,0 +1,9 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +[id="nw-ne-openshift-exposing-applications_{context}"] += Exposing applications +In Kubernetes, ClusterIP is the default service type. It exposes the service on an internal IP within the cluster, making it accessible only to other services within the cluster. The NodePort service type exposes the service on a static port on each node's IP, which allows external traffic to access the service. LoadBalancer service is typically used in cloud environments. This service type provisions an external load balancer that routes external traffic to the service. + +An API object that manages external access to services, usually HTTP and HTTPS. It provides load balancing, SSL termination, and name-based virtual hosting. A controller that implements the Ingress API, such as NGINX or HAProxy, to handle the actual routing of traffic based on defined rules. diff --git a/networking/include::modules/nw-ne-openshift-security-traffic.adoc[leveloffset=+1] b/networking/include::modules/nw-ne-openshift-security-traffic.adoc[leveloffset=+1] new file mode 100644 index 000000000000..bcf8cebb4d46 --- /dev/null +++ b/networking/include::modules/nw-ne-openshift-security-traffic.adoc[leveloffset=+1] @@ -0,0 +1,9 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +[id="nw-ne-openshift-security-traffic_{context}"] += Security and traffic management +Administrators can expose applications to external traffic and secure network connections using service types like node ports and load balancers, and API resources like Ingress and Route. The Ingress Operator and Cluster Network Operator play crucial roles in configuring and managing these aspects. An Ingress Operator deploys and manages one or more Ingress Controllers, which are responsible for routing external HTTP and HTTPS traffic to services within the cluster. A cluster network operator deploys and manages the cluster network components (such as pod networks, service networks, DNS, etc.) + +Cluster administrators have several options for exposing applications to external traffic and securing network connections, such as service types (node ports and load balancers) and API resources (Ingress and Route). diff --git a/networking/nw-ne-openshift-clients.adoc b/networking/nw-ne-openshift-clients.adoc new file mode 100644 index 000000000000..8c9e5b5ff59c --- /dev/null +++ b/networking/nw-ne-openshift-clients.adoc @@ -0,0 +1,10 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-nodes_{context}"] += What is an external client? + +An external client refers to any entity outside of the cluster that interacts with the services and applications running within the cluster. This 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, like IoT devices. + +External clients typically access the cluster services through well-defined interfaces and endpoints, often managed by Ingress Controllers and Load Balancers to ensure secure by and efficient traffic routing. diff --git a/networking/nw-ne-openshift-clusters.adoc b/networking/nw-ne-openshift-clusters.adoc new file mode 100644 index 000000000000..140245d6a827 --- /dev/null +++ b/networking/nw-ne-openshift-clusters.adoc @@ -0,0 +1,8 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-nodes_{context}"] += What is a cluster? + +A cluster in Red Hat OpenShift Container Platform (and Kubernetes in general) is a collection of nodes (which are virtual or physical machines) that work together to run containerized applications. These nodes include master nodes and worker nodes. Master nodes manage the cluster, maintaining the desired state and handling cluster-wide operations. Worker nodes run the containers (pods) that house the application workloads. Together, these nodes form a cohesive environment where resources can be efficiently managed, scaled, and distributed to meet the needs of the applications running within the cluster. \ No newline at end of file diff --git a/networking/nw-ne-openshift-concepts-components.adoc b/networking/nw-ne-openshift-concepts-components.adoc new file mode 100644 index 000000000000..07b649c9e850 --- /dev/null +++ b/networking/nw-ne-openshift-concepts-components.adoc @@ -0,0 +1,38 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-concepts-components_{context}"] += Key networking concepts and components + +Key concepts in OpenShift networking include: + +Pods and Services:: +Pods are the smallest deployable units in Kubernetes, and services provide stable IP addresses and DNS names for sets of pods. Each pod in a Kubernetes cluster is assigned a unique IP address. Pods can communicate with each other directly using their IP addresses, regardless of which node they are on. + +Ingress and Routes:: +Ingress resources define rules for routing external HTTP and HTTPS traffic to services within the cluster. Routes are used to expose services to external traffic. Ingress Controllers, such as NGINX or HAProxy, manage the actual routing based on these rules. + +Container Network Interface (CNI):: +The CNI plugin manages the pod network, enabling pod-to-pod communication. + +Cluster Network Operator (CNO):: +The CNO plugin manage cluster network configuration, including pod network CIDR and service network CIDR. + +DNS Operator:: +DNS operators manage DNS services within the cluster, ensuring services are reachable by their DNS names. + +Network Policies:: +Network policies 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:: +Load balancing distributes network traffic across multiple servers to ensure reliability and performance. + +Service Discovery:: +Service discovery is a mechanism for services to find and communicate with each other within the cluster. + +Kube-Proxy:: +Kube-Proxy is a network proxy that runs on each node and ensures that network traffic is correctly routed to the appropriate pods. + +OpenShift Container Platform Ingress Operator:: +The Ingress Operator implements the IngressController API, enabling external access to cluster services by deploying and managing HAProxy-based Ingress Controllers. This allows for routing traffic using OpenShift Route and Kubernetes Ingress resources. diff --git a/networking/nw-ne-openshift-dns-key-terms.adoc b/networking/nw-ne-openshift-dns-key-terms.adoc new file mode 100644 index 000000000000..c74a96a3b716 --- /dev/null +++ b/networking/nw-ne-openshift-dns-key-terms.adoc @@ -0,0 +1,24 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-dns-key-terms_{context}"] += Key DNS terms + +CoreDNS:: +CoreDNS is the default DNS server for Kubernetes. It provides name resolution for Kubernetes services and pods. When a new service is created, CoreDNS automatically updates its records. + +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:: +These are the human-friendly names that we use to access websites and services, such as example.com. + +IP Addresses:: +These are numerical labels assigned to each device connected to a computer network that uses the Internet Protocol for communication. An example of an IP address is 192.0.2.1. + +DNS Servers:: +These are specialized servers that store DNS records, which 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:: +When you enter a domain name in your browser, a DNS query is sent to a DNS resolver, which then contacts a series of DNS servers to find the IP address associated with the domain name. Once the IP address is found, it is returned to your browser, which then connects to the web server using the IP address. \ No newline at end of file diff --git a/networking/nw-ne-openshift-example-pod-to-pod.adoc b/networking/nw-ne-openshift-example-pod-to-pod.adoc new file mode 100644 index 000000000000..520b0a8ff278 --- /dev/null +++ b/networking/nw-ne-openshift-example-pod-to-pod.adoc @@ -0,0 +1,29 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-example-pod-to-pod_{context}"] += Example: Configuring pod-to-pod communication + +Imagine you have a microservices-based application with multiple pods such as a front-end pod and a back-end pod. The front-end pod needs to communicate with the back-end 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, Kubernetes allows you to define Network Policies. These policies specify how pods can interact with each other based on labels and selectors. This helps in enforcing security and compliance requirements. + + [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/networking/nw-ne-openshift-example-securing-connections.adoc b/networking/nw-ne-openshift-example-securing-connections.adoc new file mode 100644 index 000000000000..a5de8c514199 --- /dev/null +++ b/networking/nw-ne-openshift-example-securing-connections.adoc @@ -0,0 +1,76 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +[id="nw-ne-openshift-securing-connections_{context}"] += Example: Exposing applications and securing connections +Imagine you have a web application running in your Kubernetes cluster that needs to be accessed by external users. + +1. Create a Service + +Expose the application as a service using a type that suits your needs (e.g., LoadBalancer for cloud environments). + + [source, yaml] + apiVersion: v1 + kind: Service + metadata: + name: my-web-app + spec: + type: LoadBalancer + selector: + app: my-web-app + ports: + - port: 80 + targetPort: 8080 + +2. Configure ingress + +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 + +3. Secure with TLS + +Configure TLS for your Ingress to ensure 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/networking/nw-ne-openshift-example-service-to-pod.adoc b/networking/nw-ne-openshift-example-service-to-pod.adoc new file mode 100644 index 000000000000..3e507b59befd --- /dev/null +++ b/networking/nw-ne-openshift-example-service-to-pod.adoc @@ -0,0 +1,45 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-example-service-to-pod_{context}"] += Example: Configuring service-to-pod communication + +Imagine you have a microservices-based application with two components: a front-end and a back-end. The front-end needs to communicate with the back-end to fetch data. + +1. Create a back-end service: + [source, yaml] + apiVersion: v1 + kind: Service + metadata: + name: back-end + spec: + selector: + app: back-end + ports: + - protocol: TCP + port: 80 + targetPort: 8080 + +2. Configure back-end pods: + [source, yaml] + apiVersion: v1 + kind: Pod + metadata: + name: back-end-pod + labels: + app: back-end + spec: + containers: + - name: back-end-container + image: my-back-end-image + ports: + - containerPort: 8080 + +3. Establish front-end communication: + +The front-end pods can now use the DNS name `back-end.default.svc.cluster.local` to communicate with the back-end service. + +The service ensures that the traffic is routed to one of the back-end pods. + +Service-to-pod communication abstracts the complexity of managing pod IPs and ensures reliable and efficient communication within the Kubernetes cluster. diff --git a/networking/nw-ne-openshift-how-pods-communicate.adoc b/networking/nw-ne-openshift-how-pods-communicate.adoc new file mode 100644 index 000000000000..bb6152bbe74f --- /dev/null +++ b/networking/nw-ne-openshift-how-pods-communicate.adoc @@ -0,0 +1,8 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-how-pods-communicate_{context}"] += How pods communicate + +Pods and services in Red Hat OpenShift Container Platform (and Kubernetes in general) communicate through a combination of IP addressing, DNS, and network policies. Pods communicate in two ways: pod-to-pod and service-to-pod. \ No newline at end of file diff --git a/networking/nw-ne-openshift-ingress.adoc b/networking/nw-ne-openshift-ingress.adoc new file mode 100644 index 000000000000..cac7311a7957 --- /dev/null +++ b/networking/nw-ne-openshift-ingress.adoc @@ -0,0 +1,20 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-ingress_{context}"] += What is ingress? + +Ingress is a Kubernetes resource that provides more advanced routing capabilities, including load balancing, SSL termination, and name-based virtual hosting. Here are some key points about Ingress: + +HTTP/HTTPS Routing:: +Ingress allows you to define rules for routing HTTP and HTTPS traffic to services within the cluster. + +Load Balancing:: +Ingress Controllers, such as NGINX or HAProxy, handle the actual routing and load balancing of traffic based on the defined rules. + +SSL Termination:: +Ingress Controllers can handle SSL termination, 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, making it suitable for complex web applications. \ No newline at end of file diff --git a/networking/nw-ne-openshift-nodes-clusters-clients.adoc b/networking/nw-ne-openshift-nodes-clusters-clients.adoc new file mode 100644 index 000000000000..486e460c9cae --- /dev/null +++ b/networking/nw-ne-openshift-nodes-clusters-clients.adoc @@ -0,0 +1,8 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-nodes-clusters-clients_{context}"] += Networking with nodes, clusters, and clients + +A Kubernetes, a node is a worker machine, which can be either a physical server or a virtual machine. A cluster is a set 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/networking/nw-ne-openshift-nodes.adoc b/networking/nw-ne-openshift-nodes.adoc new file mode 100644 index 000000000000..f2b2223f8225 --- /dev/null +++ b/networking/nw-ne-openshift-nodes.adoc @@ -0,0 +1,10 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-nodes_{context}"] += What is a node? + +Master nodes + +Worker nodes diff --git a/networking/nw-ne-openshift-pod-to-pod-communication.adoc b/networking/nw-ne-openshift-pod-to-pod-communication.adoc new file mode 100644 index 000000000000..7dad60d95d4d --- /dev/null +++ b/networking/nw-ne-openshift-pod-to-pod-communication.adoc @@ -0,0 +1,10 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-pod-to-pod-communication_{context}"] += Pod-to-pod communication + +Pod-to-pod communication in Kubernetes refers to 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 Kubernetes cluster is assigned a unique IP address. Pods can communicate directly with each other using their IP addresses. This 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. Kubernetes creates a flat network, meaning all pods can communicate with each other without Network Address Translation (NAT), regardless of where they are scheduled. This allows for seamless communication between pods across different nodes. diff --git a/networking/nw-ne-openshift-routes-ingress.adoc b/networking/nw-ne-openshift-routes-ingress.adoc new file mode 100644 index 000000000000..a5226a594fcf --- /dev/null +++ b/networking/nw-ne-openshift-routes-ingress.adoc @@ -0,0 +1,8 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-routes-ingress_{context}"] += Routes and Ingress + +In Red Hat OpenShift Container Platform, Routes and Ingress are both used to expose applications to external traffic, but they serve slightly different purposes and have different capabilities. \ No newline at end of file diff --git a/networking/nw-ne-openshift-service-to-pod-communication.adoc b/networking/nw-ne-openshift-service-to-pod-communication.adoc new file mode 100644 index 000000000000..7ee2b56c9d45 --- /dev/null +++ b/networking/nw-ne-openshift-service-to-pod-communication.adoc @@ -0,0 +1,65 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-service-to-pod-communication_{context}"] += Service-to-pod communication + +Service-to-pod communication ensures that services can reliably route traffic to the appropriate pods. Services are Kubernetes objects that define a logical set of pods and provide a stable endpoint (an IP address and a DNS name) for other components to interact with. Services abstract pod IPs, which can change, and provide a consistent way to access the application components. + +Key concepts of service-to-pod communication include: + +Endpoints:: +Endpoints define the network locations (IP addresses and ports) of the pods that are associated with a service. + +Selectors:: +Selectors use labels (key-value pairs) to define the criteria for selecting a set of objects, such as pods, 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:: +Kubernetes services are discoverable via DNS. When a service is created, it is assigned a DNS name, which other pods can use to communicate with it. + +* Service Types:: +Different service types (ClusterIP, NodePort, and LoadBalancer) dictate how services are exposed within or outside the cluster: + +** ClusterIP:: +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:: +NodePort exposes the service on each Node's IP at a static port, allowing external traffic to access the service. + +** LoadBalancer:: +LoadBalancer exposes the service externally using a cloud provider's load balancer. + +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. Kubernetes maintains these endpoints and ensures that the service routes traffic to the correct pods. + +In a Kubernetes environment, 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 (ClusterIP, NodePort, LoadBalancer), 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:: +Kubernetes assigns a DNS name to the service, which other pods can use to communicate with the service. For example, if the service is named `my-service` in the `default` namespace, its DNS name is `my-service.default.svc.cluster.local`. + +* Traffic Routing:: +When a pod sends a request to the service’s DNS name, Kubernetes resolves the name to the service’s ClusterIP. The service then routes the traffic to one of the pods that match its selector, using the endpoints. + +* 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. \ No newline at end of file diff --git a/networking/understanding-networking.adoc b/networking/understanding-networking.adoc index b1b505c15b7b..a51c3b92fb41 100644 --- a/networking/understanding-networking.adoc +++ b/networking/understanding-networking.adoc @@ -5,13 +5,7 @@ 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 - -* API resources, such as `Ingress` and `Route` - -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. +Network administrators strive to ensure efficient and secure communication within Kubernetes clusters. Red Hat OpenShift Container Platform, a powerful enterprise-grade container orchestration platform built on Kubernetes, demands a deep understanding of networking fundamentals. Key elements include how pods and services communicate, the role of IP addresses, and the use of DNS for service discovery. Mastering these fundamentals is crucial for effective administration in OpenShift. [NOTE] ==== @@ -22,7 +16,30 @@ This CIDR block is not reachable from the pod network. Pods that need access to If you allow a pod host network access, you grant the pod privileged access to the underlying network infrastructure. ==== +include::modules/nw-ne-openshift-kubernetes-openshift.adoc[leveloffset=+1] +include::modules/nw-ne-openshift-improves.adoc[leveloffset=+2] +include::modules/nw-ne-openshift-nodes-clusters-clients.adoc[leveloffset=+1] +include::modules/nw-ne-openshift-nodes.adoc[leveloffset=+2] +include::modules/nw-ne-openshift-clusters.adoc[leveloffset=+2] +include::modules/nw-ne-openshift-clients.adoc[leveloffset=+2] +include::modules/nw-ne-openshift-concepts-components.adoc[leveloffset=+1] +include::modules/nw-ne-openshift-how-pods-communicate.adoc[leveloffset=+1] +include::modules/nw-ne-openshift-pod-to-pod-communication.adoc[leveloffset=+2] +include::modules/nw-ne-openshift-example-pod-to-pod.adoc[leveloffset=+3] +include::modules/nw-ne-openshift-service-to-pod-communication.adoc[leveloffset=+2] +include::modules/nw-ne-openshift-example-service-to-pod.adoc[leveloffset=+3] include::modules/nw-ne-openshift-dns.adoc[leveloffset=+1] -include::modules/nw-ne-openshift-ingress.adoc[leveloffset=+1] +include::modules/nw-ne-openshift-dns-key-terms.adoc[leveloffset=+2] +include::modules/nw-ne-openshift-example-dns.adoc[leveloffset=+2] +include::modules/nw-ne-openshift-network-policies.adoc[leveloffset=+1] +include::modules/nw-ne-openshift-routes-ingress.adoc[leveloffset=+1] +include::modules/nw-ne-openshift-routes.adoc[leveloffset=+2] +include::modules/nw-ne-openshift-ingress.adoc[leveloffset=+2] include::modules/nw-ne-comparing-ingress-route.adoc[leveloffset=+2] +include::modules/nw-ne-example-ingress-route.adoc[leveloffset=+2] +include::modules/nw-ne-openshift-security-traffic.adoc[leveloffset=+1] +include::modules/nw-ne-openshift-exposing-applications.adoc[leveloffset=+2] +include::modules/nw-ne-openshift-securing-connections.adoc[leveloffset=+2] +include::modules/nw-ne-openshift-example-securing-connections.adoc[leveloffset=+2] +include::modules/nw-ne-openshift-echoosing-service-types-and-applications.adoc[leveloffset=+2] include::modules/nw-networking-glossary-terms.adoc[leveloffset=+1] diff --git a/networking/w-ne-openshift-echoosing-service-types-and-applications.adoc[ b/networking/w-ne-openshift-echoosing-service-types-and-applications.adoc[ new file mode 100644 index 000000000000..2c023154ba33 --- /dev/null +++ b/networking/w-ne-openshift-echoosing-service-types-and-applications.adoc[ @@ -0,0 +1,28 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +[id="nw-ne-openshift-securing-connections_{context}"] += Choosing between service types and API resources +There are distinct benefits to using different service types and API resources for exposing applications and securing network connections in Kubernetes. 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. + +Service Types +* ClusterIP: +** Benefits: Internal-only exposure, easy to set up, and provides a stable internal IP address for accessing services within the cluster. +** Use Case: Suitable for communication between services within the cluster. +* NodePort: +** Benefits: Exposes the service on each node's IP at a static port, allowing external access. It's straightforward to set up and useful for development and testing. +** Use Case: Good for simple external access without the need for a cloud provider's load balancer. +* LoadBalancer: +** Benefits: Automatically provisions an external load balancer (in cloud environments), distributing traffic across multiple nodes and providing high availability. +** Use Case: Ideal for production environments where reliable, high-availability access is needed. + +API Resources +* Ingress: +** Benefits: Provides fine-grained control over routing HTTP and HTTPS traffic, including support for load balancing, SSL termination, and name-based virtual hosting. It's more flexible than services alone and supports multiple domains and paths. +** Use Case: Suitable for complex routing requirements, like web applications that need to route different paths or domains to specific services. +* Route (specific to OpenShift): +** Benefits: Similar to Ingress but provides additional features like TLS re-encryption and passthrough. It simplifies the process of exposing services externally. +** Use Case: Best for scenarios where you need the advanced features provided by OpenShift Routes, such as integrated certificate management. + +If you need a straightforward way to expose a service to external traffic, `NodePort` or `LoadBalancer` might be the best choice. For more complex scenarios involving multiple services, paths, or domains, `Ingress` or `Routes` offer greater flexibility and control. `LoadBalancer` services provide built-in load balancing and are well-suited for production environments that require robust traffic management. \ No newline at end of file diff --git a/networking/w-ne-openshift-network-policies.adoc b/networking/w-ne-openshift-network-policies.adoc new file mode 100644 index 000000000000..b4c566a2a5dc --- /dev/null +++ b/networking/w-ne-openshift-network-policies.adoc @@ -0,0 +1,8 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-network-policies_{context}"] += Network Policies + +Network policies define rules for how pods are allowed to communicate with each other and with other network endpoints. This helps secure the cluster by controlling traffic flow. These policies are implemented at the network level, ensuring that only allowed traffic can flow between pods. By leveraging these mechanisms, OpenShift ensures reliable and secure communication within the cluster, enabling efficient operation of applications and services. \ No newline at end of file diff --git a/networking/w-ne-openshift-routes.adoc b/networking/w-ne-openshift-routes.adoc new file mode 100644 index 000000000000..d354f9b5a68c --- /dev/null +++ b/networking/w-ne-openshift-routes.adoc @@ -0,0 +1,17 @@ +// Module included in the following assemblies: +// * understanding-networking.adoc + + +[id="nw-ne-openshift-routes_{context}"] += What are routes? + +Routes are OpenShift-specific resources that expose a service at a host name, such as `www.example.com`, so that external clients can reach it by name. Here are some key points about Routes: +* Host Name Mapping:: +Routes map a host name to a service, allowing external clients to access the service using the host name. + +* Load Balancing:: +OpenShift routers provide load balancing for the traffic directed to the service. + +*DNS Resolution:: +The host name used in a route is resolved to the IP address of the router, which then forwards the traffic to the appropriate service. +Security: Routes can be secured using TLS/SSL to encrypt the traffic between the client and the service. \ No newline at end of file diff --git a/networking/w-ne-openshift-securing-connections.adoc b/networking/w-ne-openshift-securing-connections.adoc new file mode 100644 index 000000000000..723c4e711bdf --- /dev/null +++ b/networking/w-ne-openshift-securing-connections.adoc @@ -0,0 +1,11 @@ +// Module included in the following assemblies: +// +// * networking/understanding-networking.adoc + +[id="nw-ne-openshift-securing-connections_{context}"] += Securing connections +Ingress Controllers often handle SSL termination, which decrypts incoming SSL/TLS traffic before passing it to the backend services. This offloads the encryption/decryption process from the application pods. Use TLS certificates to encrypt traffic between clients and your Kubernetes services. You can manage certificates with tools like cert-manager to automate the issuance and renewal of certificates. + +Network policies allow you to 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 policies are implemented at the network plugin level, ensuring that only allowed traffic can flow between pods. + +Kubernetes uses Role-Based Access Control (RBAC) to manage permissions and control who can access and perform actions on resources within the cluster. Service accounts provide identity for pods that access the Kubernetes API, allowing for granular control over what each pod can do.