分享一些近期运维面试过程中实际遇到的真题，希望能够帮到正在面试的朋友。所有回答均为作者手工整理，难免有误，仅供参考！欢迎批评指正！
从0到1负责一个运维项目，你需要做哪些步骤
-
创建阿里云主账号+多个RAM子账号，用于给项目的成员分配最小的权限。
-
预估该项目的峰值QPS、DAU等指标，决定节点服务器的配置、规模大小。
-
在阿里云ACK上购买三套ACK集群，分别用作测试环境、预发布环境、生产环境。
-
创建VPC，给每套环境划分不同的子网，设定好安全组，同时将集群节点接入堡垒机、云防火墙等设备，做好安全防护。
-
启用ACK集群的插件，包括Terway、Logtail、Prometheus Operator、Ingress-nginx等
-
配置好ACK集群的数据库和存储，包括RDS MySQL、Redis、OSS、阿里云盘等。并配置好不同存储组件的备份方式，比如RDS设置自动全量+binlog备份，Redis设置每秒AOF+每日RDB，PVC采用Snapshot Controller备份，ACK集群的etcd每周进行一次备份。每季度对测试环境进行备份恢复演练。
-
搭建好容器镜像仓库（ACR），搭建好CICD流水线，以及确定好不同环境的发布策略：测试环境采用滚动更新的方式，预发布环境和生产环境采用灰度发布的策略（20% → 50% → 100%）
-
搭建好可观测体系，包括prometheus监控节点指标，loki+SLS收集程序运行日志，ARMS Trace监控链路，Prometheus结合Alertmanager接入钉钉、企微等，实现告警。
-
应用上线：代码合并 → 镜像推送 → 测试环境部署 → 预发布环境部署 → 生产环境部署
-
日常运维：每周巡检、每周容量复盘、故障演练、变更管理
当拿到一个新服务器时，如何对它的性能进行优化？
首先，需要确定新服务器的基本信息（包括系统信息、cpu、磁盘、内存规格，还包括网卡、带宽情况），对新服务器进行一些常规的优化，然后再确定服务器的用途，根据服务器的用途（web服务器？数据库服务器？还是k8s节点？），作特定的优化：
-
常规的初始化步骤：修改主机名、用户提示符格式等，创建普通账户，创建分区 - 格式化文件系统 - 挂载分区，安装好基础依赖（jdk、htop、vim、tcpdump、telnet等），准备好容器环境（docker），部署好监控agent（比如zabbix_agent、prometheus node exporter），接入跳板机管理（给相应的研发人员分配好权限）
-
性能上优化的选项：关闭不必要开启自启的程序，比如firewalld、NetworkManager等，关闭Selinux。
-
K8s节点的特定优化：关闭swap分区、关闭selinux和防火墙、安装好容器运行时（docker 或者 containerd）、安装好CNI所需要的模块（overlay、br_netfilter），安装好k8s必要的组件（kubeadm、kubelet、kubectl），替换好国内的k8s镜像源
生产环境中有一张很大的表，需要给它添加一个字段，并且要保证不影响业务的正常运行，该怎么实现？
在不能使用工具的时候，最保守的方案是采用双表操作：先创建一个带有新字段的新表结构，然后将旧表的数据慢慢迁移至新表中，并且同步增量的数据，增量同步完成后，将业务切换到新表上，并对旧表进行重命名备份。
如果需要添加的字段允许NULL或者带默认值的话，且不采用双表的方式来操作的话，可以借助MySQL 8.0+的新特性，进行瞬时变更，这样不会造成线上的锁表。
ALTER TABLE big_table ADD COLUMN extra_info JSON NULL;
以上语句几毫秒即能执行完成，不会锁表、不会拷贝数据，可以在生产环境中使用。
使用Nodeport将pod的端口暴露给外部访问，和直接将pod中容器的端口通过宿主机映射给外部访问，这两者有什么区别？
Nodeport，可以负载多个pod，适合大规模业务的端口暴露，host映射只能暴露一个pod给外部访问，适合小规模的测试访问，如果在正式项目中全都使用host映射的方式来暴露服务，会导致常用的端口不够使用，后期造成端口冲突。
K8s的Service中，传统类型的Service和Headless类型的Service 有什么区别
传统类型的Service会创建一个负载均衡集群，用来代理所有的pod， Headless service没有负载均衡集群虚拟ip，直接暴露所有pod的ip，将所有pod的ip解析至各自pod的域名上，大多数无状态应用由于不需要知道每个pod的ip，因此采用传统的Service来暴露访问，只需要代理到每个pod就好；大多数有状态应用（statefulset，比如kafka、zookeeper），由于需要发现每个pod，需要知道每个pod的ip，因此采用headless service来进行暴露。
你在运维工作中具体怎么做巡检？
巡检的内容主要包括以下几个方面：
-
主机层面的巡检：
-
检查CPU、内存、负载是否过高，是否存在持续升高的风险
-
检查磁盘、inode使用率是否接近80%，是否需要扩容
-
检查网络延迟与连接数，是否存在异常丢包情况
-
检查是否有异常监听端口、是否有暴露的风险
-
检查日志大小，防止日志无限制的增长占满磁盘
-
服务类进程巡检：
-
检查负载均衡后端连接的健康状况
-
检查Redis的主从同步状态、内存占用情况、持久化状态
-
检查MySQL的连接数、慢查询情况、主从同步情况以及磁盘IO情况
-
检查Prometheus是否正常抓取、告警是否正常触发
-
检查K8s集群的节点健康状况、Pod状况、资源分配情况
-
K8s集群检查：检查节点的状态、Pod的状态是否健康，检查HPA扩缩容是否生效，ConfigMap/Secret是否正常加载，PV/PVC是否绑定成功，Ingress路由是否配置生效，是否存在Event异常（镜像拉取失败、探针探测失败等）
-
网络安全巡检：检查安全组、防火墙规则配置，检查SSL证书状态
-
检查告警和日志系统是否正常：检查监控和日志是否正常采集、告警是否正常推送
巡检的方式：Ansible + Shell脚本 + crontab实现自动化巡检，用Prometheus设定关键巡检指标的异常告警，将巡检结果写入告警群通知机器人，巡检的结果形成规范文档并存档在wiki空间中记录。
K8s集群内的Prometheus怎么做高可用
在K8s集群内，不同的节点上部署两个不同的Prometheus实例，两个实例同时抓取相同的metrics targets，使用不同的external_labels来区分两个prometheus实例，其中一个实例作为主告警节点，另一个实例仅作为抓取metrics的备份节点。Alertmanager和Grafana分别配置多个源，支持主备切换。
灰度发布的过程怎么控制流量分发到具体的用户上？
识别来自指定用户的请求，并将他们分发到新版本的服务上（流量识别+路由转发机制）。
最常用的一种方式是基于用户标识进行流量控制，根据请求中用户携带的特定标识（user_id），对请求来源进行规则匹配，并把请求头中带X-User-Group: gray的用户路由到灰度版本的应用。
但我们在实际项目中往往基于用户ID Hash做随机灰度，对user_id做hash，user_id % 100，小于N的请求被分发到灰度应用，其他请求走稳定版应用，用于渐进式调控灰度比例时来调控具体的流量请求分发到具体的用户上。
还可以基于IP来源，比如匹配特定来源的$remote_addr，将特定ip来源的请求转发到灰度应用上，从而实现灰度发布过程中的流量控制。
负载均衡产品有哪些？相比于其他负载均衡产品，ALB的优势在哪？什么场景下需要使用ALB？
常见的负载均衡产品包括各个云厂商的LB，比如阿里云SLB、ALB、CLB，腾讯云的ALB、CLB；还包括一些支持负载均衡的软件，比如Nginx、HAProxy、Traefik、Apisix、Envoy；还包括一些支持负载均衡的硬件，比如F5、A10。
相比于其他负载均衡产品，ALB的优势主要适用于七层应用负载均衡，可以接入WAF，日志可以投递到SLS，后端可以和ACK集成，实现Kubernetes Ingress的七层转发能力，也可以根据健康检查的状态自动调整后端目标实例等。
一般在多个服务共用同一个公网入口的场景下、业务请求存在灰度切流需求的情况下，以及需要接入多个https证书的情况下，使用ALB。
不同云厂商之间的云产品有什么区别？比如阿里云的ALB和腾讯云的ALB有什么区别？
不同云厂商之间相同类型的云产品本质区别并不大，比如阿里云的ALB和腾讯云的ALB，本质上都是用来进行七层负载均衡。
但是阿里云的ALB与阿里的其他云产品（比如ACK、阿里云证书服务等）的集成性更好，腾讯云的ALB与腾讯云自身其他的云产品（比如TKE集群、腾讯云SSL证书）的集成性更好。此外，阿里云SLB的推出时间更早。
建议部署在ACK集群中的业务使用阿里云SLB更好，而部署在TKE集群中的业务使用腾讯云SLB更好。
Pod的QoS是什么？
Pod的QoS，全称Quality of Service，是指Pod的服务质量，根据资源限制情况，分为三个等级：burstable、besteffort、guaranteed，分别代表了Pod被驱逐的不同程度：
-
BestEffort，尽力的，pod中不写入resources，不设limits和requests值的限制，这种服务质量的pod会尽可能多地占用worker节点上的cpu和内存资源。在节点资源不足时，优先被驱逐。
-
Burstable，不稳定的，limits的值 和 requests的值不相等（requests<limits），这种服务质量的pod在使用worker节点的资源时有最大值和最小值的限制。在节点资源不足时，其次被驱逐。
-
Guaranteed，保证的，limits的值和requests的值相等（requests=limits），这种服务质量的pod所使用的worker节点的资源量为一个固定值，有保证。在节点资源不足时，最后被驱逐。
负载均衡负载的是什么？负载的是请求数、连接数还是其他？
负载均衡根据所处的协议层不同，负载的单位不同：
-
四层负载均衡，负载的是连接数（connections）
-
七层负载均衡，负载的是请求数（requests）
负载均衡的方式有哪些？
按照调度算法来分类，负载均衡的方式包括如下几类：
-
轮询：将请求轮流分发到后端的服务器
-
加权轮询：根据权重，将请求轮流分配到后端的服务器
-
最少连接数：优先将请求分配给后端连接数最少的服务器
-
源地址哈希：根据客户端的ip地址固定将请求分配给后端服务器
-
一致性哈希：将请求分发到后端的一组服务器上
-
响应时间最短：动态监测，将请求分发给后端响应最快的服务器
测试环境和生产环境怎么做隔离？
-
首先在网络上进行隔离，为测试环境和生产环境创建不同的vpc，互相不路由，并且将test环境和prod环境部署在不同的k8s集群中，不同环境之间的节点完全分离。
-
CICD流程上做好隔离：test和prod环境建立不同的流水线。
-
做好权限隔离：设置不同的ServiceAccount，对不同的环境配置不同的权限，普通开发人员只对test环境有权限，运维人员对prod环境有权限。
-
监控和告警做好隔离：test环境和prod环境运行各自的prometheus/grafana，prod环境的告警直接发送到值班群，test环境的告警发送邮件和低告警等级群。
pod的创建过程
-
用户使用kubectl命令提交pod创建申请，此时pod的状态为pending
-
api-server进行权限校验，并将创建pod的信息存储到etcd
-
scheduler为即将创建的pod选择最适合的node节点
-
在目标节点上的kubelet调用CRI，进而进行拉取镜像、创建容器、挂载volume等操作，此时pod的状态变为running，pod被成功调度运行
pod启动失败有哪些原因，该怎么排查？
pod启动失败，常见的状态包括pending、CrashLoopBackOff、ImagePullBackOff、Error等。
可能原因：
-
pod可能会因为节点资源调度失败而启动失败，如果节点cpu、内存资源不足，或者pod自身设置了不合理的
requests值，或者由于nodeSelector、affinity、taint等限制造成了pod无法调度，都可以造成pod的启动失败，这种情况下，pod的状态呈现为pending。可以适当地释放节点的资源、扩容节点，或者调整pod的requests值，或者放宽调度条件，来解决pod因为无法调度而无法启动的问题。 -
pod还可能会因为镜像拉取失败而启动失败，这种情况下pod的状态为
ImagePullBackOff，可以检查一下yaml文件中的镜像名、tag标签写入得是否正确，还需要确定一下当前节点能否访问到镜像仓库地址。 -
pod中的容器启动命令出错，或者程序本身有错，会造成pod的启动失败，有可能当前pod缺少环境变量的配置，也有可能挂载的配置文件失效，还有可能数据库、redis等依赖服务未就绪，这种情况下pod会呈现
CrashLoopBackOff状态。可以检查一下镜像dockerfile内的启动脚本，检查configMap、Secret是否被挂载，检查依赖服务是否正常启动。 -
还有可能由于探针的探测失败，而造成pod的启动失败，这种情况下，pod的状态可能会呈现为
CrashLoopBackOff或者为频繁重启的Running。可以通过延长启动探针的初始延迟时间initialDelaySeconds，或者临时关闭探针进行验证。 -
如果卷挂载失败，比如pvc没有绑定成功、StorageClass名称不一致、后端的nfs/iscsi等服务没有正常运行，也会造成pod启动失败，这种情况下pod的状态为
ContainerCreating。可以检查后端的存储类服务是否运行正常，检查pvc的状态是否为bound，检查StorageClass的名称是否一致来避免pod由于卷挂载失败从而启动失败。 -
还有可能由于pod没有权限访问挂载目录而启动失败，这种情况下pod的状态为
Error。可以检查一下ServiceAccount的权限。
排查过程：
kuebctl get pod -n <ns> -o wide #查看当前pod的状态
kubectl describe pod <pod_name> #查看pod启动过程中具体的events
kubectl logs <pod_name> #查看pod运行过程中具体的日志
kubectl get pvc -n <ns> #查看pvc的状态
kubectl describe pvc <pvc_name> #查看pvc启动过程中具体的events
ping <镜像仓库地址>
Redis的高可用怎么实现？
Redis常用的高可用方式有两种，包括【哨兵模式】和【集群模式】：
-
在哨兵模式中，搭建一主二从的架构，每个节点配置上对应的哨兵进行监测节点是否存活，一旦主节点宕机，某一个从节点会主动提升为新的主节点。
-
在集群模式中，数据被拆分为16384个哈希槽，搭建3个分片，每个分片包含一主一从两个节点，可以实现数据的分布式存储和故障的自动切换。
K8s中常用的组件以及各个组件的作用
k8s分为master节点和worker节点：
master节点上的组件包括api-server、etcd、scheduler、controller-manager：
-
api-server：用于对外部的访问请求进行认证、鉴权、准入控制，同时可以连接其他组件，充当k8s的核心组件。
-
etcd：用于存储k8s集群中的数据。
-
scheduler：负责将即将创建好的pod调度至指定的节点上去。
-
controller-manager：负责调控pod实际运行的状态和用户期望的状态一致。
worker节点的组件包括kubelet、kube-proxy、container-runtime：
-
kubelet：定期向master节点的api-server汇报worker节点的状态，同时负责调用container-runtime
-
container-runtime：实际运行容器的组件
-
kube-proxy：主要负责控制外部流量向内部pod的访问规则，通过调控当前节点上的iptables或者lvs规则，从而实现对pod的访问规则的控制。
K8s中使用deployment来部署容器 和 在docker中手动启动一个容器有什么区别？
区别一：容器的启动方式不一样
-
docker启动的容器需要手动执行
docker run命令； -
而在k8s中，则是需要通过声明一个yaml文件后，再通过
kubectl apply命令来启动一个容器来启动容器。
区别二：容器的运行方式不一样
-
docker启动的容器只能运行在当前的节点上，不能调度至别的节点，不能够自动扩缩容，也不能自动恢复；
-
但是使用k8s的deployment部署的容器，可以在k8s集群内的多个节点之间进行调度，具体一定数量的副本，并且可以实现自动扩缩容和宕机自动恢复。
K8s中暴露一个pod使其被外部访问的方式有哪几种？
将pod暴露给外部访问的常见方式包括NodePort、LoadBalancer、Ingress：
-
可以部署Nodeport类型的Service，将pod的端口映射到pod所在节点的一个端口，从而使得能够在外部通过节点端口来访问内部的pod。
-
可以选择向云厂商申请一个LoadBalancer，将流量转发到内部的pod上。
-
通过Ingress配置流量转发规则，从而将流量转发到内部的Service，再转发到后端的Pod。
nacos怎么进行监控？
nacos的监控指标包括系统指标监控（CPU、内存、GC等），服务状态监控（实例数量、上下线、心跳异常等），可用性监测（探针、端口、心跳），日志监控（错误日志、异常堆栈、超时等）
-
使用prometheus+jmx exporter对nacos的系统指标、服务状态进行监控
-
调用nacos自带的接口，对nacos的节点状态状态、服务状态进行监控：
curl http://<nacos-host>:8848/nacos/v1/core/cluster/nodes
curl http://<nacos-host>:8848/nacos/v1/ns/catalog/services?pageNo=1&pageSize=10
-
结合ELK或者Loki对nacos的日志进行监控
Redis中的分片和副本的区别
分片（Sharding）- 用于将整个库的数据拆分到多个节点，解决单机存储容量不足的缺点
副本（Replication）- 用于将同一份数据复制到多个节点，主节点挂了可以自动切换，实现高可用
磁盘清理了，但是空间不释放，可能原因，如何排查？
可能原因：所删除的文件正被某个进程所占用，因此空间并不会真正的释放，进程没有关闭前，所占用的文件仍在磁盘中，直到进程关闭后，所占用的空间才会释放。
排查步骤：
-
首先使用
df -h，查看哪一个挂载点的空间满了 -
找出已被删除，但是仍被进程占用的文件：
lsof | grep deleted
-
确认进程后，终止相应的进程：
kill <pid>
收到告警，磁盘占用率达到98%，但是进入容器中查看，却只看到几k的文件大小，这种情况下该怎么排查是哪些文件让服务器磁盘占用升高？
容器只能看到容器内的文件，看不到宿主机的所有文件，可以在容器在宿主机上所挂载的目录下，使用du -sh * | sort -hr来查看是哪些文件占用率升高，有可能是容器日志占用大，在确认不影响生产的情况下，可以清理一下容器日志，也可以清理不使用的容器镜像：
docker system prune -a
JVM怎么优化？
-
调整堆内存大小，调整
-Xms和-Xmx的值的大小 -
将JVM的日志打印到
/dev/null中，节省磁盘空间
https安全的原理？
https在http的基础上添加了ssl证书，使得明文传输变成了加密传输。
浏览器访问一个https网站后，网站服务器会返回SSL证书给浏览器，这个SSL证书包含网站的公钥以及身份信息，浏览器收到SSL证书后，会验证这个证书是否由"受信任的证书颁发机构（CA）"签发，从而验证这个证书的有效性。
浏览器在验证了服务器身份的有效性后，会和服务器之间通过一系列加密算法，比如RSA或者ECC，协商出一个只有浏览器和服务器之间知道的【对称密钥】，接下来浏览器和服务器之间的所有数据传输都会使用这个对称密钥进行加密和解密，在这种情况下即使第三方获取到了数据，由于没有对称密钥，也无法获取数据的真正内容。
阿里云的OSS需要做哪些优化？
-
配置域名加速+CDN，减少延迟、降低回源频率
-
开启分片上传、断点续传
-
设置bucket的生命周期，实现自动删除过期的文件，并且可以自动转存不同的存储类型，也就是将不同数据的读写访问频率，将其归类到不同的存储类型中去，比如标准存储、低频存储、归档存储、冷归档，从而降低成本
-
关闭公共读写，避免被恶意爬虫
-
控制RAM子账号对OSS的读写权限
-
开启OSS的日志审计功能，便于排查问题、安全审计
阿里云的cdn配置好后，需要做哪些优化？
-
进行缓存优化：设置合理的缓存时间，对图片视频等静态资源，缓存时间调整为30天，对动态数据接口，不缓存，同时开启range请求回源支持
-
域名和https优化，添加证书，确保安全
-
配置多源站轮询，防止单个源站崩溃导致访问失败
-
开启智能压缩，对文本类资源开启自动压缩，从而节省流量、加速传输
配置好cdn后，在异地第一次访问目标站点和在本地访问目标站点，哪一个更快？
取决于cdn站点是否已缓存资源，第一次异地访问，cdn缓存没有命中，访问速度不如在本地访问快，但是一旦cdn站点缓存了目标站点的资源，用户再次访问时，就会直接命中cdn站点的缓存资源，访问速度相关本地访问来说会更快。
阿里云cdn需要配置哪些内容
-
添加加速域名
-
配置源站信息
-
配置缓存规则
-
配置https
阿里云cdn的主要模式
-
网页加速
-
图片小文件加速
-
视频点播加速
-
大文件下载加速
-
全站加速
-
基于WAF的加速
python的装饰器是什么？
装饰器本质上是一个函数，可以实现在不修改原函数代码的情况下，为其增加额外的功能，可以用来接收函数作为参数，并返回一个增强版的函数。
k8s集群中api-server响应慢，是什么原因，该怎么排查？
可能原因：
-
k8s集群内网络不稳定，网络插件有问题
-
QPS过高，短时间内请求量暴增
-
etcd性能瓶颈，写入延迟、IO饱和
-
内存、CPU压力，api-server的pod资源占用打满，cpu占用过高，频繁OOM
-
controller manager、kubelet和api-server之间掉线
-
webhook阻塞
-
鉴权系统慢，RBAC、认证耗时
排查思路：
-
首先在prometheus中查看api-server的延迟指标，查看是否有特定的资源延迟过高：
histogram_quantile(0.99, rate(apiserver_request_duration_seconds_bucket[5m]))
-
检查是否有流量异常（请求过大）：
kubectl top pod -n kube-system
kubeclt logs -n kube-system <api-server-pod> | grep "Slow"
如果流量请求过大，可以添加qps限制 3. 查看etcd的状态，关注etcd是否存在IO性能差等问题：
ETCDCTL_API=3 etcdctl --endpoints=... endpoint status --write-out=table
ETCDCTL_API=3 etcdctl --endpoints=... endpoint health
可以考虑将etcd部署在高性能磁盘上 4. 查看api-server的pod是否资源占用过高：
kubectl top pod -n kube-system
kubectl exec -n kube-system <api-server-pod> -c kube-apiserver -- top
-
检查webhook是否阻塞：
kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io
有些自建的webhook服务异常会卡住api-server，可以临时禁用webhook组件，观察api-server延迟是否恢复正常。 6. 使用ping或者curl命令测试etcd和api-server之间的网络是否存在抖动。 7. 建议给kube-apiserver开启--audit-log-path日志，以追踪慢请求的来源。
k8s集群中部署了LoadBalancer类型的Service，用户访问pod的链路是什么
用户 → LoadBalancer → node节点 → kube-proxy → pod
有一个业务部署在k8s集群中，用户在登录时，刷新了一下就自动退出登录了，可能是什么原因，怎么排查？
用户登录后，刷新了一下又退出登录了，说明用户登录的认证信息（token、cookie、session等）失效。
可能原因：
-
用户的请求没有落到同一个pod，导致session丢失
-
认证信息的存储机制存在问题，比如用户的登录状态保存在内存中，那么pod切换后则会丢失
-
ingress-controller没有启用会话保持策略
-
redis session存储丢失，后端使用redis保存session，但是没有持久化连接
排查思路：
-
首先，确认认证信息的存储机制，登录状态是保存在redis、数据库还是内存中，如果保存在内存中，一旦pod发生切换，登录状态必然发生切换，可以改为redis存储认证信息。
-
检查ingress controller有没有开启会话保持 如果使用的是nginx ingress controller，建议开启以下选项进行长时间会话保持：
nginx.ingress.kubernetes.io/affinity-mode: "persistent"
或者开启粘性会话：
nginx.ingress.kubernetes.io/affinity: cookie
如果使用的是阿里云SLB，则需要开启会话保持功能，建议开启30min以上。 3. 排查pod数量和负载均衡的问题，如果存在多个pod，轮询到不同的pod上，导致session不一致，从而可能导致用户的认证信息失效，可以把pod的副本数改为1，再看看是否还存在登录后又退出的现象：
kubectl scale deploy <deployment_name> --replicas=1
-
调试浏览器的网络请求，打开开发者工具，查看请求中cookies是否带有登录信息，查看刷新后是否会清除cookies，查看cookie的使用域、过期时间、SameSite是否合理
在传统的应用部署体系中（非k8s集群），如何使用cicd，实现应用的发版更新？
开发提交代码 → 编译代码，构建jar包 → 推送至oss存储 → 拉取jar包 → 备份旧版本jar包 → 停止旧版本应用 → 启动新版本应用
Jenkins怎么和k8s进行交互
Jenkins和k8s集群交互的场景：
Jenkins构建镜像 → 推送至镜像仓库 → 自动部署到k8s集群中，Jenkins管理k8s集群中的job、deployment等资源的更新。
Jenkins与k8s的交互方式：
分两种情况：一种是jenkins部署在k8s集群外部，jenkins通过kubectl的方式与k8s进行交互；另一种是jenkins部署在k8s集群内部，通过jenkins pod自身与k8s进行交互。
-
如果jenkins部署在k8s集群外部，需要在jenkins所在机器上配置好
kubectl以及kubeconfig文件，在kubeconfig文件~/.kube/config中配置好指向k8s集群的环境变量，并在jenkinsfile中调用kubectl命令，从而与k8s集群进行交互：
yum -y install kuebctl
pipeline {
agent any
stages {
stage('Deploy to K8s') {
steps {
sh 'kubectl apply -f deployment.yaml'
}
}
}
}
-
如果jenkins部署在k8s集群内部，需要给jenkins安装上kubernetes插件，配置好jenkins连接k8s集群的api地址，配置好ServiceAccount给jenkins pod授予权限，并配置好jenkins调用k8s集群所管理的pod模版：
helm repo add jenkins https://charts.jenkins.io
helm install jenkins jenkins/jenkins -n jenkins --create-namespace
pipeline {
agent {
kubernetes {
label 'mypod'
defaultContainer 'jnlp'
yaml """
apiVersion: v1
kind: Pod
spec:
containers:
- name: build
image: maven:3.6.3-jdk-8
command:
- cat
tty: true
"""
}
}
stages {
stage('Build') {
steps {
container('build') {
sh 'mvn clean package'
}
}
}
}
}
阿里云的vpc怎么配置规划？
-
首先，先创建一个vpc网络，选择好一个CIDR网段，比如
10.0.0.0/16、192.168.0.0/16，便于用来划分子网。 -
接下来，划分子网，根据可用区来划分子网（交换机）
-
配置路由表，配置NAT网关、VPN网关等路由出口
-
配置网络ACL（安全组）规则，web层只放行80/443，DB层只允许内网访问，ssh只允许跳板机ip
如果不同vpc之间需要连通，可以配置vpc对等连接
k8s集群如何实现高可用？
如果集群部署在阿里云的ACK上，可以直接购买高可用集群；
如果是使用kubeadm手动搭建的k8s集群，需要使用kubeadm join命令将多个master节点组成集群，从而实现高可用；
其他实现高可用集群的方案：sealos、rancher
mysql和mongodb有什么区别
| mysql | mongoDB |
|---|---|
| 关系型数据库 | 非关系型数据库 |
| 表 | collection |
| 行 | json/bson文档 |
-
mysql是二维表形式的关系型数据库，适用于订单、支付等需要复杂sql查询的业务场景
-
mongodb是文档形式的非关系型数据库，mongodb中的一个文档相当于mysql中的一行记录，mongodb中的collection相当于Mysql中的一个表，mongodb中的文档以json的格式来存储数据。适用于社交平台、用户发贴、文本内容等业务场景。
mysql产生了慢sql，该从哪些方面对慢sql进行优化？
-
避免sql中出现
select *，明确需要查询的字段 -
where条件中筛选的字段应有索引，如果没有索引的需要对其添加索引
-
给
where、join、order by涉及到的列建立联合索引 -
尽量避免用函数包裹字段，比如
where data(create_time)=...会导致索引失效 -
避免使用
OR，尽量使用UNION或者IN
查看某个文件被具体哪个进程占用的命令？
可以使用lsof命令来查看某个文件被具体哪一个进程给占用，比如：
lsof /var/log/nginx/access.log
pod一直处于CrashLoopBackOff状态，可能原因以及排查思路
pod一直处于CrashLoopBackOff状态，说明容器一直重启失败。
可能原因：
-
容器的启动命令写错
-
容器的依赖资源没有准备好
-
容器监听的端口被占用
-
容器探针探测失败
排查思路：
-
可以先用describe命令查看一下pod的状态和事件，再用logs命令查看一下容器启动过程中的日志：
kubectl describe pod <pod_name> -n <namespace>
kuebctl logs <pod_name> -c <container_name> -n <namespace>
-
再检查一下pod的yaml文件，查看一下环境变量、挂载路径、容器的镜像是否有填写错误，还可以查看一下探针的配置是否有错
kubectl get pod <pod_name> -o yaml
pod处于pending状态的可能原因，以及排查思路
pod处于pending状态，说明pod已经创建成功，但还没有被调度至节点上，有可能：
-
节点自身没有就绪，可以使用
kubectl get nodes查看一下节点的状态是否为ready，再使用kubectl describe node <node_name>查看一下未就绪节点的具体状态 -
调度器本身有问题，使用
kubectl get pods -n kube-system检查一下scheduler本身是否运行正常，再查看一下scheduler的日志是否报错 -
有可能节点资源不足（cpu、内存资源不足），导致pod没有合适的节点，从而一直pending
-
pod自身请求的资源量过高，没有相应的节点符合要求，可以检查一下pod的yaml文件中
requests和limits字段 -
节点被打上了taint，且pod没有对应的toleration，从而没有被调度至相应的节点上
-
pod使用了nodeSelector、nodeAffinity等约束，没有匹配到相应的节点
-
pod自身设置了podAntiAffinity，和节点上已有的pod冲突，这种情况下也是排查一下pod的yaml文件，取消反亲和性的设置
-
pod使用了pvc，但是pvc没有和pv绑定成功，这时候可以检查一下pvc的状态是否为pending
zabbix怎么实现自动发现？
-
在"网络发现"中配置扫描的网段和端口
-
设置发现的触发条件（比如响应ICMP ping或者端口开放）
-
添加发现后的动作（添加主机、关联模板、发送通知等）
MySQL怎么设计分库分表？
什么情况下需要进行分库分表？
-
单张表的数据超过1000万行时
-
单张表的QPS超过2000~5000时
-
单个库的连接数达到瓶颈（达到
max_connections规定的值） -
数据增长不可预估，比如订单类、日志类业务
可以采用以下方式进行分库分表：
-
采用哈希取模，对库或表进行拆分：
user_id % 表数量 = 表后缀
以上将user_id表拆分为user_0, user_1, ..., user_15 2. 还可以按时间范围来建表 3. 还可以根据某个自增字段的值来分表，比如将id范围0-1000w的记录放入表A，id范围1000w-2000w的记录放入表B 4. 还可以采用混合策略，比如根据月份将订单分库，再根据用户id hash在一个库中进行分表
Redis缓存失效，怎么排查？
-
首先，需要确认 redis 是否运行正常，排除自身宕机、端口变动、网络不通等问题：
redis-cli ping
redis-cli info server
-
检查 key 命令中率是否正常：
redis-cli info stats | grep hit
（如果命中率大幅下降，意味着缓存失效）
-
检查是否有大量的 key 被删除或者过期：
redis-cli info keyspace
MySQL连接数过多，怎么排查？
-
首先需要快速确认当前连接数的状态：
show status like 'Threads_connectd'; --查看当前连接数
show status like 'Max_used_connections'; --查看历史最大连接数
show variables like 'max_connections'; --查看当前最大连接数设置
-
然后，定位到哪些来源客户端、哪些用户（哪些服务）对当前mysql发起了大量连接：
SELECT host, user, COUNT(*) as connections
FROM information_schema.processlist
GROUP BY host, user
ORDER BY connections DESC;
-
并结合当前mysql的进程状态（重点关注状态为
sleep、query的进程），定位到连接数过多的原因：
show processlist;
-
最后，需要根据不同的原因对连接数过多进行处理：
-
如果是SQL执行太慢，可以考虑优化索引，优化SQL语句
-
如果是sleep连接未断开，可以设置wait_timeout较小
这两年，IT行业面临经济周期波动与AI产业结构调整的双重压力，确实有很多运维与网络工程师因企业缩编或技术迭代而暂时失业。
很多人都在提运维网工失业后就只能去跑滴滴送外卖了，但我想分享的是，对于运维人员来说，即便失业以后仍然有很多副业可以尝试。
运维副业方向
运维，千万不要再错过这些副业机会！
第一个是知识付费类副业：输出经验打造个人IP
在线教育平台讲师
操作路径：在慕课网、极客时间等平台开设《CCNA实战》《Linux运维从入门到精通》等课程，或与培训机构合作录制专题课。
收益模式：课程销售分成、企业内训。
技术博客与公众号运营
操作路径：撰写网络协议解析、故障排查案例、设备评测等深度文章，通过公众号广告、付费专栏及企业合作变现。
收益关键：每周更新2-3篇原创，结合SEO优化与社群运营。
第二个是技术类副业：深耕专业领域变现
企业网络设备配置与优化服务
操作路径：为中小型企业提供路由器、交换机、防火墙等设备的配置调试、性能优化及故障排查服务。可通过本地IT服务公司合作或自建线上接单平台获客。
收益模式：按项目收费或签订年度维护合同。
远程IT基础设施代维
操作路径：通过承接服务器监控、日志分析、备份恢复等远程代维任务。适合熟悉Zabbix、ELK等技术栈的工程师。
收益模式：按工时计费或包月服务。
网络安全顾问与渗透测试
操作路径：利用OWASP Top 10漏洞分析、Nmap/BurpSuite等工具，为企业提供漏洞扫描、渗透测试及安全加固方案。需考取CISP等认证提升资质。
收益模式：单次渗透测试报告收费；长期安全顾问年费。
比如不久前跟我一起聊天的一个粉丝，他自己之前是大四实习的时候做的运维，发现运维7*24小时待命受不了，就准备转网安，学了差不多2个月，然后开始挖漏洞，光是补天的漏洞奖励也有个四五千，他说自己每个月的房租和饭钱就够了。
为什么我会推荐你网安是运维人员的绝佳副业&转型方向?
1.你的经验是巨大优势: 你比任何人都懂系统、网络和架构。漏洞挖掘、内网渗透、应急响应，这些核心安全能力本质上是“攻击视角下的运维”。你的运维背景不是从零开始，而是降维打击。
2.越老越吃香，规避年龄危机: 安全行业极度依赖经验。你的排查思路、风险意识和对复杂系统的理解能力，会随着项目积累而愈发珍贵，真正做到“姜还是老的辣”。
3.职业选择极其灵活: 你可以加入企业成为安全专家，可以兼职“挖洞“获取丰厚奖金，甚至可以成为自由顾问。这种多样性为你提供了前所未有的抗风险能力。
4.市场需求爆发，前景广阔: 在国家级政策的推动下，从一线城市到二三线地区，安全人才缺口正在急剧扩大。现在布局，正是抢占未来先机的黄金时刻。
运维转行学习路线
（一）第一阶段：网络安全筑基
1. 阶段目标
你已经有运维经验了，所以操作系统、网络协议这些你不是零基础。但要学安全，得重新过一遍——只不过这次我们是带着“安全视角”去学。
2. 学习内容
**操作系统强化：**你需要重点学习 Windows、Linux 操作系统安全配置，对比运维工作中常规配置与安全配置的差异，深化系统安全认知（比如说日志审计配置，为应急响应日志分析打基础）。
**网络协议深化：**结合过往网络协议应用经验，聚焦 TCP/IP 协议簇中的安全漏洞及防护机制，如 ARP 欺骗、TCP 三次握手漏洞等（为 SRC 漏扫中协议层漏洞识别铺垫）。
**Web 与数据库基础：**补充 Web 架构、HTTP 协议及 MySQL、SQL Server 等数据库安全相关知识，了解 Web 应用与数据库在网安中的作用。
**编程语言入门：**学习 Python 基础语法，掌握简单脚本编写，为后续 SRC 漏扫自动化脚本开发及应急响应工具使用打基础。
**工具实战：**集中训练抓包工具（Wireshark）、渗透测试工具（Nmap）、漏洞扫描工具（Nessus 基础版）的使用，结合模拟场景练习工具应用（掌握基础扫描逻辑，为 SRC 漏扫工具进阶做准备）。
（二）第二阶段：漏洞挖掘与 SRC 漏扫实战
1. 阶段目标
这阶段是真正开始“动手”了。信息收集、漏洞分析、工具联动，一样不能少。
熟练运用漏洞挖掘及 SRC 漏扫工具，具备独立挖掘常见漏洞及 SRC 平台漏扫实战能力，尝试通过 SRC 挖洞搞钱，不管是低危漏洞还是高危漏洞，先挖到一个。
2. 学习内容
信息收集实战：结合运维中对网络拓扑、设备信息的了解，强化基本信息收集、网络空间搜索引擎（Shodan、ZoomEye）、域名及端口信息收集技巧，针对企业级网络场景开展信息收集练习（为 SRC 漏扫目标筛选提供支撑）。
漏洞原理与分析：深入学习 SQL 注入、CSRF、文件上传等常见漏洞的原理、危害及利用方法，结合运维工作中遇到的类似问题进行关联分析（明确 SRC 漏扫重点漏洞类型）。
工具进阶与 SRC 漏扫应用：
-
系统学习 SQLMap、BurpSuite、AWVS 等工具的高级功能，开展工具联用实战训练；
-
专项学习 SRC 漏扫流程：包括 SRC 平台规则解读（如漏洞提交规范、奖励机制）、漏扫目标范围界定、漏扫策略制定（全量扫描 vs 定向扫描）、漏扫结果验证与复现；
-
实战训练：使用 AWVS+BurpSuite 组合开展 SRC 平台目标漏扫，练习 “扫描 - 验证 - 漏洞报告撰写 - 平台提交” 全流程。
SRC 实战演练：选择合适的 SRC 平台（如补天、CNVD）进行漏洞挖掘与漏扫实战，积累实战经验，尝试获取挖洞收益。
恭喜你，如果学到这里，你基本可以下班搞搞副业创收了，并且具备渗透测试工程师必备的「渗透技巧」、「溯源能力」，让你在黑客盛行的年代别背锅，工作实现升职加薪的同时也能开创副业创收！
如果你想要入坑黑客&网络安全，笔者给大家准备了一份：全网最全的网络安全资料包需要保存下方图片，微信扫码即可前往获取!
因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取