K8s 从懵圈到熟练 – 镜像拉取这件小事

导读：相比 K8s 集群的其他功能，私有镜像的自动拉取，看起来可能是比较简单的。而镜像拉取失败，大多数情况下都和权限有关。所以，在处理相关问题的时候，我们往往会轻松的说：这问题很简单，肯定是权限问题。但实际的情况是，我们经常为一个问题，花了多个人的时间却找不到原因。这主要还是我们对镜像拉取，特别是私有镜像自动拉取的原理理解不深。这篇文章，作者将带领大家讨论下相关原理。

顺序上来说，私有镜像自动拉取会首先通过阿里云 Acr credential helper 组件，再经过 K8s 集群的 API Server 和 kubelet 组件，最后到 docker 容器运行时。但是我的叙述，会从后往前，从最基本的 docker 镜像拉取说起。

镜像拉取这件小事

为了讨论方便，我们来设想一个场景。很多人会使用网盘来存放一些文件，像照片，文档之类。当我们存取文件的时候，我们需要给网盘提供账户密码，这样网盘服务就能验证我们的身份。这时，我们是文件资源的所有者，而网盘则扮演着资源服务器的角色。账户密码作为认证方式，保证只有我们自己可以存取自己的文件。

这个场景足够简单，但很快我们就遇到新需求：我们需要使用一个在线制作相册的应用。按正常的使用流程，我们需要把网盘的照片下载到本地，然后再把照片上传到电子相册。这个过程是比较很繁琐的。我们能想到的优化方法是，让相册应用，直接访问网盘来获取我们的照片，而这需要我们把用户名和密码授权给相册应用使用。

这样的授权方式，优点显而易见，但缺点也是很明显的：我们把网盘的用户名密码给了相册服务，相册服务就拥有了读写网盘的能力，从数据安全角度，这个是很可怕的。其实这是很多应用都会遇到的一个一般性场景。私有镜像拉取其实也是这个场景。这里的镜像仓库，就跟网盘一样，是资源服务器，而容器集群则是三方服务，它需要访问镜像仓库获取镜像。

理解 OAuth 2.0 协议

OAuth 协议是为了解决上述问题而设计的一种标准方案，我们的讨论针对 2.0 版本。相比把账户密码直接给三方应用，此协议采用了一种间接的方式来达到同样的目的。如下图，这个协议包括六个步骤，分别是三方应用获取用户授权，三方应用获取临时 Token 以及三方应用存取资源。