以前面试重来不做笔记,每次都在网上搜题,毕竟不是自己总结的,记录下遇到面试遇到与以及感觉可能会问到的问题

一, mysql

1 备份

1.1 mysql 5.5

不支持事务 id

备份磁盘,binlog server,XtraBackup 备份,8.0 之前 mysql 默认库所表都是 MyISAM 引擎的表之前版尽量不使用,因为会出现锁表
问题: 主从切换后 binlog server 无法继续使用,因为每个节点的 binlog 位置不一样,还原数据需要新建个实例对比新切换的 master 节点数据进行还原

1.2 mysql 5.6

支持事务 id,通过事务 id 同步备份: 备份磁盘,binlog server,XtraBackup 备份,8.0 之前 mysql user 表是 MyISAM 引擎的表,能会出现锁表问题: 主从切换后 binlog server 可以继续使用,因为事务 id 是一样的,可以写脚本实现自动切换 master 节点,这里我们借鉴 Orchestrator 自己研发的 mysql 管理工具

1.3 mysql 5.7

支持事务 id,组提交

备份磁盘,binlog server,XtraBackup 备份,8.0 之前 mysql user 表是 MyISAM 引擎的表,可能会出现锁表问题: 主从切换后 binlog server 可以继续使用,因为事务 id 是一样的,可以写脚本实现自动切换 master 节点,这里我们借鉴 Orchestrator 自己研发的 mysql 管理工具

2 主从

2.1 mysql 5.5

通过 binlog 位置同步,单线程,延迟较大,备份 master 增加读负担,备份 slave 数据不全,所以选择备份 master 磁盘

2.2 mysql 5.6

事务 id 同步,库级别线程,延迟比较大,

2.3 mysql 5.7

事务 id 同步,支持组提交,表或者行级别线程,延迟较低

3 XtraBackup 锁表解决方案:

3.1 设置超时时间

中断正常长查询

3.2 kill 其他阻塞线程

这种方式对堵塞 SQL 影响很大，会强制 kill 掉，对业务会有一定的影响

3.3 暂停复制进程来防止阻塞

加大主从的延迟,关闭从库 binlog 的顺序提交,生产环境

二, redis

1 使用场景

  • 哨兵模式: 遇到读瓶颈,增加 slave 节点分担读请求

  • 集群模式, 遇到写瓶颈,单节点无法除了大并发写请求

2 读 timeout

先看监控,key 数量是不是太多,或者查询并发量比较大,再或者是不是中间网络问题.

然后手动用命令行查下,如果慢,资源使用也正常,网络也没问题,可能 redis 配置有问题,比如惰性释放,多线程之类的配置

三, Kubernetes

1 PVC 挂载

  • create 阶段，主要是创建存储；
  • attach 阶段，就是将那块存储挂载到 node 上面(通常为将存储 load 到 node 的/dev 下面)；
  • 第三个 mount 阶段，将对应的存储进一步挂载到 pod 可以使用的路径。

2 容器生命周期

  • 第一种是通过 bind 的方式，直接将宿主机的目录直接挂载到容器内；这种方式比较简单，但是会带来运维成本，因为其依赖于宿主机的目录，需要对于所有的宿主机进行统一管理。

  • 第二种是将目录管理交给运行引擎。

moby 是目前最流行的容器管理引擎，moby daemon 会对上提供有关于容器、镜像、网络以及 Volume 的管理。moby daemon 所依赖的最重要的组件就是 containerd

3 Pod 服务质量 (QoS) 配置

根据 CPU 对容器内存资源的需求，我们对 pod 的服务质量进行一个分类，有三种

  • Guaranteed ：pod 里面每个容器都必须有内存和 CPU 的 request 以及 limit 的一个声明，且 request 和 limit 必须是一样的，这就是 Guaranteed；

  • Burstable：Burstable 至少有一个容器存在内存和 CPU 的一个 request；

  • BestEffort：只要不是 Guaranteed 和 Burstable，那就是 BestEffort。

节点上 memory 配额资源不足，kubelet 会把一些低优先级的，或者说服务质量要求不高的（如：BestEffort、Burstable）pod 驱逐掉。它们是按照先去除 BestEffort，再去除 Burstable 的一个顺序来驱逐 pod 的。

4 探针类型

  • 启动探针: 有的 pod 启动时间过长,防止其他两种探针误测使用

  • 就绪探针: 是否能对外提供服务

  • 存活探针: 定时检测服务是否正常

5 监控

5.1 资源监控

CPU、内存、网络这种资源类的一个指标，通常这些指标会以数值、百分比的单位进行统计。

5.2 性能监控

性能监控指的就是 APM 监控，也就是说常见的一些应用性能类的监控指标的检查。像 jvm 里面的 GC 的次数。

5.3 安全监控

安全监控主要是对安全进行的一系列的监控策略，类似像越权管理、安全漏洞扫描等等。(这个我们用的不多)

5.4 事件监控

最典型的就是监控 pod 重启

6 etcd

6.1 查询原理

第一个 tree，维护着 revision 到 value 的映射关系。也就是说当指定 revision 查询数据的时候，就可以通过该 tree 直接返回数据。
第二个 tree。它管理着 key 到 revision 的映射关系。当需要查询 Key 对应数据的时候，会通过刚才说的 tree，将 key 翻译成 revision。再通过 revision 获取到对应的 value。至此就能满足客户端不同的查询场景了。

类似 mysql 水平分表,单表的数据量得以减少，提高性能

7 pod 生命周期

Pending：API Server 已经创建该 Pod，且 Pod 内还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程。
Running：Pod 内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状态。
Succeeded：Pod 内所有容器均成功执行退出，且不会重启。
Failed：Pod 内所有容器均已退出，但至少有一个容器退出为失败状态。
Unknown：由于某种原因无法获取该 Pod 状态，可能由于网络通信不畅导致。

四, 其他

1 服务时不时报 400

正常情况服务要么一直 400,要么不报,可能多节点,其中一个节点故障

2 磁盘 io 过高排查

这个我回答偷懒了

看监控,影响磁盘 io 方面太多,通过命令排查太慢,监控可以看看是不是网络流量比较大导致的 io 过高,或者开启了交换分区,内存满了