Difference between revisions of "PrivateEdition/Current/PEGuide/ConfigNetwork"

From Genesys Documentation
Jump to: navigation, search
(Published)
 
 
(6 intermediate revisions by 4 users not shown)
Line 2: Line 2:
 
|Standalone=No
 
|Standalone=No
 
|DisplayName=Network settings
 
|DisplayName=Network settings
−
|Context=TBD
+
|Context=Describes the network settings required for Kubernetes clusters in Genesys Multicloud CX private edition. For more information about networking outside Kubernetes clusters, see {{Link-SomewhereInThisVersion|manual=PEGuide|topic=NetworkOverview}}.
 
|ComingSoon=No
 
|ComingSoon=No
 
|Section={{Section
 
|Section={{Section
−
|sectionHeading=Setting up Container Networking Interface
+
|sectionHeading=Enabling Container Networking Interface
−
|alignment=Vertical
 
−
|structuredtext=When you create the OpenShift cluster(s) to deploy the Genesys Engage services, configure the cluster to support the Container Network Interface (CNI) or its equivalent. In a Kubernetes environment, CNI allows direct network routing to pods in a node via private IPs. Besides routing, CNI also removes the allocated resources to a container when it is deleted. When you use a CNI, you don't have to rely on kubenet and/or Calico for Pod routing.
 
−
 
 
−
Genesys Voice related connections from external systems/services, for example, Session Border Controller (SBC) requires CNI.
 
−
 
 
−
//Are we recommending any CNI provider?//
 
−
 
 
−
Any special requirements for the CNI deployment need to be documented, if applicable. //Platform team must provide this detail.//
 
−
 
 
−
<br />
 
−
|Status=No
 
−
}}{{Section
 
−
|sectionHeading=Subnet sizing
 
 
|alignment=Vertical
 
|alignment=Vertical
 +
|structuredtext=In your Kubernetes cluster, enable Container Networking Interface (CNI) or its equivalent to establish communication between pods in the cluster. <br />
 
|Status=No
 
|Status=No
 
}}{{Section
 
}}{{Section
 
|sectionHeading=Configuring Ingress Controller
 
|sectionHeading=Configuring Ingress Controller
 
|alignment=Vertical
 
|alignment=Vertical
−
|structuredtext=An ingress controller is required. This used for all HTTP and Websocket ingress traffic. The following are specific capabilities that the ingress controller implementation should have:
+
|structuredtext=You must set up an ingress controller to manage all the HTTP and WebSocket ingress traffic, and to support Cluster IP. The ingress controller you choose must have the following properties:
−
 
 
−
There will be a Helm override attributes to allow a customer to set this for each service.
 
−
 
 
−
Describe the following Ingress properties
 
  
 
*Cookies usage
 
*Cookies usage
−
*Header requirements - client IP & redirect,  passthrough
+
*Header requirements - client IP and redirect, and passthrough
 
*Session stickiness
 
*Session stickiness
−
*Whitelisting - optional
+
*Allowlisting (optional)
−
*TLS for ingress - optional (should be able to enable or disable TLS on the connection).
+
*TLS for ingress (optional) - ability to enable or disable TLS on the connection.
  
−
<br />
+
You can define these parameters in the '''values.yaml''' file for applicable services. For more information, see the related service-level guides.
 
|Status=No
 
|Status=No
 
}}{{Section
 
}}{{Section
−
|sectionHeading=Network Policy
+
|sectionHeading=DNS and Service Mesh
 
|alignment=Vertical
 
|alignment=Vertical
−
|structuredtext=Genesys does not supply or enforce any Network Policy. Customers are encouraged to create their own network policy for specific services that require a network policy and configure them in the Helm v3 charts.  
+
|structuredtext====DNS===
 +
Genesys recommends having a CoreDNS within the Kubernetes clusters along with Node LocalDNS for performance.  
  
−
For more details, refer the respective service-level documentation of the service.  
+
===Service Mesh===
−
 
+
Genesys Multicloud CX services require Consul Service Mesh that dynamically routes traffic to the right available service instance. Deploy Consul Service Mesh within the cluster where Genesys Multicloud CX services are deployed.
−
<br />
 
 
|Status=No
 
|Status=No
 
}}{{Section
 
}}{{Section
−
|sectionHeading=Connections external to Kubernetes clusters
+
|sectionHeading=Network Policy
 
|alignment=Vertical
 
|alignment=Vertical
−
|structuredtext=Requirement:
+
|structuredtext=Genesys does not supply or enforce any network policy. You can create your own network policy for services that require a network policy and configure them in the Helm v3 charts.
  
−
Any external connection from the Kubernetes cluster to other systems need to be documented.  This will include connecting to Genesys Cloud for Hybrid services (such as AI, WEM) as well as "Mixed" Environments where some components are still deployed as VMs.  Need to specify the port(s) and protocols.  
+
For more information about network policy requirements, see the related {{Link-AnywhereElse|product=PrivateEdition|version=Current|manual=PEGuide|topic=GEServices|display text=service-level guides}}.
  
−
Note that this will include 3rd party services. Customers may optionally deploy these services outside of the Kubernetes cluster especially for production environments. These connections must be secured.
 
−
 
−
Note that Mixed Environments will mainly be for transition periods when customers are migrating from a classic premise environment to Private Edition.
 
 
|Status=No
 
|Status=No
−
}}{{Section
+
}}
−
|sectionHeading=DNS and Service Mesh
+
<!--
 +
{{Section
 +
|sectionHeading=OpenShift settings
 
|alignment=Vertical
 
|alignment=Vertical
−
|structuredtext====DNS===
+
|structuredtext={{Notices|Notice=PEComingSoon}}
−
CoreDNS is recommended with in the Kubernetes clusters along with Node LocalDNS for performance.
 
−
 
 
−
===Service Mesh===
 
−
Engage Services are dependent on a Service Mesh in particular Consul to dynamically route traffic to the right available service instance. In the future it might be used to enable TLS between services as well as richer network access control between services.
 
 
|Status=No
 
|Status=No
 
}}
 
}}
 +
