$ kubectl -n letmetry get service mysql -o yaml
apiVersion: v1
kind: Service
metadata:
creationTimestamp: 2018-11-19T16:42:39Z
name: mysql
namespace: letmetry
resourceVersion: "105997025"
selfLink: /api/v1/namespaces/letmetry/services/mysql
uid: 205f30f2-ec1a-11e8-8bba-02ebb8238b60
spec:
externalName: 172.31.21.116
ports:
- port: 3306
protocol: TCP
targetPort: 3306
sessionAffinity: None
type: ExternalName
status:
loadBalancer: {}
Core dns does not work with FQDN also
OK, the issue is, I believe, that the external name field is supposed to hold a DNS name, not an IP. For example, per the Cluster DNS spec, this field is expected to be a DNS name because it must be used to construct a CNAME record (which can only contain a DNS name target).
If you want to point a cluster service to an external IP, you can do so with a headless service and static endpoint.
Also, if it works for kube-dns then it should work for core-dns as well to maintain the backward compatibility.
Perhaps. Although strictly speaking, kube-dns is violating the Cluster DNS Spec in behaving that way.
IMO, it's not intended that the ExternalName field should be able to contain an IP address. All documentation I can find assumes it will be a name, not an IP. The API should probably not allow IPs in that field.
Diving into the k8s API validation code, it looks like the Service validation is letting IPv4s slip through because it thinks they are domain names (after all, an IPV4 address is a series of valid dns labels delimited by dots). For example, looking at the code, an IPv6 address would fail validation because they contain colons. In other words, the API appears to be accepting an IPv4 address as a domain name, not as an IP. This is the regex the API uses ... [a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)* (used in IsDNS1123Subdomain() which is used when validating the externalName field for ExternalName services).
Got into this "issue" from the ingress-nginx controller perspective - version 0.18.0 or later outputs the following line:
2018/11/19 15:53:42 [error] 110379#110379: *24398057 [lua] dns.lua:61: resolve(): server returned error code: 3: name error, context: ngx.timer
This happens when any externalName is an IP, and it tries to query the nameserver with the IP as an A record.
Both CoreDNS and ingress-nginx are working according to spec, and this detail should be in the official Kubernetes docs for clarity.
Got into this "issue" from the ingress-nginx controller perspective - version 0.18.0 or later outputs the following line:
2018/11/19 15:53:42 [error] 110379#110379: *24398057 [lua] dns.lua:61: resolve(): server returned error code: 3: name error, context: ngx.timer
This happens when any externalName is an IP, and it tries to query the nameserver with the IP as an A record.
Both CoreDNS and ingress-nginx are working according to spec, and this detail should be in the official Kubernetes docs for clarity.
@nikopen - We are facing the same issue. We created the k8s cluster with Kubeadm and deployed nginx-ingress through helm chart. Can you please let me know how you fixed this issue?
@nvenky this happens when you have some Services with externalName as an IP instead of a hostname, as mentioned above.
Turn the IPs into hostnames to fix this.
I too am using externalname services with internal IP addresses.
In Kubernetes, IP addresses are not supposed to be allowed in the in ExternalName services. Kubernetes only permits FQDNs, as such an IP would be interpreted as a FQDN not an IP, resulting in unexpected behavior. IMO Kubernetes field validation could be improved here, by screening out numeric TLDs.
@sylr This is the Kubernetes spec and CoreDNS follows it as intended. Docs have been equally updated to make this detail visible.
If you want to push for this change, a good place for that would be SIG-Network in Kubernetes. If accepted and implemented there, only then I assume CoreDNS would propagate the change.
