<p>I have two questions regarding how to set up Ignite in Kubernetes.</p>
<ol>
<li>Do all nodes need to be in the same namespace? E.G. If I have a thick client and a server node, do both need to be in the same name space to form a cluster?</li>
</ol>
<p>From my research I think the answer is yes they need to be in the same namespace but I have not found any definitive documentation</p>
<ol start="2">
<li>Do both the client and server nodes need to be running the TcpDiscoveryKubernetesIpFinder or can nodes use a mix of the TcpDiscoveryKubernetesIpFinder and the static IPfinder?</li>
</ol>
<p>From my resaerch I am fairly confident that all nodes must be running with the TcpDiscoveryKubernetesIpFinder but again I have not found any definitive documentation.</p>

 RichardFeynman
<p>As far as I know, there are no restrictions from Ignite's side. But one of the main issues that need to be addressed is - how to configure discovery and communication in a dynamic K8s world and additional network virtualization. Technically, it's possible to use the default TcpDiscoveryVmIpFinder with a predefined set of IPs, but you need to keep track of the real pods IPs and change them accordingly on restarts. To address this issue it's recommended to use TcpDiscoveryKubernetesIpFinder that uses a configured K8s Service controller to resolve IPs instead.</p>
<p>Therefore answering your questions:</p>
<ol>
<li><p>I can't see why different namespaces won't work. At least if RBAC is configured properly and pods in both namespaces can access the service and each other.</p>
</li>
<li><p>No, you can use any IpFinder, but it's way simpler and recommended to use TcpDiscoveryKubernetesIpFinder as mentioned above. Note, if you need to access a cluster from outside of K8s you might need to have an additional configuration: <a href="https://ignite.apache.org/docs/latest/clustering/running-client-nodes-behind-nat" rel="nofollow noreferrer">https://ignite.apache.org/docs/latest/clustering/running-client-nodes-behind-nat</a></p>
</li>
</ol>
