|
|
| Line 2: |
Line 2: |
| | |Standalone=No | | |Standalone=No |
| | |DisplayName=Network settings | | |DisplayName=Network settings |
| − | |Context=TBD | + | |Context=Describes the network settings required for Genesys Engage cloud private edition. |
| | |ComingSoon=No | | |ComingSoon=No |
| | |Section={{Section | | |Section={{Section |
| − | |sectionHeading=Setting up Container Networking Interface
| |
| | |alignment=Vertical | | |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. | + | |structuredtext={{Notices|Notice=PEComingSoon}} |
| − | | |
| − | 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
| |
| − | |Status=No
| |
| − | }}{{Section
| |
| − | |sectionHeading=Configuring Ingress Controller
| |
| − | |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:
| |
| − | | |
| − | There will be a Helm override attributes to allow a customer to set this for each service.
| |
| − | | |
| − | Describe the following Ingress properties
| |
| − | | |
| − | *Cookies usage
| |
| − | *Header requirements - client IP & redirect, passthrough
| |
| − | *Session stickiness
| |
| − | *Whitelisting - optional
| |
| − | *TLS for ingress - optional (should be able to enable or disable TLS on the connection).
| |
| − | | |
| − | <br />
| |
| − | |Status=No
| |
| − | }}{{Section
| |
| − | |sectionHeading=Network Policy
| |
| − | |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.
| |
| − | | |
| − | For more details, refer the respective service-level documentation of the service.
| |
| − | | |
| − | <br />
| |
| − | |Status=No
| |
| − | }}{{Section
| |
| − | |sectionHeading=Connections external to Kubernetes clusters
| |
| − | |alignment=Vertical
| |
| − | |structuredtext=Requirement:
| |
| − | | |
| − | 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.
| |
| − | | |
| − | 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 | |
| − | }}{{Section | |
| − | |sectionHeading=DNS and Service Mesh
| |
| − | |alignment=Vertical
| |
| − | |structuredtext====DNS===
| |
| − | 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 |
| | }} | | }} |
| | }} | | }} |
