1.mysql为什么使用了本地的服务没有使用rds 回答了原来的环境是使用本地服务，没有做变更 2.cdn是什么 回答了内容分发网络节点缓存服务器资源，给远离实际服务器所在地的客户端提供访问 3.介绍一下了解的应用服务发布策略 没说清楚 https://www.cnblogs.com/IT-Evan/p/Release.html 第一种应用发布策略就是滚动发布，这也是比较常见的策略。它是通过逐个替换实例来逐步部署新版本的应用，直到所有实例都被替换完成为止。 当前应用提供的服务版本是 v1， 这个服务的后端有 3 个副本， 但我更新版本 v2 的时候，它是一个副本一个副本地开始替换，直到最终服务的后端全部替换成 v2 版本。 滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。 第二种就是蓝绿发布，蓝/绿发布是应用版本 1 与版本 2 的后端 pod 都部署在环境中，通过控制流量切换来决定发布哪个版本。与滚动发布相比，蓝绿发布策略下的应用终态，是可以同时存在版本 1 和版本 2 两种 pod 的，我们可以通过 service 流量的切换来决定当前服务使用哪个版本的后端。 项目逻辑上分为AB组，在项目更新系统时，首先把A组从负载均衡中摘除，进行新版本的部署。B组仍然继续提供服务。 当A组升级完毕，负载均衡重新接入A组，再把B组从负载列表中摘除，进行新版本的部署。A组重新提供服务。 最后，B组也升级完成，负载均衡重新接入B组，此时，AB组版本都已经升级完成，并且都对外提供服务。 滚动升级有一个过程需要时间，即使回滚，它也需要一定的时间才能回滚完毕，在新版本应用有缺陷的情况下，蓝绿发布的策略可以快速在 v1 和 v2 两个版本之前切流量，所以这个切换流量的时间跟滚动升级相比就缩短了很多了，但蓝绿发布的缺点跟滚动发布相同的就是这个缺陷会影响到整体用户，服务要么百分百切换到版本 2 上，要么百分百切换到版本 1 上，这是个非 0 即 100 的操作，即使蓝绿发布策略可以大大缩短故障恢复时间，但在某些场景下也是不可接受的。 而且集群环境中同时存在两个版本的 pod 副本，资源占用的话相比滚动发布是 2 倍的。 第三种发布策略是金丝雀发布（灰度发布），金丝雀部署是应用版本 1 和版本 2 同时部署在环境中，灰度发布是通过切换线上并存版本之间的路由权重，逐步从一个版本切换为另一个版本的过程，并且用户请求有可能会路由到版本 1 的后端，也可能会路由到版本 2 的后端，从而达到让一部分新用户访问到版本 2 的应用。 这种发布策略下，我们可以通过调整流量百分比来逐步控制应用向新的版本切换，它与蓝绿部署相比，不仅继承了蓝绿部署的优点，而且占用资源优于蓝绿部署所需要的 2 倍资源，在新版本有缺陷的情况下只影响少部分用户，把损失降到最低。 蓝绿发布：两套环境交替升级，旧版本保留一定时间便于回滚。 灰度发布：根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问是新版本。 滚动发布：按批次停止老版本实例，启动新版本实例。 4.七层和四层负载均衡的用途和区别 基本说对 四层负载均衡工作在OSI模型的传输层，由于在传输层，只有TCP/UDP协议，这两种协议中除了包含源IP、目标IP以外，还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后，以后通过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器 七层负载均衡工作在OSI模型的应用层，应用层协议较多，常用http、radius、dns等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个Web服务器的负载均衡，除了根据IP加端口进行负载外，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。对于一般的应用来说，有了Nginx就够了。Nginx可以用于七层负载均衡。但是对于一些大的网站，一般会采用DNS+四层负载+七层负载的方式进行多层次负载均衡。 所谓四层就是基于 IP + 端口的负载均衡； 七层即应用层，就是基于 URL 等应用层信息的负载均衡； 5.两台机器实现高可用的ip 回答了 使用keepalived实现vip的自动漂移 6.学习k8s过程中的具体应用场景 说的应对大量访问后端节点的请求，运行环境需要高可用，需要k8s集群，没说具体 7.k8s中deployment组件和statefulset组件的区别 deployment组件回答了调度可用节点部署pod，pod始终按规定副本数量保持活动 statefulset没说清楚 https://blog.csdn.net/nickDaDa/article/details/90401635 RC、RS、deployment主要提供无状态服务的部署，其pod的名字也都是随机生成的，一个pod挂了随意重建一个就好，pod的名字、在哪个node启动都无所谓，只要保证pod总数即可。 而stateful用来控制有状态服务，每一个pod的名字是预先定义好的，不能更改； 无状态的pod一般不会挂载存储、保证pod共享状态即可，可以随意创建，删除； 有状态的pod，pod都会单独挂在一个存储，如果pod出了问题，其他节点要重新创建pod，并且获取原有pod的存储信息，继续提供有状态服务。 这个特性明显就是提供给数据库使用。 8.k8s中headless service 没说对 https://support.huaweicloud.com/basics-cce/kubernetes_0024.html#kubernetes_0024__section10301171915541 Service解决了Pod的内外部访问问题，允许客户端连接到Service关联的某个Pod。但还有下面这些问题没解决。 同时访问所有Pod 一个Service内部的Pod互相访问 为了解决以上问题，Kubernetes提供了另一种较为特殊的Service类型，称为Headless Service。对于其他Service来说，客户端在访问服务时，DNS查询时只会返回Service的ClusterIP地址，具体访问到哪个Pod是由集群转发规则（IPVS或iptables）决定的。而Headless Service并不会分配单独的ClusterIP，在进行DNS查询时会返回所有Pod的DNS记录，这样就可查询到每个Pod的IP地址。StatefulSet中StatefulSet正是使用Headless Service解决Pod间互相访问的问题。 9.k8s nginx ingress动态转入机制的原理 没回答上来 igress controller通过和kubernetes api交互，动态的去感知集群中ingress规则变化， 然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段nginx配置， 再写到nginx-ingress-controller的pod里，这个Ingress controller的pod里运行着一个Nginx服务，控制器会把生成的nginx配置写入/etc/nginx.conf文件中， 然后reload一下使配置生效。以此达到域名分配置和动态更新的问题。 10.k8s探针liveness probe Readiness Probe的区别 liveness probe回答了用来检测容器内的应用程序是否正常工作 Readiness Probe，能让你确认应用可访问，只有探针通过后，k8s才将流量转发给pod。 11.k8s operator模式的调度逻辑 不清楚 https://cloud.tencent.com/developer/article/1793656 12.容器内服务会出现僵尸进程，如何构建镜像保证服务稳定 回答了容器内使用脚本检测僵尸进程完成服务重启，属于胖容器 瘦容器不清楚 用docker启动容器的时候加--init参数，容器就强制使用tini作为init进程了。tini的主进程里，就是不断在调用带WNOHANG 参数的 waitpid()，通过这个方式清理容器中所有的僵尸进程。 https://www.coder.work/article/41087 https://blog.csdn.net/Ffffatass/article/details/119329671 https://blog.csdn.net/justsomebody126/article/details/106686391 胖容器 https://blog.csdn.net/whatday/article/details/104136271 13.docker镜像多阶段构建使用的场景 回答了减少镜像体积 调整构建步骤 没说对 多个 FROM 指令并不是为了生成多根的层关系，最后生成的镜像，仍以最后一条 FROM 为准，之前的 FROM 会被抛弃，那么之前的FROM 又有什么意义呢？ 每一条 FROM 指令都是一个构建阶段，多条 FROM 就是多阶段构建，虽然最后生成的镜像只能是最后一个阶段的结果，但是，能够将前置阶段中的文件拷贝到后边的阶段中，这就是多阶段构建的最大意义。 最大的使用场景是将编译环境和运行环境分离 https://blog.csdn.net/weixin_42852772/article/details/82013418 https://blog.csdn.net/qq_43762191/article/details/125589205?utm_medium=distribute.pc_relevant.none-task-blog-2~default~baidujs_baidulandingword~default-8-125589205-blog-82013418.pc_relevant_aa2&spm=1001.2101.3001.4242.5&utm_relevant_index=11 14.mysql恢复到任意时间节点的方法 全量备份加基于GTID的binlog日志的增量备份 什么情况操作的 误删了数据表 15.安全方面的习惯 服务器禁止root登陆，内网限制ip访问服务器 16.是否参加了等保评测，业务合规性评测 无 17.使用过python脚本 shell使用的较多，python使用的较少 18.在校时是否接触过程序设计，web开发之类的 无，说的负责过网络方面的 19.之前遇到的问题，通过什么方式解决的 linux系统存储空间df 显示的已使用磁盘占用率比du 统计出来的结果要大很多， lsof |grep deleted 查看了有进程在使用被删除文件，df -i发现inode资源消耗过多，停止相关进程释放空间，或者echo > xxx 使用清空代替删除操作，直接释放inode资源 https://blog.csdn.net/weixin_34111790/article/details/93108530