背景
這幾天在研究Kubernetes, 遇到一個有意思的nodejs鏡像:luksa/kubia
之后,在宿主機使用容器IP和8080 端口可訪問該容器nodejs服務
對此我有幾個疑問,這幾個疑問在我看來有點與我之前對docker 網絡的認知相沖突。
Q1. 不是說如果容器沒有端口映射,容器內外隔離嗎,怎么在宿主機使用容器IP還可以訪問?
Q2. 使用容器IP:8080可以訪問nodejs服務,這個8080從哪里來?
頭腦風暴
首先排除一些同事說法:這個容器是以host
網絡模型連到宿主機,所以可以在宿主機通過容器IP訪問。這個新建容器肯定還是連接到默認的bridge網橋上。
All containers without a --network specified, are attached to the default bridge network.
In terms of Docker, a bridge network uses a software bridge which allows containers connected to the same bridge network to communicate, while providing isolation from containers which are not connected to that bridge network.
對於Q1,我有個誤區:沒有端口映射,容器內外網絡隔離,宿主機是無法訪問容器的。
A: 實際上,對於加入同一bridge網橋上的容器,網橋內外網絡確實是隔離的,網橋上的容器都可以相互連接。
而我們的宿主機也在這個默認的bridge網橋設備上,其IP地址是網橋設備的網關(172.17.0.1)。
Q3.那端口映射到底起什么作用呢?
A:網橋模型確保了網橋內容器可相互訪問,但除此網橋之外的網絡均不能訪問容器, 這也正是bridge網絡隔離的效果。
端口映射-p表示容器綁定宿主機的網卡端口來實現轉發訪問,綁定的網卡決定了你對外暴露的程度。
1. 綁定宿主機的回環地址127.0.0.1
那么在宿主機內只能使用127.0.0.1:8080
訪問容器
2. 綁定宿主機的物理地址 10.201.80.126
那么可使用宿主機物理IP10.201.80.126:8080
訪問容器,這樣局域網機器就能訪問到容器了
很顯然,宿主機內回環地址和物理地址
均可以訪問該容器了。
再回到上面的Q2問題,通過容器IP:8080
訪問容器,8080是哪里來的?
8080是容器內nodejs進程的監聽端口,我們在構建鏡像時本就無所謂使用expose指令
The EXPOSE instruction does not actually publish the port. It functions as a type of documentation between the person who builds the image and the person who runs the container, about which ports are intended to be published.
所以在docekr ps時候,並不會在PORTS列顯示任何內容,但是通過容器IP可直接連通容器內進程監聽端口。
為啥訪問容器IP:8080 就可以訪問容器內nodejs提供的服務?
這是因為容器鏡像在構建的時候,一般在0.0.0.0
地址上監聽請求,這意味着程序在所有地址的8080端口上監聽請求。
這樣就延伸出一個有趣的現象,讓我們進入容器內部:
幾個看起來錯誤的IP竟然也可以訪問nodejs服務, 這正是nodejs在http://0.0.0.0:8080
地址監聽請求的結果。
猜想+ 驗證+ 源碼支持,回應了一開始的幾個疑問,對容器Bridge的網絡認知進一步加深。
總結輸出
-
bridge網橋內容器通過容器IP相互訪問,外部網絡隔離
-
docker run -p 參數通過端口映射,讓bridge網橋外網絡可以訪問容器
-
一般情況下,對外提供web服務的docker鏡像會在0.0.0.0 地址上監聽請求
-
https://en.wikipedia.org/wiki/0.0.0.0
-
https://github.com/luksa/kubia-qps/blob/master/kubia-qps/app.js
-
https://linuxize.com/post/check-listening-ports-linux/