15. 什么是Pod的根容器？
答： pause 容器（ infra 容器 ）—— Pod 网络等基础环境的 “根容器”，它是 Pod 中最先启动的容器。它为整个 Pod 里的其他业务容器（比如你定义的 hello、httpd 这类容器 ）提供统一的网络命名空间（ Pod 内所有容器共享其网络栈，实现同 Pod 内容器间网络互通，像 localhost 访问 ）、IPC 命名空间等基础环境 。
16. 解释Pod的生命周期。
答：Pod 的生命周期包含多个阶段，各阶段有不同的状态和含义：
Pending（挂起）：当用户创建一个 Pod 资源后，Pod 进入 Pending 状态。此时，Kubernetes 系统已经接收到创建 Pod 的请求，API Server 已将 Pod 信息记录在 etcd 中，但还没有完成 Pod 的调度，或者 Pod 中容器镜像的下载等工作尚未结束 。
Running（运行中）：Pod 已经被调度到某个节点上，并且所有容器都已被 kubelet 创建，其中至少有一个容器处于运行（Running）、正在启动（Starting）或正在重启（Restarting）状态 。
Succeeded（成功）：Pod 中的所有容器都已成功执行并退出，且不会再重启 。
Failed（失败）：Pod 中的所有容器都已终止，且至少有一个容器是以失败状态退出的。这意味着容器运行过程中出现了错误，比如代码异常、运行时依赖缺失等导致容器崩溃退出 。
Unknown（未知）：由于某种原因，Kubernetes 无法获取 Pod 的状态信息，通常是因为与 Pod 所在节点的通信出现问题，比如节点宕机、网络故障等，导致 kubelet 无法向 API Server 汇报 Pod 状态 。
17. Init类型容器有什么特点，主要用途？
答：特点：执行顺序优先、独立生命周期、资源隔离、镜像可不同。
主要用途：环境准备、依赖检查、数据初始化、权限设置。
18. Sidecar类型容器和Init容器的区别在哪？
答：Init 容器会在所有业务容器启动前按顺序逐个运行，只有当前一个 Init 容器成功退出后，下一个才会启动，直到所有 Init 容器都完成任务，业务容器才会开始启动，其核心作用是为业务容器铺垫运行环境，比如检查外部依赖是否就绪、创建配置文件等，任务完成后便终止生命周期，若执行失败会根据重启策略重试。而 Sidecar 容器则是与业务容器业务容器并行启动，在 Pod 的整个生命周期内持续运行，不直接参与核心业务逻辑，而是通过日志收集、流量代理、配置同步等辅助功能为业务容器提供支持，二者共享 Pod 的网络和存储资源。
19. 什么是静态Pod？
答：静态Pod是由节点上的`kubelet`进程直接管理的特殊Pod，无需通过Kubernetes API Server调度或控制。其配置文件通常存放在节点指定目录（如`/etc/kubernetes/manifests`）或由`kubelet`启动参数指定路径，`kubelet`会定期扫描这些文件，自动创建、监控并维护对应Pod的运行——Pod终止后会被自动重启，配置文件修改后会按新配置重建，文件删除则Pod随之移除。由于不依赖API Server，静态Pod无法通过`kubectl`等工具直接修改或删除，操作需直接编辑节点上的配置文件，其生命周期与所在节点的`kubelet`紧密绑定，常用于部署集群核心组件（如`kube-apiserver`、`etcd`），确保关键服务在节点启动时即可被`kubelet`直接拉起。
20. 说明K8s控制器的作用？
答：Kubernetes控制器是实现集群自动化管理的核心组件，其核心作用是通过持续监控集群中资源的实际状态，并与用户定义的期望状态进行对比，当两者存在差异时自动执行调整操作（如创建/删除Pod、调度资源、处理故障等），确保实际状态始终贴合期望状态。无论是保障应用副本数稳定的Deployment、为有状态应用维护固定标识的StatefulSet，还是处理节点故障的Node控制器等，都通过封装复杂运维逻辑，实现了故障自愈、自动扩缩容、滚动更新等功能，是Kubernetes声明式API和集群自愈能力的核心支撑，让用户无需手动干预即可维持应用稳定运行。
21. 什么是ReplicaSet，说明它的主要用途。
答：ReplicaSet（副本集）是 Kubernetes 中用于确保指定数量的 Pod 副本始终运行的控制器，它通过监控 Pod 状态，维持用户定义的期望副本数。其核心机制是：当 Pod 因故障、节点问题等原因终止时，ReplicaSet 会自动创建新的 Pod 来替换，确保实际运行的 Pod 数量与期望数量一致；若实际数量超过期望，它也会删除多余的 Pod。
ReplicaSet 的主要用途是保证应用的可用性和稳定性，通过多副本部署实现负载均衡和故障冗余。
22. Deployment控制器是如何工作的，举例说明其常见用途。
答：Deployment 是 Kubernetes 中基于 ReplicaSet 的高级控制器，其核心工作机制是通过管理 ReplicaSet 来维持 Pod 的期望状态，并支持应用的声明式更新。具体来说，当用户定义 Deployment 的期望状态（如副本数、Pod 模板等）后，Deployment 会自动创建对应的 ReplicaSet，由 ReplicaSet 确保实际运行的 Pod 数量与期望一致；当需要更新应用（如修改镜像版本）时，Deployment 会创建新的 ReplicaSet 并逐步替换旧的 ReplicaSet，通过控制新旧 Pod 的替换速度实现滚动更新，同时保留旧 ReplicaSet 版本以便在出现问题时快速回滚。
常见用途：
（1）应用部署与副本管理：例如部署一个 Web 应用，通过 Deployment 定义 3 个副本，它会自动创建 ReplicaSet 并维持 3 个 Pod 运行，若 Pod 故障则自动重建，保障服务可用性。
（2）滚动更新：当应用需要升级时（如从 v1 版本更新到 v2），Deployment 会先创建运行 v2 镜像的新 ReplicaSet，逐步增加新 Pod 数量并减少旧 Pod 数量，整个过程中服务不中断，避免更新导致的 downtime。
（3）版本回滚：若更新后的 v2 版本出现问题，可通过 Deployment 快速回滚到之前的 v1 版本，只需恢复到对应的旧 ReplicaSet，无需重新配置。
（4）弹性伸缩：通过修改 Deployment 的副本数配置，可轻松实现应用的扩缩容（如从 3 个副本调整为 5 个以应对流量增长），操作简单且无需中断服务。
23. 解释DaemonSet，列举其使用场景。
答：DaemonSet 是 Kubernetes 中用于在集群所有节点（或满足特定条件的节点）上运行且仅运行一个 Pod 副本的控制器。它会自动监控节点状态：当新节点加入集群时，DaemonSet 会在新节点上创建对应的 Pod；当节点从集群移除时，其上的 Pod 也会被自动清理。这种特性使其适用于需要在每个节点上部署的基础设施类或监控类服务。
使用场景：节点监控与日志收集，网络插件组件、存储插件代理、安全与合规工具，节点本地缓存/代理，GPU/硬件设备管理、
24. 什么是StatefulSet，其主要作用是什么？
答：StatefulSet控制器用来管理基于相同容器规约的一组Pod。但和 Deploymen不同的是，StatefulSet 为它的每个 Pod 维护了一个有粘性的ID。这些Pod是基于相同的规约来创建的，但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。
主要作用是解决有状态应用的管理需求，例如数据库集群（MySQL、PostgreSQL）、分布式系统（ZooKeeper、Kafka）、分布式存储（Ceph）等。
25. 说明Job与CronJob的功能。
答：Job 主要用于执行一次性任务，确保任务能够成功完成。它会创建一个或多个 Pod 来运行指定任务，当所有 Pod 成功执行并退出（退出码为 0）后，Job 即完成使命。
CronJob 则是基于 Job 的扩展，用于管理周期性、定时执行的任务，其运行机制类似 Linux 的 cron 定时任务。它通过 Cron 表达式（如0 3 * * *表示每天凌晨 3 点）定义任务执行时间，按规则自动创建 Job 来运行任务，每次任务执行都是一个独立的 Job 实例。
26. Kubernetes如何在集群的Pod之间提供网络服务？
答：Kubernetes通过多层机制为Pod间提供网络服务：底层依赖CNI插件（如Calico、Flannel）实现Pod唯一IP分配和跨节点通信，确保Pod可直接通过IP互访；通过Service提供固定访问入口和负载均衡，屏蔽Pod IP动态变化；借助CoreDNS实现域名解析，让Pod可通过Service名称或域名通信；同时支持NetworkPolicy定义访问规则控制流量，保障通信安全与可控。
27. 解释iptables和IPVS代理模式Service的区别。
答：从实现机制看，iptables 模式通过配置 Linux netfilter 的 iptables 规则，捕获 Service 的 ClusterIP 和端口请求，再随机转发到后端 Pod，规则基于链式结构；IPVS 模式则利用 IP 虚拟服务器技术，通过内核中的哈希表结构维护规则，调用 netlink 接口创建和同步 IPVS 规则，支持更多样的负载均衡策略（如轮询、加权等）。
从性能表现看，iptables 模式虽系统开销较低，但规则链式匹配在大规模服务时可能导致延迟增加；IPVS 模式同样工作在内核空间，因哈希表结构的高效查找，不仅转发延迟更短，规则同步性能更优，且能支持更高的网络吞吐量，尤其适合大规模集群场景。
28. 举例说明ClusterIP类型Service的用法。
答：ClusterIP 类型的 Service 是 Kubernetes 中最基础的 Service 类型，它会为 Service 分配一个集群内部唯一的虚拟 IP（ClusterIP），仅允许集群内的 Pod 或组件访问，无法从集群外部直接访问。其核心作用是为一组 Pod 提供固定的内部访问入口，并实现负载均衡。
示例：创建服务，对外提供8000端口，并把流量导入具有app: nginx的后端80端口上。
29. 举例说明NodePort类型Service的用法。
答：NodePort 类型服务发现通过每个节点上的IP和静态端口（NodePort）暴露服务。NodePort服务 会路由到自动创建的ClusterIP 服务，并通过请求 :，就可以从集群的外部 访问一个NodePort服务。
示例：NodePort 会在节点的特定端口上开通服务，本实验中，我们指定的端口为 31788（在 Kubernetes 中，NodePort 服务类型的默认端口范围通常是 30000-32767）
30. 举例说明Headless类型Service的用法。
答：Headless Service（无头服务）是一种不分配 ClusterIP 的 Service 类型，主要用于需要直接访问后端 Pod 的场景，尤其适合有状态应用的服务发现。它通过 DNS 直接返回所有关联 Pod 的 IP 列表，而非通过 Service 进行负载均衡转发。
举例说明：假设用 StatefulSet 部署一个 3 节点的 ZooKeeper 集群（Pod 名称为zk-0、zk-1、zk-2），标签为app: zookeeper，每个 Pod 需要知道集群中其他节点的地址以形成集群。此时可创建 Headless Service：
31. 详细说明Ingress的实现原理和它所实现的功能。
答：Ingress 是 Kubernetes 中用于管理外部流量如何到达集群内部服务的 API 对象，主要用于 HTTP/HTTPS 流量的路由，其核心原理是规则翻译与流量转发。（1）用户创建 Ingress 资源，将规则提交到 Kubernetes API Server 并存储在 ETCD 中。（2）Ingress Controller 通过 Watch 机制感知规则变化，将 Ingress 资源中的规则翻译为具体负载均衡器的配置。例如，Nginx Ingress Controller 会将规则转换为 nginx.conf。（3）外部请求到达 Ingress Controller，Controller 根据域名、路径等规则匹配请求，并将其转发到对应的后端 Service，Service 再将请求路由到后端 Pod。
实现功能：提供外部访问入口、负载均衡、SSL终结、基于名称的虚拟托管。