PingFederate Cluster Across Multiple Kubernetes Clusters ¶
This section will discuss deploying a single PingFederate cluster that spans across multiple Kubernetes clusters.
Having PingFederate in multiple regions doesn't always mean that spanning a single PingFederate cluster across multiple Kubernetes clusters is necessary or optimal. This scenario makes sense when you have:
- Traffic that can cross between regions at any time. (us-west and us-east, and users may be routed to either)
- Configuration that needs to be the same in multiple regions and no reliable automation to ensure that
If all configuration changes are delivered via pipeline, and traffic wouldn't cross-regions, having separate PingFederate clusters can work.
The set of pre-requisites required for AWS Kubernetes multi-clustering to be successful is found Here
This section will focus on the optimal use of PingFederate features. Adaptive clustering and dynamic discovery of engines, to enable engine auto-scaling. Static engine lists, which may be used to extend traditional, on-premise PingFederate clusters is out of scope here.
Discovery Options ¶
There are two main dynamic discovery options:
DNS_PING (PF > 10.2) ¶
S3 (PF < 10.1.x) ¶
In either scenario, some prerequisites must be achieved
- Two Kubernetes clusters created with the following requirements:
- VPC IPs selected from RFC1918 CIDR blocks
- The two cluster VPCs peered together
- All appropriate routing tables modified in both clusters to send cross cluster traffic to the VPC peer connection
- Security groups on both clusters to allow traffic for ports 7600 and 7700 to pass
- Successfully verified that a pod in one cluster can connect to a pod in the second cluster on ports 7600 and 7700 (directly to the pods back-end IP, not an exposed service)
See example "AWS configuration" instructions Here
In either scenario, some pieces will remain the same. Yaml files that include:
pingfederate-adminrepresents the admin console.
pingfederaterepresents the engine(s)
Two Configmaps. One for each deployment.
- These configmaps are nearly identical, but define the operational mode separately.
- tcp.xml.subst (using S3_PING, NATIVE_S3_PING, or DNS_PING)
- One for each of the two deployments (9999 and 9031).
For items specific to using S3 or DNS_PING follow the respective docs.