非科学上网K8S系统镜像获取方法

前言：

总感觉现在这个时代，在IT领域，单靠个人的技术积累，真的难以跟上IT技术的进步速度。DOCKER成为虚拟化领域的热点才不过几年，K8S作为DOCKER容器群集的管理工具，又成为了虚拟化容器管理下一个热点。简单看了下K8S的教程，K8S的确在大规模部署容器群集方面有非常强的优势。以DOCKER作为底层，再应用K8S进行大规模的部署及管理，我不得不承认，这确实是未来虚拟化容器管理的方向。如果说K8S还能什么进化的方向，除了新功能的加入以外，我想就只有图形化的管理界面了。无论如何，K8S现阶段的学习要求真的一点也不低，但作为未来的趋势，我也只有迎难而上了。

要学习K8S，利用虚拟机模拟架设一个K8S的基础群集，这无疑是必需的。然而，要架设K8S基础群集的基础镜像，就必须访问GOOGLE，从相关的云服务器上下载相关镜像，作为一个会看这篇文章的读者，我相信大家也都很清楚国内的网络状况。无论如何，作为一个技术的爱好者，我必须在这里吐糟这一下这个情况。不过，既然现实无法改变，我们也只能另找方法去实现我们的目的。

要获取必要的镜像，目前看来有三种方法：一、使用国内别人打包好的镜像文件，使用DOCKER的相关命令进行镜像导入；缺点明显，安全性与镜像版本更新无法保证；二、利用科学上网从GOOGLE的服务器上实时获取最新镜像；没什么缺点的，只是国际带宽的那个拥堵实在难以接受；三、使用本教程的方法，详见原理说明。

 一、原理说明

对于K8S群集的基础镜像，GOOGLE并没有推送至DOCKER的官方镜像仓库，这里我又想吐糟GOOGLE，考虑一下我们中国用户啊~~所幸的是，DOCKER官方似乎已经意识到了这一个问题，已经对K8S的基础镜像进行了收录，于是我们便能够从DOCKER的官方镜像仓库中下载必要的镜像，去启动我们的基础K8S群集，毕竟国内基于DOCKER官方仓库的加速服务还是很好找的。缺点嘛，相对麻烦点，优点很明显，保证镜像的安全性与镜像版本的正确性。另外补充一点，这个方法之所以能实现，重要原因是，K8S是以镜像的名称+标签去识别应该使用的镜像，而不是使用镜像的希哈值。

对于DOCKER官方仓库镜像加速的使用方法，请百度或谷歌，以下为实现方法。

 二、实现方法

首先，使用以下命令查询当前系统安装的K8S服务所需要使用到的镜像，以下为本教程获取到的所必需镜像信息：

在获取到K8S镜像的信息后，我们需到DOCKER的官方仓库中查找相对应的镜像及其相对应的标签/版本[DOCKER官方仓库地址]；本外以查询“k8s.gcr.io/kube-apiserver:v1.16.0”为例：

一、在搜索框输入[kube-apiserver]进行查询，选择名为[mirrorgooglecontainers/kube-apiserver]的镜像；注：从本外可以注意到[mirrorgooglecontainers/*]即为DOCKER官方从谷歌镜像操作而来的镜像，其中文翻译也很明确，即为“镜像谷歌的容器”；任何情况下，对K8S的镜像文件获取，应优先使用本方式进行镜像文件的选择；

二、在确认应该使用的镜像文件后，我们需要再次确认应该使用的标签/版本[tags]；在WEB页面中点击“Tags”我们能获取到本镜像文件的所有标签/版本；对于版本的选择，为保证K8S的匹配性，应该选择想接近的版本，例如本教程应该选择“1.16.0”的标签/版本；对于每个标签，其还有子标签，其一般写法为“Alpha、Beta、RC”等等，我们应该尽量选择靠后发布的标签/版本。本例最后选择的标签为“v1.16.0-rc.2”；对于子标签/版本的意义，可百度“Alpha、Beta、RC”这些关键字；另外补充的图片有点模糊，但我觉得已经足以表述图片存在的意义了。

三、确认最终需要从DOCKER官方仓库拉取的镜像；本例最终确定为[mirrorgooglecontainers/kube-apiserver:v1.16.0-rc.2]；之后，便可以使用“docker pull”命令下载相关镜像，并通过重命名方法，生成K8S可识别的镜像，具体操作如下：

四、至此，我们已经完成了第一个K8S的必要镜像的下载与适配了，其它镜像重复上述步骤即可。

三、懒人福利[更新日期：2019/10/17]

如果你实在懒得查询相关镜像的版本，又或者不熟悉相关的操作方法，而你恰好又是使用K8S的“v1.16.0”版本[当前最新版本][可使用“kubectl version”命令查询]，那么你可以直接使用以下命令。当然，如果你的K8S系统默认使用的镜像与本教程的镜像相近，也可尝试使用。

拉取所有K8S必需的相接近的镜像文件：

重命名镜像文件以适配K8S必要镜像的命名方式：

结语、

我果然很懒，写文章果然很花时间，太花时间了；