- 正确答案：Kubernetes（k8s）是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用；Docker 是一个开源的应用容器引擎，基于 Linux 内核的 cgroups 和 namespaces 实现进程级隔离与资源限制，提供镜像构建、分发和运行时环境。二者是互补关系：Docker 负责单机容器的生命周期管理（build、run、push/pull），而 Kubernetes 负责跨多台主机的容器集群调度、服务发现、负载均衡、自愈、滚动更新、配置管理等。 - 解答思路：面试中考察 k8s + Docker 通常不是孤立问概念，而是通过场景题检验候选人对容器技术栈底层原理、协作逻辑和工程实践的理解深度。典型路径是：从“一个 HTTP 服务如何在 k8s 中上线”出发，逐层拆解——Dockerfile 构建镜像 → 镜像推送到 registry → k8s 中定义 Deployment + Service → kubelet 拉取镜像并启动容器 → CNI 网络插件分配 IP → kube-proxy 或 eBPF 实现服务流量转发 → Pod 生命周期与健康检查触发自愈。回答需体现“控制平面 vs 数据平面”、“声明式 API vs 命令式操作”、“镜像不可变性 vs 容器可变性”等关键认知。 - 深度知识讲解： 1. Docker 底层核心机制： - namespaces：提供进程隔离视图。pid namespace 隔离进程 ID 空间（容器内 init 进程 PID=1），net namespace 隔离网络协议栈（独立 lo/eth0、路由表、iptables），mnt namespace 隔离挂载点，uts namespace 隔离 hostname/domainname，ipc namespace 隔离 System V IPC 和 POSIX 消息队列，user namespace 隔离 UID/GID 映射（实现 root 映射为非 root 宿主机用户，提升安全性）。 - cgroups v1/v2：资源限制与统计。cgroups v1 按子系统（cpu、memory、blkio、pids 等）组织为 hierarchy；v2 统一单 hierarchy，支持 nested controller 和 delegation。例如 memory.limit_in_bytes 控制最大内存使用，memory.swap.max 控制 swap 上限（v2），pids.max 限制进程数防 fork bomb。 - UnionFS（如 overlay2）：镜像分层存储机制。每层为只读目录（lowerdir），容器运行时添加一个可写层（upperdir），合并视图为 merged。写时复制（Copy-on-Write）避免重复存储相同文件；删除文件时在 upperdir 创建 .wh. 白名单标记隐藏。overlay2 支持 page cache 共享，比 aufs 性能更优且被主线 kernel 支持。 - 容器运行时接口：Docker daemon 早期直接调用 libcontainer，后演进为符合 OCI（Open Container Initiative）规范的容器运行时抽象。Docker 默认使用 containerd（而非直接调用 runc），containerd 作为守护进程管理容器生命周期，runc 是 OCI runtime 实现（调用 clone() + setns() + execve() 创建命名空间隔离进程）。k8s 1.24+ 已弃用 dockershim，要求运行时必须实现 CRI（Container Runtime Interface），即通过 gRPC 与 kubelet 通信（如 containerd 的 cri-plugin）。 2. Kubernetes 核心组件与数据流： - 控制平面（Control Plane）： * kube-apiserver：唯一入口，提供 RESTful API，所有组件（kubectl、controller-manager、scheduler、kubelet）均通过它通信；内置 RBAC、Admission Control（如 PodSecurityPolicy 已废弃，替换为 Pod Security Admission）、etcd 存储交互。 * etcd：强一致性键值数据库（基于 Raft 协议），存储集群全部状态（Pod、Node、Service、Secret 等对象的完整 spec/status）。k8s 不存任何状态到内存，所有决策依赖 etcd 当前快照 + watch 事件流。 * kube-scheduler：监听未绑定 Pod（spec.nodeName == ""），执行 predicates（硬约束，如资源足够、nodeSelector 匹配、taint/toleration） + priorities（软策略，如 least requested、balanced resource allocation）打分，选择最优 Node 并创建 Binding 对象写入 etcd。 * kube-controller-manager：包含多个 controller，每个 controller 为“控制循环”（control loop）：watch etcd 中某类资源变化 → 对比期望状态（spec）与实际状态（status）→ 执行 reconcile 补偿操作。例如： - ReplicationManager：确保 Deployment 关联的 ReplicaSet 下 Pod 数量等于 replicas； - NodeController：检测 Node 心跳超时（默认 40s），标记 NotReady，5min 后驱逐其上 Pod； - EndpointSliceController：监听 Service 和 Pod 变化，自动更新 endpointslices（替代旧 endpoints，支持更大规模服务发现）。 * cloud-controller-manager（可选）：将云厂商特有逻辑（如 LoadBalancer Service 创建 CLB、Node 地址获取）从核心 controller 中解耦。 - 数据平面（Data Plane）： * kubelet：运行在每个 Node 上的代理，核心职责包括： - 通过 CRI 调用 containerd 启停容器； - 管理 volume（mount/unmount，支持 CSI 插件）； - 执行 liveness/readiness/startup probes（以 exec/http/grpc 方式调用容器内进程或端口）； - 上报 Node 状态（conditions、capacity、allocatable）、Pod 状态（phase、containerStatuses）到 apiserver； - cAdvisor 集成：采集容器 CPU/memory/disk/network 实时指标（暴露 /metrics/cadvisor endpoint）。 * containerd + runc：实际运行容器的 OCI 运行时栈。 * CNI 插件（如 Calico、Cilium、Flannel）：实现 Pod 网络。Calico 使用 BGP 分发路由，Cilium 基于 eBPF 实现高性能网络策略与可观测性，Flannel 提供简单 overlay（vxlan 或 host-gw 模式）。 * kube-proxy（或 Cilium 替代）：实现 Service 的虚拟 IP（ClusterIP）和服务发现。传统模式： - userspace：已淘汰； - iptables：为每个 ClusterIP 生成大量链规则，O(n) 规则匹配，大规模集群性能差； - ipvs：基于 netfilter 的 hash table，O(1) 查找，支持更多负载均衡算法（rr/wlc/sh），但需内核模块支持； - eBPF（Cilium）：绕过 iptables/netfilter，直接在内核 socket 层拦截流量，零拷贝、动态更新、细粒度策略。 3. 关键对象原语与设计哲学： - Pod：k8s 最小调度单元，逻辑上是一组共享 Network + UTS + IPC namespace 的容器（即“逻辑主机”），但不共享 PID namespace（各容器 PID 空间独立）。Pause 容器（infrastructure container）持有网络和挂载命名空间，其他业务容器加入其 namespace，实现“一个 Pod 一个 IP”的语义。Pod 是短暂的（ephemeral），由控制器管理生命周期。 - Deployment：声明式更新 Pod 模板的控制器，底层通过 ReplicaSet 版本管理（RS 名为 -），支持滚动更新（maxSurge/maxUnavailable 控制灰度节奏）、回滚（revisionHistoryLimit 保留历史 RS）、暂停/恢复发布。 - Service：定义一组 Pod 的访问策略（ClusterIP/NodePort/LoadBalancer/ExternalName）。ClusterIP 本质是 iptables/ipvs 规则 + endpointslice，将 VIP:port 映射到底层 Pod IP:port。Headless Service（clusterIP=None）不分配 VIP，直接返回 Pod DNS 记录（...svc.cluster.local），用于有状态服务（如 ZooKeeper、etcd）。 - ConfigMap / Secret：解耦配置与镜像。Secret 默认 base64 编码（仅防意外明文泄露，非加密），敏感数据应配合 external-secrets 或 Vault 动态注入；二者均以 volume 或 env 方式挂载，volume 方式支持热更新（subPath 不支持）。 - Init Container：在主容器启动前顺序执行的临时容器，常用于等待依赖服务就绪（如 wait-for-db.sh）、下载配置、修改卷权限等。失败则重启整个 Pod（按 restartPolicy）。 4. 常见故障排查链路（体现工程能力）： - Pod 处于 Pending：kubectl describe pod → Events 中提示 “0/3 nodes are available: 2 Insufficient cpu, 1 node(s) had taints that the pod didn’t tolerate” → 检查节点资源 allocatable、污点设置、Pod requests/limits。 - Pod 处于 ContainerCreating：常见原因：镜像拉取失败（imagePullSecret 错误、registry 认证失败）、CNI 网络未就绪（kubectl get pods -n kube-system 查看 calico-node/cilium 状态）、volume mount 失败（NFS server 不可达、PV/PVC 未绑定）。 - Pod CrashLoopBackOff：kubectl logs -p 查看上次崩溃日志；kubectl exec -it 进入容器检查进程、磁盘、网络；检查 liveness probe 设置是否过严（如初始延迟 initialDelaySeconds 太小导致刚启动就被 kill）。 - Service 无法访问：先确认 Endpoints 是否有后端（kubectl get endpoints ）；再检查 Pod readinessProbe 是否通过（kubectl get pod -o wide 确认 READY 列为 1/1）；然后验证 ClusterIP 是否能 ping 通（注意：ICMP 可能被禁用，改用 curl http://:port）；最后检查 kube-proxy 是否正常运行、iptables/ipvs 规则是否存在（ipvsadm -ln 或 iptables -t nat -L | grep ）。 - 伪代码/关键命令示例（辅助理解）： 1. Docker 构建镜像分层过程（简化版）： ``` # Dockerfile FROM ubuntu:22.04 RUN apt-get update && apt-get install -y nginx # layer 1: rootfs diff COPY nginx.conf /etc/nginx/nginx.conf # layer 2: config file EXPOSE 80 CMD ["nginx", "-g", "daemon off;"] # 构建时，docker daemon 依次执行： # 1. 创建基础层（ubuntu:22.04 tarball 解压） # 2. chroot 到该层，执行 RUN 命令 → 新增 layer（含 /usr/sbin/nginx 等二进制） # 3. COPY 命令 → 新增 layer（仅 /etc/nginx/nginx.conf） # 4. 生成镜像 manifest，记录 layers 的 sha256 digest 数组 ``` 2. k8s Deployment 滚动更新核心逻辑（伪代码）： ``` func rolloutUpdate(deployment *Deployment, newRS *ReplicaSet) { // Step 1: 扩容新 RS，缩容旧 RS，保持 totalDesired = deployment.Spec.Replicas scaleUp(newRS, min(maxSurge, deployment.Spec.Replicas)) scaleDown(oldRS, min(maxUnavailable, oldRS.Spec.Replicas)) // Step 2: 等待新 Pod Ready（readinessProbe 成功），且数量达标 for len(getReadyPods(newRS)) < newRS.Spec.Replicas { sleep(1s) if timeout { panic("rollout timeout") } } // Step 3: 删除旧 RS（当其 Pod 数为 0） if len(getAllPods(oldRS)) == 0 { delete(oldRS) } } ``` 3. kubelet 启动容器的关键调用链（简化）： ``` kubelet.mainLoop() → podWorkers.UpdatePod() → syncPod() → // 1. 计算 Pod 状态差异（如 missing containers） // 2. 调用 containerRuntime.Start()（即 containerd CRI 接口） // 3. containerd → shim → runc create → clone(CLONE_NEWNS|CLONE_NEWPID|...) → execve("/proc/self/exe", args) ``` - 扩展知识： - eBPF 在云原生中的演进：Cilium 使用 eBPF 替代 iptables 实现 Service 转发和 NetworkPolicy，相比传统方案，具备零拷贝、动态加载、无需修改内核、可观测性强（tracepoint/kprobe）等优势。Linux 5.15+ 支持 eBPF 程序直接调用内核 helper 函数，进一步降低开销。 - 容器安全加固方向：启用 seccomp profile（限制系统调用）、AppArmor/SELinux 策略、只读根文件系统（readOnlyRootFilesystem: true）、非 root 用户运行（runAsNonRoot: true）、PodSecurity Admission（替代 PSP）强制执行 baseline/restricted 策略。 - Serverless 容器：Knative Serving 基于 k8s CRD（Service/Revision/Route）实现自动扩缩容（KPA/KPA）和流量切分；Cloud Run、AWS Fargate 是托管形态。 - 边缘计算：K3s（轻量 k8s）、KubeEdge（边缘节点离线自治、元数据同步）、MicroK8s（Ubuntu 官方轻量发行版）解决资源受限与网络不稳定问题。以上内容覆盖了校招面试中对 Docker 与 Kubernetes 的核心考察维度：原理深度（namespace/cgroup/overlay）、架构理解（控制面/数据面/CRI/CNI）、对象语义（Pod/Deployment/Service）、排障能力（Pending/CrashLoopBackOff）、以及前沿趋势（eBPF/安全/Serverless）。建议候选人结合自身项目，准备 1~2 个真实踩坑案例（如“因忘记设置 resources.limits 导致节点 OOMKill”或“ConfigMap 挂载后未生效因 subPath 导致热更新失效”），更能体现工程素养。

Tiktok AI后台开发二面分享 1h

全站热榜

创作者周榜