Kubernetes CKA課程筆記 29
考量到上一篇最後測試curl的情境
如果哪天遇到在測試Pod內執行curl指令到Service-Name:Service-Port
假設發現不通!!!
然後確認了
- Service Component還在! (OK)
- Pod還活著,並且確認是Service的Endpoint! (OK)
那麼問題會出在哪裡呢?
所以就要研究上一篇最後Service-Name如何解析成Service的IP位置!
也就是當curl是打向Service的IP:Service的Port可以通!
那也就是"Service-Name解析成IP位置"這個過程出了問題!
至於何謂DNS呢?
DNS — Domain Name Service
- 整個網路都依賴DNS來運作
- 所有電腦在網路世界裡都是有唯一的IP位置來辨別
- 任何電子元件(如電腦)與其他電子元件溝通都透過IP位置
- 但是進到google(www.google.com)或FB(www.facebook.com)等網站
- 都不是透過IP位置,並且實際上這些網站背後可能有多台電腦
- 這些電腦都是不同IP位置
- 並且當地的餐廳網站則可能是只有單一個電腦在處理
- 所以為什麼要用名子替代IP位置?
- 簡單原因是人類比較容易記住名稱而非像電腦一樣容易辨識IP位置
- 所以名稱轉變為IP位置,最終Request傳送到某個IP位置
- 完成這件事的就是DNS=translates domain names to IP addresses
- 最初期網路興盛前,DNS的設置是存在本機/etc/hosts目錄下
- 並且上述路徑仍是當今DNS服務查找的第一個位置
- 但是現在網路太過龐大,不太可能本機端就把所有的DNS存在單一電腦裡
- DNS使用簡單的劃分策略來切分不同的domain或group
- Domain Name使用hierarchical(等級制)結構
- 從根源(Root) Domains先劃分出13個由a ~ m(參考)根域名伺服器
- 往下在畫分Top Level Domains(或稱TLD),其中有6個較為常見的:
- .mli : for military(軍事) (ex : www.marines.mli)
- .edu : for educational institutions (ex : www.mit.edu)
- .com : for general purpose or businesses (ex : www.google.com)
- .org : for non-profit organizations (ex : www.wikipedia.org)
- .net : for networking technologies (ex : www.fairtrade.net)
- .gov : for government (ex : www.nyc.gov)
- 在後續演變下,TLD又有增加由地理位置的domains:
- at(Austria),de(Germany),us(USA),fr(France)
- ex : www.a1.at 或www.bmw.de等
- 後面還有各種TLD加入(.biz,.int,.dev,…etc)
- 當有企業建立網站,則可以購買domain(ex : google.com或是amazon.com)
- 購買可能為期一年之類的期限
- 至於誰管理這些domain?或誰出售這些domain?誰建立名稱可循性
- 一切都是由網際網路名稱與數字位址分配機構(ICANN)
- ICANN(Internet Corporation for Assigned Names and Numbers)
- ICANN統一管理了domain的命名空間,註冊與授權及分配
- 所以所有的domain name都屬於Root
- 例如講師建立了網站給人瀏覽
- 所以在TLD為.com後面購買了"techworld-with-nana"這個名稱
- 但是該公司網站又有劃分三台主機Server
- 所以網域上又有Subdomain(分別為bootcamp,workshops,course),故有:
- www.bootcamp.techworld-with-nana.com
- www.workshops.techworld-with-nana.com
- www.course.techworld-with-nana.com
- 也就是企業網站再依據Subdomain來區分不同應用系統
- 這些系統都屬於該企業公司
- 如上圖此時就有完整的domain name可以進到對應的IP位置機台
- 還有另一個domain name定義FQDN由Root開始
Fully Qualified Domain Name(FQDN):
- course.techworld-with-nana.com.
- (注意上面尾巴多了個點,也就是Root,但實際上不太需要用這個)
至於DNS又是如何解析的?
DNS解析:
- 一般電腦都有預先安裝好DNS Client
- 所以打開瀏覽器鍵入網址後
- 系統都會發出DNS Query(例如問www.facebook.com)
- 去詢問DNS該網址位置,找到對應該網址的IP位置
- 首先DNS Query會先到達recursive name server(遞迴式名稱伺服器)
- 遞迴式名稱伺服器通常就是網路服務供應商
- 遞迴式名稱伺服器通常會儲存詢問的網址對應的IP位置
- 若很剛好這個網址沒有儲存
- 則會在轉拋這個DNS Query給”13 Root Server”其中一個
- 用以請求top level domain(因為top level domain是Root Server管理)
- 這些13 Root Server分布在全世界
- (由技術上拓展鏡像伺服器架設13 Root Server到2019共有1008台)
- 所以DNS Query很快會得到回應,並返還回到recursive name server
- 但是通常返還的不是真正Query所要的IP位置
- 而是返還告知recursive name server,這個.com的TLD你可以詢問這個位置的TLD Server(管理.com的TLD Server)
- 該TLD Server則再回應給recursive name server一個清單
- 該清單上記載針對.com的authoritative name Server(授權名稱伺服器)
- 最終這些清單上的所有authoritative name Server才真的知道facebook.com的IP位置
- recursive name server由清單挑選一個authoritative name Server詢問
- 然後recursive name server才真的拿到facebook.com的IP位置
- 而當然不是每次都需要這麼費工
- 所以個人電腦或recursive name server都有cache機制紀錄一段時間
- 保留facebook.com對應的IP位置一陣子
