2025-5-29 错题分析2

多选题

94/231、华为云应用运维管理AOM服务具有哪些功能?

容器监控

日志采集

告警管理

智能排障

好的，华为云应用运维管理 AOM 服务具备以下功能：

  • 容器监控 (Container Monitoring): AOM 提供对 Kubernetes 容器、节点、工作负载等运行状态的监控，包括 CPU、内存、网络、磁盘等指标的采集和展示，帮助用户了解容器化应用的资源使用情况和健康状况。
  • 日志采集 (Log Collection): AOM 支持从 Kubernetes 集群中的容器、节点等采集日志数据，并提供日志检索、分析和存储等功能，方便用户进行故障排查和问题分析。
  • 告警管理 (Alarm Management): AOM 允许用户基于监控指标配置告警规则，当指标达到阈值时发送告警通知，支持多种告警渠道和告警策略，帮助用户及时发现和处理应用及基础设施问题。
  • 智能排障 (Intelligent Troubleshooting): AOM 通常会集成一些智能诊断和排障工具，例如基于 AI 的异常检测、故障关联分析、根因分析等，帮助用户更快速地定位和解决问题，提高运维效率。

因此，所有列出的功能都是华为云应用运维管理 AOM 服务具备的功能。

多选题95/231、容器洞察引擎具有以下哪些特点?

开放兼容云原生技术

以应用为中心，聚焦业务指标

数据无缝关联，快捷排障

健集群诊断

好的，容器洞察引擎通常具备以下特点：

  • 开放兼容云原生技术: 容器洞察引擎通常会遵循和兼容云原生生态的技术栈，例如 Kubernetes、容器运行时 (Docker/CRI-O)、Prometheus、Grafana、OpenTelemetry 等，能够无缝集成和监控这些技术。
  • 以应用为中心，聚焦业务指标: 优秀的容器洞察引擎不仅仅关注基础设施指标，更重要的是能够从应用的角度出发，提供业务相关的关键指标监控和分析，帮助用户了解应用的健康状况和业务影响。
  • 数据无缝关联，快捷排障: 容器洞察引擎能够将来自不同来源的监控数据（例如容器指标、日志、链路追踪等）进行关联分析，帮助用户快速定位问题根源，缩短故障排除时间。
  • 健康集群诊断: 容器洞察引擎通常提供集群级别的健康诊断功能，能够监控 Kubernetes 集群的各个组件（例如控制平面、节点、存储、网络等）的健康状态，并提供告警和诊断信息，确保集群稳定运行。

因此，所有列出的特点通常都是容器洞察引擎所具备的。

多选题

96/231、Karmada控制面包含以下哪些组件?

Karmada APl Server

B

Karmada Controller Manager

Karmada Agent

ETCD

好的，Karmada 控制面包含以下组件：

  • Karmada API Server: 这是 Karmada 的核心组件，提供 RESTful API 接口，用于接收和处理用户对联邦资源的请求。它类似于 Kubernetes API Server。
  • Karmada Controller Manager: 这个组件运行着 Karmada 的核心控制逻辑，包括资源调度、策略执行、集群管理等各种控制器。它类似于 Kubernetes Controller Manager。
  • ETCD: Karmada 使用 ETCD 作为其分布式键值存储系统，用于持久化存储联邦资源和集群状态等关键信息。这与 Kubernetes 控制平面使用 ETCD 类似。

Karmada Agent 是部署在成员集群中的组件，它负责与 Karmada 控制面通信，并根据控制面的指令在成员集群中执行资源操作。因此，Karmada Agent 不属于 Karmada 控制面的组件。

总结：

Karmada 控制面包含：

  • Karmada API Server
  • Karmada Controller Manager
  • ETCD
多选题

100/231、以下关于List-Watch机制的特点的描述，正确的是哪些选项?

消息可靠性

消息实时性

消息顺序性

高性能

好的，关于 Kubernetes (K8S) 中的 List-Watch 机制的特点，以下选项是正确的：

  • 消息可靠性 (Message Reliability): List-Watch 机制通过 HTTP 长连接保持与 Kubernetes API Server 的连接，并使用 ResourceVersion 来确保客户端不会丢失事件。当连接断开时，客户端可以根据上次收到的 ResourceVersion 重新发起 Watch 请求，从而保证消息的可靠性。
  • 消息实时性 (Message Real-time): 一旦 Kubernetes API Server 中被监听的资源发生变化，Watch 连接会立即将事件推送给客户端，从而实现近实时的事件通知。
  • 高性能 (High Performance): 相较于轮询 (Polling) 机制，List-Watch 通过长连接和事件驱动的方式，避免了频繁的请求和响应，显著降低了 API Server 的负载，并提高了性能。只有在资源发生变化时才会产生网络流量。

消息顺序性 (Message Orderliness): 虽然 List-Watch 机制力求保证事件的顺序性，但在分布式系统中，尤其是在连接中断和重连的情况下，并不能严格保证绝对的消息顺序。API Server 会尽力按事件发生的顺序发送通知，但在复杂的网络环境或客户端处理延迟等因素下，客户端收到的事件顺序可能与实际发生的顺序略有偏差。因此，将消息顺序性作为 List-Watch 的一个绝对特点是不准确的。

总结：

List-Watch 机制的主要特点是：

  • 消息可靠性
  • 消息实时性
  • 高性能

消息顺序性 虽然是其努力保证的目标，但并非一个完全可靠的特性。因此，如果要求是绝对正确的特点，那么不应选择消息顺序性。如果从实践角度，List-Watch 在大多数情况下能保持较好的顺序性，则可能存在争议。但从严格定义上来说，可靠性和实时性以及性能是其更核心和明确的特点。

根据严格的定义，正确的选项是：

  • 消息可靠性
  • 消息实时性
  • 高性能
多选题 101/231、以下关于将指定Pod调度至特定Node节点的方式的描述，正确的是哪些项?

通过nodeSelector将Pod调度到匹配label的Node节点上

通过nodeName将Pod调度到期望的Node节点上

通过设置podAffinity，基于Pod的标签来选择Node，仅调度到满足条件Pod所在的Node上

通过没置nodeAffinitv中的requiredDurinaSchedulinalgnoredDuringExerution细粒度描述选择Node所必备的条件

好的，以下关于将指定 Pod 调度至特定 Node 节点的方式的描述，正确的是：

  • 通过 nodeSelector 将 Pod 调度到匹配 label 的 Node 节点上。 这是正确的。nodeSelector 是 PodSpec 中的一个字段，允许您指定一组 Node label，只有包含所有这些 label 的 Node 才能被调度该 Pod。
  • 通过 nodeName 将 Pod 调度到期望的 Node 节点上。 这是正确的。nodeName 是 PodSpec 中的另一个字段，允许您直接指定 Pod 应该被调度到的 Node 的名称。这是一种强制调度方式，会绕过正常的调度器选择过程。
  • 通过设置 podAffinity，基于 Pod 的标签来选择 Node，仅调度到满足条件 Pod 所在的 Node 上。 这是正确的。podAffinity 允许您定义规则，使 Pod 调度到已经运行了满足特定标签的 Pod 的 Node 上（或避免调度到这些 Node 上）。
  • 通过设置 nodeAffinity 中的 requiredDuringSchedulingIgnoredDuringExecution 细粒度描述选择 Node 所必备的条件。 这是正确的。nodeAffinity 提供了比 nodeSelector 更灵活的 Node 选择策略。requiredDuringSchedulingIgnoredDuringExecution 是一种硬性约束，只有满足条件的 Node 才能被调度该 Pod。ignoredDuringExecution 表示即使在 Pod 运行后 Node 的标签不再满足条件，Pod 也不会被驱逐。

总结：

所有列出的选项都是将指定 Pod 调度至特定 Node 节点的有效方式。它们提供了不同级别的灵活性和控制：

  • nodeSelector: 基于 Node 标签的简单匹配。
  • nodeName: 直接指定 Node 名称的强制调度。
  • podAffinity: 基于已存在 Pod 的标签进行亲和性调度。
  • nodeAffinity (特别是 requiredDuringSchedulingIgnoredDuringExecution): 基于 Node 标签的更灵活和强大的匹配规则。
多选题102/231、以下关于lstio中Gateway描述，正确的有哪几项?

Gateway可以指定进入或离开网格的流量

B

Gateway配青应用于网格边缘的独立的Envoy代理上

Gateway配置应用于服务负载的 Envoy代理上

Gateway能够配置分发目标地址的流量

好的，以下关于 Istio 中 Gateway 的描述，正确的是：

  • Gateway 可以指定进入或离开网格的流量。 这是正确的。Istio Gateway 用于管理进出服务网格的流量，可以配置入口 (ingress) 和出口 (egress) 流量。
  • Gateway 配置应用于网格边缘的独立的 Envoy 代理上。 这是正确的。Gateway 的配置（例如监听的端口、TLS 设置、路由规则等）会应用到部署在网格边缘的专门的 Envoy 代理实例上，这些 Envoy 代理与应用服务自身的 Sidecar 代理是分开的。
  • Gateway 能够配置分发目标地址的流量。 这是正确的。Gateway 的路由规则可以根据请求的各种属性（例如主机名、路径、Header 等）将流量转发到网格内部特定的服务或工作负载。

Gateway 配置应用于服务负载的 Envoy 代理上 是错误的。Gateway 的配置是应用于独立的 Gateway Envoy 代理实例，而不是应用服务 Pod 中的 Sidecar 代理。Sidecar 代理主要负责处理 Pod 内部的流量和服务间的通信，其配置由 VirtualService、DestinationRule 等资源管理。

总结：

正确的选项是：

  • Gateway 可以指定进入或离开网格的流量。
  • Gateway 配置应用于网格边缘的独立的 Envoy 代理上。
  • Gateway 能够配置分发目标地址的流量。
多选题
103/231、应用服务网格ASM支持以下哪几种故障注入?
时延故障
探针故障
中断故障
总线故障

好的，应用服务网格（ASM）通常支持以下几种故障注入类型，以帮助用户测试其应用程序的弹性和容错能力：

  • 时延故障 (Latency Fault Injection): 这是 ASM 最常见的故障注入类型之一。它允许在服务之间的通信中引入预定义的延迟，模拟网络延迟增加或服务响应变慢的情况，以测试应用程序在这些场景下的表现。
  • 中断故障 (Abort Fault Injection): 中断故障允许在服务之间的通信中模拟连接中断、服务返回错误（例如 HTTP 错误码）或其他类型的通信失败。这可以测试应用程序在依赖服务不可用或返回错误时的处理能力。

探针故障 (Probe Fault Injection) 通常不是 ASM 直接提供的故障注入类型。探针（例如 Kubernetes 的 Readiness 和 Liveness Probes）是应用程序自身健康检查的机制。虽然可以通过配置不正确的探针来间接导致类似故障的效果，但这不属于 ASM 主动注入的故障。

总线故障 (Bus Fault Injection) 这个术语在应用服务网格的故障注入场景中不太常见。总线故障通常与硬件层面或操作系统底层的通信总线错误相关，这超出了应用服务网格的控制范围。ASM 主要关注应用层和网络层的故障注入。

总结：

应用服务网格 ASM 通常直接支持的故障注入类型包括：

  • 时延故障
  • 中断故障

探针故障 和 总线故障 不是 ASM 常规提供的故障注入类型。

多选题104/231、服务网格以基础设施的方式提供哪些无侵入的能力?

连接


安全

可监控性

测试

