因爲工作的緣故，測試了一下docker的上傳方式和kubernetes中ImagePullPolicy的拉取策略。
爲什麼要測這個呢？
因爲項目負責人讓對兩個功能進行測試，這兩個功能如果研究清楚確實有很大的用處。
是哪兩個功能呢？
第一個功能：本地有個和倉庫中不同的鏡像，但是鏡像名和tag號是相同的，這個本地的鏡像是否能覆蓋倉庫的鏡像。
第二個功能：倉庫中有個鏡像的鏡像名和tag號和本地的鏡像相同，但是倉庫的鏡像是別的鏡像修改之後上傳的，再部署的時候會不會重新去拉取倉庫中的這個鏡像。
第一個功能經過測試發現，是能夠上傳並覆蓋的。測試方式也不復雜，你只需要將一個本地不是特別的的鏡像上傳到倉庫中，然後在本地刪除之前的鏡像（刪除之前記得將該鏡像打包成tar保存起來），並將另外一個大小比較明顯的鏡像重命名爲之前那個鏡像的鏡像名和tag號。然後測試上傳這個鏡像到倉庫，觀察倉庫中的鏡像大小和IMAGE ID是否發生了變化。你會發現倉庫中的鏡像的大小和IMAGE ID都發生了變化。然後刪除本地重命名後的鏡像，記住不要用IMAGE ID去刪，否則會連同重命名之前的鏡像一起刪除了。最後把之前備份的tar包導入進docker重新往倉庫上傳，會發現倉庫中的鏡像又還原了。
所以，經過測試當本地鏡像和倉庫的鏡像不是同一個鏡像的時候，如果鏡像名和tag號都相同，會對倉庫中的鏡像進行覆蓋。
第二個功能經過測試發現，這個是和部署文件的ImagePullPolicy有關係的。
之前其實簡單的測試過，但是因爲看了kubernetes的一段相關介紹反而搞蒙了。
-----------------------------------------------------------------------------------------
https://www.kubernetes.org.cn/kubernetes-pod
ImagePullPolicy
支持三種ImagePullPolicy
Always：不管鏡像是否存在都會進行一次拉取。
Never：不管鏡像是否存在都不會進行拉取
IfNotPresent：只有鏡像不存在時，纔會進行鏡像拉取。
注意：
默認爲IfNotPresent，但:latest標籤的鏡像默認爲Always。
拉取鏡像時docker會進行校驗，如果鏡像中的MD5碼沒有變，則不會拉取鏡像數據。
生產環境中應該儘量避免使用:latest標籤，而開發環境中可以藉助:latest標籤自動拉取最新的鏡像。
-----------------------------------------------------------------------------------------
最後經過測試，其結果是（以下均不討論標籤爲latest的情況）：
如果ImagePullPolicy使用的是默認的IfNotPresent，kubernetes會檢查本地是否和部署文件有同名同tag的鏡像，
如果有則不會去拉取鏡像，即使本地的鏡像是根據其他鏡像重命名而來的不同鏡像也不會重新拉取。
如果ImagePullPolicy使用的是默認的Always，會校驗倉庫的鏡像和本地的鏡像是否同一個鏡像，
如果不是同一個鏡像，即使是同名同tag也會拉取，並把本地之前同名同tag的鏡像的tag號置爲“<none>”。
之前之所以會把確定的問題弄得不確定了，是因爲這句話“拉取鏡像時docker會進行校驗，如果鏡像中的MD5碼沒有變，則不會拉取鏡像數據”。這句話其實是docker的策略，和kubernetes沒有關係，如果kubernetes的ImagePullPolicy設置的拉取策略沒走到拉取鏡像這一步，就不用考慮這一點，我把兩句話當成了一句話，所以把自己明白的事情搞蒙了。
關於第一個功能的測試過程就不整理了，第二個功能的測試過程如下：
我分別在本地拉去了兩個鏡像busybox:musl(ff773d70e0ec)和busybox:glibc(7636bfb4b772)
然後刪除ff773d70e0ec也就是busybox:musl，然後將busybox:glibc重命名爲busybox:musl（用tag命令將busybox:glibc改成busybox:musl，然後刪除busybox:glibc已達到真正的重命名的目的，此時鏡像busybox:musl的IMAGE ID爲7636bfb4b772）
編寫一個沒有ImagePullPolicy的deployment部署busybox:musl
發現pod的Events裏面沒有去拉取鏡像的記錄，本地的鏡像也沒有發生變化
然後將deployment加上“imagePullPolicy: Always”重新部署鏡像
發現pod的Events裏面有拉取鏡像的記錄，而且本地鏡像“busybox:musl”的“IMAGE ID”由“7636bfb4b772”變成了“ff773d70e0ec”
而且之前“IMAGE ID”爲“7636bfb4b772”的鏡像的tag號變成了“<none>”
所以，通過分析。如果鏡像倉庫的同名同tag的鏡像相對於本地的鏡像發生了改變還想在重新部署的時候會重新拉取的話，必須使用“imagePullPolicy: Always”的拉取策略纔行。因爲使用默認的拉取策略，kubernetes只會校驗部署文件的鏡像與本地鏡像的鏡像名和tag。