more 注释之前的内容被视为文章摘要。

面试口述要点（约 1 分钟）

CI/CD 是持续集成（Continuous Integration）与持续交付/部署（Continuous Delivery/Deployment）的简称，核心目标是通过自动化提升交付效率、质量与一致性：

• 持续集成（CI）：开发者频繁提交代码到主干，触发自动化构建、单元测试、静态扫描、依赖检查，快速发现集成问题与冲突，保证主干可随时发布。
• 持续交付（CD-Delivery）：在 CI 基础上自动化环境部署（Dev/Test/Staging），通过集成测试、E2E 测试、性能测试验证发布候选，手工审批后推生产。
• 持续部署（CD-Deployment）：更进一步，所有通过测试的变更自动部署到生产，依赖金丝雀/蓝绿/灰度策略与监控回滚机制，降低人工干预。
• 核心流程：代码提交 → 触发 Pipeline → 构建镜像/制品 → 运行测试 → 制品推送仓库 → 部署目标环境 → 健康检查/烟测 → 验收/回滚。
• 关键实践：分支策略（GitFlow/Trunk-based）、自动化测试覆盖、环境隔离与一致性（IaC/容器化）、快速反馈与回滚、制品版本化与 Immutable。
• 常用工具链：源码管理（Git/GitLab/GitHub）、CI 引擎（Jenkins/GitLab CI/GitHub Actions/Tekton）、构建工具（Maven/Gradle/Docker）、制品仓库（Harbor/Artifactory）、部署编排（Kubernetes/Helm/ArgoCD）、监控告警（Prometheus/Grafana）。

面试口述要点（约 1 分钟）

完整的 CI/CD 工具链覆盖代码管理、构建、测试、制品管理、部署、监控等全生命周期：

• 源码管理：Git + GitLab/GitHub/Gitea，提供分支管理、MR/PR 审查、Webhook 触发；企业侧重 GitLab 私有化部署与 RBAC。
• CI 引擎：Jenkins（插件丰富、社区大但配置重）、GitLab CI（与 Git 深度集成、YAML Pipeline）、GitHub Actions（云原生、Marketplace 生态）、Tekton（Kubernetes-native、CRD 驱动）、Travis CI/CircleCI（SaaS 简单但灵活性受限）。
• 构建工具：Maven/Gradle（Java）、npm/Yarn（Node.js）、pip/Poetry（Python）；容器化统一用 Docker/Buildah/Kaniko（无需 Docker Daemon）。
• 代码质量：SonarQube（静态扫描/代码异味/技术债）、ESLint/Pylint（语法检查）、单元测试框架（JUnit/pytest/Jest）、覆盖率工具（JaCoCo/coverage.py）。
• 制品仓库：Docker 镜像用 Harbor/Docker Hub/ECR，二进制制品用 Artifactory/Nexus，Helm Chart 用 ChartMuseum。
• 部署编排：Kubernetes（Helm/Kustomize 管理配置）、ArgoCD/Flux（GitOps）、Spinnaker（多云多集群）；传统应用用 Ansible/Terraform（IaC）。
• 监控告警：Prometheus + Grafana（指标）、ELK/Loki（日志）、Jaeger/SkyWalking（链路追踪）、PagerDuty/钉钉/企微（告警通知）。
• 安全扫描：Trivy/Clair（镜像漏洞）、Snyk（依赖扫描）、OWASP ZAP/Fortify（应用安全）。

面试口述要点（约 1 分钟）

Dockerfile 通过声明式指令定义镜像构建过程，常见指令分为基础设置、文件操作、运行时配置三类：

基础指令：

• FROM <image>:<tag>：指定基础镜像，必须是第一条指令；多阶段构建可多次使用，如 FROM golang:1.20 AS builder。
• LABEL <key>=<value>：添加元数据，如版本、维护者、描述。

要点

EXPOSE 仅用于声明容器内应用监听的端口及协议，方便人和工具理解镜像，不会自动对宿主机或外部开放端口。

• 不做映射：EXPOSE 不等于开放端口；需要 -p/--publish 或 Compose ports: 才会将容器端口映射到宿主机。
• 文档化与默认映射：docker run -P 会为镜像中所有 EXPOSE 端口随机映射宿主机端口；否则无映射。
• 协议声明：支持 EXPOSE 80/tcp、EXPOSE 53/udp，便于工具按协议处理。
• Docker 网络：处于同一自定义网络的容器可直接互访 IP/服务名，与是否 EXPOSE 无关；EXPOSE 仅起说明作用。
• Kubernetes：EXPOSE 不参与暴露；应在 Pod 里用 containerPort 声明、用 Service/Ingress 对内外暴露。

系统化排查流程

排查原则：从外到内，从简到繁，逐层深入

排查顺序：
1. 查看 Pod 状态 (kubectl get/describe)
2. 查看容器日志 (kubectl logs)
3. 查看事件信息 (kubectl events)
4. 检查资源配额 (Resource Quota)
5. 检查节点状态 (Node)
6. 检查网络策略 (Network Policy)
7. 检查存储卷 (PV/PVC)
8. 检查安全策略 (Security Context)

核心概念

Pod

• K8s 最小部署单元，包含一个或多个容器
• 共享网络和存储资源
• 同一 Pod 内容器通过 localhost 通信

Service

• 为 Pod 提供稳定的网络访问入口
• 通过标签选择器关联 Pod
• 支持 ClusterIP、NodePort、LoadBalancer 类型

Deployment

简答

可以。Pod 内可以运行多个进程，主要有两种方式：

1. 多容器模式：一个 Pod 中运行多个容器，每个容器运行一个或多个进程
2. 单容器多进程：一个容器中运行多个进程（不推荐，但技术上可行）

详细解答

1. Pod 的基本概念

• Pod 是 Kubernetes 中最小的调度单元
• Pod 包含一个或多个容器，这些容器共享网络命名空间和存储卷
• Pod 内的所有容器共享同一个 IP 地址和端口空间

简答

主要原因是 cron 执行环境与用户登录 shell 环境不同，包括环境变量、工作目录、PATH 路径、用户权限等差异，导致脚本在 cron 中找不到命令或无法访问资源。

详细原因分析

1. 环境变量缺失（最常见）

问题表现：

# 手动执行成功
$ ./backup.sh
Success!

# cron 执行失败
* * * * * /home/user/backup.sh
# 报错：command not found

核心答案

Kubernetes 主要使用 kube-proxy 来控制网络转发，它通过以下三种模式实现 Service 的负载均衡和流量转发：

1. iptables 模式（默认，最常用）
2. IPVS 模式（高性能场景）
3. userspace 模式（已废弃）

此外，底层还依赖：

• Linux 内核的 Netfilter 框架（iptables/IPVS 的基础）
• CNI 插件（如 Calico、Flannel、Weave）处理 Pod 间的网络通信
• 网络命名空间（Network Namespace）实现网络隔离