好的，服务网格以基础设施的方式为应用程序提供以下无侵入的能力：

  • 连接 (Connectivity): 服务网格通过在应用程序 Pod 旁边注入 Sidecar 代理，透明地管理服务之间的网络连接。它负责服务发现、请求路由、负载均衡等，无需应用程序代码感知底层网络拓扑。
  • 安全 (Security): 服务网格可以透明地为服务间的通信提供安全保障，例如通过双向 TLS (mTLS) 实现身份验证和加密，而无需修改应用程序代码。它还可以实施细粒度的访问控制策略。
  • 可监控性 (Observability): 服务网格能够自动收集服务间的通信数据，包括请求延迟、错误率、流量指标等，并将其暴露给监控和追踪系统。这为应用程序提供了全面的可观测性，方便进行性能分析和故障排查，同样无需应用程序进行额外的埋点。
  • 测试 (Testing): 服务网格提供的流量管理能力，例如流量分流、流量镜像、故障注入等，可以用于在不影响生产环境的情况下进行各种测试，例如灰度发布、A/B 测试、性能测试和弹性测试。这些测试能力对应用程序是透明的。

总结：

服务网格以基础设施的方式提供的无侵入能力包括：

  • 连接
  • 安全
  • 可监控性
  • 测试
多选题105/231、某金融公司将把物理数据中心中的部分业务部署到华为云上，为实现以下不同场景中云上云下和云内的互通，可以采取对应的哪些措施?场景一:金融投资业务部署在物理数据中心中，要求能够与云上门户业务互通，场景二:门户业务部署在北京四。上海二、广州区域中，要求各区域之间互通
场景一:使用VPCPeering连接云上云下数据中心
场景一:使用VPN实现云下云上数据中心互通
场景二:使用VPCPeering连接云上各区域数据中心
场景二:使用云连接实现云上各区域间数据中心互通

场景一:使用VPCPeering连接云上云下数据中心
场景二:使用云连接实现云上各区域间数据中心互通

好的，针对该金融公司在不同场景下实现云上云下和云内互通的需求，可以采取以下措施：

场景一：金融投资业务部署在物理数据中心中，要求能够与云上门户业务互通

  • 场景一：使用 VPN 实现云下云上数据中心互通。这是实现物理数据中心与华为云 VPC 之间安全可靠连接的常用方法。通过 VPN 连接，可以将物理数据中心和云上的 VPC 建立加密的通道，实现网络互通。
  • 场景一：使用专线接入实现云下云上数据中心互通（选项中未直接提供，但通常是更稳定和高带宽的选择）。专线接入提供一条物理的、独占的线路连接物理数据中心和华为云，具有更高的带宽和更低的延迟，适合对网络质量要求较高的金融业务。

选项 A “场景一：使用 VPC Peering 连接云上云下数据中心” 是不适用的。 VPC Peering 连接只能在同一个区域内的不同 VPC 之间建立，无法直接连接云上的 VPC 和物理数据中心。

场景二：门户业务部署在北京四、上海二、广州区域中，要求各区域之间互通

  • 场景二：使用云连接实现云上各区域间数据中心互通。云连接（Cloud Connect）是华为云提供的区域间高速互联服务，可以轻松实现不同区域的 VPC 之间的互通，满足门户业务在不同地域之间进行数据同步和访问的需求。
  • 场景二：使用 VPC Peering 连接云上各区域数据中心。这是可行的，VPC Peering 连接可以用于连接同一区域内的不同 VPC，也可以用于连接同一账号下不同区域的 VPC。需要在每两个需要互通的 VPC 之间创建 Peering 连接。

总结：

因此，以下措施是可行的：

  • 场景一：使用 VPN 实现云下云上数据中心互通
  • 场景二：使用云连接实现云上各区域间数据中心互通
  • 场景二：使用 VPC Peering 连接云上各区域数据中心

选项 A “场景一：使用 VPC Peering 连接云上云下数据中心” 是错误的。

多选题106/231、以下关于密钥使用方式的描述，哪些项是错误的?
密钥可以作为文件挂载到工作负载中数据卷中使用
密钥的Value需要用Base64或ASCII等方式编码
密钥可以在Pod中设置为环境变量
通过密钥设置工作负载环境变量还可以在界面上进行操作，在创建工作负载时，设置容器的高级设置，选择Secret即可配置

密钥的Value需要用Base64或ASCII等方式编码
通过密钥设置工作负载环境变量还可以在界面上进行操作，在创建工作负载时，设置容器的高级设置，选择Secret即可配置

好的，关于密钥（Secret）使用方式的描述，以下哪些项是错误的：

  • 密钥的 Value 需要用 Base64 或 ASCII 等方式编码。这是错误的。Kubernetes Secret 的 data 字段中的值必须使用 Base64 编码。虽然 ASCII 字符在 Base64 编码后仍然是 ASCII 字符，但直接使用未编码的 ASCII 值是不符合要求的。stringData 字段允许直接提供字符串值，Kubernetes 会自动进行 Base64 编码。
  • 通过密钥设置工作负载环境变量还可以在界面上进行操作，在创建工作负载时，设置容器的高级设置，选择 Secret 即可配置。这在概念上是正确的，但描述可能不够精确，具体界面操作会因 Kubernetes 管理工具或平台（例如华为云 CCE 控制台）而异。通常，在创建工作负载时，管理界面会提供选项允许用户选择已创建的 Secret，并将其中的键值对配置为容器的环境变量。因此，这个描述本身不能完全算作错误，但可能不够通用。

让我们更仔细地审视每个选项：

  • 密钥可以作为文件挂载到工作负载中数据卷中使用。这是正确的。可以将 Secret 作为 Volume 挂载到 Pod 的文件系统中，容器可以像访问普通文件一样读取 Secret 的内容。
  • 密钥可以在 Pod 中设置为环境变量。这是正确的。可以将 Secret 中的键值对注入到 Pod 容器的环境变量中，应用程序可以通过环境变量来获取敏感信息。
  • 密钥的 Value 需要用 Base64 或 ASCII 等方式编码。这是错误的，必须使用 Base64 编码 data 字段的值。
  • 通过密钥设置工作负载环境变量还可以在界面上进行操作，在创建工作负载时，设置容器的高级设置，选择 Secret 即可配置。这在实践中通常是正确的，各种 Kubernetes 管理界面通常会提供这种便捷的操作方式。

因此，唯一明确错误的描述是：“密钥的 Value 需要用 Base64 或 ASCII 等方式编码”。 ASCII 本身不是一种编码方式，Base64 是一种特定的编码方式，而 Secret 的 data 字段强制要求 Base64 编码。

最终答案：

错误的是：

  • 密钥的 Value 需要用 Base64 或 ASCII 等方式编码
多选题107/231、华为云AOM应用运维管理架构分为以下哪几层?

业务计算层

传输存储层

数据采集层

数据应用层


业务计算层 传输存储层 数据采集层

好的，华为云 AOM 应用运维管理架构通常可以划分为以下几层：

  • 数据采集层: 这是 AOM 架构的基础，负责从各种数据源收集运维数据，包括：
    • 监控数据: 指标 (Metrics)，例如 CPU 使用率、内存使用率、网络流量、磁盘 IO 等。
    • 日志数据: 应用程序日志、系统日志、中间件日志等。
    • 链路追踪数据: 分布式追踪 (Tracing) 信息，记录请求在不同服务之间的调用路径和延迟。
    • 事件数据: Kubernetes 事件、告警事件等。
  • 传输存储层: 这一层负责对采集到的海量运维数据进行高效的传输、存储和管理。通常会使用分布式存储系统和消息队列等技术，以保证数据的可靠性、可扩展性和高吞吐量。
  • 数据应用层: 这是 AOM 的核心层，基于存储的运维数据提供各种应用功能，例如：
    • 监控展示: 提供仪表盘、图表等可视化方式展示监控指标。
    • 告警管理: 配置告警规则、发送告警通知、告警抑制等。
    • 日志分析: 提供日志检索、过滤、聚合、分析等功能。
    • 链路追踪分析: 展示请求调用链、分析性能瓶颈和错误。
    • 智能运维 (AIOps): 利用机器学习等技术进行异常检测、根因分析、容量预测等。
    • 报表与分析: 生成各种运维报表，帮助用户了解系统运行状况和趋势。

业务计算层 通常不是 AOM 架构的直接组成部分。AOM 主要关注对业务运行状态的监控、管理和优化，而业务计算本身是由应用程序所在的计算资源（例如 ECS、容器等）来承担的。AOM 会监控这些计算资源的运行情况，但不会直接参与业务逻辑的计算。

总结：

华为云 AOM 应用运维管理架构主要分为以下几层：

  • 数据采集层
  • 传输存储层
  • 数据应用层

业务计算层 不属于 AOM 的核心架构分层。

多选题
108/231、运维分为哪些类别?
应用运维
系统运维
运维研发
数据库运维

好的，运维通常可以分为以下类别：

  • 应用运维 (Application Operations): 专注于保障特定应用程序的稳定运行、性能优化、故障处理和版本发布等。应用运维人员需要深入了解应用程序的架构、配置、依赖和业务逻辑。
  • 系统运维 (System Operations): 负责管理和维护底层的基础设施，包括服务器（物理机和虚拟机）、操作系统、存储、网络等。系统运维的目标是确保基础设施的稳定、安全和高效运行，为上层应用提供可靠的支撑。
  • 数据库运维 (Database Operations): 专注于数据库系统的管理和维护，包括数据库的安装配置、性能调优、备份恢复、高可用架构搭建、安全管理等。数据库是许多应用的关键组件，需要专业的运维技能。
  • 运维研发 (Operations Development / SRE - Site Reliability Engineering): 这是一个相对新兴的类别，强调通过软件工程的方法解决运维问题，提高运维效率和自动化水平。运维研发人员通常具备开发能力，负责构建和维护运维工具、自动化脚本、监控系统、CI/CD 流水线等。

因此，以上所有类别通常都被认为是运维的不同方面或专业领域。

多选题
109/231、Karmada Controller Manager负责初始化相关的controllers，包合的controller主要有以下哪些?
binding controller
execution controller
propagation policy controller
cluster controller

binding controller
execution controller
propagation policy controller

好的，Karmada Controller Manager 负责初始化和运行多个控制器，以实现跨集群的资源管理和调度。以下列出的控制器都是 Karmada Controller Manager 中包含的主要控制器：

  • Binding Controller (绑定控制器): 该控制器负责将满足调度策略的联邦资源绑定到目标成员集群。它监听 PropagationPolicy 和 Cluster 对象的变化，并创建相应的 ResourceBinding 对象，指示资源应该部署到哪些集群。
  • Execution Controller (执行控制器): 该控制器负责在成员集群中实际创建、更新或删除由 ResourceBinding 关联的资源。它监听 ResourceBinding 对象的变化，并与成员集群的 Karmada Agent 通信，执行具体的资源操作。
  • Propagation Policy Controller (分发策略控制器): 该控制器负责处理 PropagationPolicy 对象。PropagationPolicy 定义了联邦资源应该分发到哪些成员集群的策略（例如，基于标签选择器）。Propagation Policy Controller 监听 PropagationPolicy 的创建、更新和删除，并根据策略创建或更新相应的 ResourceBinding 对象。
  • Cluster Controller (集群控制器): 该控制器负责管理 Karmada 中的成员集群。它监听 Cluster 对象的创建、更新和删除，维护集群的状态信息（例如，是否可达、资源使用情况等），并负责集群的注册和注销。

因此，Karmada Controller Manager 包含以上所有列出的主要控制器。

多选题
模式?
1101231、在多个集群中部署的应用可以通过公网域名实现统一的访问，
主备模式
均衡模式
自适应模式
自定义模式

主备模式
均衡模式
自适应模式
自定义模式

好的，在多个集群中部署的应用可以通过公网域名实现统一的访问，常见的模式包括：

  • 主备模式 (Active-Passive Mode): 在这种模式下，只有一个集群对外提供服务（处于 Active 状态），其他的集群作为备份（处于 Passive 或 Standby 状态）。当主集群发生故障时，流量会切换到备集群。虽然可以通过公网域名访问，但域名通常指向当前处于 Active 状态的集群的负载均衡器或入口网关。
  • 均衡模式 (Load Balancing Mode): 在这种模式下，通过一个或多个公网域名，流量会被分发到多个后端集群中运行的应用实例。这可以通过全局负载均衡器 (Global Load Balancer, GLB) 或 DNS 级别的负载均衡来实现。每个集群都参与处理一部分流量，从而提高整体的吞吐量和可用性。
  • 自适应模式 (Adaptive Mode): 这种模式通常是均衡模式的一种更智能的变体。流量的分发可能不是静态的，而是根据各个集群的健康状况、负载水平、性能指标等动态调整。全局负载均衡器或智能 DNS 系统会根据实时数据将更多流量导向更健康的或负载较低的集群。
  • 自定义模式 (Custom Mode): 这指的是根据具体业务需求和架构设计实现的流量分发策略。例如，可以基于地理位置、用户属性、请求内容等自定义规则将流量路由到特定的集群。这可能涉及到更复杂的全局流量管理系统或应用层的路由逻辑。

总结：

在多个集群中部署的应用可以通过公网域名实现统一的访问，常见的模式包括：

  • 主备模式
  • 均衡模式
  • 自适应模式
  • 自定义模式

这些模式各有优缺点，适用于不同的高可用和流量管理需求。通常会结合使用全局负载均衡、DNS 管理、服务发现等技术来实现跨集群的统一访问。

多选题 113/231、某Kubenetes集群各Node节点的配置为4核8G。在创建负载时，需要将容器能够使用的CPU资源限制在1核以内。则以下哪些选项的配置是正确的?
spec.containers.resources.reguests.cpu=1
B
speccontainers.resources,limits.cpu=1
spec.containers.resources.requests.cpu=1000m
D
spec.containersresources,limits.cpu=1000m

好的，为了将 Kubernetes 容器能够使用的 CPU 资源限制在 1 核以内，以下选项的配置是正确的：

  • spec.containers.resources.limits.cpu=1：这是正确的。limits.cpu 字段用于设置容器可以使用的 CPU 资源的最大值。设置为 1 表示容器最多可以使用 1 个 CPU 核。
  • spec.containers.resources.limits.cpu=1000m：这也是正确的。在 Kubernetes 中，CPU 资源可以用小数表示，也可以用毫核 (millicores) 表示。1 核等于 1000 毫核。因此，1000m 也表示容器最多可以使用 1 个 CPU 核。

以下选项的配置是用于设置 CPU 请求量，而不是限制使用量，因此不符合题目要求：

  • spec.containers.resources.requests.cpu=1：requests.cpu 字段用于设置容器启动时 Kubernetes 需要为其预留的 CPU 资源量。这并不限制容器可以使用的最大 CPU 资源。
  • spec.containers.resources.requests.cpu=1000m：同样，requests.cpu 设置的是容器启动时请求的 CPU 资源量，而不是限制其使用的上限。

总结：

要将容器能够使用的 CPU 资源限制在 1 核以内，正确的配置选项是：

  • spec.containers.resources.limits.cpu=1
  • spec.containers.resources.limits.cpu=1000m
多选题114/231、以下哪些命令可用于查看名为nginx的Deployment的历史更新情况?
kubectl describe nginx deployment nginx
kubectl get deployment nginx -o yaml
kubectl rollout status deployment nginx
kubectl rollout history deployment nginx

kubectl describe nginx deployment nginx
kubectl get deployment nginx -o yaml
kubectl rollout status deployment nginx

好的，以下命令可用于查看名为 nginx 的 Deployment 的历史更新情况：

  • kubectl rollout history deployment nginx: 这是查看 Deployment 历史更新情况的专用命令。它会列出 Deployment 的所有 revision 及其相关的变更信息，例如更新时间、原因、配置等。

以下命令虽然可以提供 Deployment 的信息，但不是专门用于查看历史更新情况的：

  • kubectl describe deployment nginx: 这个命令会显示 Deployment 的详细信息，包括当前的副本数、更新策略、事件等，但不会详细列出历史 revision 的配置变更。
  • kubectl get deployment nginx -o yaml: 这个命令会以 YAML 格式输出 Deployment 的当前配置信息，也无法直接查看历史更新记录。
  • kubectl rollout status deployment nginx: 这个命令用于查看当前 Deployment 的滚动更新状态，例如正在更新的副本数、是否已完成等，而不是历史更新记录。

因此，查看 Deployment 历史更新情况的正确命令是：

  • kubectl rollout history deployment nginx
多选题116/231、lstio以非侵入的方式提供了哪几种遥测类型?
Metrics √
Distributed Traces v
Service Discovery
Access Logs √

Metrics √
Distributed Traces v
Access Logs √

好的，Istio 以非侵入的方式提供了以下几种遥测类型：

  • Metrics (指标): Istio 自动收集服务网格中服务的各种指标，例如请求量、延迟、错误率等。这些指标可以用于监控服务的健康状况和性能。您可以通过 Prometheus 等工具查询和可视化这些指标.
  • Distributed Traces (分布式追踪): Istio 能够生成分布式追踪数据，记录请求在服务网格中的调用链路。这有助于理解服务之间的依赖关系和定位性能瓶颈。Istio 支持 Jaeger、Zipkin 等追踪后端。
  • Access Logs (访问日志): Istio 的 Sidecar 代理（Envoy）可以记录每个请求的详细信息，包括请求时间、来源、目标、状态码、延迟等。这些访问日志对于审计、故障排除和流量分析非常有用。您可以配置 Istio 将访问日志输出到标准输出、文件或特定的日志收集系统。

Service Discovery (服务发现) 是 Istio 的核心功能，它使得服务能够自动发现和连接到网格中的其他服务，但这通常不被归类为遥测的类型。遥测更侧重于收集和报告关于服务行为的数据。

因此，正确的选项是：

  • Metrics
  • Distributed Traces
  • Access Logs
多选题
120/231、以下关于nodeAfnity(节点亲和)中字段的描述，哪些是正确的?
In: label 的值在某个列表中
Notln: label 的值不在某个列表中
Lt; label 的值小于某个值
DoesNotExist:某个label 不存在

In: label 的值在某个列表中
Notln: label 的值不在某个列表中
Lt; label 的值小于某个值
DoesNotExist:某个label 不存在

好的，以下关于 nodeAffinity（节点亲和性）中字段的描述，正确的是：

  • In: 当 Node 上的指定 label 的值存在于 values 列表中时，亲和性条件满足。
  • NotIn: 当 Node 上的指定 label 的值不存在于 values 列表中时，亲和性条件满足。
  • DoesNotExist: 当 Node 上不存在指定的 label 时，亲和性条件满足。

< (Lt; label 的值小于某个值) 不是 nodeAffinity 中直接使用的操作符。nodeAffinity 主要基于标签的精确匹配或集合关系进行选择。对于数值类型的标签比较，通常需要借助更高级的调度器扩展或自定义调度器逻辑来实现。Kubernetes 内置的 nodeAffinity 机制主要关注标签是否存在以及是否在给定的值列表中。

总结：

正确的描述是：

  • In: label 的值在某个列表中
  • NotIn: label 的值不在某个列表中
  • DoesNotExist: 某个 label 不存在
多选题122/231、以下哪些是Grafana官方支持的数据源?
Elasticsearch
Prometheus
Oracle
MysQL

Elasticsearch
Prometheus
Oracle
MysQL

好的，以下是 Grafana 官方支持的数据源：

  • Elasticsearch
  • Prometheus
  • MySQL

虽然 Oracle 有 Grafana Enterprise 插件，但它不像 Elasticsearch、Prometheus 和 MySQL 那样被列为核心的、开源支持的数据源。但是，根据 Grafana 的版本（Enterprise 与开源）和可用的插件，Oracle 可以 作为数据源使用。

因此，严格来说，基于核心的、开源版本官方支持的数据源：

  • Elasticsearch
  • Prometheus
  • MySQL

所以，正确的选项是 A、B 和 D。

多选题124/231、在使用多云容器平台MCP进行计算资源合理调配时，以下描述正确的是哪些项?
对于A1、基因测序场景，可将计算业务部署在云上，利用云提供特殊硬件算力
非特殊硬件需求的业务可以部署在私有云
资源按需采购，消除闲置
支持华为云CCE Turbo集群

好的，以下关于在使用多云容器平台 MCP 进行计算资源合理调配时的描述，正确的是：

  • 对于 AI、基因测序场景，可将计算业务部署在云上，利用云提供特殊硬件算力。 这是正确的。公有云通常提供各种加速计算硬件，例如 GPU、FPGA 等，非常适合 AI 和基因测序等需要大量并行计算的场景。MCP 可以帮助将这些工作负载调度到具备相应能力的云资源上。
  • 非特殊硬件需求的业务可以部署在私有云。 这是正确的。对于对硬件没有特殊要求的通用计算任务，可以部署在成本相对较低或符合合规要求的私有云环境中，MCP 可以统一管理这些资源。
  • 资源按需采购，消除闲置。 这是 MCP 的一个重要优势。通过统一管理多个云平台的资源，可以根据实际需求动态地分配和调整计算资源，避免在单个云或私有云中出现资源闲置的情况，从而优化成本。
  • 支持华为云 CCE Turbo 集群。 这是正确的。MCP 作为多云管理平台，通常会支持主流的 Kubernetes 服务，包括华为云的 CCE 和 CCE Turbo 集群，以便统一纳管和调度这些集群中的计算资源。

总结：

所有列出的选项都是在使用多云容器平台 MCP 进行计算资源合理调配时的正确描述。MCP 的核心价值在于能够跨多个云环境和私有云统一管理和调度计算资源，从而实现成本优化、弹性伸缩和利用各平台的独特优势。

多选题 125/231、Kubermetes中，Pod创建完成后，通过Kubectl describe pod spod各>可查看Pod中容器的状态，其

状态包括以下哪些选项?

Waiting

Running

Restarting

Terminated

好的，Kubernetes 中，当 Pod 创建完成后，通过 kubectl describe pod <pod_name> 可以查看 Pod 中容器的状态，其状态包括以下选项：

  • Waiting: 容器处于等待状态，表示容器还没有开始运行。这可能是因为需要拉取镜像、等待其他容器启动、或者处于 Pod 的初始化容器 (init containers) 阶段。
  • Running: 容器处于运行状态，表示容器已经成功启动并且正在执行其预定的进程。
  • Terminated: 容器处于终止状态，表示容器已经完成运行并且已经退出。这可能是因为容器中的进程正常结束，或者因为发生了错误而退出。kubectl describe pod 会显示容器的退出码和终止原因。
  • Restarting: 容器处于重新启动状态，表示容器由于某种原因（例如进程崩溃）而退出，并且 Kubernetes 正在尝试重新启动它。Pod 的 restartPolicy (例如 Always, OnFailure, Never) 决定了容器在何种情况下会被重新启动。

因此，所有列出的选项都是 Pod 中容器可能具有的状态。

127/231、以下属于CCE亲和/反亲和调度特性中可配置的“简易调度策略”类型的是哪些项?多选题

工作负载和区域的亲和性

工作负载和可用区的亲和性 √

工作负载和节点的亲和性√

工作负载间的亲和性 V

好的，华为云容器引擎 CCE 的亲和/反亲和调度特性中，可配置的“简易调度策略”类型包括：

  • 工作负载和可用区的亲和性 (Workload and Availability Zone Affinity): 允许将工作负载调度到指定的可用区，或避免调度到某些可用区，以提高容灾能力或满足特定的地域性需求。
  • 工作负载和节点的亲和性 (Workload and Node Affinity): 允许将工作负载调度到满足特定标签的节点上，或避免调度到某些节点，以利用节点的特定资源或进行节点隔离。
  • 工作负载间的亲和性 (Workload Affinity/Anti-affinity): 允许将某些工作负载调度到一起（亲和性），或者避免将某些工作负载调度到同一个节点（反亲和性），以提高性能（例如将密切相关的服务放在一起）或提高可用性（例如将同一服务的不同副本分散到不同节点）。

工作负载和区域的亲和性 (Workload and Region Affinity) 通常不是一个直接在 CCE 亲和/反亲和调度策略中配置的“简易调度策略”类型。区域 (Region) 是比可用区 (Availability Zone) 更大的地理范围。跨区域的亲和性调度通常涉及到更复杂的跨地域部署和流量管理策略，可能需要借助多可用区部署和全局负载均衡等更高层次的机制来实现，而不是直接通过节点亲和性配置。

总结：

属于 CCE 亲和/反亲和调度特性中可配置的“简易调度策略”类型的有：

  • 工作负载和可用区的亲和性
  • 工作负载和节点的亲和性
  • 工作负载间的亲和性
多选题128/231、以下关于ConfgMap和Secret的相同点的描述，正确的是哪些项?
key-value键值对的形式
属于某个特定的 namespace
可作为容器的环境变量被 Pod 引用
可作为 Volume 挂载到 Pod 上

好的，以下关于 ConfigMap 和 Secret 的相同点的描述，正确的是：

  • Key-value 键值对的形式: ConfigMap 和 Secret 都以 key-value 对的形式存储数据。ConfigMap 通常用于存储非敏感的配置信息，而 Secret 用于存储敏感信息，但它们的数据组织结构都是键值对。
  • 属于某个特定的 namespace: ConfigMap 和 Secret 都是 Kubernetes 命名空间 (namespace) 级别的资源对象。它们在创建时会关联到一个特定的 namespace，并且只能被同一个 namespace 中的 Pod 和其他资源引用。
  • 可作为容器的环境变量被 Pod 引用: Pod 的容器可以通过配置环境变量的方式来使用 ConfigMap 和 Secret 中存储的数据。可以将 ConfigMap 或 Secret 中的某个 key 映射为容器的环境变量。
  • 可作为 Volume 挂载到 Pod 上: ConfigMap 和 Secret 都可以作为 Volume 挂载到 Pod 的文件系统中。Pod 中的容器可以像访问普通文件一样读取 Volume 中挂载的 ConfigMap 或 Secret 的内容。

因此，所有列出的选项都是 ConfigMap 和 Secret 的相同点。 它们都用于向 Pod 提供配置信息，但 Secret 额外提供了存储和管理敏感信息的能力。

多选题

129/231、以下关于istio中Galley组件的描述，正确的有哪几项?

Galley作为负责配置管理的组件


Galley能够验证配置信息的格式和内容的正确性

Galley能够提供流量管理的功能

Galley能够将配置信息提供给管理面的Pilot使用

好的，以下关于 Istio 中 Galley 组件的描述，正确的是：

  • Galley 作为负责配置管理的组件: 这是正确的。Galley 是 Istio 的配置管理中心组件，负责接收、验证、处理和分发 Istio 的配置信息。
  • Galley 能够验证配置信息的格式和内容的正确性: 这是正确的。Galley 具有配置验证的功能，可以根据 Istio 的 API 定义和语义规则，对用户提交的配置信息进行格式和内容的校验，防止错误的配置被下发到数据平面。
  • Galley 能够将配置信息提供给管理面的 Pilot 使用: 这是正确的。Galley 充当控制平面中 Pilot 等组件的配置信息来源。Pilot 通过与 Galley 交互，获取最新的服务发现信息和流量管理规则等配置，然后将这些配置转换为数据平面代理（Envoy）可以理解的格式进行下发。

Galley 能够提供流量管理的功能 是不完全准确的。流量管理的核心功能（例如路由、负载均衡、流量策略等）是由 Pilot 组件负责实现的，并通过配置下发到数据平面的 Envoy 代理来执行。Galley 的作用是管理和分发配置，为流量管理功能的实现提供基础。

总结：

正确的选项是：

  • Galley 作为负责配置管理的组件
  • Galley 能够验证配置信息的格式和内容的正确性
  • Galley 能够将配置信息提供给管理面的 Pilot 使用
多选题130/231、以下关于istio中VirtualService的描述，正确的有哪几项?
VirtualService由一组路由规则组成 v
VirtualService能够对服务实体进行寻址 v
VirtualService负责启用应用程序的入口流量 x
VirtualService能够配置流量权重分配 v

好的，以下关于 Istio 中 VirtualService 的描述，正确的是：

  • VirtualService 由一组路由规则组成。 这是正确的。VirtualService 的核心是定义了一系列路由规则，这些规则描述了如何将请求转发到网格内的不同服务或服务版本。
  • VirtualService 能够对服务实体进行寻址。 这是正确的。VirtualService 通过 hosts 字段指定了可以被寻址的目标主机名（可以是内部服务名或外部服务名）。当请求的目标主机与 hosts 匹配时，VirtualService 的路由规则将被应用。
  • VirtualService 能够配置流量权重分配。 这是正确的。VirtualService 的路由规则可以配置流量权重，将一定比例的流量导向不同的后端服务版本（在 destination 中指定 weight）。这对于实现灰度发布、A/B 测试等场景非常重要。

VirtualService 负责启用应用程序的入口流量 是不完全准确的。虽然 VirtualService 可以配置如何路由进入网格的流量，但真正负责接收和处理入口流量的组件通常是 Gateway。Gateway 定义了网格的入口点（例如监听的端口、协议、TLS 配置等），而 VirtualService 则定义了通过 Gateway 进入的流量应该如何被路由到内部服务。VirtualService 也可以用于配置网格内部服务之间的流量路由，而不仅仅是入口流量。

总结：

正确的选项是：

  • VirtualService 由一组路由规则组成
  • VirtualService 能够对服务实体进行寻址
  • VirtualService 能够配置流量权重分配
多选题
133/231、当用户需要在CCE集群中部罢工作负载时，可以使用以下哪些途径开展集群部罢工作?
使用CCE负载管理主界面开展部署 v
使用后台yam方式部署 v
使用后台API方式部署 v
使用Helm工具部署 x

好的，当用户需要在华为云容器引擎 CCE 集群中部署工作负载时，可以使用以下途径开展集群部署工作：

  • 使用 CCE 负载管理主界面开展部署: 华为云 CCE 控制台提供了图形化的界面，用户可以通过 Web 页面方便地创建和管理各种工作负载，例如 Deployment、StatefulSet、DaemonSet、Job 等。
  • 使用后台 YAML 方式部署: 用户可以编写 Kubernetes 资源对象的 YAML 配置文件，然后使用 kubectl apply -f <yaml_file> 等命令将这些配置应用到 CCE 集群中，从而部署工作负载。
  • 使用后台 API 方式部署: Kubernetes 提供了 RESTful API，用户可以直接调用这些 API 来创建、更新和管理集群中的资源对象，包括部署工作负载。可以使用各种编程语言的 Kubernetes 客户端库（例如 Python 的 kubernetes 库）来实现。
  • 使用 Helm 工具部署: Helm 是 Kubernetes 的包管理工具，它将一组相关的 Kubernetes 资源打包成 Chart 进行管理。用户可以使用 Helm Chart 来方便地部署复杂的应用程序到 CCE 集群中。

因此，所有列出的选项都是在 CCE 集群中部署工作负载的有效途径。

多选题
134/231、华为云CCE资源监控指标包括以下哪些?
CPU分配率 v
磁盘分配率 v
网络上下行速率 x
内存使用率 v

好的，华为云 CCE 资源监控指标通常包括以下几项：

  • CPU 使用率 (CPU Utilization): 监控集群、节点、Pod 和容器的 CPU 使用情况，例如 CPU 总使用率、用户态 CPU 使用率、系统态 CPU 使用率等。您提到的 CPU 分配率 如果是指已分配的 CPU 资源与节点总 CPU 资源的比率，也可以作为监控指标。
  • 内存使用率 (Memory Utilization): 监控集群、节点、Pod 和容器的内存使用情况，例如总内存使用量、已使用内存百分比、可用内存等。
  • 磁盘使用率 (Disk Utilization): 监控节点和 Pod 的磁盘使用情况，例如根文件系统使用率、数据盘使用率、Pod 存储卷使用率等。您提到的 磁盘分配率 如果是指已分配的磁盘空间与总磁盘空间的比率，也可以作为监控指标。
  • 网络上下行速率 (Network Inbound/Outbound Rate): 监控节点和 Pod 的网络流量，包括接收和发送的速率，可以帮助分析网络瓶颈和流量模式。

因此，所有列出的选项通常都属于华为云 CCE 的资源监控指标。

多选题1371231、以下关于Envoy的描述，正确的有哪几项?
Envoy采用C++实现 v
Envoy是一组基于不同数据源的服务发现协议的总称 v
Envoy本身为四层及七层代理 v
Envoy可以根据用户应用请求内的数据进行高级服务治理能力 x

好的，以下关于 Envoy 的描述，正确的是：

  • Envoy 采用 C++ 实现。 这是正确的。Envoy 是一款高性能的网络代理，为了实现其性能和效率，它使用 C++ 语言开发。
  • Envoy 本身为四层及七层代理。 这是正确的。Envoy 不仅可以作为传输层（第四层，TCP/UDP）代理，还可以作为应用层（第七层，HTTP/gRPC 等）代理，能够理解和处理应用层协议的内容。
  • Envoy 可以根据用户应用请求内的数据进行高级服务治理能力。 这是正确的。作为七层代理，Envoy 可以检查和操作应用层协议的内容（例如 HTTP Header、gRPC Metadata），从而实现高级的服务治理功能，例如基于 Header 的路由、流量染色、内容修改等。

Envoy 是一组基于不同数据源的服务发现协议的总称 是错误的。Envoy 本身是一个独立的代理程序。它支持多种服务发现协议（例如 Kubernetes DNS、Consul、etcd 等），但 Envoy 并不是这些协议的总称。Envoy 通过其服务发现接口与不同的服务发现系统集成。

总结：

正确的选项是：

  • Envoy 采用 C++ 实现
  • Envoy 本身为四层及七层代理
  • Envoy 可以根据用户应用请求内的数据进行高级服务治理能力
多选题
139/231、以下关于lstio中Gateway描述，正确的有哪几项?
Gateway可以指定进入或离开网格的流量
Gateway配置应用于网格边缘的独立的 Envoy代理上
Gateway画置应用于服务负载的 Envoy代理上
Gateway能够配置分发目标地址的流量

Gateway可以指定进入或离开网格的流量
Gateway配置应用于网格边缘的独立的 Envoy代理上

好的，以下关于 Istio 中 Gateway 的描述，正确的是：

  • Gateway 可以指定进入或离开网格的流量。 这是正确的。Istio Gateway 用于管理进出服务网格的流量，可以配置入口 (ingress) 和出口 (egress) 流量。
  • Gateway 配置应用于网格边缘的独立的 Envoy 代理上。 这是正确的。Gateway 的配置（例如监听的端口、TLS 设置、路由规则等）会应用到部署在网格边缘的专门的 Envoy 代理实例上，这些 Envoy 代理与应用服务自身的 Sidecar 代理是分开的。
  • Gateway 能够配置分发目标地址的流量。 这是正确的。Gateway 的路由规则可以根据请求的各种属性（例如主机名、路径、Header 等）将流量转发到网格内部特定的服务或工作负载。

Gateway 配置应用于服务负载的 Envoy 代理上 是错误的。Gateway 的配置是应用于独立的 Gateway Envoy 代理实例，而不是应用服务 Pod 中的 Sidecar 代理。Sidecar 代理主要负责处理 Pod 内部的流量和服务间的通信，其配置由 VirtualService、DestinationRule 等资源管理。

总结：

正确的选项是：

  • Gateway 可以指定进入或离开网格的流量
  • Gateway 配置应用于网格边缘的独立的 Envoy 代理上
  • Gateway 能够配置分发目标地址的流量
多选题
141/231、以下关于ConfgMap配置项使用方式的描述中，正确的有哪些?
创建工作负载时，可以将配置项设置为环境变量，使用valueFrom参数引用ConfigMap中的Key/alue，多个配置项需要多次使用valueFrom参数
通过配置项没置工作负载环境变量还可以在界面上进行操作，在创建工作负载时，设置容器的高级设置选择onfiaMap即可
在创建工作负载时，可以将配置项挂载到工作负载中，并在数据卷里面使用
可以使用配置项设置容器中的命令或者参数值，可以使用环境变量换语法S(VAR_NAME)来进行

好的，以下关于 ConfigMap 配置项使用方式的描述中，正确的是：

  • 创建工作负载时，可以将配置项设置为环境变量，使用 valueFrom 参数引用 ConfigMap 中的 Key/Value，多个配置项需要多次使用 valueFrom 参数。 这是正确的。在 Pod 或工作负载的容器定义中，可以通过 env 字段的 valueFrom 选项来引用 ConfigMap 中的特定 key 的值作为环境变量。要引用多个配置项，需要在 env 数组中为每个配置项定义一个 valueFrom。
  • 通过配置项设置工作负载环境变量还可以在界面上进行操作，在创建工作负载时，设置容器的高级设置选择 ConfigMap 即可。 这是正确的。大多数 Kubernetes 管理界面（包括云平台的控制台）都提供了通过图形化方式将 ConfigMap 中的键值对设置为容器环境变量的功能，通常在创建或编辑工作负载的容器配置时选择 ConfigMap 并指定要使用的键值对。
  • 在创建工作负载时，可以将配置项挂载到工作负载中，并在数据卷里面使用。 这是正确的。可以将 ConfigMap 作为 Volume 挂载到 Pod 的文件系统中。Pod 中的容器可以像访问普通文件一样读取 ConfigMap 中的数据，每个 key 对应 Volume 中的一个文件名，value 对应文件内容。
  • 可以使用配置项设置容器中的命令或者参数值，可以使用环境变量替换语法 $(VAR_NAME) 来进行。 这是正确的。在 Pod 或工作负载的容器定义中，command 和 args 字段支持使用环境变量替换语法 $(VAR_NAME)。因此，可以将 ConfigMap 中的值设置为环境变量，然后在 command 或 args 中引用这些环境变量，从而动态配置容器的启动命令或参数。

总结：

所有列出的选项都是关于 ConfigMap 配置项正确的使用方式。ConfigMap 提供了多种灵活的方式将配置数据注入到 Pod 和容器中。

142/231、用户的容器中运行了Apache web服务(应用端口80)，以下关于指定监听端口方法的描述，哪些项是错
多选题
误的?
EXPOSE SAPP PORT
EXPOSE 80
ENV APP PORT=80 EXPOSE APP PORT
ENV APP PORT=80 EXPOSE SAPP PORT

EXPOSE SAPP PORT
EXPOSE 80

好的，以下关于在 Dockerfile 中指定 Apache Web 服务（应用端口 80）监听端口方法的描述，哪些项是错误的：

  • A. EXPOSE $APP_PORT: 如果 $APP_PORT 这个环境变量在构建镜像时没有被定义，那么这条 EXPOSE 指令实际上不会暴露任何端口，或者可能会被 Docker 解析为空。如果 $APP_PORT 在构建时被设置为 80，那么这条指令是正确的。因此，在不确定 $APP_PORT 是否已定义的情况下，这条指令可能是错误的。
  • C. ENV APP_PORT=80 EXPOSE APP_PORT: 这条指令是正确的。它首先定义了一个名为 APP_PORT 的环境变量并赋值为 80，然后使用 EXPOSE 指令暴露了该环境变量所代表的端口。
  • D. ENV APP_PORT=80 EXPOSE $APP_PORT: 这条指令也是正确的。它与 C 选项类似，先定义环境变量 APP_PORT 为 80，然后使用 EXPOSE 指令暴露该变量的值所代表的端口。
  • B. EXPOSE 80: 这条指令是正确的。它直接明确地指定了容器将监听的端口是 80。这是最直接和常用的暴露端口的方式。

结论：

根据题意，我们寻找错误的描述。选项 A 在环境变量 $APP_PORT 未定义的情况下是错误的，因为它不会实际暴露端口 80。选项 C 和 D 都正确地定义了环境变量并使用它来暴露端口 80。选项 B 直接暴露了端口 80，也是正确的。

因此，错误的选项是：

  • A. EXPOSE $APP_PORT (在 $APP_PORT 未定义的情况下)

需要注意的是，Dockerfile 中的 EXPOSE 指令仅仅是声明了容器运行时会监听的端口，它并不会自动进行端口映射或在宿主机上开放该端口。要使外部可以访问容器的端口，需要在运行容器时使用 -p 或 -P 参数进行端口发布。

鉴于这是一个多选题，且选项 A 在特定情况下是错误的，我们将其标记为错误。如果所有环境变量都在构建时正确设置，那么 A 也可能是正确的。但从稳健性和明确性来看，B、C 和 D 更为推荐。

最终答案：

错误的是：

  • A. EXPOSE $APP_PORT (当环境变量 $APP_PORT 在构建时未定义时)
多选题 144/231、Resource Template是对Karmada可分发资源对象的一种抽象，这里的resource包含以下哪些内容?

Deployment

Service

PVC

用户自定义CRD

好的，Resource Template 是 Karmada 对可分发资源对象的一种抽象，这里的 resource 包含但不限于以下内容：

  • Deployment：Kubernetes 的 Deployment 资源，用于管理无状态应用的多个副本。Karmada 可以将 Deployment 分发到多个成员集群。
  • Service：Kubernetes 的 Service 资源，用于暴露应用服务。Karmada 可以将 Service 分发到多个成员集群，并结合多集群服务发现和流量管理策略。
  • PVC (PersistentVolumeClaim)：Kubernetes 的持久卷声明资源，用于申请持久存储。Karmada 可以将 PVC 分发到多个成员集群，并根据存储策略在成员集群中创建对应的 PV。
  • 用户自定义 CRD (CustomResourceDefinition)：Kubernetes 允许用户自定义资源类型。Karmada 同样可以管理和分发用户自定义的 CRD 及其对应的 Custom Resource 对象。

子 这个选项看起来不完整或不明确，通常不作为 Kubernetes 或 Karmada 资源类型的标准名称。

总结：

Resource Template 在 Karmada 中可以包含：

  • Deployment
  • Service
  • PVC
  • 用户自定义 CRD
多选题 146/231、)

通过ServiceName形式“nginx.default.svc.cluster.local"访问Service，以下相关描述正确的是哪些项?

访问的Service名称为“nginx" v

该Service创建时未指定Namespace v

svc.cluster.local为域名后缀 v

所有情况下都可以省略<namespace>.svc.cluster.ocal部分，直接使用ServiceName访问Service v

好的，关于通过 ServiceName 形式 "nginx.default.svc.cluster.local" 访问 Service，以下相关描述正确的是：

  • 访问的 Service 名称为 “nginx”。这是正确的。在 ServiceName 的格式中，第一个部分通常是 Service 的名称。
  • svc.cluster.local 为域名后缀。这是正确的。svc.cluster.local 是 Kubernetes 集群内部 Service 的默认域名后缀。

以下描述是错误的：

  • 该 Service 创建时未指定 Namespace。这是错误的。default 表明该 Service 是在名为 default 的 Namespace 中创建的。如果未指定 Namespace，则会使用默认的 default Namespace。因此，该 Service 明确指定了 Namespace。
  • 所有情况下都可以省略 <namespace>.svc.cluster.local 部分，直接使用 ServiceName 访问 Service。这是错误的。在同一个 Namespace 内的 Pod 可以直接使用 ServiceName（例如 nginx）来访问 Service。但是，如果 Pod 需要访问不同 Namespace 中的 Service，则必须使用包含 Namespace 的完整域名（例如 nginx.other-namespace.svc.cluster.local）。省略 <namespace>.svc.cluster.local 部分只在访问同一 Namespace 下的 Service 时有效。

总结：

正确的选项是：

  • 访问的 Service 名称为 “nginx”
  • svc.cluster.local 为域名后缀
多选题
152/231、以下关于Karmada scheduler的处理流程的描述，正确的是哪些项?
B
scheduler根据override poticy，通过调度算法决定k8-原生API盗源对象应该调度到哪些member集群中
scheduler使用list/watch机制监控resource binding、propagation policy的变更事件
首次调度时，resource binding对象的特征是spec.clusters字段为空
Jscheduler的输出 是为resource binding加上调度结果spec.clusters

scheduler使用list/watch机制监控resource binding、propagation policy的变更事件
首次调度时，resource binding对象的特征是spec.clusters字段为空
Jscheduler的输出 是为resource binding加上调度结果spec.clusters

好的，以下关于 Karmada scheduler 的处理流程的描述，正确的是：

  • scheduler 使用 list/watch 机制监控 resource binding、propagation policy 的变更事件。 这是正确的。Karmada scheduler 通过监听这些关键资源对象的变更事件来触发调度流程。当 PropagationPolicy 或 ResourceBinding 发生变化时，scheduler 会收到通知并进行相应的处理。
  • 首次调度时，resource binding 对象的特征是 spec.clusters 字段为空。 这是正确的。在 scheduler 首次对一个联邦资源进行调度之前，与之关联的 ResourceBinding 对象的 spec.clusters 字段是空的，表示该资源尚未被调度到任何成员集群。
  • scheduler 的输出是为 resource binding 加上调度结果 spec.clusters。 这是正确的。scheduler 的主要任务是根据调度策略和算法，决定联邦资源应该部署到哪些成员集群，并将这些调度结果记录到对应的 ResourceBinding 对象的 spec.clusters 字段中。

scheduler 根据 override policy，通过调度算法决定 k8s 原生 API 资源对象应该调度到哪些 member 集群中 是不完全准确的。Karmada scheduler 的主要输入是 PropagationPolicy（分发策略）和 ResourceBinding 对象，以及考虑集群的可用性和资源状况。OverridePolicy（覆盖策略）主要用于在将资源部署到成员集群时进行差异化配置，它会影响资源在目标集群中的具体形态，但不是 scheduler 直接用来决定调度到哪个集群的主要依据。Scheduler 主要根据 PropagationPolicy 的选择器和调度策略来决定目标集群。

总结：

正确的选项是：

  • scheduler 使用 list/watch 机制监控 resource binding、propagation policy 的变更事件
  • 首次调度时，resource binding 对象的特征是 spec.clusters 字段为空
  • scheduler 的输出是为 resource binding 加上调度结果 spec.clusters
多选题 154/231、其用户采用名为 nginx 的 Deployment 部署 nginx:1.7.9，若此时需在业多不中断的前提下，将通过此Deployment 创建的Pods 更新至
Nginx:1.9.1，可采用以下哪些方式?
kubectl delete deploy nginx 后应用支持 nginx:1.9.1 的YAML
kubectl edit deploy nginx 的方式修改此 YAML的 spec.template.spec.containerimage 字段
kubectl set image deploy nginx nginx-nginx:1.9.1
修改此 YAML 文件的spec.template 5pec.containerimage 宁段后重新应用此 YAML

好的，在 Kubernetes 中，为了在业务不中断的前提下，将名为 nginx 的 Deployment 管理的 Pods 从 nginx:1.7.9 更新至 nginx:1.9.1，可以采用以下方式：

  • kubectl edit deploy nginx 的方式修改此 YAML 的 spec.template.spec.containers[0].image 字段 (假设 nginx 容器是 Deployment 中唯一的或第一个容器)。kubectl edit 命令允许您直接编辑 Kubernetes 对象的配置。修改 image 字段并保存后，Kubernetes Deployment 控制器会自动触发滚动更新 (Rolling Update)，逐步替换旧版本的 Pods 为新版本的 Pods，期间会保持一定数量的可用副本，从而实现业务不中断。
  • kubectl set image deploy nginx nginx=nginx:1.9.1。这是一个更简洁的命令，用于直接更新 Deployment 中指定容器的镜像。set image 命令会自动触发滚动更新，与 kubectl edit 修改 YAML 文件然后应用的效果相同。这里的 nginx= 部分指定了要更新的容器名称，如果 Deployment 中只有一个容器，也可以省略容器名称。
  • 修改此 YAML 文件的 spec.template.spec.containers[0].image 字段后重新应用此 YAML (kubectl apply -f <your_deployment_file.yaml>) (假设 nginx 容器是 Deployment 中唯一的或第一个容器)。首先修改本地存储的 Deployment 的 YAML 文件，将 image 字段更新为 nginx:1.9.1，然后使用 kubectl apply -f 命令重新应用该文件。Kubernetes 会对比当前状态和期望状态，并触发滚动更新以达到期望的版本。

以下方式会导致业务中断，因此不应采用：

  • kubectl delete deploy nginx 后应用支持 nginx:1.9.1 的 YAML。删除 Deployment 会导致其管理的所有 Pods 被删除，在新的 Deployment 和 Pods 创建完成之前，业务将无法提供服务，造成中断。

总结：

正确的更新 Deployment 镜像且不中断业务的方式包括：

  • kubectl edit deploy nginx 并修改镜像字段
  • kubectl set image deploy nginx nginx=nginx:1.9.1
  • 修改 YAML 文件并使用 kubectl apply -f 重新应用
多选题156/231、以下关于Service的描述，正确的是哪些项?
-个Service有一个固定的IP地址
Service通过Label Selector来选择将流量转发给哪几个Pod
集群内部仅可通过域名的形式对Service进行访问
Service能为多个 Pod 提供负载均衡能力

ABD

好的，以下关于 Kubernetes Service 的描述，正确的是：

  • 一个 Service 有一个固定的 IP 地址（ClusterIP）。 这是正确的。当创建一个 Service 时，Kubernetes 会为其分配一个在集群内部唯一的虚拟 IP 地址，即 ClusterIP。这个 IP 地址在 Service 的整个生命周期内保持不变。
  • Service 通过 Label Selector 来选择将流量转发给哪几个 Pod。 这是正确的。Service 使用 Label Selector 来匹配具有特定标签的 Pods，并将发送到 Service 的流量负载均衡到这些匹配的 Pods 上。
  • Service 能为多个 Pod 提供负载均衡能力。 这是正确的。Service 的主要功能之一就是为后端多个提供相同服务的 Pods 提供负载均衡，将客户端的请求分发到不同的 Pod 实例上，从而提高应用的可用性和性能。

集群内部仅可通过域名的形式对 Service 进行访问 是错误的。在集群内部，可以通过以下两种方式访问 Service：

  • 通过 ClusterIP 和端口: 可以直接使用 Service 的 ClusterIP 和端口进行访问。
  • 通过域名: Kubernetes DNS 服务会将 Service 的名称解析为 ClusterIP，因此也可以通过域名（例如 <service-name>.<namespace>.svc.cluster.local）来访问 Service。

总结：

正确的选项是：

  • 一个 Service 有一个固定的 IP 地址
  • Service 通过 Label Selector 来选择将流量转发给哪几个 Pod
  • Service 能为多个 Pod 提供负载均衡能力
157/231、以下关于Kubernetes的校心概念之-Volume的描述，正确的是哪些项?多选题

用于声明在Pod中的容器可以访问的文件目录

可以被同一个Pod中多个容器共同访问

支持安种后端存储(本地存储、分布式存储、云存储等)

-个Pod仅可挂我个Volume

好的，以下关于 Kubernetes 的核心概念之一 Volume 的描述，正确的是：

  • 用于声明在 Pod 中的容器可以访问的文件目录。 这是正确的。Volume 是 Pod 中定义的一个可供一个或多个容器访问的目录，它可以挂载到容器的文件系统中，使得容器可以读写 Volume 中的数据。
  • 可以被同一个 Pod 中多个容器共同访问。 这是正确的。同一个 Pod 中的多个容器可以挂载同一个 Volume，从而实现它们之间的数据共享。
  • 支持多种后端存储 (本地存储、分布式存储、云存储等)。 这是正确的。Kubernetes Volume 抽象了底层的存储实现，支持各种类型的存储后端，包括本地磁盘（emptyDir、hostPath）、网络文件系统（NFS）、云存储（例如 AWS EBS、GCP Persistent Disk、Azure Disk、华为云 CBS 等）、分布式存储系统（例如 Ceph、GlusterFS）等。

一个 Pod 仅可挂载一个 Volume 是错误的。一个 Pod 可以根据需要在其 spec.volumes 字段中定义多个 Volume，并在每个容器的 spec.containers.volumeMounts 字段中指定要挂载的 Volume 及其挂载路径。

总结：

正确的选项是：

  • 用于声明在 Pod 中的容器可以访问的文件目录
  • 可以被同一个 Pod 中多个容器共同访问
  • 支持多种后端存储 (本地存储、分布式存储、云存储等)
多选题160/231、以下关于lstio中Citadel组件的描述，正确的有哪几项?
Citadel负责身份认证功能
Citadel负责证书管理功能
Citadel当前作为一个模块被整合在 istiod 中 √
Gitadel能够实现服务间和最終用户的身份验证

好的，以下关于 Istio 中 Citadel 组件的描述，正确的是：

  • Citadel 负责身份认证功能。 这是正确的。Citadel（在 Istio 1.5 及更高版本中已集成到 istiod 中）是 Istio 中负责提供强大的身份验证和授权的基础设施组件。它通过为服务和最终用户颁发和管理证书来建立安全的服务间通信。
  • Citadel 负责证书管理功能。 这是正确的。Citadel 负责生成、分发、轮换和吊销在 Istio 网格中使用的 TLS 证书。这对于实现双向 TLS (mTLS) 身份验证至关重要。
  • Citadel 当前作为一个模块被整合在 istiod 中。 这是正确的。在 Istio 1.5 版本之后，Citadel 的功能以及 Pilot 和 Galley 的部分功能都被整合到了一个名为 istiod 的统一组件中，以简化 Istio 的部署和管理。
  • Citadel 能够实现服务间和最终用户的身份验证。 这是正确的。Citadel 不仅负责为网格中的服务提供身份验证（通过 mTLS），还可以与外部身份验证系统集成，以验证最终用户的身份，为服务间的授权决策提供依据。

总结：

所有列出的选项都是关于 Istio 中 Citadel 组件（或其集成后的 istiod 功能）的正确描述。

多选题
163/231、以下关于Confg Map配置项使用方式的描述中，正确的有哪些?
口 创建工作负载时，可以将配置项设置为环境变量，使用valueFrom参数引用ConfigMap中的KeyNalue,多个配置项需要多次使用valueFrom参数引用
口 通过配置项设置工作负载环境变量还可以在界面上进行操作，在创建工作负载时，设置容器的高级设置，选择ConfigMap即可配置
在创建工作负载时，可以将配置项挂载到工作 负载中，并在数据老里面使用
口 可以使用配置项设置容器中的命令或者参数值，可以使用环境变量替换语法$(VAR NAME)来进行
提交答案

好的，以下关于 ConfigMap 配置项使用方式的描述中，正确的是：

  • 创建工作负载时，可以将配置项设置为环境变量，使用 valueFrom 参数引用 ConfigMap 中的 Key/Value，多个配置项需要多次使用 valueFrom 参数引用。 这是正确的。在 Pod 或工作负载的容器定义中，可以通过 env 字段的 valueFrom 选项来引用 ConfigMap 中的特定 key 的值作为环境变量。要引用多个配置项，需要在 env 数组中为每个配置项定义一个 valueFrom。
  • 通过配置项设置工作负载环境变量还可以在界面上进行操作，在创建工作负载时，设置容器的高级设置，选择 ConfigMap 即可配置。 这是正确的。大多数 Kubernetes 管理界面（包括云平台的控制台）都提供了通过图形化方式将 ConfigMap 中的键值对设置为容器环境变量的功能，通常在创建或编辑工作负载的容器配置时选择 ConfigMap 并指定要使用的键值对。
  • 在创建工作负载时，可以将配置项挂载到工作负载中，并在数据卷里面使用。 这是正确的。可以将 ConfigMap 作为 Volume 挂载到 Pod 的文件系统中。Pod 中的容器可以像访问普通文件一样读取 ConfigMap 中的数据，每个 key 对应 Volume 中的一个文件名，value 对应文件内容。
  • 可以使用配置项设置容器中的命令或者参数值，可以使用环境变量替换语法 $(VAR_NAME) 来进行。 这是正确的。在 Pod 或工作负载的容器定义中，command 和 args 字段支持使用环境变量替换语法 $(VAR_NAME)。因此，可以将 ConfigMap 中的值设置为环境变量，然后在 command 或 args 中引用这些环境变量，从而动态配置容器的启动命令或参数。

总结：

所有列出的选项都是关于 ConfigMap 配置项正确的使用方式。ConfigMap 提供了多种灵活的方式将配置数据注入到 Pod 和容器中。

多选题166/231、在配置CCE自定义监控时，下列说法中正确的有此些?

口 ICAgent周用白定义指标的接口周期为1分钟，不支持修改

口 ICAgent仅支持上报Gauge指标类型的指标。

口 Pod提供的自定义指标必须满足prometheus的监控数据规范才能够被CAgent采集

口 ICAgent兼容Prometheus的监控数据规范

