德迩象网机器人 运维实习生一面：URL 渲染链路、子网划分与 K8s 监控

《面试题目》

一面

1. 浏览器输入 URL 到页面展示的完整过程
2. DNS 解析出 IPv4 还是 IPv6？还能解析哪些记录类型？
3. 了解 HTTP/3 吗？
4. 子网掩码含义、可用主机数、判断 IP 归属
5. 同子网内路由行为、跨地域子网如何连通
6. 应急场景：CPU/GPU 100% 如何处理
7. SSH 被攻击后的加固措施
8. K8s 服务与节点健康监控、关键指标
9. 对公网开放时用 Ingress 还是直接暴露 Pod？HTTPS 链路怎么走？
10. 如何搭建持续部署服务？注意什么？
11. 反向提问：公司云平台多还是物理机多？

《参考解析》

1. URL 到页面展示要一次讲全，别漏掉握手与渲染：完整链路是——浏览器解析 URL 并查缓存（浏览器缓存 → 系统缓存 → hosts）→ DNS 解析（先查本地缓存与 hosts，再按递归/迭代问本地 DNS、根、顶级域、权威服务器）→ 拿到 IP 后建立 TCP 连接（三次握手）→ 如果是 HTTPS 再做 TLS 握手（协商版本与套件、验证证书、用非对称加密交换出会话密钥）→ 发送 HTTP 请求，中间可能经过 CDN、负载均衡、反向代理再到后端服务 → 服务端处理并返回 HTML → 浏览器解析 HTML 构建 DOM，遇到 CSS/JS/图片再发起请求，构建 CSSOM 合成渲染树 → 布局、绘制、合成上屏。这题的分水岭在于能否主动补上「TCP 握手、TLS 握手、渲染流水线」这三段，只答 DNS 和发请求会被认为停在表面。

2. DNS 记录类型：A 记录把域名映射到 IPv4，AAAA 映射到 IPv6，所以问「解析出 IPv4 还是 IPv6」的答案是「取决于查询类型和权威记录，两者可以同时存在，客户端按协议栈能力与偏好选择」。其余要能报出名字和用途：CNAME 是别名，把域名指向另一个域名（CDN、第三方托管常用）；MX 指定邮件服务器；TXT 常用于域名所有权验证与 SPF/DKIM 等邮件策略；NS 指定权威服务器；SOA 是区文件的起始授权记录；PTR 是反向解析，从 IP 查域名。漏掉 CNAME/MX/TXT 之外的类型不算错，但把 CNAME 与 A 的区别讲清楚（CNAME 不能再有其他记录、根域名通常不能用 CNAME）是加分点。

3. 子网掩码、可用主机数与同子网/跨地域通信：掩码决定前多少位是网络位、后多少位是主机位，/24 表示前 24 位网络位、主机位 8 位，可用主机数是 2^8 - 2 = 254（减掉网络地址和广播地址）；/25 是从一个 /24 里切出来的两半之一，主机位 7 位，可用主机数 2^7 - 2 = 126。判断 IP 是否属于同一子网就是把 IP 与掩码按位与，比较得到的网络地址是否相同。通信路径上：同一子网内的主机靠 ARP 拿到对方 MAC，经交换机二层转发，不经过网关；跨子网必须经过路由器做三层转发。跨地域把两个子网打通，常见做法是 IPSec VPN 隧道（把私网流量封装进公网隧道并加密，成本低、配置简单，适合中小规模）、专线或云企业网（时延与带宽稳定，贵）、基于 WireGuard 与 GRE over IPSec 的自建隧道，两边都在云上时也可以用对等连接或 Transit Gateway。答题时补一句「隧道要规划好两侧网段不能重叠，否则路由会冲突」，能体现真配过。

