本文經作者授權，由InfoQ翻譯併發布。
Gartner分析師Marco Meinardi、Richard Watson和Alan Waite表示，不能主要爲了應用程序的可移植性而採用Kubernetes，因爲雖然K8s從理論上提高了可移植性，但在實踐中它使應用依賴於特定平臺，同時有可能讓應用無法使用雲平臺的最佳特性。
他們最近在“專業技術建議”文件中提出了這一理論，並且在2020年9月4日的一篇博文中總結了這個理論。
我們閱讀了完整的文件，其中心思想是：想要採用Kubernetes的話，你還得選擇合適的Kubernetes管理工具供應商纔行。
“使用Kubernetes時，你只是將一種依賴形式換成了另外一種。”他們寫道，“通過使用Kubernetes來減少對特定供應商的依賴是很吸引人的，但K8s的抽象層使其演變爲另一種形式的依賴。你現在依賴於抽象層，而不是底層基礎環境。”
這很重要，因爲“儘管抽象層對於可移植性可能很有用，但底層雲服務商常常掩蓋或扭曲這些抽象層，使其並不具有完全相同的功能。總的來說，公有云服務所提供的抽象層會帶來成本和服務不一致的問題，所以當你的組織將產品迅速上市和迅速產生收益作爲首要目標時，採用雲服務商提供的這些抽象層並不是什麼好選項。”
他們還擔心爲了實現可移植性，用戶可能無法使用雲平臺的最佳特性。
“使Kubernetes應用具備可移植性需要避免一切對基礎設施提供商的依賴，例如雲服務商提供的原生服務。而我們開始使用該雲平臺的原因通常就是因爲這些服務所提供的功能。”他們寫道。
然後，他們三人指出不同雲服務商運行Kubernetes的基礎設施特性不同，這也使移植變得不太容易。
“計算實例用到的雲服務提供者的特定功能越多，實現可移植性的可能性就越低。”分析師們寫道，“例如，在AWS Fargate上使用EKS未經CNCF認證，甚至可以說它不是標準的Kubernetes。由容器實例（ACI）實現的Azure虛擬節點也是如此。”
該文件也指出，採用Kubernetes幾乎肯定意味着要採用第三方的存儲和網絡組件，這也意味着移植應用程序必須同時複製這些額外的組件，因此這也使應用程序更加依賴於特定平臺。
使用雲服務商在基礎設施堆棧中預置的軟件可以減少一些麻煩，例如可以選擇Google Anthos，Azure Stack或AWS Outposts。
但總體而言，該文件表明你別無選擇，只能“依賴於特定平臺，儘可能減輕這種依賴並接受它。”
而且，應該是在三位分析師評估的應用移植概率“極低”的情況下做這個選擇。
“由於可移植性的挑戰，大多數應用程序不會在雲服務提供商之間遷移，但是大多數應用程序也不需要這種可移植性。“數據引力”使應用程序往往更靠近數據的存儲位置。遷移數據通常是困難且昂貴的。出於類似的原因，爲了利用最便宜的基礎設施而頻繁移動應用程序的情況尚未出現。”
因此，該建議表明爲移植性而建立應用可能會引入“移植稅”。
“如果你採用Kubernetes僅僅是爲了實現應用的可移植性，那麼你會在嘗試解決一個問題的同時，引入了三個本來沒有的新問題。”
但是如果你不管上述問題，仍然選擇使用Kubernetes並且重視可移植性，他們三人推薦使用另外一層基礎設施。
“進一步抽象是避免依賴於特定Kubernetes消費模型和供應商的合理方法。這種方法建議使用Kubernetes管理器的管理器，例如D2iQ Kommander，Giant Swarm，Google Anthos，Platform9，Rancher，VMware Tanzu Mission control或者類似的管理器。”
但是，一旦你使用了這樣的平臺，就會出現另一個你無法避免的問題。
分析師寫道：“這類聯合產品的目的是聯合多個Kubernetes集羣供應和管理，跨越多種基礎架構和Kubernetes消費模型。但是，這就會冒着對該聯合產品產生新的依賴性的風險，而這種新的依賴比對主要雲服務商或軟件供應商的依賴還要糟糕。”
原文鏈接：
https://www.theregister.com/2020/09/08/kubernetes_app_portability_problems