-->
 
}}
 
}}

Latest revision as of 04:01, March 31, 2023

This topic is part of the manual Setting up Genesys Multicloud CX Private Edition for version Current of Genesys Multicloud CX Private Edition.

Describes the network settings required for Kubernetes clusters in Genesys Multicloud CX private edition. For more information about networking outside Kubernetes clusters, see Networking overview.

Enabling Container Networking Interface

In your Kubernetes cluster, enable Container Networking Interface (CNI) or its equivalent to establish communication between pods in the cluster.

Configuring Ingress Controller

You must set up an ingress controller to manage all the HTTP and WebSocket ingress traffic, and to support Cluster IP. The ingress controller you choose must have the following properties:

  • Cookies usage
  • Header requirements - client IP and redirect, and passthrough
  • Session stickiness
  • Allowlisting (optional)
  • TLS for ingress (optional) - ability to enable or disable TLS on the connection.

You can define these parameters in the values.yaml file for applicable services. For more information, see the related service-level guides.

DNS and Service Mesh

DNS

Genesys recommends having a CoreDNS within the Kubernetes clusters along with Node LocalDNS for performance.

Service Mesh

Genesys Multicloud CX services require Consul Service Mesh that dynamically routes traffic to the right available service instance. Deploy Consul Service Mesh within the cluster where Genesys Multicloud CX services are deployed.

Network Policy

Genesys does not supply or enforce any network policy. You can create your own network policy for services that require a network policy and configure them in the Helm v3 charts.

For more information about network policy requirements, see the related service-level guides.

Retrieved from "https://all.docs.genesys.com/PrivateEdition/Current/PEGuide/ConfigNetwork (2025-06-20 22:06:38)"
Comments or questions about this documentation? Contact us for support!