容器镜像服务,作为一个可选付费产品,主要作用是存储docker的镜像仓库,供k8s拉取到Pod节点里。 你可以自己搭建一个harbor镜像仓库,在公司的开发环境下,将image推送到仓库;然后在生产k8s从仓库拉取image到本地。
如下图的方案二所示,阿里云的容器镜像服务,其实也就是一个镜像仓库。它可以被harbor/nexus等私有部署所替代。
方案一
方案二
既然是一个镜像仓库,那么需要运维的地方就和harbor类似,存储空间的治理就显得非常重要。
本文主要介绍,我们在运维阿里云镜像仓库过程中,需要主要的一些问题。
规格选择基础版,对于我们生产环境来说,足够使用。
阿里云容器镜像仓库服务,支持你新建多个命名空间,用于支持不同镜像的部署。
创建仓库
删除仓库
这一点,建议产品设计做交互的时候,向阿里云学习。点击“删除”,弹出确认删除的提示框,让你再次勾选后才触发删除。
默认情况下,按钮“确定”是灰的,不可点。
第二步,删除后,列表的整行背景变灰,不允许用户再次去删除。并且在表格的状态列,展示“删除中”的字眼。
此时,该记录变为不可操作态,“管理”和“删除”的按钮都置为灰色。
第三步,待服务端将该仓库删除完成,客户端界面将被删除的那行从表格里移除。
背后的技术实现,删除是异步操作,可能是以下两种:
作为存储空间的优化重点,我们需要对镜像进行定期清理。
阿里云的策略比较简单,不会像harbor那么复杂,当然也足够受用了。
因为是但环境下的镜像仓库,所以用不上什么正则匹配。
选择保留最近构建的3个镜像,再早的就自动废弃了。
每周会跑定时任务。(具体周几的几点,阿里云对于我们使用的用户来说,都是透明的)
我这里等不及定时清理了,所以点击了一次“立即执行”,可以看到,在用的实例下成功地清理掉了671个image,总花费6分钟的时间。
这里,建议产品经理们学一下它这里是如何设计异步操作交互。
单独的一个刷新按钮,而非整个页面刷新。
清理的Tag数,会随着手动刷新而逐渐变多,直至清理状态是“已完成”。点击“查看”,可以看到清理的明细进度。
本文主要是介绍了一下阿里云的容器镜像服务,需要主要的一些运维问题,希望可以帮助到你。