You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the Kubernetes IP Finder requires configuring a Kubernetes Service name, and the module queriesthis object in the Kubernetes API to enumerate Ignite cluster node IP addresses. Kubernetes will list only those nodes which have already successfully become ready to receive query traffic. OrderedReady pod management policy in StatefulSet is the default, and works well, but enforces the slowest cluster startup as each node must present itself as ready prior to the next node's pod startup. Parallel pod management policy does not work because all nodes perform and complete the discovery phase before any nodes have presented themselves as ready for the Kubernetes Service.
Consequences:
Large clusters (many nodes) and clusters with many cache groups may take tens of minutes (or more) to start up. Kubernetes hosted Ignite clusters should behave more like non-Kubernetes hosted clusters with Parallel pod management policy, enabling independent nodes to perform most startup work concurrently. This proposal would enable arbitrarily large Kubernetes clusters to start up in similar time to small clusters.
Proposal:
Continue to use nodes' IPs enumerated by the Service ClusterIPs or Endpoints
Inspect the Service spec.Selector
List pods constrained by the Service Selector
Iterate through listed pods, and query each Pod's status to collect PodIPs
Merge collected PodIPs to the list of IPs from the Service
Problem:
Currently, the Kubernetes IP Finder requires configuring a Kubernetes Service name, and the module queries this object in the Kubernetes API to enumerate Ignite cluster node IP addresses. Kubernetes will list only those nodes which have already successfully become ready to receive query traffic. OrderedReady pod management policy in StatefulSet is the default, and works well, but enforces the slowest cluster startup as each node must present itself as ready prior to the next node's pod startup. Parallel pod management policy does not work because all nodes perform and complete the discovery phase before any nodes have presented themselves as ready for the Kubernetes Service.
Consequences:
Large clusters (many nodes) and clusters with many cache groups may take tens of minutes (or more) to start up. Kubernetes hosted Ignite clusters should behave more like non-Kubernetes hosted clusters with Parallel pod management policy, enabling independent nodes to perform most startup work concurrently. This proposal would enable arbitrarily large Kubernetes clusters to start up in similar time to small clusters.
Proposal:
References:
ignite/modules/kubernetes/src/main/java/org/apache/ignite/internal/kubernetes/connection/KubernetesServiceAddressResolver.java
Line 95 in 27ed13a
The text was updated successfully, but these errors were encountered: