小米云原生K8s运维实战：面试高频考点与深度解析

1. 从面试题看小米K8s运维的“硬核”要求

大家好，我是秋意零。最近有不少朋友在准备云原生方向的面试，特别是像小米这样体量的公司，他们的K8s运维岗位面试题，说实话，挺有代表性的。我复盘了一下自己和其他朋友的面经，发现小米的面试官问得特别“实”，他们不满足于你知道概念，更想知道你“踩过什么坑”、“怎么解决的”。这其实反映了一个趋势：大厂的云原生运维，早已不是简单的“会敲命令”就行，它要求你具备从底层原理到上层应用，再到大规模集群稳定性保障的全链路能力。

就拿一面那个“OpenStack有几个关键组件”的问题来说，这看似是个背诵题。但如果你只回答了keystone、nova这些名字，可能就拿不到高分。面试官紧接着问“搭建过程中有遇到什么问题吗？”，这才是真正的考点。我自己当初搭OpenStack（用的Queens版）时，就卡在neutron网络组件和nova计算服务的对接上，因为组件间的依赖和配置顺序没搞对，导致虚拟机网络一直不通。你得能说出这种具体的、因为组件强关联性带来的挑战，并且说明你是怎么查日志（比如看/var/log/nova/nova-api.log）、怎么定位到是ML2插件配置或者消息队列连接问题的。这才能证明你的经验不是纸上谈兵。

再比如“K8s服务暴露有几种方式”这个题，很多人能背出NodePort、LoadBalancer、Ingress。但小米的面试官把它列为“加分项”，并且期望你能说出“不区分集群内外”的几种方式，这要求就上来了。你得理解，像ExternalName这种Service类型，它虽然不提供负载均衡，但能把外部服务（比如一个公司的老数据库）映射成K8s内部的一个服务域名，方便内部应用无感知地访问。更高级的，是提到Service Mesh（如Istio）。我在实际项目中用过Istio，它的Gateway和VirtualService资源能提供基于内容的路由、灰度发布、熔断等远超传统Ingress的能力。你可以举个简单例子：通过一个VirtualService，把来自手机端的流量路由到v1版本的应用，把来自Web端的流量路由到v2版本，这种精细化的流量管理，在小米这样业务场景复杂的公司是刚需。能聊到这个层面，面试官才会觉得你对“服务暴露”的理解是立体和深入的。

2. 核心原理深挖：Pod创建与调度器内幕

面试中，关于K8s原理的问题往往是最能拉开差距的。小米二面那个“Pod的创建过程”和“调度器怎么知道要调度”的连环问，就是一个经典的深度考察点。很多资料会给你一个步骤列表，但我想结合源码和实际排错经验，给你拆解得更透一些。

Pod的创建绝不是一条直线，而是一个状态机在多个组件间流转。当你执行kubectl apply -f pod.yaml后：

1. kubectl 会把你的YAML提交给 kube-apiserver。APIServer是第一道关卡，它会做认证、鉴权，还要通过一个叫 Admission Controller 的链条。比如，它会自动给你的Pod加上默认的ServiceAccount，或者验证资源限制是否合理。这一步出问题，你会在kubectl命令里直接看到错误。
2. 验证通过后，Pod的配置信息作为一个对象被存入 etcd