<p>Is the service affected when all masters are stopped?</p>
<p>OpenShift 4</p>
<ul>
<li>Infra Node 3</li>
<li>Master Node 3</li>
<li>Worker Node 3</li>
</ul>
<p>※ Router pods are in the Infra Node.</p>
<p>The work request is as follows.</p>
<ul>
<li><p>frontend(DC) -&gt; api(DC)</p>
<ul>
<li>Internet -&gt; Infra Node(Router) -&gt; SDN -&gt; Worker Node</li>
</ul>
</li>
<li><p>www.frontend.test.com(443) - Route</p>
<ul>
<li>api REST Call (HttpUrlConnection or HttpClient 4.x, api:8080 or api.test1.svc.cluster.local:8080)</li>
</ul>
</li>
</ul>
<p>When all master nodes are stopped, the front-end always succeeds. However, the API call fails intermittently.</p>
<p>Slow Hang or UnknownHostException Message.</p>
<p>It is ok if there is at least one master node.</p>
<pre><code>GET http://api.test1.svc.cluster.local:8080/ : java.net.UnknownHostException: api.test1.svc.cluster.local
or
GET http://api:8080/ : java.net.UnknownHostException: api
</code></pre>
<p>When slow Message.</p>
<pre><code>&quot;http-nio-8080-exec-2&quot; #33 daemon prio=5 os_prio=0 cpu=6.89ms elapsed=452.97s tid=0x00007fdb88f15800 nid=0xb3 runnable  [0x00007fdb34fc2000]
   java.lang.Thread.State: RUNNABLE
    at java.net.Inet6AddressImpl.lookupAllHostAddr(java.base@11.0.14.1/Native Method)
    at java.net.InetAddress$PlatformNameService.lookupAllHostAddr(java.base@11.0.14.1/InetAddress.java:929)
    at java.net.InetAddress.getAddressesFromNameService(java.base@11.0.14.1/InetAddress.java:1519)
    at java.net.InetAddress$NameServiceAddresses.get(java.base@11.0.14.1/InetAddress.java:848)
    - locked &lt;0x0000000782ff5be0&gt; (a java.net.InetAddress$NameServiceAddresses)
    at java.net.InetAddress.getAllByName0(java.base@11.0.14.1/InetAddress.java:1509)
    at java.net.InetAddress.getAllByName(java.base@11.0.14.1/InetAddress.java:1368)
    at java.net.InetAddress.getAllByName(java.base@11.0.14.1/InetAddress.java:1302)
    at org.apache.http.impl.conn.SystemDefaultDnsResolver.resolve(SystemDefaultDnsResolver.java:45)
    at
</code></pre>
<p>thank you.</p>

<p>Yes, it is affected. Here's what's happening when you stop all the master nodes.</p>
<ol>
<li>The incoming traffic to the DC egress is being forwarded to the <code>Ingress</code> component of your Kubernetes/Openshift cluster. (Your <code>front-end</code>).</li>
<li>This is succeeding because the name resolution of <code>Ingress</code> is responsibility of your infrastructure, since <code>Ingress</code> interfacing is external to <code>Openshift</code>.</li>
<li>Once the traffic reaches the <code>Ingress</code> (<code>front-end</code> successfully reached), it needs to be forwarded now, to the <code>backend</code> service depending on the path in the request.</li>
<li>This cannot be done, since <code>Ingress</code> objects, by design, dynamically resolve <code>Service</code> DNS names into IP addresses in order to reach them inside the cluster. This is done, so that when services go down and come up and the IP address changes, <code>Ingress</code> doesn't need to be reconfigured since the DNS name stays consistent.</li>
<li>Here, the resolution fails, because your DNS system (probably <code>core-dns</code>) is supposed to be running on the <code>master</code> nodes, which it isn't, and this leads to <code>unresolved name</code> behavior.</li>
<li>Sometimes, it is possible that the <code>Ingress</code> has a local resolver cache entry which is valid and the request makes it to the <code>Service</code> and it gets a response. But this is highly unstable, since it is possible that this cache has been set with a auto-clean timeout and those entries are automatically purged after a while.</li>
</ol>
