雲原生技術kubernetes調度單位pod的使用詳解

k8s中的最小調度單位—pod

     之前的文章中,我們對k8s能夠解決的問題做瞭簡單介紹,簡單來說,它解決的問題是容器的編排與調度,它的核心價值在於:運行在大規模集群的任務之間,實際上存在著各種各樣的關系,這些關系的處理,才是任務編排和系統管理最困難的地方,k8s就是為瞭這個問題而生的。

      這句話比較難理解,我們從已有的知識入手,抽絲剝繭,慢慢理解它。我們已經知道,容器的本質是一個進程,它包含三個部分:

如果說容器是雲環境的一個進程,那麼你可以將k8s理解成雲環境中的一個操作系統。

    在一個操作系統當中,進程並不總是孤立運行的,往往是通過一個進程組的方式運行的。實際部署應用的時候,我們的應用往往不是以孤立的形式跑在docker容器中的,應用之間存在這樣那樣的關系,有的時候,他們必須跑在同一臺機器上,並且相互訪問,類似於捆綁式的,例如:如果兩個容器之間要發生之間的文件交換、需要共享某些Linux Namespace等場景。這種關系我們稱之為”超親密關系”。

     基於上面的這個前提,k8s在設計之初,就考慮瞭這一點,所以它在設計的時候,並不是以容器為最小的調度單位的,而是以pod這個新的概念作為k8s的最小調度單位,而每一個pod中可以包含多個容器,這樣,就實現瞭部署在容器中的應用程序之間就實現瞭捆綁,也就是他們永遠隻能被部署在一臺機器上,要麼部署成功,要麼失敗,不可能出現一種中間狀態。

Pod和容器的關系?

   需要註意的是,Pod是一個邏輯上的概念,它的本質是一組共享瞭某些資源的容器。確切的說,同一個pod裡面的容器,共享瞭相同的network namespace,當然,還可以共享掛載卷等資源。

    所謂的共享,並不是依賴,而是對等。

    假如我們有A、B兩個容器,如果A依賴B,那麼A的啟動順序一定在B之後。如果A、B的地位對等,那麼A、B的啟動順序將沒有嚴格要求,這才是真正的共享。那麼誰來預先創建被共享的network資源呢?

   在Pod中,如果包含瞭多個應用容器,是需要一個infra容器,將這些應用容器給關聯起來的。類似於下面這樣:

在K8S中,infra容器占用瞭極少的資源,它隻運行瞭一個叫pause的鏡像,所以也被稱為pause容器,它占用的磁盤大小在100~200kb之間。infra的存在是為瞭創建network namespace,然後應用容器A和應用容器B就可以加入到這個   network namespace中瞭。

對於 Pod 裡的容器 A 和容器 B 來說:
1、它們可以直接使用 localhost 進行通信;
2、它們看到的網絡設備跟 Infra 容器看到的完全一樣;
3、一個 Pod 隻有一個 IP 地址,也就是這個 Pod 的 Network Namespace 對應的 IP 地址;
4、當然,其他的所有網絡資源,都是一個 Pod 一份,並且被該 Pod 中的所有容器共享;
5、Pod 的生命周期隻跟 Infra 容器一致,而與容器 A 和 B 無關
6、對於同一個 Pod 裡面的所有用戶容器來說,它們的進出流量,也可以認為都是通過 Infra 容器完成的

    在這種設計模式下,掛載相同的Volume卷就很容易瞭,隻需要在Pod的初始化yaml文件中配置volume參數即可,具體內容後續會專門分享。

     對於容器來說,一個容器隻能管理一個進程,而不是一個應用。我們在進行應用上雲遷移的時候,需要將應用若幹個進程,然後去考慮應用模塊之間是否具有”超親密關系”,擁有超親密關系的進程可以部署在一個Pod中,其他的進程部署在另外的Pod中,用這個思路去拆分應用,才符合容器設計的初衷。

以上就是雲原生技術kubernetes調度單位pod的使用詳解的詳細內容,更多關於kubernetes調度單位pod的使用的資料請關註WalkonNet其它相關文章!