K8S集群管理(4)
目录
1. 解释ResourceQuota的作用。
2. 解释Service Account的用途。
3. 详细解释Role和ClusterRole。
4. 什么是K8s的NetworkPolicy？
5. 详细描述在K8s中如何控制跨Namespace的Pod访问？
6. 举例说明K8s中都有哪些常规的维护管理操作。
7. 如何升级K8s到新的版本？在升级过程中应该注意哪些事项？
8. 解释ETCD及其备份和恢复的过程。
9. Kustomization在Kubernetes中的作用。
10. 什么是CRD，它对K8s有什么重要意义？
11. CRD 的典型应用场景有哪些，举例说明。
12. 结合教材，解释CRD的完整创建和使用过程。
13. Gateway API有哪几个核心组件，分别有哪些作用？
14.说明PriorityClass是在解决K8s资源争用时的调度决策原理。
15. HPA是如何在K8s集群中实现自动扩缩容机制的？
16.请谈谈Argo CD的核心架构组件有哪些，分别做简要说明。
17.你是如何理解CI/CD流水线技术的，它和提升企业竞争力有什么关系？
1. 解释ResourceQuota的作用。
ResourceQuota（资源配额）用于在 Kubernetes 命名空间级别限制资源使用，防止单个命名空间过度消耗集群资源，确保资源公平分配。其主要作用包括：
限制命名空间内可使用的计算资源（如 CPU、内存）和存储资源总量；
限制命名空间内可创建的对象数量（如 Pod、Service、ConfigMap 等）；
保障集群资源的合理利用，避免资源滥用导致的集群不稳定。
2. 解释Service Account的用途。
Service Account（服务账户）是 Kubernetes 中为 Pod 内运行的进程提供身份认证的实体，主要用途包括：
为 Pod 提供访问 Kubernetes API Server 的身份凭证（通过挂载的令牌文件）；
与 RBAC（基于角色的访问控制）结合，控制 Pod 对集群资源的操作权限；
区别于 “用户账户”（面向人类用户），Service Account 是面向 Pod 内应用程序的自动化身份，便于集群内服务间的安全通信。
3. 详细解释Role和ClusterRole。
两者均为 Kubernetes 中定义权限规则的资源，核心区别在于作用范围：
Role：
作用范围限定在单个命名空间内；
仅能对该命名空间内的资源（如 Pod、Deployment）定义操作权限（如 get、list、create）。
ClusterRole：
作用范围为整个集群，是集群级别的权限集合；
可对集群级资源（如 Node、Namespace）、跨命名空间资源（如跨命名空间的 Service）或所有命名空间的资源定义权限。
4. 什么是K8s的NetworkPolicy？
NetworkPolicy 是 Kubernetes 中用于控制 Pod 间网络通信的规则集合，作用包括：
基于 Pod 标签、命名空间标签筛选流量，定义入站（Ingress）和出站（Egress）规则；
限制哪些 Pod 可以被访问（入站）或可以访问其他 Pod / 外部服务（出站）；
默认情况下，Pod 间可自由通信，NetworkPolicy 可实现 “默认拒绝，按需允许” 的安全隔离，增强集群网络安全性。
5. 详细描述在K8s中如何控制跨Namespace的Pod访问？
（1）NetworkPolicy：通过namespaceSelector在规则中匹配目标命名空间
（2）Service 与 Endpoint：跨命名空间访问可通过<service-name>.<Namespace
-name>.svc.cluster.local的 DNS 格式，但需结合 NetworkPolicy 限制是否允许实际通信。
- RBAC 权限控制：若涉及 API 操作（如跨命名空间查询 Pod），可通过 ClusterRole 定义跨命名空间权限，再通过 ClusterRoleBinding 绑定。
6. 举例说明K8s中都有哪些常规的维护管理操作。
节点管理：标记节点不可调度（kubectl cordon）、排空节点（kubectl drain）进行硬件维护；
资源监控：通过kubectl top、metrics-server 或 Prometheus 监控 Pod / 节点资源使用率；
日志与调试：查看 Pod 日志（kubectl logs）、进入容器调试（kubectl exec）、检查事件（kubectl get events）；
应用更新：滚动更新 Deployment（kubectl set image）、回滚错误版本（kubectl rollout undo）；
资源清理：删除无用 Pod、PV/PVC、未使用的 ConfigMap/Secret；
备份与恢复：定期备份 etcd 数据（集群状态存储）；
安全维护：更新镜像版本、轮换 Service Account 令牌、扫描镜像漏洞。
7. 如何升级K8s到新的版本？在升级过程中应该注意哪些事项？
升级步骤：
升级控制平面：先升级 kube-apiserver，再升级 controller-manager、scheduler 等组件；
升级节点：驱逐节点上的 Pod（drain），升级 kubelet 和 kube-proxy，再将节点重新加入集群（uncordon）；
验证：检查组件状态（kubectl get pods -n kube-system）、节点版本（kubectl get nodes）。
注意事项：
遵循 “小版本逐步升级” 原则（如 v1.24→v1.25→v1.26），避免跨多个次要版本直接升级；
升级前备份 etcd 数据，以便回滚；
确认集群插件（如 CNI 网络插件、Ingress 控制器）与目标版本兼容；
升级过程中控制平面可能短暂不可用，需避开业务高峰期；
升级后验证核心功能（如 Pod 调度、服务发现、网络通信）。
8. 解释ETCD及其备份和恢复的过程。
ETCD：是 Kubernetes 的分布式键值存储，用于保存集群所有状态（如 Pod、Service、配置等），是集群的 “数据库”。
备份过程：
（1）使用etcdctl工具执行快照
恢复过程：
（1）停止使用旧数据的控制平面组件（如 kube-apiserver）；
（2）从快照恢复数据
（3）重新配置控制平面组件，指向恢复后的 etcd 数据目录，重启组件
9. Kustomization在Kubernetes中的作用。
Kustomization 是 Kubernetes 的原生配置管理工具，通过kustomization.yaml文件定义配置，实现：
配置复用：基于 “基础配置” 定义不同环境（开发、测试、生产）的差异化配置（如资源限额、镜像版本），无需复制整个配置文件；
声明式管理：避免使用模板引擎（如 Helm），直接通过 YAML 文件的覆盖（overlays）机制管理配置差异；
简化维护：集中管理标签、注解、名称前缀等，减少配置冗余，便于批量修改。
10. 什么是CRD，它对K8s有什么重要意义？
CRD（CustomResourceDefinition，自定义资源定义）是 Kubernetes 中用于扩展 API 的机制，允许用户定义自己的资源类型（如Database、MessageQueue），就像内置资源（Pod、Service）一样被 Kubernetes 管理。
重要意义：
扩展 Kubernetes 的能力，使其能管理业务特定资源（如数据库实例、AI 模型）；
实现 “声明式 API” 范式，用户通过定义 CR（Custom Resource，自定义资源）描述期望状态，由控制器（如 Operator）自动维护实际状态；
简化复杂应用的管理，将业务逻辑封装为 Kubernetes 原生资源，提升运维效率。
11. CRD 的典型应用场景有哪些，举例说明。
CRD 适用于需要将自定义资源纳入 Kubernetes 管理的场景，例如：
数据库管理：定义MySQLInstance资源，通过控制器自动创建数据库 Pod、PV，并处理备份、扩容等操作（如 Percona Operator）；
消息队列：定义KafkaTopic资源，控制器自动在 Kafka 集群中创建对应的 Topic 并配置分区；
CI/CD 工作流：如 Argo Workflows 通过 CRD 定义Workflow资源，描述任务依赖和执行逻辑；
监控规则：定义CustomPrometheusRule资源，控制器自动将规则同步到 Prometheus 配置中。
12. 结合教材，解释CRD的完整创建和使用过程。
（1）创建 CRD 定义：定义资源的组（group）、版本（version）、名称（kind）等元信息
执行kubectl apply -f crd.yaml创建 CRD。
（2）创建 CR 实例：使用定义的资源类型创建具体实例：
执行kubectl apply -f db-instance.yaml创建 CR。
（3）创建控制器（Operator）：通过控制器监听 CR 的变化，实现状态同步（如创建 MySQL Pod）。可使用 Operator SDK 或 Kubebuilder 开发控制器，逻辑包括：
监听Database资源的新增 / 更新事件；
根据 CR 的spec字段创建对应的 Deployment、Service 等资源；
定期检查实际状态与spec是否一致，自动修复差异。
（4）使用与管理：通过kubectl管理 CR，如kubectl get databases查看实例，kubectl edit database mydb修改配置。
13. Gateway API有哪几个核心组件，分别有哪些作用？
Gateway API 是 Kubernetes 新一代流量管理 API，替代 Ingress，核心组件包括：
GatewayClass：定义网关类型的模板，由基础设施提供者（如 NGINX、Istio）管理，指定网关的实现方式（如控制器、配置）。
Gateway：具体的网关实例，绑定到网络端点（如 Service 的 NodePort），负责接收外部流量，关联到一个 GatewayClass。
Route（路由）：定义流量转发规则，如HTTPRoute（HTTP 流量）、GRPCRoute（GRPC 流量），指定匹配条件（如路径、主机名）和后端服务（如 Service），并关联到一个或多个 Gateway。
作用：提供更灵活的流量管理能力（如多团队共享网关、细粒度路由规则、跨命名空间路由），比 Ingress 更标准化、可扩展。
14.说明PriorityClass是在解决K8s资源争用时的调度决策原理。
PriorityClass 用于定义 Pod 的优先级（数值越高优先级越高），在资源争用时的调度逻辑如下：
当集群资源充足时，优先级不影响调度，仅作为元数据；
当资源不足（如节点 CPU / 内存不足）时：
调度器优先调度高优先级 Pod，低优先级 Pod 可能被 “挤掉”（无法调度）；
若需驱逐已有 Pod 释放资源，低优先级 Pod 会被优先驱逐（遵循 “优先级抢占” 机制），确保高优先级服务（如核心业务）的可用性。
通过 PriorityClass，可保障关键业务在资源紧张时的稳定性。
15. HPA是如何在K8s集群中实现自动扩缩容机制的？
HPA（Horizontal Pod Autoscaler，水平 Pod 自动扩缩容）通过以下流程实现自动扩缩容：
指标收集：依赖 metrics-server 或自定义指标适配器（如 Prometheus Adapter）收集 Pod 的指标（CPU 使用率、内存、自定义指标如 QPS）；
指标评估：HPA 控制器定期（默认 15 秒）检查当前指标值与目标值（如 CPU 使用率 80%）的差异；
计算副本数：根据预设算法（如期望副本数 = 当前副本数 × (当前指标值 / 目标指标值)）计算所需副本数，受限于minReplicas和maxReplicas；
执行扩缩容：HPA 通过修改 Deployment/StatefulSet 的replicas字段，触发 Pod 的创建或删除。
16.请谈谈Argo CD的核心架构组件有哪些，分别做简要说明。
Argo CD 是基于 GitOps 的持续部署工具，核心组件包括：
Repo Server：负责从 Git 仓库拉取配置代码，通过 kustomize/helm 渲染生成 Kubernetes manifests，并缓存结果。
Application Controller：核心控制器，持续监控应用的实际状态（集群内）与期望状态（Git 仓库）的差异，触发同步操作（如创建 / 更新资源）。
API Server：提供 REST API，用于接收用户操作（如创建 Application、触发同步）。
UI：Web 界面，可视化展示应用状态、同步历史、差异对比等。
Dex：身份认证组件，支持与 LDAP、OAuth2 等集成，管理用户访问权限。
17.你是如何理解CI/CD流水线技术的，它和提升企业竞争力有什么关系？
CI/CD 流水线是持续集成（Continuous Integration）和持续部署（Continuous Deployment）的自动化流程：
CI：代码提交后自动触发构建、测试（单元测试、集成测试），快速发现错误；
CD：测试通过后自动部署到开发、测试或生产环境，实现频繁、可靠的发布。
与企业竞争力的关系：
加速交付：缩短从代码开发到产品上线的周期，帮助企业快速响应市场需求（如迭代新功能、修复漏洞）；
提升质量：自动化测试减少人为错误，持续反馈机制降低发布风险；
增强协作：标准化流程促进开发、测试、运维团队协同，减少沟通成本；
迭代创新：支持小批量、高频次发布，使企业能快速验证业务假设，在竞争中保持灵活性和领先性。