不能 1. 问题背景 基于 Kubernetes 构建可靠、稳定的运维系统时，虚拟机 (VM) 的销毁和新建是一种常态。VM 提供的是计算和内存资源，而使用外部存储，通过 StorageClass 提供给集群中的 PVC 消费。 在这样的背景下，如何快速初始化 VM 成为新的挑战。常见的思路是制作 Node 节点的 VM 镜像，提前将依赖

Docker 的 Mirror 仅能加速 docker.io 的镜像，而不能加速私有仓库的镜像。 1. 为什么需要一个私有的镜像仓库 mirror 公网限速 dockerhub 拉取限制频率 减少拉取镜像时间 2. 创建一个 Registry 镜像加速服务 生成一个配置文件 version: 0.1 log: fields: service: registry storage: cache: blobdescriptor: inmemory filesystem: rootdirectory: /var/lib/registry http: addr: :5000 headers: X-Content-Type-Options: [nosniff] health: storagedriver: enabled: true interval: 10s threshold: 3 但这样启动的服务只能作为 Registry

1. Buildpack 老树开新花 Buildpacks 项目最早是由 Heroku 在 2011 年发起, 被以 Cloud Foundry 为代表的 PaaS 平台广泛采用。在之前的文档 《PaaS 部署之 buildpack》 中, 我演示了如何将一个 Django 应用部署到 Heroku 上。 Buildpacks 不足的是产出包是 Droplet 格式, 不能直接适配容器平台。 在 2018 年 1 月, Pivotal 和 Heroku 发起了一个项

1. 一个奇怪的需求 老板有个奇怪的需求，通过一个 kubeconfig 文件，获取主机的各种状态信息，比如进程列表、进程状态等。 第一反应就是，老板是不是不懂容器，容器怎么能这样玩，这样玩还要什么容器，内心万马奔腾。 直到最近遇到了一个命令行工具，才发现原来小丑是我自己

1. Github Container Registry 9 月 1 日，GitHub 宣布 Github Container Registry 开始公测，测试期间提供免费、无限容量的 Docker 镜像仓库服务。 再也不用担心，docker.io 一言不合清理镜像了。真好真香！ GitHub 正在以托管代码仓库为切入点，逐步覆盖整个研发工具链，打造一站式 DevOps 平台。项目管理有 Issues