Using Docker on Mac, I am trying to port docker run parameters to kubernetes yaml configuration, today we are running a container with following DNS flags:
--dns="8.8.8.8" --dns="8.8.4.4"
when I do docker inspect on this container I see:
"Dns": [
"8.8.8.8",
"8.8.4.4"
]
After reading the Kubernetes docs, I configured the pod yaml like this:
dnsPolicy: "None"
dnsConfig:
nameservers:
- 8.8.8.8
- 8.8.4.4
But when I do docker inspect on the container that Kubernetes launched I see
"Dns": null
Is that expected? is the configuration correct? maybe Kubernetes networking bypasses the container configurations so the container is not aware... I simply don't know.
As fiunchinho clarified the behavior is correct. Configuring Pod DNS policy will have impact on the container, but you won't be able to see that through docker commands, like in few other cases. This is because docker and Kubernetes operate on different layers of the stack.
So adding the DNS parameter to docker run will result in writing them in /etc/resolv.conf and the same thing happens with adding dnsConfig although in the last example Docker will not be aware of it. So answering the question, yes this is expected behavior.
Related
I have setup coredns to run in a container and everything is working. I would like to force all containers going forward to use this DNS from the this container. The DNS server I installed was coredns.
I know I can use "dns" from a docker-compose but this requires a IP address and my container doesn't have a fixed IP.
Is there some way to force all container to use this specific container as their "port 53" dns server
Thanks in advance
no, if you are not able to setup static IP for coredns you must manually update /etc/resolv.conf in every container after each build/reboot or run docker with --dns parameter
with static you can setup global dns for all in /etc/docker/daemon.json and restart docker service
Due to some requirement, I am using dind (docker inside docker) whose docker daemon is used by other container inside the same pod.
I want to run this dind container's docker daemon on any port other than 2375.
There is another pod existing inside K8 node which serves all other pods with the docker daemon.
But there are some inconsistencies occuring as same docker daemon is used by pods of different services.
For the above reason i decided to use dind container in every requiring pod. Thus i had to set the hostNetwork to false, but now the pod is not able to
pull any public image.
pull any public debian package etc.
I have tried setting up the dns values with 8.8.8.8 and 8.8.4.4, but still the issue is coming.
The only thing is that the hostNetwork=false is a mandatory flag.
Is there any way to make the pod able to pull public images and artifacts while the above flag is set to false ?
Thanks in advance.
With k3d, I am receiving a DNS error when the pod tries to access a URL over the internet.
ERROR:
getaddrinfo EAI_AGAIN DNS could not be resolved
How can I get past this error?
It depends on your context, OS, version.
For instance, you will see various proxy issue in k3d-io/k3d issue 209
this could be related to the way k3d creates the docker network.
Indeed, k3d creates a custom docker network for each cluster and when this happens resolving is done through the docker daemon.
The requests are actually forwarded to the DNS servers configured in your host's resolv.conf. But through a single DNS server (the embedded one of docker).
This means that if your daemon.json is, like mine, not configured to provide extra DNS servers it defaults to 8.8.8.8 which does not resolve any company address for example.
It would be useful to have a custom options to provide to k3d when it starts the cluster and specify the DNS servers there
Which is why there is "v3/networking: --network flag to attach to existing networks", referring to Networking.
Before that new flag:
For those who have the problem, a simple fix is to mount your /etc/resolve.conf onto the cluster:
k3d cluster create --volume /etc/resolv.conf:/etc/resolv.conf
I am working behind a company proxy.
Because of the many limitations enforced, I have to switch to public network when I come to build my docker images (mainly ubuntu-based images). The build is performed on the same computer (thus, the same dns conf).
Apart from the build, I always run my containers behind this proxy.
The company also (and indeed) has its own dns.
Unfortunately, I don't understand how to pass the host dns to the containers the "proper way" and don't understand how docker manages to build the containers resolv.conf.
When I look at my host, I see such a conf :
$ cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.8.4
nameserver 10.xxx.yyy.z
search rennes.mycompany.fr
And from within my containers, I see:
search rennes.mycompany.fr
nameserver 127.0.0.11
options ndots:0
What looks odd to me is that only a part of the host configuration can be found in the container...
And when I try to reach any company-hosted name from the container, I have a name resolution failure.
But if I add the host's resolv.conf nameserver to the container's one, it works:
$ echo nameserver 192.168.1.1 >> /etc/resolv.conf
So, this is indeed not the way to do it... but I am not sure how I should perform it.
I tried to add the 'dns' to my services in the docker-compose, but I didn't work (or not a way I understand), and the documentation there is quite spartan...
Is there a way to tell docker to use/share host's dns configuration?
May my problem come from my building the image outside of the company network?
EDIT: the docker-compose.yml
version: '3.3'
services:
my-apache:
image: apache:latest
ports:
- 8088:80
networks:
- my-project-net
dns:
- 192.168.1.1
depends_on:
- my-project
my-project:
image: my-project:latest
networks:
- my-project-net
dns:
- 192.168.1.1
networks:
my-project-net:
driver: bridge
only 'my-project' requires access to company dns, but I added dns to both in case I missed some clue...
EDIT 2 : few more details and attempts
docker version : 18.03.0-ce, build 0520e24
docker-compose version : 1.18.0, build 8dd22a9
The name I try to resolve looks like this :
some-pf-db.network.mycompany.fr
The (modified) docker daemon conf looks like this :
$ cat /etc/docker/daemon.json :
{
"insecure-registries": [
"some.test.registry.mycompany.fr:5000"
],
"log-driver": "json-file",
"log-opts": {
"max-file": "3",
"max-size": "10m"
},
"dns-opts": ["ndots:15"]
}
Following #BMitch link, I tried to update docker daemon (+restart) with the ndots options up to 15 (don't think I'd need that many, but it's the lazy way!)...
and unfortunately it didn't solve the problem. The new value replaces the former one within the container, but it keeps failing reaching the dns
could not translate host name "some-pf-db.network.mycompany.fr" to
address: Temporary failure in name resolution
EDIT3 : I was looking at the wrong container... so, changing the threshold for dots (ndots) up to (eg.) 15 within the docker daemon conf (/etc/docker/daemon.json) AND removing the "dns" param from the service makes the magic operate! I have now access to my company dns for names (with a lot of dots in them!!)
The 127.0.0.11 entry inside the container is expected even when you override DNS on the container. This points back to the loopback interface inside the container which has a mapping for port 53 to go back to the docker engine for DNS resolution. You need docker to do the DNS resolution to give you container to container networking with DNS for discovery.
You should still see the docker engine call out to your DNS server even with the 127.0.0.11 entry inside the container, so it's not a bug, or lack of configurability, you just don't see this configuration from inside the container.
We'd need more details on the actual issue you are encountering, but one possible problem I've seen from this before is DNS not resolving external hosts without a fully qualified name in some specific scenarios. You can read about that in this issue/thread here:
https://github.com/moby/moby/issues/32093
if you are using docker-compose you need to add dns section onto your service definition in yaml file.
If you running docker directly for command line you may use --dns=IP_ADDRESS... argument for defining your company nameserver.
more details in documentation here: https://docs.docker.com/v17.09/engine/userguide/networking/default_network/configure-dns/
Docker can build containers just fine up until I connect my Cisco VPN. After that, containers are unable to connect to the outside internet. It's more than a DNS problem, it simply can't route to anything outside of Docker's own network. Now, I can get around this by running containers with --net=host But the problem is with building containers with dockerfiles. I see no way to set the host there. Is there somewhere else I can configure docker to simply always use 'host' as the default network?
The docker build command also has a --network parameter that you can use to specify the network mode that should be used for intermediate containers. This flag has the same effect and possible values as the identically named parameter of the docker run command.
--network (=default) Set the networking mode for the RUN instructions during build
This should allow you to build your containers with:
docker build -t yourimagename --network=host .
Dockerfile is to define how to build an image. It has no runtime parameters beyond setting the default command and/or entrypoint.
Networking is a runtime concern only. If using arguments to docker run is not fitting, perhaps you can use docker-compose.yml and either the docker-compose tool, or a swarm. In both cases, you can define network parameters for the container(s) defined in docker-compose.yml.
network_mode: "host"
See the documentation.
I encountered this problem on a vm running CentOS 7. After I upgraded some yum packages (containerd, container-selinux, docker-ce and docker-ce-cli), it was resolved.