提交答案

abcd

好的，以下关于配置 CCE 自定义监控的说法中，正确的是：

  • Pod 提供的自定义指标必须满足 Prometheus 的监控数据规范才能够被 ICAgent 采集。 这是正确的。CCE 的自定义监控通常与 Prometheus 生态集成，ICAgent 作为数据采集组件，需要 Pod 暴露的自定义指标符合 Prometheus 的 Exporter 规范，例如以特定的格式（通常是文本格式）通过 HTTP 端点暴露指标。
  • ICAgent 兼容 Prometheus 的监控数据规范。 这是正确的。ICAgent 设计上能够理解和采集符合 Prometheus 监控数据规范的指标格式。这意味着您可以复用为 Prometheus 设计的 Exporter 来暴露您的自定义指标，并被 ICAgent 采集。

以下说法是错误的：

  • ICAgent 上报自定义指标的接口周期为 1 分钟，不支持修改。 这是错误的。ICAgent 的上报周期通常是可以配置的，虽然默认值可能是 1 分钟，但用户应该能够根据自己的需求调整上报频率。具体的配置方式需要参考华为云 CCE 的相关文档。
  • ICAgent 仅支持上报 Gauge 指标类型的指标。 这是错误的。Prometheus 支持多种指标类型，包括 Gauge（瞬时值）、Counter（计数器）、Histogram（直方图）、Summary（摘要）等。ICAgent 通常也应该支持采集多种 Prometheus 指标类型，以便更全面地监控应用程序的状态。

总结：

正确的说法是：

  • Pod 提供的自定义指标必须满足 Prometheus 的监控数据规范才能够被 ICAgent 采集
  • ICAgent 兼容 Prometheus 的监控数据规范
多选题
167/231、以下关于Karmada中相关controller的作用的描达，正确的是哪些项?
6
口 resource detector监听propagation policy和k85原生API资源对象的变化，实现两者的绑定口 propagation policy controller负责绑定propagation policy和k8s原生API资源对象
囗 resource binding controller负责把resource binding转换为work
execution controller负责把work中包含的k8s原生API资源同步到push模式的member集群中
提交答案

acd
 resource detector监听propagation policy和k85原生API资源对象的变化，实现两者的绑定口 
  resource binding controller负责把resource binding转换为work
execution controller负责把work中包含的k8s原生API资源同步到push模式的member集群中

好的，以下关于 Karmada 中相关 controller 的作用的描述，正确的是：

  • resource detector 监听 propagation policy 和 k8s 原生 API 资源对象的变化，实现两者的绑定。 这是正确的。Resource Detector 负责监视 PropagationPolicy 和 Kubernetes 原生 API 资源对象（例如 Deployment）的创建、更新和删除事件。当检测到新的联邦资源对象或 PropagationPolicy 时，它会根据策略规则将两者关联起来，通常会创建或更新 ResourceBinding 对象。
  • propagation policy controller 负责绑定 propagation policy 和 k8s 原生 API 资源对象。 这与 Resource Detector 的功能描述重复且不够准确。Propagation Policy Controller 主要负责处理 PropagationPolicy 对象的生命周期，例如验证策略的有效性等，而将 PropagationPolicy 与联邦资源对象关联并创建 ResourceBinding 的主要职责在于 Resource Detector。
  • resource binding controller 负责把 resource binding 转换为 work。 这是正确的。Resource Binding Controller 监听 ResourceBinding 对象的创建和更新。对于每个需要下发到成员集群的资源绑定，Resource Binding Controller 会将其转换为 Work 对象。Work 对象是 Karmada 控制平面下发到成员集群执行的最小单元，包含了需要在目标集群中创建或更新的 Kubernetes 资源清单。
  • execution controller 负责把 work 中包含的 k8s 原生 API 资源同步到 push 模式的 member 集群中。 这是正确的。Execution Controller 监听 Work 对象的创建和更新。对于 Push 模式的成员集群（即 Karmada Agent 主动连接控制平面的模式），Execution Controller 会将 Work 对象中包含的 Kubernetes 资源清单同步到相应的 Karmada Agent，然后由 Agent 在成员集群中执行这些资源操作。

总结：

正确的选项是：

  • resource detector 监听 propagation policy 和 k8s 原生 API 资源对象的变化，实现两者的绑定
  • resource binding controller 负责把 resource binding 转换为 work
  • execution controller 负责把 work 中包含的 k8s 原生 API 资源同步到 push 模式的 member 集群中

propagation policy controller 负责绑定 propagation policy 和 k8s 原生 API 资源对象 的描述不够准确，主要负责该绑定的是 Resource Detector。

多选题
168/231、以下哪些命令可用丁査看名为nginx的Deployment的历史更新情况?
 kubectl describe nginx deployment nginx
 kubectl get deployment nginx -o yaml
 kubectl rollout status deployment nginx
 kubectl rollout history deployment nginx
 
 abd
 kubectl describe nginx deployment nginx
 kubectl get deployment nginx -o yaml
 kubectl rollout history deployment nginx

好的，查看名为 nginx 的 Deployment 的历史更新情况，可以使用以下命令：

  • kubectl rollout history deployment nginx: 这个命令会显示 nginx Deployment 的历史版本（revisions），包括每个版本的变更记录、部署时间、变更原因等信息。

以下命令虽然可以提供 Deployment 的信息，但不是专门用于查看历史更新情况的：

  • kubectl describe deployment nginx: 这个命令会显示 nginx Deployment 的详细信息，包括当前状态、副本数、更新策略、事件等，但不会详细列出历史 revision 的配置变更。
  • kubectl get deployment nginx -o yaml: 这个命令会以 YAML 格式输出 nginx Deployment 的当前配置信息，无法直接查看历史更新记录。
  • kubectl rollout status deployment nginx: 这个命令用于查看 nginx Deployment 当前的滚动更新状态（例如，正在更新的副本数、是否已完成等），而不是历史更新记录。

因此，查看 Deployment 历史更新情况的正确命令是：

  • kubectl rollout history deployment nginx
多选题

171/231、Kubernetes中，处于以下哪些状态的PV卷可被PVC声明使用?

O Available


0 Bound

 Released

口 Failed

好的，在 Kubernetes 中，处于以下状态的 PersistentVolume (PV) 卷可被 PersistentVolumeClaim (PVC) 声明使用：

  • Available: 处于 Available 状态的 PV 是空闲的，尚未被任何 PVC 绑定。因此，PVC 可以选择并绑定到处于此状态的 PV。
  • Bound: 处于 Bound 状态的 PV 已经成功地绑定到一个 PVC。这意味着该 PV 已经被某个 PVC 所声明并正在被其使用，因此不能再被其他的 PVC 声明使用。
  • Released: 处于 Released 状态的 PV 是之前绑定的 PVC 已经被删除，但 PV 自身的生命周期管理策略 (Reclaim Policy) 设置为 Retain（保留）。虽然 PV 已经解除绑定，但其数据可能仍然存在，需要管理员手动处理后才能再次被新的 PVC 使用。通常情况下，处于 Released 状态的 PV 不能直接被新的 PVC 声明使用，除非管理员进行了特定的清理和重置操作。
  • Failed: 处于 Failed 状态的 PV 表明该 PV 在配置或使用过程中遇到了问题，无法正常工作，因此不能被 PVC 声明使用。

总结：

只有处于 Available 状态的 PV 卷可以被 PVC 声明使用。处于 Bound、Released 和 Failed 状态的 PV 通常不能直接被新的 PVC 使用。

判断题 175/231、00M的全称是out of memory，当"不合格”的程序运行在系统上会额外的消耗内存资源，导致kerel无法正常向其它进程分配资源当系统遇到OOM时，kerel默认会按照系统默认机制进行调节，用户不可设置调度策略.
正确
多
错误

答案是 错误。

解释:

  • OOM 的全称是 Out Of Memory，当“不合格”的程序运行在系统上会额外地消耗内存资源，导致 kernel 无法正常向其它进程分配资源。 这部分描述是正确的。OOM 指的是系统内存不足的情况，不良的程序确实可能过度消耗内存，导致系统资源紧张。
  • 当系统遇到 OOM 时，kernel 默认会按照系统默认机制进行调节，用户不可设置调度策略。 这部分描述是错误的。Linux 内核提供了 OOM Killer 机制来处理内存不足的情况。虽然内核有默认的策略来选择杀死哪个进程以释放内存，但是用户可以通过调整进程的 oom_score_adj 值来影响 OOM Killer 的决策。oom_score_adj 的范围是 -1000 到 1000，值越大，该进程被 OOM Killer 选中的可能性就越高。将 oom_score_adj 设置为 -1000 可以有效地阻止进程被 OOM Killer 杀死。

因此，用户是可以在一定程度上设置 OOM 的调度策略的，通过调整进程的 oom_score_adj 值来影响 OOM Killer 的行为。

判断题
177/231、在编写dockerfle时，优先使用ADD命令而不是COPY命令拷贝文件至镜像
正确
B
错误

答案是 错误。

解释:

在编写 Dockerfile 时，通常优先使用 COPY 命令而不是 ADD 命令来拷贝本地文件到镜像中。原因如下：

  • COPY 的行为更明确和可预测: COPY 命令仅仅是将本地文件或目录复制到镜像中的指定路径。它的行为非常简单直接，不会进行额外的操作。
  • ADD 的功能更强大，但也更复杂: ADD 命令除了具备 COPY 的功能外，还支持以下特性：
    • 解压 tar 压缩包：如果源文件是可识别的压缩格式（如 tar、gzip 等），ADD 会自动将其解压到目标路径。
    • 支持远程 URL：ADD 可以直接从 URL 下载文件并添加到镜像中。

这些额外的功能虽然在某些场景下很方便，但也带来了潜在的风险和不确定性：

  • 自动解压的意外行为: 如果不希望压缩包被自动解压，使用 ADD 可能会导致意想不到的结果。
  • 远程 URL 的安全风险和依赖: 从远程 URL 下载文件增加了构建过程对外部资源的依赖，并且存在安全风险（例如，URL 指向恶意文件）。
  • 可读性降低: ADD 的多重功能使得 Dockerfile 的意图不如 COPY 那样清晰。

最佳实践建议：

  • 对于简单的文件和目录拷贝，优先使用 COPY。 这使得 Dockerfile 更清晰、更易于理解和维护。
  • 只有在需要自动解压本地压缩包时才使用 ADD。
  • 尽量避免使用 ADD 从远程 URL 下载文件。 更好的做法是使用 RUN wget 或 RUN curl 下载文件，然后使用 COPY 将其添加到镜像中。这样可以更精确地控制下载过程，并在必要时进行校验。

因此，优先使用 ADD 而不是 COPY 是不推荐的做法。

判断题 185/231、34 存活探(livenessProbe)用于指示容器是否准备好服务请求，若探测失败，Endpoint Controler将从与Pod匹配的所有Service的Endpoints中删除该Pod的IP地址，
正确
错误

答案是 错误。

解释:

存活探针 (Liveness Probe) 和就绪探针 (Readiness Probe) 在 Kubernetes 中扮演着不同的角色：

  • 存活探针 (Liveness Probe): 用于检测容器是否正在运行。如果存活探针探测失败，Kubernetes 会认为容器已经不健康，并根据 Pod 的 restartPolicy 来决定是否重启容器。Endpoint Controller 不会因为存活探针失败而将 Pod 的 IP 地址从 Service 的 Endpoints 中移除。重启容器的目的是尝试恢复容器的健康状态。
  • 就绪探针 (Readiness Probe): 用于检测容器是否已经准备好接收服务请求。只有当就绪探针探测成功时，Pod 才会被认为是就绪状态，其 IP 地址才会被添加到与 Pod 匹配的所有 Service 的 Endpoints 中。如果就绪探针探测失败，Endpoint Controller 会将该 Pod 的 IP 地址从 Service 的 Endpoints 中移除，从而防止将流量路由到尚未准备好的 Pod。

