59. 什么是CRD，它对K8s有什么重要意义？

答：

CRD（CustomResourceDefinition，自定义资源定义）是 Kubernetes 提供的一种扩展机制，

允许用户在不修改 Kubernetes 核心代码的情况下，定义和使用新的资源类型（即自定义资

源），这些资源与内置资源（如 Pod、Service）具有同等地位，可通过 Kubernetes API 进行

创建、查询、更新和删除等操作。

它极大扩展了 Kubernetes 的能力边界，使 Kubernetes 从一个通用的容器编排平台转变为一个可高度定制的平台。通过 CRD，用户可以将业务领域的概念（如数据库实例、AI 模型、自定义工作流等）抽象为 Kubernetes 资源，利用 Kubernetes 的声明式 API、控制器模式等特性进行管理，实现业务逻辑与 Kubernetes 生态的深度融合。

60. CRD 的典型应用场景有哪些，举例说明。

答：

CRD（CustomResourceDefinition）的典型应用场景集中在扩展Kubernetes能力以适配特定业务需求，通过自定义资源将业务概念纳入K8s管理体系并结合控制器实现自动化逻辑。例如，在自定义应用管理中，开发团队可创建`AppDeployment` CRD，包含应用版本、依赖服务、滚动策略等字段，配合控制器自动处理数据库迁移、缓存预热等部署流程，简化复杂应用的标准化发布；基础设施管理方面，可定义`DatabaseInstance` CRD描述数据库类型、规格、备份策略等，控制器联动云厂商API联动自动创建实例，实现基础设施即代码；工作流与任务调度场景中，`BatchJob` CRD可定义批量处理任务的并行度、重试次数等配置，控制器控制器调度Pod执行并监控进度；服务网格工具如Istio使用`VirtualService`和`DestinationRule`等CRD配置流量路由与访问策略，控制器将其转化为底层网络配置；监控与运维领域则可通过`MetricAlert` CRD定义监控指标、阈值和通知方式，控制器结合Prometheus生成告警规则，这些场景均通过CRD将业务逻辑转化为K8s原生资源，利用其声明式API和控制器模式实现自动化管理。

 61. 结合教材，解释CRD的完整创建和使用过程。

答：

创建和使用CRD的完整过程始于定义CRD资源，即通过编写YAML文件明确新资源的组、版本、作用域及字段结构，比如定义一个包含数据库类型、存储大小等属性的`Database` CRD，随后用`kubectl apply`提交到集群，使Kubernetes API服务器注册该资源类型，可通过`kubectl get crd`确认注册结果。接着，基于已注册的CRD创建具体的自定义资源实例，编写YAML文件指定实例的配置细节，例如创建`my-mysql`实例并设置类型和存储大小，提交后Kubernetes会将实例存储在etcd中，可通过`kubectl get`命令查看实例状态并进行CRUD操作。若需实现自动化管理，还需开发控制器，控制器通过监听自定义资源的变化，依据业务逻辑驱动实际状态向期望状态调整，比如当检测到`Database`实例创建时调用云厂商API创建对应数据库并更新实例状态，删除时则清理底层资源，控制器通常部署为Pod运行在集群中，借助Informer机制与Kubernetes API交互完成闭环控制，最终将业务概念转化为Kubernetes原生资源并实现自动化运维。

62. Gateway API有哪几个核心组件，分别有哪些作用？

答：

GatewayClass 是集群级资源，用作网关的模板，定义了网关的实现类型（如特定厂商的负载均衡器）和配置参数，由集群管理员管理，为 Gateway 提供统一的底层实现标准，确保同一类网关具有一致的基础特性。

Gateway 是命名空间级资源，基于 GatewayClass 创建，代表集群中实际运行的网关实例，负责监听网络端口、配置 TLS 等基础网络设置，将流量接入集群，同时作为路由资源的附着点，为路由规则提供作用范围。

HTTPRoute（以及 TCPRoute、TLSRoute 等路由资源）用于定义流量路由规则，通过匹配请求的主机名、路径、 headers 等属性，将流量从 Gateway 转发到后端服务（如 Service），支持更细粒度的流量控制（如权重分流、路径重写），并可跨命名空间关联后端服务，实现灵活的流量管理。

