以前在找工作的时候面试了一些大厂，其中在面试字节跳动和阿里巴巴的时候，对于K8S这块，他们问了一个相同的问题：请详细说说，用户执行了一个deployment.yaml文件时，新创建了一个Pod，这个Pod的创建流程是怎样的, Pod的更新流程又是怎样的。简短的一个问题，要是想答的详细，其实还是涉及了K8S中的很多东西，我觉的这是一道比较有质量的题，我在现场答出来了，在这里，我想再总结一下，查漏补缺，算是对面试的总结，更是对K8S自身的学习和沉淀。
我在回答这个问题的时候，其实头脑里大概是有一个流程图的，然后再按着从头到尾，逐步展开的的原则来详细说明，下面就参照这幅图，再来还原一个Pod被创建时的流程。
第一步：假如我们的deployment.yaml中使用了Nginx镜像，且replicas的值设置为1，然后用户执行了kubectl create -f deployment.yaml命令。
第二步：kubectl执行yaml文件后，对api-server发起了请求，这时api-server会对此次操作进行身份认证，在客户端的~/.kube文
件夹下，已经设置好了相关的用户认证信息，这样api-server会知道我是哪个用户，并对此用户进行鉴权，当api-server确定我们的请求合法后，就会接受本次操作，并把相关的信息保存到etcd中。
第三步：下面controller-manager组件就会介入，controller-manager是有多个类型的，比如Deployment Controller, 它的作用就是负责监听Deployment，此时Deployment Controller发现我们的deployment.yaml文件诉求是需要一个复本集且数量为1，那么它就会去创建一个ReplicaSet，一个ReplicaSet的产生，又被另一个叫做ReplicaSet的Controller监听到了，紧接着它就会去分析ReplicaSet的语义，它了解到是要依照ReplicaSet的template去创建Pod, 它一看这个Pod并不存在，那么就新建此Pod，当Pod刚被创建时，它的nodeName属性值为空，代表着此Pod未被调度。
第四步：调度工作自然是由Scheduler组件来完成的，Scheduler一直关注Pod及Node的信息，所以它就要把未被调度的Pod，调度到合适的Node上去。但是它所做的也只是把它的调度方案，返回给api-server。
第五步：kubelet组件布署于Node之上，它从api-server处知道有一个Pod应该要被调度到自身所在Node上来，它会先判断本地是否在此Pod，如果不存在，则会进入创建Pod流程，创建Pod有分为几种情况，第一种是容器不需要挂载外部存储，则相当于直接docker run把容器启动，但不会直接挂载docker网络，而是通过CNI调用网络插件配置容器网络，如果需要挂载外部存储，则还要调用CSI来挂载存储。
第六步：Pod建立成功后，ReplicaSet Controller会对其持续进行关注，如果Nginx Pod因意外或被我们手动退出，ReplicaSet Controller会知道，并创建新的Pod，以保持replicas数量期望值。
第七步：更新Pod，什么时候会更新Pod? 当deployment.yaml文件中template的部分被更新，就会触发Pod更新，因为Deployment Controller 会把template部分文本计算一个hash值，根据这个hash值判断文本变化。
第八步：既然触发了更新，那么ReplicaSet Controller就会新建一个ReplicaSet并在其中启动新的Pod，在老的ReplicaSet里关闭Pod，直到新的ReplicaSet接替老的ReplicaSet。
总结：
可以看到，对于一个简单的问题，可以回答的内容还是很多，我相信上述内容，如果面试官不是要求你对源码上熟悉与开发，已经回答的比较详尽了。我建议在面试的时候，如果面试官问了一个你比较熟或精通的问题，那么你应该抓住机会尽可能的把这个问题讲深，讲广，如果面试官不叫停，甚至可以把与此相关的东西说出来。你知道这样做的目的吗？可以在评论处与一讨论 : )
?