1.kubenete中apply和create的区别是什么？

简单来说,apply是一个声明式的管理，而create是命令时管理。主要区别在于create要求你执行一个具体的操作（例如创建一个文件资源），这个资源必须是之前没有的，一旦存在它就会直接报错。而apply在创建资源时不管有没有都直接进行，如果之前没有这个资源则直接创建，如果就将这个资源更新成我apply的那个资源状态，这也就是为什么apply是声明式的管理

apply很像你的经理，他告诉你了一个任务，他不管你之前做的怎么样，我现在要的就是你要交给我的。（有没有霸道总裁的味道~）

在CRD中这两者的关系一定要理清楚，因为CRD的不可变性与apply的合并机制冲突，如果在不知道有没有CRD资源存在时你一不小心直接用了apply将直接导致新配置的CRD与现有的在不可变字段上产生冲突，导致CRD资源直接损坏！十分危险！而create整好避免了这一危险，所以在有关CRD的操作下优先使用create。

2.ingress和service的区别是什么？

这是一个经典的问题，首先一定要对ingress熟悉，他是面试时候的重点。二者都是k8s中的网络概念，简单来说，最主要的区别就是service提供内部服务发现和负载均衡，而ingress提供外部HTTP/HTTPS的路由管理。接下来我用形象的比喻来让各位明白二者的区别：

将k8s集群比作一个大型公司，现在突然有一个外部访客（外部流量，比如host:123.com）他走到公司门口，看着这么大的地方我应该怎么去我要去的地方，这时候公司前台（ingress）过来问他,你要去哪啊？访客就把他的名字（host:123.com）告诉他，前台一看接待手册（yaml文件）就知道他要去哪里，于是帮他指了一下他想去的地方，这时候访客到达了研发部也懵了啊，这么大我又该咋办？要不说人家是大公司，一进来就有专门的招待人员（service）！招待人员一看这个访客，又看了研发部的招待手册，赶紧把那些可以为他服务的人员叫齐（查找与labels匹配的pod），然后让访客会随机分配一个之前叫齐的人中的一个。

这个例子就能很清晰直观的理解二者区别。

当然还有细节需要注意：

1.例子中的前台ingress本身是一个概念，实际上它是由ingress controller和ingress Resources组成的体系，其中前者的功能诸多，由监听端口，解析HTTP请求，SSL/TSL终止，负载均衡，路径重写等，后者主要是定义路由规则，配置SSL证书，设置路径重写等。

2.例子中将可以服务人员叫齐实际上是通过Endpoints Controller来持续监控Pod，然后根据就绪探针来判断Pod是否处于可用状态，然后通过service selector来筛选Pod。

3.例子中的随机其实并不是那么随机，它涉及到了负载均衡和请求转发的知识，首先他需要有负载均衡器有多个出口，所有出口都对应上一步service selector给你筛选的Pod，而流量每次进入是会自动选择最合适的出口（有些Pod会处于宕掉或是非健康状态不可工作，就绪探针检测到会告知kubele,然后更新Pod的Ready状态，然后Endpoints Controller监控到并将其删除），同时还涉及到流量转发规则和分配策略配置，这里就不一一讲了。

4.当面对突如其来的很多流量时，这时候就用到了弹性伸缩与高可用性，HPA迅速自动扩容，创建新的Pod，这些Pod不仅用于Pod不够用的情况下，而且还用在被Endpoints Controller监控到并将其删除的Pod空缺之中。高可用性指的是session Affinity,也就是会话保持，它可以基于客户端的IP来确保每一次为他服务的Pod都是相同的。

5.为了保证服务完整还有服务网格与高级路由的进阶功能。

3.cri-dockerd是什么？

这就和k8s和docker的历史有关系了。

早期k8s和docker还是其乐融融，k8s由docker engine集成，Docker 提供了构建、打包、运行容器的全套功能，Kubernetes 就直接用它来管理容器。

后来因为k8s为了支持更多的容器进行时（不仅仅是docker），它定义了一个标准接口规范，容器进行时接口（container runtime interface），也就是cri。只有你的容器进行时符合这个规范就能接入使用。

这里简单讲一下容器进行时，简单来说容器进行时就是真正负责启动，停止和管理容器的软件，而它还可以分为低级运行时和高级运行时，低级运行专注于如何在操作系统层面运行一个隔离的进程，他们直接与内核交互。而高级运行时专注于什么时候需要运行，他们管理镜像传输，存储和网络，并最终调用低级运行时来创建容器。

而docker本来就诞生在CRI之前，也不满足cri的规范，为了能够继续满足k8s的需求，cri-docker就出现了，他好比是一个转接头，一边接cri的标准接口，另一边接docker的非标准接口。将通过cri的请求翻译成docker egine能够理解的api请求。

而且由于k8s的不断升级，目前使用更轻量级的cri-docker或者直接使用containerd,由于containerd是被docker内部使用，而现在的k8s只看上了docker中containerd,所有直接就和container“合作”，绕过了cri-docker的转接头。

ok这就是本章内容的全部内容，感谢观看，如有问题欢迎指出！