63. 说明PriorityClass是在解决K8s资源争用时的调度决策原理。

答:

PriorityClass是Kubernetes中用于定义Pod优先级的集群级资源，在集群资源（如CPU、内存）不足引发资源争用时，通过优先级数值和抢占机制影响调度决策，确保高优先级Pod优先获得资源或在资源紧张时优先保留。每个PriorityClass关联一个整数优先级值（值越高优先级越高），Pod通过指定priorityClassName关联对应的优先级，当集群资源充足时优先级不直接影响调度顺序，但资源不足时调度器会优先调度优先级更高的Pod以确保其优先获得资源；若高优先级Pod因资源不足无法调度，调度器会触发抢占机制，寻找已运行低优先级Pod所在节点，驱逐这些低优先级Pod释放资源，使高优先级Pod能调度到该节点，而被驱逐的低优先级Pod会进入重新调度队列等待资源释放后再调度。这种机制实现了资源争用时的优先级排序和资源保障，确保核心业务Pod在资源紧张时优先获得资源，减少非核心业务对核心业务的影响，提升集群资源利用合理性和业务稳定性。

64. HPA是如何在K8s集群中实现自动扩缩容机制的？

答：

HPA（Horizontal Pod Autoscaler）在 Kubernetes 集群中通过监控目标资源（如 Deployment、StatefulSet）的 Pod 指标（如 CPU 使用率、内存使用率或自定义指标），动态调整 Pod 副本数量以实现自动扩缩容。其工作原理是：首先由用户定义 HPA 规则，指定目标资源、扩缩容的最小 / 最大副本数以及触发扩缩容的指标阈值（如 CPU 使用率 80%）；然后 HPA 控制器定期（默认 15 秒）从 Metrics Server 或自定义指标 API 获取目标资源的 Pod 指标数据，计算当前指标平均值与阈值的差异；当实际指标持续高于阈值时，HPA 按比例增加副本数（不超过最大限制）。

 65. 请谈谈Argo CD的核心架构组件有哪些，分别做简要说明。

答：

Argo CD 是基于 GitOps 理念的 Kubernetes 持续部署工具，其核心架构组件围绕“声明式配置管理”和“Git 作为单一可信源”设计，主要包括 API Server、Repository Server、Application Controller、ApplicationSet Controller、UI/Dashboard、CLI 及 Redis。API Server 是核心控制平面，提供 RESTful API 和 GraphQL 接口，处理用户请求、管理资源状态，是用户及外部系统与内部组件交互的入口；Repository Server 负责与 Git 仓库等外部数据源交互，定期拉取配置并解析，传递“期望状态”给应用控制器，还支持配置校验；Application Controller 持续监控应用实际状态与 Git 中期望状态，对比差异生成同步计划，按策略触发同步以保持状态一致；ApplicationSet Controller 用于批量管理应用，通过模板化配置和生成器动态创建多个 Application 实例，简化大规模部署；UI/Dashboard 提供可视化界面，方便查看应用状态、触发同步等操作，降低使用门槛；CLI（argocd）支持终端交互，是自动化脚本和 CI 流水线集成的主要方式；Redis 作为缓存和状态存储，缓存元数据、存储任务队列，提升系统响应速度和操作有序性。这些组件协同工作，形成以 Git 为核心的声明式部署流程，实现 Kubernetes 应用的自动化、可追溯部署。

 66. 你是如何理解CI/CD流水线技术的，它和提升企业竞争力有什么关系？

答：

CI/CD 流水线是通过自动化工具串联软件开发、构建、测试、部署全流程的技术体系，核心是实现持续集成（频繁代码合并与自动化验证）和持续部署/交付（自动化推送验证后代码至环境），以标准化流程减少人工操作与失误。 

它与企业竞争力的关联体现在：一是加速迭代，通过自动化缩短从开发到上线周期，让企业快速响应需求、抢占市场；二是提升质量，将测试与安全验证嵌入流程，提前暴露问题，降低线上故障风险；三是降本增效，减少重复劳动与后期修复成本，提高资源利用率；四是支撑创新，为多团队协作、业务扩展提供稳定交付能力，降低试错成本，增强企业灵活性与市场适应性，最终将技术效率转化为业务优势。