#Pod

有很多同学发现在Pod中通过volume挂载数据的时候，如果挂载目录下原来有文件，挂载后将被覆盖掉。有的时候，我们希望将文件挂载到某个目录，但希望只是挂载该文件，不要影响挂载目录下的其他文件。有办法吗？

我们前面的课程中学习了Pod的基本用法，我们也了解到Pod的生命是有限的，死亡过后不会复活了。我们后面学习到的RC和Deployment可以用来动态的创建和销毁Pod。尽管每个Pod都有自己的IP地址，但是如果Pod重新启动了的话那么他的IP很有可能也就变化了。这就会带来一个问题：比如我们有一些后端的Pod的集合为集群中的其他前端的Pod集合提供API服务，如果我们在前端的Pod中把所有的这些后端的Pod的地址都写死，然后去某种方式去访问其中一个Pod的服务，这样看上去是可以工作的，对吧？但是如果这个Pod挂掉了，然后重新启动起来了，是不是IP地址非常有可能就变了，这个时候前端就极大可能访问不到后端的服务了。

上节课我们学习了Pod自动伸缩的方法，我们使用到了HPA这个资源对象，我们在后面的课程中还会和大家接触到HPA的。今天我们来给大家介绍另外一类资源对象：Job，我们在日常的工作中经常都会遇到一些需要进行批量数据处理和分析的需求，当然也会有按时间来进行调度的工作，在我们的Kubernetes集群中为我们提供了Job和CronJob两种资源对象来应对我们的这种需求。

前面我们的课程中学习了Pod的一些基本使用方法，而且前面我们都是直接来操作的Pod，假如我们现在有一个Pod正在提供线上的服务，我们来想想一下我们可能会遇到的一些场景：

• 某次运营活动非常成功，网站访问量突然暴增
• 运行当前Pod的节点发生故障了，Pod不能正常提供服务了

第一种情况，可能比较好应对，一般活动之前我们会大概计算下会有多大的访问量，提前多启动几个Pod，活动结束后再把多余的Pod杀掉，虽然有点麻烦，但是应该还是能够应对这种情况的。

第二种情况，可能某天夜里收到大量报警说服务挂了，然后起来打开电脑在另外的节点上重新启动一个新的Pod，问题也很好的解决了。

TODO

我们知道Pod是Kubernetes中最小的调度单元，平时我们操作Pod的时间也是最多的，那么你知道Pod是怎样被创建出来的吗？知道他的工作流程吗？

前面在k8s技术圈微信群里面有朋友问到如何在容器中获取 POD 的基本信息，其实kubernetes原生就提供了支持的，那就是Downward API。