<p>I am having spring boot app where in <code>application.property</code> we are specifying below properties. kafka is installed on remote machine with self-signed certificate (outside the kubernete cluster).</p>

<pre><code>camel.component.kafka.configuration.brokers=kafka-worker1.abc.com:9092,kafka-worker2.abc.com:9092,kafka-worker3.abc.com:9092
</code></pre>

<p>at startup of application it will try to look for kafka broker.
now if i add hostaliases to deployment it will work fine like below</p>

<pre><code>  hostAliases:
  - ip: 10.76.XX.XX
    hostnames:
    - kafka-worker1.abc.com
  - ip: 10.76.XX.XX
    hostnames:
    - kafka-worker2.abc.com
  - ip: 10.76.XX.XX
    hostnames:
    - kafka-worker3.abc.com
</code></pre>

<p>it will work fine but i dont want this as its not good practice to have hostaliases , we may need to restart the pod if IP changes.
we want that hostname resolution to be happen on coredns, or to resolve without adding ip to host file of pod.</p>

<p>how to achieve this.
followed this <a href="https://stackoverflow.com/questions/58205141/cannot-connecto-to-external-database-from-inside-kubernetes-pod">Cannot connecto to external database from inside kubernetes pod</a> service endpoint like below created for kafka-worker2 &amp; kafka-worker3 with respective IP</p>

<pre><code>    kind: Service
    apiVersion: v1
    metadata:
     name: kafka-worker1
    spec:
     clusterIP: None
     ports:
     - port: 9092
       targetPort: 9092
     externalIPs:
       - 10.76.XX.XX
</code></pre>

<p>and added this in property file </p>

<pre><code>camel.component.kafka.configuration.brokers=kafka-worker1.default:9092,kafka-worker2.default:9092,kafka-worker3.default:9092
</code></pre>

<p>still getting same WARN</p>

<pre><code>2020-05-13T11:57:12.004+0000 Etc/UTC docker-desktop WARN  [main] org.apache.kafka.clients.ClientUtils(:74) - Couldn't resolve server hal18-coworker2.default:9092 from bootstrap.servers as DNS resolution failed for kafka-worker1.default
2020-05-13T11:57:12.318+0000 Etc/UTC docker-desktop WARN  [main] org.apache.kafka.clients.ClientUtils(:74) - Couldn't resolve server hal18-coworker1.default:9092 from bootstrap.servers as DNS resolution failed for kafka-worker2.default
2020-05-13T11:57:12.567+0000 Etc/UTC docker-desktop WARN  [main] org.apache.kafka.clients.ClientUtils(:74) - Couldn't resolve server hal18-coworker3.default:9092 from bootstrap.servers as DNS resolution failed for kafka-worker3.default
</code></pre>

<p><strong>Update Section</strong></p>

<p>Used "Services without selectors" as below still getting same error</p>