4. CPU/GPU 打满的应急处置：先用监控确认范围和趋势（单机还是集群、是突增还是缓慢上涨），再上机定位——top 看负载与 P 排序找出吃 CPU 的进程、top -Hp 看线程、按进程的启动命令与部署记录判断是不是正常的业务高峰，GPU 用 nvidia-smi 看显存占用与进程列表、nvidia-smi pmon 看利用率、必要时 nvidia-smi -q 查是否降频或 ECC 报错。处置顺序是先止损（限流、扩容、摘掉异常节点、必要时迁移业务）再排查根因。面试官常追问两个场景：进程配了自动重启就一直重启——那就不能靠杀掉解决，要摘流量再查崩溃日志或先降级；有备用机器——切流量的同时保留现场（dump、日志、进程快照），别直接重装把证据清掉。判断「业务紧急先恢复、不紧急再排查」本身没错，但要说明白证据怎么留。

5. SSH 被攻击后的加固：按层次来——认证上禁用密码登录、只用密钥（并给密钥设口令）、禁用 root 直登、限制允许登录的用户；网络上改默认端口只能减少扫描噪音不算防护，真正的收敛是把 22 端口收到内网，只允许堡垒机或 VPN 网段访问，公网入口只留堡垒机；再上 Fail2ban 这类工具做暴力破解封禁，配合登录告警；运维侧审计所有登录与 sudo 记录、定期轮换密钥。答题时强调「端口改号是降噪不是安全」，比只列措施更能说明你理解防护边界。

6. K8s 监控与对外暴露：健康监控分两层——服务层用 liveness/readiness/startup 探针定义「活着」和「可以接流量」，节点与集群层看节点状态、CPU/内存/磁盘与 inode 使用率、Pod 的重启次数与 CrashLoopBackOff、调度失败事件；指标侧常用 Prometheus 抓 kube-state-metrics 与 node-exporter，Grafana 出图，Alertmanager 告警。要能报出几个关键指标：请求 QPS 与 P99 延迟、错误率、Pod 副本数与 HPA 伸缩情况、容器内存 RSS 与 limit 的比值（这个比值最能提前预警 OOM Kill）、JVM 应用的 GC 与线程数。被问到「具体业务指标怎么定」时诚实说清楚哪些是基础设施指标、哪些要业务侧埋点，别硬编。

7. 对公网开放用 Ingress 还是直接暴露 Pod，以及 HTTPS 链路：默认用 Ingress（或 Gateway API）而不是 NodePort/LoadBalancer 直暴 Pod——Ingress 提供了统一的域名与路径路由、TLS 终止、限流与鉴权入口，Pod 可以保持在私有网络里并由 NetworkPolicy 限制访问，直暴 Pod 会让每个副本都暴露、证书和 IP 管理也会失控。HTTPS 链路上，证书以 Secret 形式挂在 Ingress 上，由 Ingress 控制器终止 TLS，客户端与服务端用非对称加密协商出对称会话密钥（客户端用服务端证书里的公钥加密预主密钥，服务端用自己的私钥解密——这里最容易说反），之后走对称加密；Ingress 到后端 Pod 通常是集群内明文 HTTP，需要端到端加密时再上 mTLS 或服务网格。如果被追问「Pod 要不要终止 TLS」，可以说清两种方案各自的证书管理成本。

8. CI/CD 搭建要注意什么：一条最小可用的链路是——代码提交触发流水线，跑静态检查与测试，构建镜像并推到镜像仓库（用内容哈希或 commit 号打 tag，不要用 latest），再由 Argo CD 之类的 GitOps 工具把期望状态同步到 K8s，配合滚动更新与就绪探针保证不中断，出问题一键回滚到上一个镜像版本。要注意的点：凭据走 Secret 管理而不是写进仓库、构建产物可复现、区分环境用不同的 values 与命名空间、保留可回滚的历史版本、加上部署后的健康校验与自动回滚、以及变更要有审计记录（谁在什么时候发了什么）。回滚能一键完成，是这套体系是否合格的分界线。