因此，题目中描述的行为是就绪探针 (Readiness Probe) 的功能，而不是存活探针 (Liveness Probe) 的功能。

判断题 186/231、Kubemetes中，持久化存储声明PVC一旦创建，其申领的存储容量后期不可更改，若应用需要申领更大容量的存储需新建一个PVC.
正确
错误

答案是 错误。

解释:

在 Kubernetes 中，持久化存储声明 (PVC) 一旦创建，在某些情况下是可以扩容的，而不是后期容量绝对不可更改。是否可以扩容取决于以下几个因素：

  • StorageClass 的 allowVolumeExpansion 字段: 创建 PVC 时所使用的 StorageClass 必须将其 allowVolumeExpansion 字段设置为 true，才允许扩容 PVC。如果该字段为 false（或未设置，默认通常为 false），则 PVC 创建后无法扩容。
  • 底层存储提供商的支持: 底层的存储提供商（例如云存储服务、本地存储卷管理器等）也需要支持卷的扩容操作。
  • Kubernetes 版本: PVC 扩容功能在较新的 Kubernetes 版本中才稳定可用。

如果满足上述条件，用户可以通过编辑已有的 PVC 对象，修改其 spec.resources.requests.storage 字段来请求更大的存储容量。Kubernetes 会尝试与底层存储系统协商并完成扩容操作。

然而，需要注意的是，并非所有的存储提供商和 Kubernetes 版本都支持 PVC 扩容。在不支持扩容的情况下，题目中的描述是正确的，即需要创建新的 PVC 来申领更大的存储容量。

因此，笼统地说 PVC 一旦创建容量就不可更改是不准确的。是否可更改取决于具体的配置和环境。

判断题 190/231、工作负戴业务探针(ReadinesProbe) 用于检测容器是否准备好开始处理用户请求，如果检查失败，集群会屏蔽请求访问该容器，并直接重启Pod。
正确
错误

答案是 错误。

解释:

题目中关于就绪探针 (Readiness Probe) 的描述部分正确，部分错误：

  • “工作负载业务探针 (Readiness Probe) 用于检测容器是否准备好开始处理用户请求” 是 正确 的。就绪探针的主要目的是判断容器内的应用程序是否已经启动完成，并且能够正常接收和处理外部流量。
  • “如果检查失败，集群会屏蔽请求访问该容器” 是 正确 的。当就绪探针检测失败时，Kubernetes 会将该 Pod 从所有匹配的 Service 的 Endpoints 列表中移除。这意味着发送到该 Service 的请求将不会被路由到这个未就绪的 Pod 上，从而避免将流量导向不健康或未准备好的实例。
  • “并直接重启 Pod” 是 错误 的。当就绪探针失败时，Kubernetes 不会 自动重启 Pod。就绪探针失败表明容器暂时无法处理流量，但并不一定意味着容器本身已经崩溃或需要重启。Pod 的重启是由存活探针 (Liveness Probe) 失败触发的。存活探针用于检测容器是否仍然在运行，如果存活探针失败，Kubernetes 才会根据 Pod 的 restartPolicy 来决定是否重启容器。

总结:

就绪探针失败会导致集群屏蔽对该容器的请求，但不会直接触发 Pod 的重启。Pod 的重启是由存活探针失败触发的。

判断题StatefulSet的副本机制是通过ReplicaSet实现的。这一点可通过查看对应Pod的ownerReference字段199/231、查看。

正确 x


错误 v

错误

答案是 正确。

解释:

StatefulSet 的副本管理机制确实是通过底层的 ReplicaSet 实现的。

当你创建一个 StatefulSet 时，Kubernetes 控制平面会自动创建一个或多个与之关联的 ReplicaSet。每个 ReplicaSet 负责管理 StatefulSet 的一组具有相同 Pod 模板的副本。StatefulSet 控制器会确保这些 ReplicaSet 按照特定的顺序创建和删除 Pod，并为每个 Pod 提供稳定的网络标识和持久存储。

你可以通过查看 StatefulSet 创建的 Pod 的 ownerReferences 字段来验证这一点。这个字段会指向管理该 Pod 的 ReplicaSet，而该 ReplicaSet 的 ownerReferences 字段又会指向创建它的 StatefulSet。

因此，StatefulSet 实际上是将副本的管理委托给了 ReplicaSet，自身则专注于提供有状态应用所需的有序性、唯一性和持久性保证。

判断题

203/231、在编写dockerhle过程中，使用“WORKDIR/app“与”RUNcd /app”的执行结果相同

正确 v


错误

答案是 错误。

解释:

WORKDIR /app 和 RUN cd /app 在 Dockerfile 中的作用和影响范围是不同的：

  • WORKDIR /app: 这个指令用于设置镜像中后续所有 RUN、CMD、ENTRYPOINT、COPY 和 ADD 指令的工作目录为 /app。它会改变 Dockerfile 构建过程中后续命令执行的上下文。如果 /app 目录不存在，Docker 会自动创建它。这个工作目录在最终运行的容器中也会被设置为 /app。
  • RUN cd /app: 这个指令会在当前 RUN 指令创建的 shell 环境中执行 cd /app 命令，将当前工作目录切换到 /app。但是，这个改变只影响当前的 RUN 指令，不会影响后续的指令或最终运行的容器的工作目录。 当下一个 RUN 指令执行时，工作目录会恢复到之前的设置（可能是默认的根目录 /，或者之前使用 WORKDIR 设置的目录）。

举例说明:

假设 Dockerfile 如下：

Dockerfile

FROM ubuntu:latest
RUN mkdir /test
WORKDIR /app
RUN pwd  # 输出 /app
RUN cd /test
RUN pwd  # 输出 /app，因为上一个 RUN cd 的影响只在当前 RUN 中

如果将 WORKDIR /app 替换为 RUN cd /app：

Dockerfile

FROM ubuntu:latest
RUN mkdir /test
RUN cd /app
RUN pwd  # 输出 /app
RUN cd /test
RUN pwd  # 输出 /，因为第一个 RUN cd /app 的影响已经结束

可以看到，使用 WORKDIR 会持久地改变后续指令的工作目录，而 RUN cd 只会影响当前指令的执行环境。因此，它们的执行结果是不同的。

2071231、应用服务网格通过侵入的方式提供服务的调用链埋点，并对接相关服务后能够实现完整的调用链数据
判断题
采集、收集、检索功能
正确
错误

答案是 错误。

解释:

应用服务网格（Service Mesh），如 Istio 和 Linkerd 等，其核心优势之一就是以非侵入的方式提供服务的可观测性，包括调用链追踪（Distributed Tracing）。

服务网格通过在应用程序 Pod 的旁边注入 Sidecar 代理（通常是 Envoy）来实现这一点。这些 Sidecar 代理拦截应用程序之间的所有网络通信，并自动收集和报告调用链数据，而无需修改应用程序的代码。

因此，应用服务网格并非通过侵入的方式提供调用链埋点。它们采用透明代理的方式，对应用程序是无感的。一旦配置对接了相应的追踪后端（如 Jaeger、Zipkin），服务网格就能够实现完整的调用链数据采集、收集和检索功能。

题目中“通过侵入的方式”的描述是与服务网格的核心设计理念相悖的，因此是错误的。

210/231、存活探(livenessProbe)用于指示容器是否准备好服务请求若探测失败，Endpoint Controller将从与Pod判断题匹配的所有Service的Endpoints中删除该Pod的IP地址

正确

错误

答案是 错误。

解释:

题目中描述的行为是就绪探针 (Readiness Probe) 的功能，而不是存活探针 (Liveness Probe) 的功能。

  • 存活探针 (Liveness Probe): 用于检测容器是否正在运行。如果存活探针探测失败，Kubernetes 会认为容器已经不健康，并根据 Pod 的 restartPolicy 来决定是否重启容器。Endpoint Controller 不会因为存活探针失败而将 Pod 的 IP 地址从 Service 的 Endpoints 中移除。重启容器的目的是尝试恢复容器的健康状态.
  • 就绪探针 (Readiness Probe): 用于检测容器是否已经准备好接收服务请求。只有当就绪探针探测成功时，Pod 才会被认为是就绪状态，其 IP 地址才会被添加到与 Pod 匹配的所有 Service 的 Endpoints 中。如果就绪探针探测失败，Endpoint Controller 会将该 Pod 的 IP 地址从 Service 的 Endpoints 中移除，从而防止将流量路由到尚未准备好的 Pod。

因此，存活探针失败会导致容器重启（根据 restartPolicy），而就绪探针失败会导致 Pod 从 Service 的 Endpoints 中移除。

判断题220/231、在不考虑污点等因素的前提下，当Kubernetes集群出现节点故障时，DaemonSet控制的pod数量并不会随之减少

正确 v

错误

答案是 正确。

解释:

DaemonSet 的设计目标是在集群中的每个（或满足特定条件的）节点上运行一个 Pod 的副本。它确保即使在节点故障的情况下，只要还有健康的节点存在，这些节点上仍然会运行 DaemonSet 控制的 Pod。

当一个节点发生故障时，运行在该节点上的 DaemonSet Pod 自然会消失。但是，DaemonSet 控制器会监控集群中的节点状态。当新的节点加入集群（或者故障节点恢复后重新加入），DaemonSet 控制器会立即在该新节点上创建相应的 Pod，以维持在每个健康节点上运行一个 Pod 副本的目标。

因此，在不考虑节点亲和性、污点（Taints）和容忍度（Tolerations）等限制性因素的前提下，DaemonSet 控制的 Pod 总数会随着集群中健康节点数量的变化而动态调整，而不会因为单个或少数节点的故障而减少集群范围内运行的 DaemonSet Pod 的数量（只要还有其他健康节点）。

总结来说，DaemonSet 旨在保证每个合格的节点上都有一个 Pod 副本，节点故障只会导致该节点上的 Pod 消失，但不会影响其他健康节点上的 Pod，并且新的健康节点会立即被部署上相应的 Pod。

判断题222/231、StatefulSet的副本机制是通过ReplicaSet实现的。这一点可通过查看对应的Pod的ownerReference字段查看。

正确

错误 v

答案是 正确。

解释:

StatefulSet 的副本管理机制确实是通过底层的 ReplicaSet 实现的。

当你创建一个 StatefulSet 时，Kubernetes 控制平面会自动创建一个或多个与之关联的 ReplicaSet。每个 ReplicaSet 负责管理 StatefulSet 的一组具有相同 Pod 模板的副本。StatefulSet 控制器会确保这些 ReplicaSet 按照特定的顺序创建和删除 Pod，并为每个 Pod 提供稳定的网络标识和持久存储。

你可以通过查看 StatefulSet 创建的 Pod 的 ownerReferences 字段来验证这一点。这个字段会指向管理该 Pod 的 ReplicaSet，而该 ReplicaSet 的 ownerReferences 字段又会指向创建它的 StatefulSet。

因此，StatefulSet 实际上是将副本的管理委托给了 ReplicaSet，自身则专注于提供有状态应用所需的有序性、唯一性和持久性保证。