我们团队规模采用命名空间区分各种环境是完全足够的，但是我们的集群可能会经常进行一些业务应用和容器的新特性调试，考虑命名空间只能提供软隔离，以及dev环境不能影响线上环境的原则，我们预发布和生产是同一个集群，通过命名空间隔离，dev则是单独的小集群

每节课我都做了实验，有需要的可以参考，写的比较详细，github.com/librant/git-ops-learn，觉得有用帮忙star一下嘞

跟着老师一步一个脚印，github.com/librant/git-ops-learn 每章节的详细实践，可以大家一起学习分享，觉得不错的可以帮忙 star一下，我会坚持到课程结束嘞

继续追剧

老师好，内容太棒了！请问什么时候更新后面的内容呀

首先感谢老师的文章，比较适合我这种 先感受,再理论（先feel it,再know it)的实战派。 问题中的"所有的文件" 可能是一个动态变化的“一堆文件”，因为后期随着项目的不断迭代，里面会引进一些其它的文件，因此这个所谓的“所有文件”可能是一个动态文件， 而 COPY requirements.txt 在今后的镜像构建里是一个静态的单一文件，因为只有'requirements.txt'。 docker 在构建镜像的时候，dockerfile的会每一个命令会构建一个层， 而在构建的时候是有一个缓存的特点，而这个缓存机制如果是遇到发生变化的层，即使后面的层没有发生变化，也会重新构建，进而并不会用到缓存。 所以，把不变的层放在前面，变的层放在后面，就会让变化之前的层利用到构建镜像的缓存机制，来加速构建镜像的时间。 不知道我说的对不，还请老师指点，我之前有遇到过这个问题。

我本地windows实验成功了，感谢大佬

kind 有很多设计理念，比如 1. 优雅降级 因为 kind 是专为测试 k8s 设计的，所以自身很顽强。支持所有的 k8s 官方版本，并且如其名字所示，docker 里搞出来的 k8s，集群依赖的所有的镜像都打包在了它的节点镜像里，厉害的是，如果这些镜像损坏了或者丢失了，节点镜像还能帮你重新拉下来，真是打不死的小强。 2. 不重复发明轮子 虽然现在已经有了很多功能类似的软件，比如大名鼎鼎的 kubeadm，但是 kind 并不是来搅局的，他很谦虚的抱着协作的态度，能复用就复用，站稳巨人的肩膀，专注解决痛点，合作共赢。 3. 最小化假设 kind 表示只要求安装 docker 即可，剩下的就交给我了。避免做出任何不必要的假设，minikube 表示，你礼貌吗？ 4. 封闭原则，无状态原则 力求操作幂等、避免依赖外部服务，本身不存储或管理状态。好家伙，低内聚，高耦合，本身还没有副作用，不愧是 kind，确实很友好。 5. 避免伤害用户，遵循 k8s API 约定 啥？还有这原则。来看看都啥内容，避免配置和命令行接口的不兼容性修改，严格遵守 k8s 的弃用政策，面向外部的特性考虑扩展性以及长期支持性，使用 k8s 的配置风格，减少参数个数...一上来就海誓山盟还真是不习惯。 另外还有自动化和支持 CRI，感兴趣的可以了解了解 https://kind.sigs.k8s.io/docs/design/principles/

板凳坐好

最近也在做相关学习，结合自己工作经历制作了几个实验，覆盖了老师提到的12个领域中的8个。看到老师上了这个新专栏，非常兴奋啊 希望老师能指点一下 感谢🙏https://github.com/chance2021/devopsdaydayup