<pre><code>2020-05-18T14:47:10.865+0000 Etc/UTC docker-desktop WARN  [Camel (SMP-Proactive-Camel) thread #1 - KafkaConsumer[recommendations-topic]] org.apache.kafka.clients.NetworkClient(:750) - [Consumer clientId=consumer-hal-tr69-streaming-1, groupId=hal-tr69-streaming] Connection to node -1 (kafka-worker.default.svc.cluster.local/10.100.153.152:9092) could not be established. Broker may not be available.
2020-05-18T14:47:12.271+0000 Etc/UTC docker-desktop WARN  [Camel (SMP-Proactive-Camel) thread #1 - KafkaConsumer[recommendations-topic]] org.apache.kafka.clients.NetworkClient(:750) - [Consumer clientId=consumer-hal-tr69-streaming-1, groupId=hal-tr69-streaming] Connection to node -1 (kafka-worker.default.svc.cluster.local/10.100.153.152:9092) could not be established. Broker may not be available.
2020-05-18T14:47:14.191+0000 Etc/UTC docker-desktop WARN  [Camel (SMP-Proactive-Camel) thread #1 - KafkaConsumer[recommendations-topic]] org.apache.kafka.clients.NetworkClient(:750) - [Consumer clientId=consumer-hal-tr69-streaming-1, groupId=hal-tr69-streaming] Connection to node -1 (kafka-worker.default.svc.cluster.local/10.100.153.152:9092) could not be established. Broker may not be available.
</code></pre>

<p>Services &amp; Endpoint yaml</p>

<pre><code>apiVersion: v1
kind: Service
metadata:
 name: kafka-worker
spec:
 type: ClusterIP
 ports:
 - port: 9092
   targetPort: 9092
---
apiVersion: v1
kind: Endpoints
metadata:
 name: kafka-worker
subsets:
 - addresses:
   - ip: 10.76.XX.XX # kafka worker 1
   - ip: 10.76.XX.XX # kafka worker 2
   - ip: 10.76.XX.XX # kafka worker 3
   ports:
   - port: 9092
     name: kafka-worker

kubectl.exe get svc,ep
NAME                                         TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
service/ingress-nginx-controller             LoadBalancer   10.99.101.185    localhost     80:31247/TCP,443:31340/TCP   11d
service/ingress-nginx-controller-admission   ClusterIP      10.103.212.117   &lt;none&gt;        443/TCP                      11d
service/kafka-worker                         ClusterIP      10.100.153.152   &lt;none&gt;        9092/TCP                     97s
service/kubernetes                           ClusterIP      10.96.0.1        &lt;none&gt;        443/TCP                      17d

NAME                                           ENDPOINTS                                            AGE
endpoints/ingress-nginx-controller             10.1.0.XX:80,10.1.0.XX:443                           11d
endpoints/ingress-nginx-controller-admission   10.1.0.xx:8443                                       11d
endpoints/kafka-worker                         10.76.xx.xx:9092,10.76.xx.xx:9092,10.76.xx.xx:9092   97s
endpoints/kubernetes                           192.168.XX.XX:6443                                   17d
</code></pre>

<p>Thank you for the question and showing your effort to solve the problem.</p>

<p>You are right about adding <code>hostAliases</code> to be not a good practice because on an event your kafka hosts IP changes then you will have to apply the new IP to the deployment and it will trigger a pod reload.</p>

<p>I am not sure how <a href="https://kubernetes.io/docs/concepts/services-networking/service/#external-ips" rel="noreferrer">externalIPs</a> fits over here as a solution since:</p>

<blockquote>
  <p>Traffic that ingresses into the cluster with the external IP (as destination IP), on the Service port, will be routed to one of the Service endpoints. externalIPs are not managed by Kubernetes and are the responsibility of the cluster administrator.</p>
</blockquote>

<p>But for a moment if I take it for granted that externalIP solution is working, even then the way you are accessing your service is not correct!</p>

<p>DNS resolution is failing because your domain name is wrong <code>camel.component.kafka.configuration.brokers=kafka-worker1.default:9092</code> changing it to this <code>camel.component.kafka.configuration.brokers=kafka-worker1.default.svc.cluster.local:9092</code> may fix it. Note: if your k8s cluster has a different domain than the default then replace <code>cluster.local</code> with your k8s cluster domain.</p>

<p>Check DNS debugging <a href="https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/#check-the-local-dns-configuration-first" rel="noreferrer">REF</a></p>

<p><strong>There are two solutions which I can think of:</strong></p>

<p>First <a href="https://kubernetes.io/docs/concepts/services-networking/service/#services-without-selectors" rel="noreferrer">Service without selectors</a> and manual endpoint creation: </p>

<p><em>(example code) the name of the endpoint is used to attach to the service. therefore use same names for both service and endpoint which is <code>kafka-worker</code></em></p>

<p></p>

<pre><code>apiVersion: v1
kind: Service
metadata:
 name: kafka-worker
spec:
 type: ClusterIP
 ports:
 - port: 9092
   targetPort: 9092
---
apiVersion: v1
kind: Endpoints
metadata:
 name: kafka-worker
subsets:
 - addresses:
   - ip: 10.76.XX.XX # kafka worker 1
   - ip: 10.76.XX.XX # kafka worker 2
   - ip: 10.76.XX.XX # kafka worker 3
   ports:
   - port: 9092
     name: kafka-worker
</code></pre>

<p>Way to access this would be <code>camel.component.kafka.configuration.brokers=kafka-worker.default.svc.cluster.local:9092</code></p>

<p>Note: 
 - You can add more information to you endpoint ip like nodeName,
   hostName checkout this <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#endpointaddress-v1-core" rel="noreferrer">api ref</a>
 - advantage of this approach is k8s will load balance for you to the kafka workers</p>

<p>Second <a href="https://kubernetes.io/docs/concepts/services-networking/service/#externalname" rel="noreferrer">ExternalName</a>:</p>

<p>For this approach you will need to have single Domain name defined already, how to do that is out of scope of this answer but for example <code>kafka-worker.abc.com</code>  is your domain name, now it is your responsibility to attach all of your 3 kafka worker node IPs in a (maybe) roundrobin fashion to your DNS server. <em>Note: this kind load balancing (via DNS) is not always preferred because there is no health check performed by the DNS server to make sure which nodes are alive and which are dead</em>.</p>

<p>This approach is not guaranteed and may need addition tweaks depending on your systems networking to resolve domain names. which is to say the node where you have your coredns/kube-dns running that node should be able to resolved <code>kafka-worker.abc.com</code> otherwise when k8s return the CNAME you application will fail to resolve it!</p>

<p>Here is an example:</p>

<pre><code>kind: Service
metadata:
  name: kafka-worker
spec:
  type: ExternalName
  externalName: kafka-worker.abc.com
</code></pre>

<p><strong>Update</strong>:
Following your update in Question. 
Looking at the first error it seems you have created 3 services which generates 3 DNS </p>

<pre><code>kafka-worker3.default.svc.cluster.local
kafka-worker2.default.svc.cluster.local
kafka-worker1.default.svc.cluster.local
</code></pre>

<p>I suggest, if you could please check my example code! you DO NOT need to create 3 services,  just one service which is attach to a endpoint which has 3 IPs of your 3 brokers.</p>

<p>For your second error:
<code>hostname</code> is not domain name, hostname is typically the name give to the machine (please check the <a href="https://superuser.com/questions/59093/difference-between-host-name-and-domain-name">difference</a>). just for the sake of simplicity I would suggest to use only IP in endpoint object.</p>
