2025-5-29 错题分析1

以下关于lstio中gateway 的说法，错误的是哪一项?
Gateway 主要用于管理Ingress流量
Gateway 可以配置egress gateway
Gateway 配置应用于服务负载的Envoy 代理上
Gateway 可以用来限制哪些服务可以访问外部网络

这道题考察的是对 Istio 中 Gateway 的理解。我们逐项分析，找出错误选项：

✅ 选项分析： #

✅ 1. Gateway 主要用于管理 Ingress 流量 #

正确。 Istio 中的 Gateway 资源主要用于配置入口（Ingress）流量，比如通过 HTTP、HTTPS 等协议从集群外部进入服务网格。

✅ 2. Gateway 可以配置 egress gateway #

正确。 虽然 Gateway 默认是用来处理 Ingress 流量的，但 Istio 同样支持通过配置一个 Egress Gateway 来控制 出网（egress）流量，例如设置出口 IP、控制访问哪些外部服务等。 这个 egress gateway 通常是通过配置 ServiceEntry + VirtualService + Gateway 等来实现的。

❌ 3. Gateway 配置应用于服务负载的 Envoy 代理上 #

错误。 这是错误选项，正确答案就是它。

解释： Istio 的 Gateway 配置并不是应用在每个服务的 sidecar Envoy 上，而是应用在专门部署的 Gateway Envoy 实例（比如 ingressgateway）上。

  • Sidecar 是跟随应用 Pod 部署的 Envoy。
  • Gateway 是一个独立部署的 Envoy 实例，其配置不影响具体服务的 sidecar Envoy。

所以这句话混淆了 Gateway 和 Sidecar 的概念，是错误的。

✅ 4. Gateway 可以用来限制哪些服务可以访问外部网络 #

正确。 这个功能可以通过配置 Egress Gateway + ServiceEntry + VirtualService 实现，确实可以控制哪些服务能够访问哪些外部地址或 IP。

✅ 正确答案： #

Gateway 配置应用于服务负载的 Envoy 代理上 ✅ 错误选项（答案）

如需我结合图解或 YAML 示例进一步说明，可以继续问我。

以下关于ConfgMap和Secret对象描述，哪个是错误的?
配置项(ConfigMap):用于存储工作负载所需配置信息的资源类型，例如工作负载的环境变量，需要连接的mysql地址、端口等信息

密钥(Secret):用于存储工作负所需要认证信息、加密的敏感信息等的资源类型，例女私有镜像仓库的帐号、密码等信息
ConfigMap内容修改后，对应的pod必须重启或者重新加载配置
Secret类似于ConfigMap，是用Base64加密，密文显示，只用来存放用于鉴权的登录码信息

我们逐项分析，找出哪个关于 ConfigMap 和 Secret 的描述是错误的：

✅ 选项分析： #

✅ 1. 配置项(ConfigMap):用于存储工作负载所需配置信息的资源类型，例如工作负载的环境变量，需要连接的mysql地址、端口等信息 #

✅ 正确描述： ConfigMap 确实用于存储非敏感配置信息，如环境变量、配置文件内容、服务地址等。

✅ 2. 密钥(Secret):用于存储工作负载所需要认证信息、加密的敏感信息等的资源类型，例如私有镜像仓库的帐号、密码等信息 #

✅ 正确描述： Secret 是为存储敏感信息（如密码、token、证书等）设计的，符合描述。

✅ 3. ConfigMap内容修改后，对应的Pod必须重启或者重新加载配置 #

✅ 基本正确： ConfigMap 修改后，Pod 是否感知变化取决于挂载方式：

  • 若以环境变量形式引用：必须重启 Pod 才生效；
  • 若以volume 挂载方式引用，Kubelet 会定期检测 ConfigMap 变化并更新挂载内容，但应用需要主动重新加载配置。

所以这句话表述是合理的。

❌ 4. Secret类似于ConfigMap，是用Base64加密，密文显示，只用来存放用于鉴权的登录码信息 #

❌ 错误描述，应为正确选项。

原因：

  • Base64 编码不是加密！ Secret 是使用 Base64 编码（可逆），主要是为了符合 API 要求或转义处理，而不是安全加密。
  • 用途也不限于“登录码信息”。Secret 可用于存放多种类型的敏感信息，例如：
    • 密码、API token
    • TLS 证书/私钥
    • 私有镜像仓库认证信息
    • 自定义敏感配置信息等

✅ 正确答案是： #

Secret类似于ConfigMap，是用Base64加密，密文显示，只用来存放用于鉴权的登录码信息 ✅ 错误选项（答案）

如需我提供具体 YAML 示例或 Base64 解码演示，也可以继续问我。

这个说法：

ConfigMap 内容修改后，对应的 Pod 必须重启或者重新加载配置

是 基本正确的，但 并不绝对，这里来详细解释：

✅ 正确的理解： #

ConfigMap 的更新是否会让 Pod 中的容器立即感知，取决于它是如何被挂载/使用的：

✅ 使用方式一：作为环境变量注入 Pod #

env:
  - name: MYSQL_HOST
    valueFrom:
      configMapKeyRef:
        name: my-config
        key: mysql_host
  • Pod 启动时读取 ConfigMap 内容；
  • 之后即使 ConfigMap 修改，Pod 内不会自动感知变更；
  • ✅ 必须重启 Pod 才能加载新配置。

✅ 使用方式二：以 Volume 方式挂载到文件系统 #

volumes:
  - name: config-volume
    configMap:
      name: my-config
  • 会被挂载到容器文件系统中；
  • kubelet 默认每隔 1 分钟（configMapAndSecretChangeDetectionStrategy）检测并刷新挂载文件；
  • 但应用必须自己重新读取文件或支持热加载，否则不会生效。

所以是：

✅ Pod 不一定要重启，但要么 Pod 重启，要么应用自己 reload 配置才生效。

❗总结： #

使用方式ConfigMap 更新后效果
环境变量必须重启 Pod 才能生效
文件挂载文件内容会更新，但应用需自己 reload 配置

✅ 结论： #

“ConfigMap 内容修改后，对应的 Pod 必须重启或者重新加载配置” 是准确的总结性描述。 在考试或面试中，属于 正确选项。

如你需要我演示一个自动 reload 的 sidecar 或示例配置，也可以告诉我。

某用户的dockerfle中，依照顺序分别执行了以下命令:“WORKDIR /a"“RUN /b"、“WORKDIR /c”，此时之后各层的工作目录为以下哪一项?

在集群网络地址段规划选择上，在以下哪一种网络模式下，所有集群的容器网段可以重叠，服务网段也可重叠
vpc网络
云原生网络2.0
容隧道网络
Flannel网络

在容器隧道网络模式下，所有集群的容器网段可以重叠，服务网段也可以重叠。

原因：

  • 容器隧道网络 (例如 Flannel 的 VXLAN 模式等): 在这种模式下，不同节点上的 Pod 之间的通信会通过隧道进行封装。每个节点维护自己的容器网段，Pod 的 IP 地址只在节点内部可见。跨节点的 Pod 通信通过在宿主机之间建立隧道（例如 VXLAN）来实现，原始的 Pod IP 数据包被封装在宿主机的网络包中进行传输。因此，不同集群的容器可以使用相同的 IP 地址段，因为它们在网络层面是隔离的。服务网段通常也是集群内部的虚拟地址，只要在每个集群内部不冲突即可。

其他网络模式的限制：

  • 云原生网络 2.0 (例如直接路由模式): 在这种模式下，容器 IP 通常直接路由，需要确保不同集群的容器网段不重叠，以避免路由冲突。服务网段也通常需要避免与容器网段和节点网络重叠。
  • Flannel 网络 (非隧道模式，例如 host-gw 模式): 在 host-gw 模式下，依赖宿主机路由实现 Pod 间的通信，不同集群的 Pod 网段仍然需要避免重叠，以防止路由冲突。服务网段的限制与云原生网络 2.0 类似。

因此，容器隧道网络是唯一选项，允许在多个集群中重叠使用容器网段和服务网段。

某用户的dockerfle中，依照顺序分别执行了以下命令:“WORKDIR /a"“RUN d6"、“WORKDIRC”，此时之后各层的工作目录为以下哪一项?
/a/b/c

用户的 Dockerfile 中执行了以下命令：

  1. WORKDIR /a
  2. RUN d6
  3. WORKDIR c

我们来分析一下每一步执行后的工作目录：

  • 执行 WORKDIR /a: 这条命令将容器中的当前工作目录设置为 /a。后续的 RUN、CMD、ENTRYPOINT、COPY 和 ADD 指令都将以此目录为基准。
  • 执行 RUN d6: 这条命令会在 /a 目录下执行 d6 命令。执行完毕后，工作目录仍然是 /a。RUN 指令执行 shell 命令，但不会改变后续指令的工作目录。
  • 执行 WORKDIR c: 这条命令会将容器中的当前工作目录更改为 /c。注意，这里使用的是相对路径 c，但因为之前没有使用 WORKDIR 设置过相对路径的基准，或者说上一个 WORKDIR 设置的是绝对路径 /a，Docker 会将相对路径 c 相对于根目录 / 来解析。因此，工作目录被设置为 /c。

总结:

  • 执行 WORKDIR /a 后，工作目录为 /a。
  • 执行 RUN d6 后，工作目录仍然为 /a。
  • 执行 WORKDIR c 后，工作目录变为 /c。

因此，此时之后各层的工作目录为 /c。

以下关于多云容器平台提供的混合云管理方案的描述，错误的是哪一项?
混合云方案是指混合华为云的CCE集群和自建数据中心的Kubernetes集群的场景
云上统一管理，公有云上实现资源、应用、网格等多云统一管理
云上伸缩应用，私有云作为备用资源，公有云作为固定资源，业务流量突发时，实现快速扩容
云上数据无关，核心数据放线下，公有云上运行与核心数据无关的应用

混合云方案是指混合华为云的CCE集群和自建数据中心的Kubernetes集群的场景

这道题考查的是对多云容器平台中混合云管理方案的理解。我们来逐项分析：

✅ 正确描述分析： #

  1. 混合云方案是指混合华为云的CCE集群和自建数据中心的Kubernetes集群的场景 ✔️ 正确。这是混合云最典型的场景之一，融合云上的 Kubernetes（如 CCE）与本地集群。
  2. 云上统一管理，公有云上实现资源、应用、网格等多云统一管理 ✔️ 正确。现代多云平台支持统一控制面（如华为云 UCM、阿里云 ASM 等）进行跨集群管理。
  3. 云上数据无关，核心数据放线下，公有云上运行与核心数据无关的应用 ✔️ 正确。这符合安全合规要求的一种典型数据分布方式，在政企金融领域常见。

❌ 错误项： #

  1. 云上伸缩应用，私有云作为备用资源，公有云作为固定资源，业务流量突发时，实现快速扩容 ⛔ 错误。这个描述反了。
    • 实际情况是： ➤ 私有云资源通常为固定资源（容量有限、扩容慢） ➤ 公有云才是弹性资源（适合快速扩容、应对突发流量）

✅ 正确答案是： #

云上伸缩应用，私有云作为备用资源，公有云作为固定资源，业务流量突发时，实现快速扩容（❌ 错误）

如需配套图解或更详细背景资料，我可以进一步补充。

以下关于Karmada的核心架构的描述，错误的是哪一项?

Karmada的控制面拥有自己独立的api
提供针对故障迁移、集群资源等调度策略的支持，支持用户自定义扩展
与member集群同步方面，Karmadaagent的push工作模式，可以有效分散控制面压力
Karmada支持集成KubeEdge实现对边缘k8s集群的管理

Karmada支持集成KubeEdge实现对边缘k8s集群的管理

这道题考查对 Karmada 核心架构的理解。我们逐项分析：

✅ 正确项分析： #

  1. Karmada 的控制面拥有自己独立的 API ✔️ 正确。Karmada 的控制面拥有独立的 API Server，提供资源统一管理能力。
  2. 提供针对故障迁移、集群资源等调度策略的支持，支持用户自定义扩展 ✔️ 正确。Karmada 的调度器支持跨集群调度策略，如故障恢复、资源利用率优先等，并允许扩展调度逻辑。
  3. Karmada 支持集成 KubeEdge 实现对边缘 k8s 集群的管理 ✔️ 正确。Karmada 的设计初衷之一就是支持多种类型的集群，包括 KubeEdge 管理的边缘集群。

❌ 错误项分析： #

  1. 与 member 集群同步方面，Karmada-agent 的 push 工作模式，可以有效分散控制面压力 ⛔ 错误。
    • 实际情况：Karmada 默认使用的是 pull 模式：由 karmada-agent 定期从控制面拉取资源并同步到成员集群。
    • 这种设计是为了降低网络开销、提高控制面稳定性，而不是 push。

✅ 正确答案是： #

与 member 集群同步方面，Karmada-agent 的 push 工作模式，可以有效分散控制面压力（❌ 错误）

如需进一步了解 Karmada 的工作机制（如控制面组件、调度器、agent 工作流等），我可以提供详细图解或源码路径。

以下关于多云容器平台MCP进行业务流量分担的描述，错误的是哪一项?

可以从私有云弹性扩容到公有云集群来分担流量

可以自定义域名解析权重

可以对来自不同地域的请求就近转发

需要手动控制在不同云间的应用实例的伸缩

以下关于多云容器平台 MCP 进行业务流量分担的描述，错误的是：

需要手动控制在不同云间的应用实例的伸缩

原因：

多云容器平台 MCP 的核心价值之一就是提供跨多个云环境的自动化管理能力，包括流量分担和应用伸缩。如果需要手动控制不同云之间的应用实例伸缩来分担流量，那就失去了 MCP 的自动化和便捷性优势。

正确的多云流量分担场景通常包含以下自动化或半自动化的机制：

  • 基于预设策略的自动伸缩： MCP 能够根据监控指标（例如 CPU 利用率、内存使用率、请求延迟等）在不同的云环境中自动增加或减少应用实例，以应对流量变化。
  • 流量亲和性策略： MCP 可以根据请求的来源、用户地域等信息，将流量导向更合适的云环境中的实例，例如就近转发。
  • 统一的流量管理： MCP 提供统一的流量入口和管理机制，例如通过全局负载均衡器或服务网格，能够根据配置的策略（例如权重、健康状态）自动将流量分发到不同云环境中的后端实例。

其他选项的分析：

  • 可以从私有云弹性扩容到公有云集群来分担流量: 这是混合云和多云场景下常见的流量分担方式，利用公有云的弹性能力应对私有云不足的情况，描述是正确的。
  • 可以自定义域名解析权重: MCP 通常提供基于 DNS 的流量分发能力，允许管理员设置不同云环境的域名解析权重，从而控制流量的比例，描述是正确的。
  • 可以对来自不同地域的请求就近转发: 这是提升用户体验和降低延迟的常见策略，MCP 通常支持基于地理位置的流量路由，描述是正确的。

因此，认为需要手动控制不同云之间应用实例的伸缩是错误的，MCP 的目标正是实现这种伸缩的自动化或至少是策略驱动的。

单选题9/231、在 Pilot和Envoy 通信的场景中，XDS 协议是基于RPC 实现的传输协议。以下哪一个选项提供路由发现
服务?
LDS
RDS
CDS
EDS

正确答案是 RDS。

解释：

  • XDS (xDiscovery Service) 是一组由 Envoy 使用的发现协议，用于动态获取配置信息。它基于 gRPC 实现。
  • LDS (Listener Discovery Service) 用于发现 Envoy 需要监听的端口和相关的监听器配置。
  • RDS (Route Discovery Service) 用于发现 Envoy 如何将流量路由到不同的后端服务。它提供了路由规则、虚拟主机、路径匹配等配置信息。
  • CDS (Cluster Discovery Service) 用于发现后端服务的集群信息，包括集群成员（Pod IP 地址和端口）、负载均衡策略、健康检查配置等。

在 Pilot 和 Envoy 通信的场景中，Pilot 作为 XDS 服务的提供者，Envoy 通过订阅不同的 XDS API 来获取所需的配置。为了实现路由发现服务，Envoy 需要订阅 RDS API，从 Pilot 获取路由规则。

单选题
10/231、以下关于lsito中Sidecar的描述，错误的是哪一项?
Sidecar将与应用业务逻辑无关的功能抽象到共同基础设施
Sidecar可独立升级
Sidecar不能降低微服务代码的复杂度
Sidecar能够使用istioctl手动注入

正确答案是 Sidecar不能降低微服务代码的复杂度。

解释：

Istio 的 Sidecar 代理（通常是 Envoy）的主要目标之一就是将许多与应用业务逻辑无关的通用功能（例如服务发现、负载均衡、遥测、安全策略实施等）从应用程序代码中解耦并下沉到基础设施层。

通过使用 Sidecar，微服务开发者可以更专注于自己的业务逻辑，而无需在每个服务中重复实现这些通用功能。这实际上降低了微服务代码的复杂度，使其更加轻量级和易于维护。

其他选项的分析：

  • Sidecar将与应用业务逻辑无关的功能抽象到共同基础设施: 这是 Sidecar 的核心设计理念和主要优势，描述是正确的。
  • Sidecar可独立升级: Sidecar 代理可以独立于应用程序容器进行升级，这提供了更大的灵活性和降低了升级风险，描述是正确的。
  • Sidecar能够使用 istioctl 手动注入: Istio 提供了 istioctl 命令行工具，用户可以使用它来手动将 Sidecar 注入到 Kubernetes Pod 中，描述是正确的。

因此，认为 Sidecar 不能降低微服务代码的复杂度是错误的。相反，它是 Sidecar 的一个重要优势。

单选题
11/231、以下关于应用服务网格ASM流量监控的相关描述，错误的是哪一项?
流量监控记录的是组件过去24小时内的数据，所以当部分组件删除后并不能及时的在拓扑图上消失，而是会仍然存在一段时间
流量治理中的故障注入功能，能够作用于基于请求比例灰度发布的场景
企业版网格多集群场景下，只支持集群内部服务之间的流量监控
企业版网格多集群场景下，暂时不支持跨集群服务之间的流量监控

正确答案是 企业版网格多集群场景下，只支持集群内部服务之间的流量监控。

解释：

应用服务网格 (ASM) 的核心价值之一就是提供对跨多个集群的服务流量的可观测性。在企业版网格的多集群场景下，通常会支持跨集群服务之间的流量监控。管理员可以通过统一的控制平面来查看和分析不同集群中服务之间的调用关系、性能指标和健康状态。

其他选项的分析：

  • 流量监控记录的是组件过去24小时内的数据，所以当部分组件删除后并不能及时的在拓扑图上消失，而是会仍然存在一段时间: 这通常是出于数据聚合、性能和避免频繁更新拓扑图的考虑，是一种常见的设计，描述可能是正确的。
  • 流量治理中的故障注入功能，能够作用于基于请求比例灰度发布的场景: 故障注入（例如延迟注入、错误注入）是服务网格中用于测试系统韧性的重要功能，它可以精确地应用于符合特定条件的流量（例如灰度发布中的一部分流量），描述是正确的。
  • 企业版网格多集群场景下，暂时不支持跨集群服务之间的流量监控: 这与服务网格的核心价值相悖。企业级通常会要求具备跨集群的统一可观测性。因此，这个描述很可能是错误的。

因此，企业版网格多集群场景下，只支持集群内部服务之间的流量监控 是错误的描述。企业版 ASM 通常会提供跨集群的流量监控能力。

单选题 12/231、设置容器日志转储后，ICAget采集的日志不会实时转储，而是积攒到一定量后再转储。当积攒到的日志容量达到多少时会触发转储动作?
10MB
20MB
50MB
100M

100m

单选题131231、应用运维管理AOM的日志管理功能不包括以下哪一项?
日志检索
日志转储
日志报表展示
日志智能订阅

日志报表展示

正确答案是 日志智能订阅。

解释：

应用运维管理 (AOM) 的日志管理功能通常包括对日志数据的收集、存储、检索、分析和可视化。让我们逐个分析选项：

  • 日志检索: 这是日志管理的基本功能，允许用户根据关键字、时间范围、来源等条件查找特定的日志条目。
  • 日志转储: 指将存储的日志数据导出或备份到其他存储介质或系统，以满足长期存储、合规性或进一步分析的需求。
  • 日志报表展示: 日志管理系统通常提供各种报表和仪表盘，以可视化地展示日志数据的统计信息、趋势和异常情况，帮助用户更好地理解系统行为和性能。
  • 日志智能订阅: “日志智能订阅” 通常指的是用户可以根据预定义的规则或模式，自动接收符合条件的实时或近实时的日志通知或流。虽然一些高级的日志管理或事件管理系统可能包含类似功能，但这并非应用运维管理 AOM 日志管理功能的核心或常见组成部分。更常见的是告警或通知功能，这些功能基于日志分析结果触发，而不是直接订阅原始日志流。

因此，日志智能订阅 不是应用运维管理 AOM 日志管理功能通常包含的选项。

单选题 141231、对弹性到CC的Pod，若其配置的资源规格不满足CCI容器规范，virtua-kubelet会自动尝试将Pod资源向上规整到满足CCI容器规范的范围。CPU向上调整的极限是多少核?
8核
16核
32核
64核

32

单选题

15/231、以下关于CCE和CCI的区别的描述，正确的是哪一项?

使用CCE，无需要创建集群和节点，而CCI需要创建和管理Master节点及Work节点CCE支持按需计费方式，而CCI支持包年/包月与按需计费两种方式CCE适用于大规模长期稳定的应用，而CCI适用于批后计算、高性能计算、突发扩容等场景CCE最小计A价单位为秒，CCI最小计价单位为小时

正确答案是 CCE适用于大规模长期稳定的应用，而CCI适用于批后计算、高性能计算、突发扩容等场景。

解释：

让我们逐一分析每个选项：

  • 使用 CCE，无需要创建集群和节点，而 CCI 需要创建和管理 Master 节点及 Worker 节点: 这是错误的。CCE (Cloud Container Engine) 是华为云的 Kubernetes 服务，它需要创建和管理集群（包括 Master 和 Worker 节点），虽然华为云会托管 Master 节点。CCI (Cloud Container Instance) 才是真正的 Serverless 容器实例，无需用户管理节点。
  • CCE 支持按需计费方式，而 CCI 支持包年/包月与按需计费两种方式: 这是错误的。CCE 和 CCI 都支持按需计费的方式。CCE 通常也支持包年/包月等预付费模式，而 CCI 主要以按需计费为主，更贴合其弹性使用的特性。
  • CCE 适用于大规模长期稳定的应用，而 CCI 适用于批后计算、高性能计算、突发扩容等场景: 这是正确的。
    • CCE 提供完整的 Kubernetes 集群管理能力，适合运行需要长期稳定运行、有复杂编排和管理需求的大规模应用。
    • CCI 提供轻量级的 Serverless 容器实例，按实际使用资源计费，启动速度快，非常适合短时任务、弹性伸缩、批处理、事件驱动等场景。
  • CCE 最小计价单位为秒，CCI 最小计价单位为小时: 这是错误的。通常情况下，云计算服务的计费粒度都在逐渐细化。CCE 和 CCI 的按需计费都可能支持秒级计费，具体以华为云最新的计费策略为准。

因此，最准确描述 CCE 和 CCI 区别的选项是 CCE 适用于大规模长期稳定的应用，而 CCI 适用于批后计算、高性能计算、突发扩容等场景。

单选题 16/231、以下关于华为云容器引擎CCE和自建Kubernetes集群的描述，错误的是哪一项?
自建kubermetes集群管理基础设施通常涉及安装、操作、扩展自己的集群管理软件、配置管理系统和监控解决方案，管理复杂
自建Kubermetes集群需要根据业务流量情况和健康情况人工确定容器服务的部署，可扩展性差云容器引擎CCE需自行登录服务器输入命令行查看监控、日志信息，无法及时察知系统异常
借助云容器引擎CCE，可以一键创建和升级Kubermetes容器集群，无需自行搭建Docker和Kubernetes集群

正确答案是 云容器引擎CCE需自行登录服务器输入命令行查看监控、日志信息，无法及时察觉系统异常。

解释：

华为云容器引擎 CCE 提供了完善的监控和日志管理功能，旨在帮助用户方便地观察和诊断集群及应用的状态。它通常包括：

  • 集成的监控仪表盘: CCE 提供可视化的监控界面，展示集群、节点、Pod 和容器的各项性能指标（CPU、内存、网络等）。用户无需登录服务器即可查看这些信息。
  • 集成的日志管理: CCE 通常与华为云的日志服务 LTS 集成，用户可以在控制台集中查看和检索集群中各个容器的日志，而无需登录到每个节点或 Pod 中。
  • 告警机制: CCE 允许用户配置告警规则，当集群或应用的指标达到预设阈值时，系统会自动发送告警通知，帮助用户及时发现和处理异常。

因此，认为 CCE 需要用户自行登录服务器通过命令行查看监控和日志，并且无法及时察觉系统异常是错误的。CCE 提供了更便捷和自动化的方式来管理集群的监控和日志。

其他选项的分析：

  • 自建 Kubernetes 集群管理基础设施通常涉及安装、操作、扩展自己的集群管理软件、配置管理系统和监控解决方案，管理复杂: 这是正确的。自建 Kubernetes 集群需要用户承担更多基础设施的管理和维护工作。
  • 自建 Kubernetes 集群需要根据业务流量情况和健康情况人工确定容器服务的部署，可扩展性差: 这是相对而言正确的。虽然 Kubernetes 本身提供了弹性伸缩的能力，但在自建场景下，配置和管理这些自动伸缩策略可能更加复杂，并且依赖于用户自行搭建和维护监控告警系统。相比之下，CCE 通常提供了更便捷的自动伸缩和弹性伸缩能力。
  • 借助云容器引擎 CCE，可以一键创建和升级 Kubernetes 容器集群，无需自行搭建 Docker 和 Kubernetes 集群: 这是正确的。CCE 简化了 Kubernetes 集群的创建和管理过程，用户无需从头开始搭建底层基础设施。
单选题17/231、以下关于CCE支持的几种容器网络的描述，错误的是哪一项?

CCE支持容器隧道网络VPC网络、云原生网络2.0三种模型

子

云原生网络2.0基于vxlan隧道封装，有一定性能损耗，而容器隧道网络性能无损耗容器隧道网络和VPC网络适用于CCE集群，而云原生网络2.0适用于CC

Turbo集群

容器隧道网络和云原生网络2.0最大均可支持2000节点，而VPC网络默认仅支持200节点

正确答案是 云原生网络 2.0 基于 vxlan 隧道封装，有一定性能损耗，而容器隧道网络性能无损耗。

解释：

  • 容器隧道网络 (例如 Flannel 的 VXLAN 模式): 这种网络模式通常会使用 VXLAN (Virtual Extensible LAN) 等隧道技术对容器间的通信进行封装，这会带来一定的性能损耗，因为需要额外的封包和解包操作。
  • 云原生网络 2.0 (例如基于 ENI 的直接路由模式): 这种网络模式通常会将容器的网络接口直接连接到 VPC 网络，容器拥有 VPC 内的 IP 地址，可以直接进行路由，性能损耗相对较小，接近于 VPC 网络的性能。它避免了额外的隧道封装开销。

因此，描述云原生网络 2.0 基于 VXLAN 封装且有性能损耗，而容器隧道网络性能无损耗是错误的。情况正好相反。

其他选项的分析：

  • CCE 支持容器隧道网络 VPC 网络、云原生网络 2.0 三种模型: 这是正确的。CCE 通常支持这几种主流的容器网络模型，以满足不同场景的需求。
  • 容器隧道网络和 VPC 网络适用于 CCE 集群，而云原生网络 2.0 适用于 CCE Turbo 集群: 这通常是正确的。云原生网络 2.0 由于其高性能和与 VPC 的深度集成，更适合对网络性能有较高要求的 CCE Turbo 集群。
  • 容器隧道网络和云原生网络 2.0 最大均可支持 2000 节点，而 VPC 网络默认仅支持 200 节点: 这通常是正确的。容器隧道网络和云原生网络 2.0 在设计上可以支持更大规模的集群节点，而 VPC 网络可能会受到 IP 地址数量和路由规则等限制，默认支持的节点数量较少。
单选题

19/231、在ingerss中，以下哪个组件真正实现外部请求的转发?

Ingress
ingress
Service
Endpoint

service

正确答案是 Ingress Controller。

您提供的选项中没有直接提到 Ingress Controller。在 Kubernetes Ingress 的体系结构中，以下组件协同工作以实现外部请求的转发：

  1. Ingress 对象 (API 对象): 它定义了将外部请求路由到集群内部服务的规则。您提供的选项中的 “Ingress” 和 “ingress” 指的是这个 API 对象。但 Ingress 对象本身不负责实际的流量转发。它只是一个配置。
  2. Ingress Controller: 这是一个具体的控制器（通常以 Pod 的形式运行在集群中），它监听 Ingress 对象的创建、更新和删除事件，并根据这些规则配置底层的负载均衡器或代理服务器（例如 Nginx Ingress Controller、Traefik、HAProxy Ingress Controller 等）。Ingress Controller 才是真正实现外部请求接收、路由和转发到后端 Service 的组件。
  3. Service: Kubernetes Service 是一种抽象，它为一组 Pod 提供了一个稳定的 IP 地址和 DNS 名称。Ingress Controller 会将流量转发到后端 Service。
  4. Endpoint: Endpoint 对象记录了 Service 对应的后端 Pod 的 IP 地址和端口。Ingress Controller 通常会通过 Service 发现其对应的 Endpoint。

由于您提供的选项中没有 Ingress Controller，最接近的但并不完全准确的答案是 Ingress。 然而，需要明确的是，Ingress Controller 才是真正执行流量转发的组件。

如果必须从您提供的选项中选择，考虑到 Ingress 对象定义了转发规则，可以勉强选择 Ingress (或 ingress，两者在 Kubernetes 中通常不区分大小写，指的是同一个 API 对象)，但请务必理解它本身不执行转发，而是由 Ingress Controller 根据 Ingress 对象的配置来完成转发。

更好的表述应该是：Ingress Controller 真正实现外部请求的转发。

单选题 20/231、在K8s中，当节点内存资源不足时，内核可以按照策略的优先级，优先终上服务质量OS低的容器，以下关于优先级的描术，哪个是正确的?

状态为burstable优先级的POD，设置的requests和limits不一致，00MAdi为0~1000，会被优先kil

状态为guaranteed优先级的POD，设置的requests和limits一致，00MAdij为-998，会被优先ki

状态为besteffort优先级的POD，不设置requests和limits，当系统OOM后，会被优先kil!

OOMAdj值越高，Qos越低

正确答案是 状态为 besteffort 优先级的 POD，不设置 requests 和 limits，当系统 OOM 后，会被优先 kill!

解释：

Kubernetes 使用服务质量 (QoS) 类来管理 Pod 的资源分配和优先级。当节点内存不足 (OOM - Out Of Memory) 时，kubelet 会根据 Pod 的 QoS 优先级和 OOM score 杀死 Pod 以回收内存。优先级从低到高依次是：BestEffort < Burstable < Guaranteed。

让我们分析一下每个选项：

  • 状态为 burstable 优先级的 POD，设置的 requests 和 limits 不一致，OOMAdj 为 0~1000，会被优先 kill: Burstable 优先级的 Pod 会在资源紧张时被考虑驱逐，但优先级高于 BestEffort。OOMAdj 值在 0 到 1000 之间，值越高越容易被 kill。但它们不会比 BestEffort 的 Pod 更优先被 kill。
  • 状态为 guaranteed 优先级的 POD，设置的 requests 和 limits 一致，OOMAdj 为 -998，会被优先 kill: Guaranteed 优先级的 Pod 拥有最高的优先级，kubelet 会尽力保证它们的资源需求。它们的 OOMAdj 值通常为 -998 或更低，这意味着它们最不容易被 OOM killer 杀死。
  • 状态为 besteffort 优先级的 POD，不设置 requests 和 limits，当系统 OOM 后，会被优先 kill! BestEffort 优先级的 Pod 不保证任何资源，当节点内存不足时，它们是最先被 kubelet 考虑驱逐的，因为它们对系统资源的要求最低。它们的 OOMAdj 值通常是最高的正值。
  • OOMAdj 值越高，Qos 越低: 这是正确的。OOMAdj (Out-of-Memory Adjustment) 是 Linux 内核的一个参数，kubelet 会根据 Pod 的 QoS 类设置这个值。OOMAdj 值越高，该进程被 Linux 内核 OOM killer 杀死的可能性就越大，因此对应的 QoS 也就越低。 BestEffort Pod 的 OOMAdj 值最高，Guaranteed Pod 的 OOMAdj 值最低（负值）。

因此，最准确的描述是状态为 besteffort 优先级的 POD 在系统 OOM 后会被优先 kill! 虽然 “OOMAdj 值越高，Qos 越低” 这个描述也是正确的，但问题是关于优先级的描述，而选项 C 直接描述了 BestEffort Pod 的驱逐优先级。

单选题 21/231、当镜像仓库SWR中的镜像版本更新时，用户希望能够自动更新CCE或CCI使用该镜像的应用，应该采用以下哪一个方法实现?

在SWR中为镜像添加触发器

在CCE或CCI中更新负载部霉文件

在SWR中添加存活时间老化规则

在SWR中添加版本数目老化规则

正确答案是 A. 在 SWR 中为镜像添加触发器。

解释：

华为云镜像仓库 SWR (Software Repository for Container) 提供了镜像触发器 (Image Trigger) 功能。通过在 SWR 中为特定的镜像仓库和标签配置触发器，可以在镜像版本更新（例如推送了新的镜像标签）时自动触发预定义的操作。

对于自动更新 CCE 或 CCI 中使用该镜像的应用，您可以配置触发器来：

  • 触发 CCE 工作负载的更新: 可以配置触发器调用 CCE 的 API 来更新 Deployment、StatefulSet 等工作负载的镜像版本，从而触发 Pod 的滚动更新。
  • 触发 CCI 实例的更新: 可以配置触发器调用 CCI 的 API 来更新容器实例的镜像版本，并触发实例的重启或更新。

其他选项的分析：

  • B. 在 CCE 或 CCI 中更新负载部署文件: 这是一种手动更新镜像的方法，无法实现自动更新。
  • C. 在 SWR 中添加存活时间老化规则: 存活时间老化规则用于自动删除长时间未使用的镜像版本，与自动更新应用无关。
  • D. 在 SWR 中添加版本数目老化规则: 版本数目老化规则用于保留最新 N 个镜像版本，删除旧版本，同样与自动更新应用无关。

因此，在 SWR 中为镜像添加触发器 是实现镜像版本更新时自动更新 CCE 或 CCI 应用的正确方法。

单选题22/231、以下关于Cluster AutoScaler伸缩策略的描述，哪个是错误的?

Cluster

Cluster

当承载某应用的容器CPU使用率飙升时，可通过配置Cluster当集群里资源不足时，可通过配置Cluster

当集群里资源不足时，可通过配置Cluster

当承载某应用的容器CPU使用率飙升时，可通过配置Cluster当集群里资源不足时，可通过配置Cluster

您好！您提供的选项似乎不完整，缺少了伸缩策略的具体描述。为了给出正确的答案，请您提供完整的选项内容。

不过，我可以先根据 Cluster Autoscaler 的常见行为和策略，推测一些可能的选项以及哪个可能是错误的：

Cluster Autoscaler 的常见伸缩策略通常包括：

  • 基于资源利用率的伸缩: 当集群中某些节点的 CPU 或内存利用率过高或过低时，自动增加或减少节点。
  • 基于 Pod Pending 的伸缩: 当集群中有因资源不足而无法调度的 Pending Pod 时，自动增加新的节点。
  • 基于自定义指标的伸缩: (通常需要集成 Horizontal Pod Autoscaler (HPA) 和 Custom Metrics Adapter) 根据应用程序的自定义指标进行节点伸缩。

以下是一些可能错误的描述示例 (需要您提供完整选项才能确定哪个是您题目中的错误选项)：

  • Cluster Autoscaler 会根据单个容器的 CPU 使用率直接触发节点伸缩。 (错误。Cluster Autoscaler 主要关注节点级别的资源利用率和 Pod 的调度需求，而不是单个容器的指标。单个容器的伸缩通常由 Horizontal Pod Autoscaler (HPA) 负责。)
  • Cluster Autoscaler 可以保证在任何情况下都能立即满足 Pod 的资源需求。 (错误。节点扩容需要时间，并且受到云提供商的资源限制。)
  • Cluster Autoscaler 会在 Pod CPU 使用率降低时立即缩减节点。 (错误。为了避免频繁伸缩，Cluster Autoscaler 通常会设置缩容的冷却时间 (scale-down-delay)。)
  • Cluster Autoscaler 的缩容策略会优先删除运行重要应用的节点。 (错误。Cluster Autoscaler 会尽量避免删除运行重要 Pod 的节点，例如带有特定的 annotation。)

请您提供完整的选项，我将能够准确地告诉您哪个描述是错误的。

单选题 23/231、在一个集群中部分节点配置有GPU卡，如果不希望不使用专用硬件的Pod调度到这个节点上，可以通过配置以下选项中描述的哪个策略?

通过配置Taints和Toleration策略

通过配置HPC策略

通过配置Cluster

通过配置PodAffinity策略

正确答案是 A. 通过配置 Taints 和 Toleration 策略。

解释：

  • Taints (污点): 您可以在配置有 GPU 卡的节点上设置 Taints。Taint 用于标记节点，表明某些 Pod 不应该调度到该节点上，除非这些 Pod 具有相应的 Toleration。例如，您可以设置一个名为 nvidia.com/gpu=present:NoSchedule 的 Taint 到 GPU 节点上。
  • Toleration (容忍度): 您需要在希望调度到带有 GPU Taint 节点的 Pod 的 PodSpec 中配置相应的 Toleration。Toleration 允许 Pod 容忍一个或多个 Taints。只有当 Pod 的 Toleration 与节点的 Taint 相匹配时，该 Pod 才能调度到该节点上。

通过这种 Taints 和 Toleration 的组合使用，您可以确保只有需要 GPU 资源的 Pod 才会被调度到配置了 GPU 卡的节点上，而其他不需要 GPU 的 Pod 则会被调度到没有这些 Taints 的节点上。

其他选项的分析：

  • B. 通过配置 HPC 策略: HPC (High-Performance Computing) 策略通常关注于高性能计算任务的资源调度和优化，例如节点亲和性、拓扑感知调度等，但它不是直接用来阻止非 GPU Pod 调度到 GPU 节点的机制。
  • C. 通过配置 Cluster: “Cluster” 本身不是一个具体的策略配置选项。Cluster Autoscaler 是用于自动调整集群节点数量的组件，与控制 Pod 在特定节点上的调度无关。
  • D. 通过配置 PodAffinity 策略: PodAffinity (Pod 亲和性) 用于控制 Pod 应该调度到哪些节点上，基于已经运行在该节点上的其他 Pod 的标签。虽然可以使用节点标签配合 PodAffinity 实现类似的效果，但 Taints 和 Toleration 是 Kubernetes 专门为控制 Pod 是否可以（或不可以）调度到特定节点而设计的机制，更加直接和清晰。
单选题 24/231、某用户使用容器隧道网络作为容器网络模型，容器网段为172.168.0.0/16(IP量为65536)，节点从容器网段中一次分配的IP网段为16，则最多可创建的节点数量和每个节点最多创建的POD数量是以下哪一项?

A)4096，16

B)4096,256

256,16

256,256

正确答案是 A) 4096，16。

解释：

  • 容器网段: 172.168.0.0/16，总共有 216=65536 个 IP 地址。
  • 每个节点分配的 IP 网段大小: /28 (因为 32 - 16 = 16，而 216−12=24=16，所以是 /28，每个节点分配 232−28=24=16 个 IP 地址)。题目中直接说明每个节点分配的 IP 网段为 16，这等价于一个 /28 的子网。

计算可创建的节点数量:

总 IP 地址数量 / 每个节点分配的 IP 地址数量 = 可创建的节点数量

65536/16=4096

计算每个节点最多创建的 Pod 数量:

在容器隧道网络模型中，每个 Pod 通常会分配一个独立的 IP 地址。因此，每个节点最多可以创建的 Pod 数量受到分配给该节点的 IP 地址数量的限制。题目中说明每个节点从容器网段中一次分配的 IP 网段为 16，这意味着每个节点最多可以拥有 16 个 Pod 的 IP 地址。

因此，最多可创建的节点数量是 4096，每个节点最多创建的 Pod 数量是 16。

单选题26/231、以下关于多云场景下存在的挑战的描述，错误的是哪一项?
集群繁多，配置繁琐
业务过于集中
集群的边界限制，带来资源调度、弹性伸缩等受限问题
厂商绑定


业务过于集中

B) 业务过于集中

多云战略的一个主要目标和特点就是分散风险、避免业务过度集中在单一云服务商或单一地理位置。因此，“业务过于集中”与多云场景的特性是相悖的，它不是多云场景下会存在的挑战，反而是多云试图解决的问题。

其它选项描述的是多云场景下确实存在的挑战：

  • A) 集群繁多，配置繁琐: 管理和维护来自不同云服务商的多个集群，配置和运维的复杂度会显著增加。
  • C) 集群的边界限制，带来资源调度、弹性伸缩等受限问题: 不同云平台之间存在技术壁垒和管理边界，实现跨云的统一资源调度、无缝弹性伸缩等会比较困难。
  • D) 厂商绑定: 虽然多云旨在减少对单一厂商的过度依赖，但在实际操作中，一旦在某个云平台上使用了其特有的服务或技术，仍然可能形成一定程度的厂商绑定，迁移成本较高。
单选题

28/231、以下关于应用服务网格ASM灰度发布全流程自动化管理的说法，错误的是哪一项?

灰度版本一键部署，流量切换一键生效

B

配置式灰度策略，仅支持流量比例策略

一站式健康、性能、流量监控

能够实现灰度发布过程量化、智能化、可视化

B) 配置式灰度策略，仅支持流量比例策略

错误原因：

应用服务网格 (ASM) 通常提供非常灵活和丰富的流量管理策略，而不仅仅是基于流量比例的灰度发布。除了按百分比切分流量外，ASM 通常还支持更复杂的灰度策略，例如：

  • 基于请求内容： 如基于 HTTP Header (例如 user-agent、cookie、自定义业务标签)、URL 路径、请求参数等进行流量切分。这允许将特定用户群体（如内测用户、特定地区用户）或特定类型的请求导向灰度版本。
  • 基于来源： 如基于源 IP 地址或源服务。

声称“仅支持流量比例策略”是对现代服务网格能力的一种低估，因此这个说法是错误的。

其他选项的正确性：

  • A) 灰度版本一键部署，流量切换一键生效: 这是服务网格致力于实现的目标之一，通过简化操作来提高发布效率和降低风险。
  • C) 一站式健康、性能、流量监控: 服务网格的核心能力之一就是提供强大的可观测性，对灰度版本和稳定版本的健康状况、性能指标（如延迟、错误率）和流量分布进行统一监控。
  • D) 能够实现灰度发布过程量化、智能化、可视化: 通过监控数据，可以量化灰度版本的表现；结合自动化工具，可以实现基于策略的智能决策（如自动回滚或逐步放量）；同时，提供可视化界面来展示整个灰度过程的状态。
单选题?29/231、在lstio 架构中，基于xDS协议提供了标准的控制面规范，并以此向数据面传递服务信息和治理规则。以下哪一个选项提供集群发现服务?
LDS
RDS
CDS
Eds

rds

正确答案是：CDS

解析：

在 Istio 架构中，xDS 协议是 Envoy 与控制面通信的重要机制，它包括以下几个主要组件：

缩写全称功能简介
LDSListener Discovery Service监听器发现服务，配置监听端口及协议等。
RDSRoute Discovery Service路由发现服务，配置路由规则。
CDSCluster Discovery Service集群发现服务，配置上游服务集群信息。
EDSEndpoint Discovery Service实例发现服务，配置具体的服务实例（IP+端口）。

因此，提供“集群发现服务”的是 CDS（Cluster Discovery Service）。

✅ 正确答案：CDS

单选题 31/231、容器洞察引擎CIE的容器洞察提供了资源全景、资源消耗、近一小时的指标展示以及故障一览和故障分析的功能。其支持查看的资源不包括以下哪个?

容器组Pod

守护进程集DaemonSet

无状态负载Deployment

有状态负载StatefulSet

好的，答案是 守护进程集DaemonSet。

解释:

容器洞察引擎CIE的容器洞察通常关注于代表应用实例的资源，例如：

  • 容器组Pod: Kubernetes 中最小的可部署单元，包含一个或多个共享存储、网络、以及如何运行这些容器的声明的容器。
  • 无状态负载Deployment: Kubernetes 控制器，用于管理无状态应用（Pod 的副本集）。
  • 有状态负载StatefulSet: Kubernetes 控制器，用于管理有状态应用（具有稳定网络标识、持久存储等）。

守护进程集DaemonSet 确保在每个（或某些特定的）节点上运行一个 Pod 的副本。它更多地关注于集群级别的、通常是基础设施相关的任务，而不是代表单个应用实例。因此，容器洞察引擎的资源洞察功能通常不直接查看 DaemonSet 本身，而是关注由 DaemonSet 管理的 Pod 实例的资源使用情况。

因此，容器洞察引擎CIE的容器洞察通常不直接支持查看 守护进程集DaemonSet 这个资源对象本身，而是会查看由 DaemonSet 管理的 Pod 的资源情况。

单选题321231、若需要将部署在CCE上的无状态负载、有状态负载、普通任务三种类型的容器实例弹性创建到华为云云容实例CCI服务上，在创建CCE集群时，需要设置集群的网络类型为以下哪一项?

VPC网络

多

容器隧道网络

VPC网络和容器隧道网络均可

CCI专用网络


vpc

好的，答案是 容器隧道网络。

解释:

为了能够将部署在 CCE 上的不同类型的容器实例（无状态负载 Deployment、有状态负载 StatefulSet、普通任务 Job/CronJob）弹性地创建到华为云容器实例 CCI 服务上，CCE 集群的网络类型必须设置为 容器隧道网络。

原因：

  • 容器隧道网络 允许 CCE 集群内的 Pod 和 CCI 之间建立安全的隧道连接。这种隧道机制使得 CCE 集群内的容器实例能够通过该隧道弹性地扩展到 CCI 上，并且能够与 CCE 集群内的其他服务进行通信。
  • VPC 网络 是华为云的基础网络，CCE 集群本身需要部署在 VPC 网络内，但仅有 VPC 网络无法直接实现 Pod 到 CCI 的弹性创建和通信。
  • VPC 网络和容器隧道网络均可 的说法不准确。虽然 CCE 集群需要 VPC 网络作为基础，但实现弹性伸缩到 CCI 的关键在于容器隧道网络。
  • CCI 专用网络 并非 CCE 集群的网络类型选项。CCI 本身运行在 VPC 网络中，但 CCE 集群需要特定的网络类型才能与其协同工作进行弹性伸缩。

总结：

要实现将 CCE 上的容器实例弹性创建到 CCI，必须在创建 CCE 集群时选择 容器隧道网络。

单选题 33/231、若需要对Kubermetes集群某节点NodeA进行下线维护，并将该节点上运行的业务Pod重新调度至其他节点，则可为此Node A节点添加以下哪一项污点效果?

NoSchedule

BPreferSchedule

PreferNoSchedule

NoExecute

好的，答案是 NoSchedule 和 NoExecute 都可以实现将 NodeA 上的业务 Pod 重新调度至其他节点，但它们的效果略有不同，需要根据具体维护需求选择。

详细解释:

  • NoSchedule:
    • 当给 NodeA 添加 NoSchedule 污点后，新的 Pod 将不会被调度到该节点上。
    • 已经运行在 NodeA 上的 Pod 不会立即被驱逐。如果希望驱逐已有的 Pod，需要配合其他操作（例如手动删除 Pod 或使用 Drain 节点）。
    • 因此，如果你的目标是阻止新的 Pod 调度到 NodeA 并逐步清理其上的现有 Pod，可以先添加 NoSchedule 污点，然后手动驱逐或等待控制器自动在其他节点创建新的副本。
  • PreferNoSchedule:
    • 这是一种偏好设置，而不是强制性规则。调度器会尽量避免将新的 Pod 调度到具有该污点的节点上，但如果实在没有其他合适的节点，仍然有可能调度上去。
    • 这个选项通常用于柔性地避免在某些节点上运行某些类型的 Pod。
  • PreferNoExecute:
    • 这也是一种偏好设置，调度器会尽量避免将新的 Pod 调度到具有该污点的节点上。
    • 已经运行在 NodeA 上的 Pod 不会被驱逐。
  • NoExecute:
    • 当给 NodeA 添加 NoExecute 污点后，新的 Pod 将不会被调度到该节点上。
    • 最重要的是，已经运行在 NodeA 上的 Pod 会被驱逐（evicted），除非 Pod 本身定义了可以容忍该污点。
    • 这是进行节点维护并快速将业务 Pod 迁移到其他节点的常用选项。

总结:

为了实现将 NodeA 上的业务 Pod 重新调度至其他节点并阻止新的 Pod 调度到该节点，你可以选择：

  • NoSchedule: 阻止新的 Pod 调度，但需要额外操作驱逐现有 Pod。
  • NoExecute: 更直接地实现你的需求，它会阻止新的 Pod 调度，并且会自动驱逐已经运行在该节点上的 Pod（除非 Pod 有相应的容忍度设置）。

因此，最符合题目要求的选项是 NoExecute，因为它能直接触发 Pod 的重新调度。如果你希望更温和地处理，可以先使用 NoSchedule，再配合节点排空（kubectl drain) 命令。但从选项来看，NoExecute 是更直接的答案。

考虑到题目只要求添加一个污点效果，并且目标是“并将该节点上运行的业务 Pod 重新调度至其他节点”，NoExecute 是最合适的选择。

单选题341231、以下关于Service的YAML文件中的参数的描述，错误的是哪一项?

kind参数后应填写为Service

metada.name参数指定Service的名称

specports中targetPort参数指定Service对外暴露的端口

spectype参数指定Service的类型

好的，答案是 spec.ports 中 targetPort 参数指定 Service 对外暴露的端口。

解释:

让我们逐个分析这些描述：

  • kind 参数后应填写为 Service: 这是正确的。在 Kubernetes 的 YAML 配置文件中，kind 字段用于指定资源对象的类型，对于 Service 来说，其值应为 Service。
  • metadata.name 参数指定 Service 的名称: 这也是正确的。metadata.name 字段用于为 Kubernetes 资源对象（包括 Service）指定一个在命名空间内唯一的名称。
  • spec.ports 中 targetPort 参数指定 Service 对外暴露的端口: 这是错误的。spec.ports.targetPort 参数指定的是 Pod 中容器暴露的端口，Service 会将接收到的流量转发到与 targetPort 匹配的 Pod 的端口上。Service 对外暴露的端口是由 spec.ports.port 参数指定的。
  • spec.type 参数指定 Service 的类型: 这是正确的。spec.type 字段用于指定 Service 的类型，常见的类型包括 ClusterIP、NodePort、LoadBalancer 和 ExternalName。

正确理解 Service 的端口配置:

在 Service 的 spec.ports 数组中，通常会包含以下字段：

  • port: Service 本身对外暴露的端口。客户端通过这个端口访问 Service。
  • targetPort: 后端 Pod 中容器监听的端口。Service 会将接收到的流量转发到这些 Pod 的 targetPort 上。
  • protocol: 暴露的协议，通常是 TCP 或 UDP。
  • nodePort (仅在 type 为 NodePort 或 LoadBalancer 时使用): 在每个 Node 上的保留端口，外部可以通过 NodeIP:NodePort 访问 Service。

因此，错误的是关于 targetPort 的描述。targetPort 不是 Service 对外暴露的端口，而是后端 Pod 容器的端口。

单选题36/231、以下关于不同类型的Service的描述，错误的是哪一项?

NodePort类型的Service会让Kubemetes集群每个节点上保留一个相同的端口BLoadBalancer类型的Service是NodePort类型Service的扩展

NodePort类型或者LoadBalancer类型的Service都会被分配-个ClusterlP

Headless

好的，答案是 NodePort 类型或者 LoadBalancer 类型的 Service 都会被分配一个 ClusterIP。

解释:

让我们逐个分析这些描述：

  • NodePort 类型的 Service 会让 Kubernetes 集群每个节点上保留一个相同的端口: 这是正确的。NodePort 类型的 Service 会在集群的每个 Node 上开放一个指定的端口（在 30000-32767 范围内），通过 NodeIP:NodePort 可以从集群外部访问 Service。
  • LoadBalancer 类型的 Service 是 NodePort 类型 Service 的扩展: 这是正确的。LoadBalancer 类型通常在云环境中使用，它会自动创建一个外部负载均衡器，并将流量转发到后端的 NodePort Service 上。因此，LoadBalancer 依赖于 NodePort 的功能。
  • NodePort 类型或者 LoadBalancer 类型的 Service 都会被分配一个 ClusterIP: 这是错误的。
    • NodePort 类型的 Service 会被分配一个 ClusterIP。ClusterIP 是 Service 在集群内部的虚拟 IP 地址，用于集群内部的服务发现和负载均衡。NodePort Service 除了 NodePort 之外，也拥有一个 ClusterIP。
    • LoadBalancer 类型的 Service 也会被分配一个 ClusterIP。LoadBalancer 在提供外部访问能力的同时，在集群内部仍然通过 ClusterIP 进行服务发现和路由。
  • Headless Service 不会分配 ClusterIP: 这是正确的。Headless Service 通过将 Service 的 DNS 条目直接指向后端的 Pod IP 地址，而不是通过 ClusterIP 进行代理。它的 spec.clusterIP 字段设置为 None。

总结:

NodePort 和 LoadBalancer 类型的 Service 都会被分配一个 ClusterIP，用于集群内部的通信。因此，描述 “NodePort 类型或者 LoadBalancer 类型的 Service 都会被分配一个 ClusterIP” 本身是正确的，但题目要求找出错误的描述。

仔细审题，我之前的理解有偏差。选项 C 的描述本身是正确的。让我们重新审视所有选项，找出真正错误的那个。

  • A. NodePort 类型的 Service 会让 Kubernetes 集群每个节点上保留一个相同的端口: 正确。
  • B. LoadBalancer 类型的 Service 是 NodePort 类型 Service 的扩展: 正确。
  • C. NodePort 类型或者 LoadBalancer 类型的 Service 都会被分配一个 ClusterIP: 正确。
  • D. Headless Service 不会分配 ClusterIP: 正确。

重新思考: 题目中可能存在一些歧义或者我之前的知识点理解存在偏差。让我们再次仔细分析 Service 的类型和特性。

关键点回顾:

  • ClusterIP: 集群内部的虚拟 IP，仅可在集群内部访问。所有 Service 类型（除了 Headless）都会分配一个 ClusterIP。
  • NodePort: 在每个 Node 上开放一个端口，允许通过 NodeIP:NodePort 从集群外部访问。NodePort Service 也会拥有一个 ClusterIP。
  • LoadBalancer: 在 NodePort 的基础上，由云服务商提供外部负载均衡器，将流量转发到 NodePort Service。LoadBalancer Service 也会拥有一个 ClusterIP。
  • Headless: 不分配 ClusterIP，而是通过 DNS 直接解析到 Pod IP。

再次分析选项:

考虑到以上回顾，选项 A、B、C 和 D 的描述都是正确的。这与题目要求找出错误项相矛盾。

可能性分析:

  1. 题目本身可能存在错误。
  2. 我对某些概念的理解存在细微偏差。

让我们再次聚焦于每个选项的细微之处。

  • 选项 A: “保留一个相同的端口” 是准确的，每个节点都会监听同一个 NodePort。
  • 选项 B: LoadBalancer 通常通过 NodePort 实现，是其上层抽象。
  • 选项 C: 这是 Service 架构的基础，ClusterIP 用于内部路由。
  • 选项 D: Headless Service 的核心特点就是没有 ClusterIP。

结论:

经过再次仔细分析，所有给出的描述都是正确的。题目要求找出错误的描述，但选项中并没有错误的描述。

如果必须选择一个“最可能被误解”或者在某些极端情况下可能不完全准确的选项，可能是 C。 虽然通常 NodePort 和 LoadBalancer 都会分配 ClusterIP，但在非常特殊或自定义的网络配置下，理论上或许存在一些边缘情况。但这并非 Kubernetes 的标准行为。

鉴于所有选项在标准 Kubernetes 行为下都是正确的，题目可能存在问题。

如果我必须强制选择一个，我会选择 C，理由是虽然这是标准行为，但理解上可能会有歧义，认为外部访问的 Service 可能不需要内部 IP。但这仍然是不正确的。

最终决定： 由于所有描述在标准 Kubernetes 行为下都是正确的，我认为题目本身可能存在错误。如果必须选择，我会选择 C 作为最有可能引起误解的选项，尽管它在技术上是正确的。

强烈建议核对题目来源和答案。

单选题371231、以下关于Kube-Scheduler进行Pod调度的流程的描述，错误的是哪一项?

Informer组件list-watch

又

节点优选(Priorities)，先于节点预选执行，通过如LeastRequested，SelectorSpreading等策略对Node节点进行评分排序

节点预选(Predicates)，通过如CheckNodeConditon，MatchNodeSelector,Taint&Toleration等策略过

滤不合适的Node节点

当Scheduler为Pod选择了一个合适的Node节点，通过Bind将Pod和节点进行绑定

好的，答案是 节点优选(Priorities)，先于节点预选执行，通过如LeastRequested，SelectorSpreading等策略对Node节点进行评分排序。

解释:

Kube-Scheduler 进行 Pod 调度的流程通常是这样的：

  1. Informer 组件 list-watch: Informer 组件负责监听 Kubernetes API Server 中与调度相关的资源对象（如 Pod、Node、PersistentVolume 等）的变化，并将这些信息缓存到本地，供 Scheduler 使用。这是调度流程的第一步，用于获取集群的实时状态。
  2. 节点预选 (Predicates): 预选阶段是根据一系列预选策略（Predicates）过滤掉不满足 Pod 调度要求的 Node 节点。例如：
    • CheckNodeCondition: 检查 Node 的健康状况。
    • MatchNodeSelector: 检查 Pod 的 nodeSelector 是否与 Node 的标签匹配。
    • Taint & Toleration: 检查 Node 的污点（Taints）是否被 Pod 的容忍度（Tolerations）所允许。 预选阶段会快速排除掉不合格的节点。
  3. 节点优选 (Priorities): 在通过预选阶段的合格节点中，优选阶段会根据一系列优选策略（Priorities）对这些节点进行评分。评分高的节点更倾向于被选择。常见的优选策略包括：
    • LeastRequested: 优先选择资源利用率较低的节点。
    • SelectorSpreading: 尽量将属于同一个 ReplicaSet 或 Deployment 的 Pod 分散到不同的 Node 上。
  4. Bind: 当 Scheduler 为 Pod 选择了一个评分最高的合适 Node 节点后，会通过 Bind 操作将该 Pod 和目标 Node 绑定。这个绑定信息会更新到 Kubernetes API Server 中，然后 kubelet 就会在被绑定的 Node 上创建并运行该 Pod。

因此，描述中“节点优选(Priorities)，先于节点预选执行”是错误的。正确的执行顺序是先进行节点预选 (Predicates) 过滤掉不合适的节点，然后在通过预选的节点中进行节点优选 (Priorities) 评分排序。

单选题 38/231、CCE基于Kubemetes社区容器存储接口CSl(Contaimer Storage nterface)实现了云存储服务接入能力，以下关于CCE容器存储插件的描述，哪一项是错误的?

CCE集群中的CSI客器存储插件名为Everest。

Everest插件的Everest-csi-controller组件，提供存储卷的创建、删除、扩容、云盘快照等功能

Everest插件的Everest-csi-driver组件，提供存储卷在node上的挂载、卸载、格式化等功能。

CCE集群中的容器存储插件与容器的内核版本无关

好的，答案是 CCE集群中的容器存储插件与容器的内核版本无关。

解释:

让我们逐个分析这些描述：

  • CCE集群中的CSI容器存储插件名为Everest。 这是正确的。华为云 CCE 集群使用的 CSI 插件通常被称为 Everest。
  • Everest插件的Everest-csi-controller组件，提供存储卷的创建、删除、扩容、云盘快照等功能。 这是正确的。CSI controller 组件通常负责集群范围内的存储管理操作。
  • Everest插件的Everest-csi-driver组件，提供存储卷在node上的挂载、卸载、格式化等功能。 这是正确的。CSI driver 组件运行在每个 Node 上，负责与底层存储系统交互，执行卷的挂载、卸载和格式化等节点本地操作。
  • CCE集群中的容器存储插件与容器的内核版本无关。 这是错误的。容器存储插件（特别是 CSI driver 组件）需要与 Node 节点的操作系统和内核进行交互，以实现存储卷的挂载、卸载等操作。不同的内核版本可能需要不同版本的驱动或者特定的内核模块支持。虽然 CSI 旨在提供一个标准的接口，以减少对特定存储和内核的依赖，但实际部署和运行 CSI driver 时，仍然需要考虑其与底层操作系统和内核的兼容性。

总结:

CCE 集群中的容器存储插件 Everest 的正常运行和功能实现，与 Node 节点的内核版本是相关的。因此，认为它们无关的描述是错误的。

39/231、某用户的CPU管理策略为Resources.limits.cpu:500m,Resources limits.memory:512Mi,单选题Resources.requests,cpu:100m,Resources.equests.memory:256Mi，以下那一个Pod可以正常工作?

allocatable.cpu:400m, allocatable.memory:512Mi

allocatable.cpu:400m,allocatable.memory:200Mi

allocatable.cpu:80m, allocatable.memory:600Mi

allocatable.cpu:90m,alocatablememory:256Mi

好的，答案是 allocatable.cpu:400m, allocatable.memory:512Mi。

解释:

为了使 Pod 能够正常工作，它所请求的资源（requests）必须小于或等于 Node 上的可分配资源（allocatable），并且它所设置的资源限制（limits）也必须小于或等于 Node 上的可分配资源。

让我们分析给定的 Pod 资源需求和限制：

  • Resources.limits.cpu: 500m (Pod 的 CPU 上限为 0.5 个 CPU 核)
  • Resources.limits.memory: 512Mi (Pod 的内存上限为 512 MiB)
  • Resources.requests.cpu: 100m (Pod 请求的 CPU 为 0.1 个 CPU 核)
  • Resources.requests.memory: 256Mi (Pod 请求的内存为 256 MiB)

现在，我们逐个检查选项中的 Node 可分配资源：

  • A. allocatable.cpu: 400m, allocatable.memory: 512Mi
    • CPU 请求 (100m) <= 可分配 CPU (400m) 满足
    • CPU 限制 (500m) > 可分配 CPU (400m) 不满足
  • B. allocatable.cpu: 400m, allocatable.memory: 200Mi
    • 内存请求 (256Mi) > 可分配内存 (200Mi) 不满足
  • C. allocatable.cpu: 80m, allocatable.memory: 600Mi
    • CPU 请求 (100m) > 可分配 CPU (80m) 不满足
  • D. allocatable.cpu: 90m, allocatable.memory: 256Mi
    • CPU 请求 (100m) > 可分配 CPU (90m) 不满足

重新分析： 我之前的理解有误，Pod 的资源请求必须小于等于 Node 的可分配资源，Pod 的资源限制也必须小于等于 Node 的可分配资源。让我们重新检查选项。

  • A. allocatable.cpu: 400m, allocatable.memory: 512Mi
    • CPU 请求 (100m) <= 可分配 CPU (400m) 满足
    • CPU 限制 (500m) > 可分配 CPU (400m) 不满足
  • B. allocatable.cpu: 400m, allocatable.memory: 200Mi
    • 内存请求 (256Mi) > 可分配内存 (200Mi) 不满足
  • C. allocatable.cpu: 80m, allocatable.memory: 600Mi
    • CPU 请求 (100m) > 可分配 CPU (80m) 不满足
  • D. allocatable.cpu: 90m, allocatable.memory: 256Mi
    • CPU 请求 (100m) > 可分配 CPU (90m) 不满足

再次重新思考： 我又犯了一个错误。Pod 能够 正常工作的前提是其资源 请求 可以被满足。资源 限制 是 Pod 可以使用的最大资源量，即使超过请求，只要不超过限制并且 Node 可分配资源足够，Pod 仍然可以被调度。

让我们再次以正确的理解来分析：Pod 能够被调度并正常工作，需要满足以下条件：

  1. Pod 的 CPU 请求 <= Node 的可分配 CPU
  2. Pod 的内存请求 <= Node 的可分配内存

我们不需要直接比较 Pod 的资源 限制 和 Node 的可分配资源，虽然在实际运行时 Pod 不能超过其限制，但调度器主要关注 请求 是否能够满足。

现在，让我们再次检查选项，只关注资源请求：

  • A. allocatable.cpu: 400m, allocatable.memory: 512Mi
    • CPU 请求 (100m) <= 可分配 CPU (400m) 满足
    • 内存请求 (256Mi) <= 可分配内存 (512Mi) 满足
    • 这个 Pod 可以正常工作。
  • B. allocatable.cpu: 400m, allocatable.memory: 200Mi
    • CPU 请求 (100m) <= 可分配 CPU (400m) 满足
    • 内存请求 (256Mi) > 可分配内存 (200Mi) 不满足
  • C. allocatable.cpu: 80m, allocatable.memory: 600Mi
    • CPU 请求 (100m) > 可分配 CPU (80m) 不满足
  • D. allocatable.cpu: 90m, allocatable.memory: 256Mi
    • CPU 请求 (100m) > 可分配 CPU (90m) 不满足

最终答案:

只有选项 A 满足 Pod 的 CPU 和内存请求都小于或等于 Node 的可分配资源。因此，这个 Pod 可以被成功调度并正常工作。

单选题

44/231、以下关于应用服务网格ASM灰度发布优势的描述，错误的是哪一项?

灰度版本一键部署，流量切换一键生效

配置式灰度策略，支持流量比例、请求内容(Cookie

仅支持金丝雀发布

一站式健康、性能、流量监控，实现灰度发布过程量化、智能化、可视化

好的，答案是 仅支持金丝雀发布。

解释:

应用服务网格（ASM）的灰度发布通常提供多种策略，而不仅仅是金丝雀发布。以下是 ASM 灰度发布的一些常见优势和策略：

  • 灰度版本一键部署，流量切换一键生效: 这是 ASM 提供的便利性之一，简化了灰度发布的部署和流量管理操作。

  • 配置式灰度策略，支持流量比例、请求内容 (Cookie 等): ASM 允许用户根据不同的策略配置流量路由，例如按流量百分比将一部分用户导向新版本，或者基于特定的请求内容（如 Cookie、Header 等）将特定用户导向新版本。这使得灰度发布更加灵活和可控。

  • 一站式健康、性能、流量监控，实现灰度发布过程量化、智能化、可视化: ASM 通常集成监控和追踪能力，可以实时监控新旧版本的健康状况、性能指标和流量情况，帮助用户做出更明智的决策，甚至实现自动化回滚或流量调整。

  • 仅支持金丝雀发布:

    这是

    错误

    的。金丝雀发布是灰度发布的一种常见策略，但 ASM 通常还支持其他策略，例如：

    • 蓝绿发布 (Blue/Green Deployment): 同时部署新旧两个版本，将所有流量从旧版本切换到新版本。
    • A/B 测试 (A/B Testing): 将不同用户导向不同版本以进行功能或体验的对比。
    • 流量比例切分 (Traffic Splitting): 逐步增加导向新版本的流量比例。

因此，认为 ASM 灰度发布仅支持金丝雀发布的描述是错误的。ASM 通常提供更丰富的灰度发布策略。

531231、以下Service类型中，可用于Pod间相互发现的是哪一项?单选题

Clusterip

NodePort

LoadBalancer

Headtess

好的，答案是 ClusterIP 和 Headless。

解释:

让我们分析一下每种 Service 类型在 Pod 间相互发现方面的作用：

  • ClusterIP:
    • 这是 Kubernetes Service 的默认类型。
    • 它在集群内部创建一个虚拟 IP 地址，并将发送到该 IP 地址和端口的流量负载均衡到与该 Service 关联的 Pod 上。
    • Pod 可以通过 ClusterIP 和 Service 名称来相互访问，而无需关心后端 Pod 的具体 IP 地址。Kubernetes 的 DNS 服务会将 Service 名称解析为 ClusterIP。因此，ClusterIP 是 Pod 间相互发现和通信的主要方式之一。
  • NodePort:
    • NodePort 类型在每个 Node 节点上保留一个静态端口（在 30000-32767 范围内），并将发送到该端口的流量转发到 Service 的 ClusterIP 和端口。
    • 虽然 NodePort 允许集群外部访问 Service，但 Pod 通常不会直接使用 NodePort 来相互发现和通信，因为这涉及到知道其他 Pod 所在的 Node IP 和 NodePort，不如直接使用 ClusterIP 方便和稳定。
  • LoadBalancer:
    • LoadBalancer 类型通常在云环境中使用，它会自动创建一个外部负载均衡器，并将流量转发到后端的 NodePort Service 上（通常也会分配一个 ClusterIP）。
    • 与 NodePort 类似，Pod 之间通常不直接通过 LoadBalancer 的外部 IP 或域名进行通信，而是使用内部的 ClusterIP。
  • Headless:
    • Headless Service 不会分配 ClusterIP。
    • 相反，Kubernetes DNS 会为 Headless Service 的每个后端 Pod 创建一个 DNS A 记录，记录该 Pod 的 IP 地址。
    • Pod 可以通过 Headless Service 的名称解析到后端 Pod 的具体 IP 地址，从而实现直接通信。这对于需要 Pod 之间保持稳定网络标识的 StatefulSet 等场景非常有用。因此，Headless Service 也是 Pod 间相互发现的一种方式。

总结:

ClusterIP 是最常用的用于 Pod 间服务发现和通信的 Service 类型，它提供了一个稳定的虚拟 IP 地址供 Pod 访问。Headless Service 则通过 DNS 直接暴露后端 Pod 的 IP 地址，也实现了 Pod 间的相互发现，适用于特定的场景。

因此，选项中 ClusterIP 和 Headless 都可用于 Pod 间相互发现。如果这是一个单选题，并且只能选择一个最主要的答案，那么 ClusterIP 由于其广泛的使用场景和作为默认类型的特性，通常被认为是 Pod 间相互发现的首选方式。

然而，根据题目给出的选项，如果只能选择一个，并且 Headless 也在选项中，那么两者都提供了 Pod 间相互发现的能力。如果题目有歧义或者期望一个更常用的答案，那么 ClusterIP 可能是更倾向的选择。

鉴于问题是单选题，并且列出了两者，我需要选择最直接和最常用的答案。ClusterIP 是 Kubernetes 中实现内部服务发现和负载均衡的核心机制，因此是 Pod 间相互发现的最常见和基础的方式。

单选题

62/231、以下关于OverridePolicyspec关健字段参数的描述，错误的是哪一项?

overriders: 差异化策略内容

B

targetCluster: 指定目标资源YAML中的差异化位置

resourceSelectors:选择关联的资源

targetCluster: 选择差异化策略生效的集群

好的，答案是 targetCluster: 指定目标资源YAML中的差异化位置。

解释:

OverridePolicySpec 是 Karmada（Kubernetes Resource Multi-Cluster Administration）中用于定义跨集群资源覆盖策略的关键对象。让我们分析一下每个字段的作用：

  • overriders: 这个字段定义了具体的差异化策略内容。它包含了一系列的覆盖规则，例如修改特定的字段值、添加或删除字段等。描述是正确的。
  • resourceSelectors: 这个字段用于选择需要应用此覆盖策略的资源。你可以通过指定资源的 Group、Version、Kind 和 Name 等信息来选择一组特定的资源。描述是正确的。
  • targetCluster: 选择差异化策略生效的集群: 这个字段用于指定该覆盖策略应该应用到哪些目标集群。你可以通过集群的名称或其他选择器来指定目标集群。描述是正确的。
  • targetCluster: 指定目标资源YAML中的差异化位置: 这个字段的描述是错误的。targetCluster 的作用是选择策略生效的目标集群，而不是指定目标资源 YAML 中的差异化位置。指定差异化位置通常是在 overriders 字段中通过路径（例如 JSONPath）来实现的。overriders 中的具体规则会指明需要在目标集群的资源 YAML 的哪个字段进行修改。

总结:

targetCluster 字段用于指定覆盖策略应用的目标集群，而差异化的具体位置和内容则在 overriders 字段中定义。因此，描述 targetCluster 用于指定目标资源 YAML 中的差异化位置是错误的。

单选题

63/231、以下关于lstio中熔断机制的描述，错误的是哪一项?

熔断能够动态地将异常实例从负载均衡池中移除

被移除的实例在一段时间之后，不会被加回来再次尝试访问

对于TCP服务，如果到目标服务的连接超时和失败，则都会被记为出错

当连续的错误数超过配置的闯值时，后端实例会被移除

好的，答案是 被移除的实例在一段时间之后，不会被加回来再次尝试访问。

解释:

Istio 的熔断机制旨在通过临时阻止对故障服务的访问，防止故障蔓延并提高系统的整体可用性。让我们逐个分析这些描述：

  • 熔断能够动态地将异常实例从负载均衡池中移除: 这是正确的。当 Istio 的 Sidecar 代理检测到后端实例出现连续的错误时，会将这些异常实例从其负载均衡池中暂时移除，从而避免将新的请求发送到这些不健康的实例。
  • 被移除的实例在一段时间之后，不会被加回来再次尝试访问: 这是错误的。Istio 的熔断机制通常包含一个恢复机制。被熔断（移除）的实例在经过一段配置的时间间隔后，Sidecar 代理会尝试重新向这些实例发送少量的探测请求，以检查它们是否已经恢复健康。如果探测成功，该实例会被重新加入到负载均衡池中。
  • 对于 TCP 服务，如果到目标服务的连接超时和失败，则都会被记为出错: 这是正确的。对于 TCP 连接，连接超时和连接失败通常都被认为是服务不健康的信号，会被熔断机制记录为错误计数。
  • 当连续的错误数超过配置的阈值时，后端实例会被移除: 这是正确的。Istio 允许用户配置触发熔断的错误阈值。当在一定时间内，对某个后端实例的连续错误请求数超过这个阈值时，该实例就会被熔断并从负载均衡池中移除。

总结:

Istio 的熔断机制是临时的，被移除的实例在经过一定的冷却时间后会尝试恢复。因此，认为被移除的实例不会被加回来再次尝试访问的描述是错误的。

image-20250529164547751

单选题 67/231、在设置了华为云CCE容器日志转储后，AOM会在某个日志文件超过一定大小时对其转储，在该日止文件所在的目录下生成一个新的zip文件。但对于一个日志文件，其生成的zip文件不会永久保留，当zip文件超过多少个时AOM会删除较早的zip文件?

10

6


20


30

---
20

71/231、以下关于不同类型的Service的描述，错误的是哪一项?
单选题
NodePort类型的Service会让Kubemetes集群每个节点上保留一个相同的端口LoadBalancer类型的Service是NodePort类型Service的扩展NodePort类型或者LoadBalancer类型的Service都会被分配一个ClusterlPHeadless Service创建后，后端相应Pod被重新创建导致Pod的IP地址发生变化，其对应的域名也会发生变化

好的，答案是 Headless Service 创建后，后端相应 Pod 被重新创建导致 Pod 的 IP 地址发生变化，其对应的域名也会发生变化。

解释:

让我们逐个分析这些描述：

  • NodePort 类型的 Service 会让 Kubernetes 集群每个节点上保留一个相同的端口: 这是正确的。NodePort Service 在集群的每个 Node 上开放一个相同的端口，用于从集群外部访问 Service。
  • LoadBalancer 类型的 Service 是 NodePort 类型 Service 的扩展: 这是正确的。LoadBalancer 通常在云环境中实现，它在 NodePort 的基础上提供外部负载均衡器。
  • NodePort 类型或者 LoadBalancer 类型的 Service 都会被分配一个 ClusterIP: 这是正确的。ClusterIP 是 Service 在集群内部的虚拟 IP，用于集群内部的服务发现和负载均衡。NodePort 和 LoadBalancer 类型也会拥有一个 ClusterIP。
  • Headless Service 创建后，后端相应 Pod 被重新创建导致 Pod 的 IP 地址发生变化，其对应的域名也会发生变化: 这是错误的。对于 Headless Service，Kubernetes DNS 会为每个后端 Pod 创建一个 DNS A 记录，这个记录的名称通常是 <pod-name>.<headless-service-name>.<namespace>.svc.<cluster-domain>。虽然 Pod 的 IP 地址在重新创建后会发生变化，但是 Pod 的名称通常保持不变（除非 ReplicaSet 等控制器进行了扩缩容或替换操作），因此，其对应的域名会解析到新的 IP 地址，但域名本身不会发生变化。 DNS 服务会自动更新与 Pod 名称关联的 IP 地址。

总结:

Headless Service 的关键特性是它不分配 ClusterIP，而是依赖 DNS 来直接解析到后端 Pod 的 IP 地址。当 Pod IP 地址变化时，DNS 记录会被更新，但 Pod 的域名（基于 Pod 名称和 Service 名称）通常保持不变。因此，认为其对应的域名也会发生变化的描述是错误的。

单选题75/231、CCE基于Kubernetes社区容器存储接口CS实现了云存储服务接入能力，以下关务CCE支持的存储类型的描述，哪个是错误的?

文件存储可用于HPC高性能计算、媒体处理、内容管理和Web服务、大数据和分析应用程序等 √

块存储可用于HPC高性能计算、企业核心集群应用、企业应用系统和开发测试等

自建存储可用于高性能网站、日志存储、Devops、企业办公等

对象存储可用于大数据分析、静态网站托管、在线视频点播、基因测序、智能视频监控、备份归档、企业云盘(网盘)等


文件存储可用于HPC高性能计算、媒体处理、内容管理和Web服务、大数据和分析应用程序等 √

好的，答案是 自建存储可用于高性能网站、日志存储、Devops、企业办公等。

解释:

让我们逐个分析关于 CCE 支持的存储类型的描述：

  • 文件存储可用于 HPC 高性能计算、媒体处理、内容管理和 Web 服务、大数据和分析应用程序等: 这是正确的。文件存储（例如网络文件系统 NFS）具有共享访问的特性，适用于这些需要多个实例读写相同数据的场景。

  • 块存储可用于 HPC 高性能计算、企业核心集群应用、企业应用系统和开发测试等: 这是正确的。块存储（例如云硬盘）提供高性能、低延迟的持久化存储，非常适合对 IO 性能要求高的应用和数据库等。

  • 对象存储可用于大数据分析、静态网站托管、在线视频点播、基因测序、智能视频监控、备份归档、企业云盘 (网盘) 等: 这是正确的。对象存储具有高可扩展性、低成本和海量存储的特性，适用于存储非结构化数据，并提供各种应用场景的支持。

  • 自建存储可用于高性能网站、日志存储、Devops、企业办公等: 这是错误的。自建存储通常指的是用户在 Kubernetes 集群外部自行搭建和管理的存储系统。虽然理论上可以通过各种方式将自建存储接入 Kubernetes，但将其直接列为 CCE 支持的存储类型 并描述其适用场景是不准确的。CCE 提供的存储接入能力主要是针对华为云上的云存储服务（如文件存储 CFS、块存储 EBS、对象存储 OBS）。

    将自建存储集成到 CCE 通常需要用户自行配置和管理 PersistentVolume 和 PersistentVolumeClaim，并可能需要安装和配置第三方存储驱动或使用 HostPath 等方式，但这并非 CCE 平台直接提供的、开箱即用的存储类型。描述中列出的 “高性能网站、日志存储、Devops、企业办公” 等场景可以使用云上的文件存储、块存储或对象存储来更好地满足需求。

总结:

CCE 主要提供对华为云存储服务的集成和支持。将“自建存储”列为 CCE 直接支持的存储类型，并且描述其适用场景是错误的。用户可以使用 CCE 提供的卷管理机制来挂载和使用自建存储，但这与 CCE 平台直接提供的存储类型有所不同。

单选题

801231、以下关于应用服务网格ASM灰度发布优势的描述，错误的是哪一项?

灰度版本一键部署，流量切换一键生效

B

配置式灰度策略，支持流量比例、请求内容(Cookie、Os、浏览器等)、源IP等

仅支持金丝雀发布

一站式健康、性能、流量监控，实现灰度发布过程量化、智能化、可视化

好的，答案仍然是 仅支持金丝雀发布。

解释:

与之前的第 44 题类似，应用服务网格（ASM）的灰度发布通常提供多种策略，而不仅仅是金丝雀发布。让我们再次分析这些描述：

  • 灰度版本一键部署，流量切换一键生效: 这是 ASM 提供的便利性，简化了灰度发布的操作。
  • 配置式灰度策略，支持流量比例、请求内容 (Cookie、Os、浏览器等)、源IP等: ASM 通常提供丰富的流量路由策略配置，可以基于多种请求属性进行流量导向，实现更精细化的灰度发布。
  • 仅支持金丝雀发布: 这是错误的。金丝雀发布是灰度发布的一种常见策略，但 ASM 通常还支持其他策略，例如蓝绿发布、A/B 测试、流量比例切分等。
  • 一站式健康、性能、流量监控，实现灰度发布过程量化、智能化、可视化: ASM 通常集成监控和追踪能力，帮助用户实时了解新旧版本的运行状态，从而更好地进行灰度发布决策。

总结:

认为 ASM 灰度发布仅支持金丝雀发布的描述是错误的。ASM 通常提供多种灵活的灰度发布策略。

单选题

81/231、以下关于istio数据平面的描述，正确的是哪一项?

用来提供服务发现，流量管理功能

负责管理和配置来控制数据平面和控制平面本身组件

用来验证用户编写的lstio API配置

以sidecar方式配置代理来管理数据通信

好的，答案是 以 sidecar 方式配置代理来管理数据通信。

解释:

让我们分析一下每个选项：

  • 用来提供服务发现，流量管理功能: 这是 控制平面 的主要职责，例如 Istiod 组件。控制平面负责生成数据平面所需的配置，包括服务发现信息和流量管理规则。
  • 负责管理和配置来控制数据平面和控制平面本身组件: 这也是 控制平面 的职责。控制平面负责管理 Sidecar 代理（数据平面组件）的生命周期和配置，并协调控制平面自身的各个组件。
  • 用来验证用户编写的 Istio API 配置: 这主要是 控制平面 中验证组件的功能，例如 Istiod 在接收用户配置时会进行语法和语义校验。
  • 以 sidecar 方式配置代理来管理数据通信: 这是 数据平面 的核心特征。在 Istio 中，数据平面由部署在每个应用 Pod 中的 Sidecar 代理（通常是 Envoy）组成。这些代理拦截 Pod 的所有入站和出站流量，并根据控制平面下发的配置执行流量管理、安全策略、遥测收集等任务。

总结:

Istio 的数据平面是由一系列轻量级的代理（Sidecar）组成，它们与应用程序容器部署在同一个 Pod 中，负责实际的数据通信的管理和控制。

单选题

83/231、关于华为云CCE告警监控项的描述，错误的是哪一项?

工作负载CPU使用率:服务实际使用的1分钟内平均值与申请的CPU核数量比率Pod文件系统使用率:实际使用量与文件系统容量的百分比

Pod容器错包个数:实例收到的错误包的数量

主机文件系统磁盘使用率:已使用的磁盘空间占总的磁盘空间容量百分比

好的，答案是 Pod容器错包个数:实例收到的错误包的数量。

解释:

让我们逐个分析这些告警监控项的描述：

  • 工作负载 CPU 使用率: 服务实际使用的 1 分钟内平均值与申请的 CPU 核数量比率: 这是合理的告警监控项，用于监控工作负载的 CPU 使用情况相对于其申请量的比例，帮助判断是否存在资源瓶颈或过度使用。
  • Pod 文件系统使用率: 实际使用量与文件系统容量的百分比: 这是常见的告警监控项，用于监控 Pod 内容器文件系统的磁盘使用情况，防止磁盘空间不足导致应用异常。
  • 主机文件系统磁盘使用率: 已使用的磁盘空间占总的磁盘空间容量百分比: 这是标准的节点级别告警监控项，用于监控 Kubernetes 节点主机的磁盘使用情况，确保节点有足够的磁盘空间运行容器和系统服务。
  • Pod 容器错包个数: 实例收到的错误包的数量: 这是错误的描述。通常，错包率（错误包的数量与总包数量的比率）比绝对的错误包数量更有意义，因为绝对数量会受到流量大小的影响。此外，容器本身通常不直接暴露底层的网络错误包数量，这个指标更常在网络接口级别（例如，宿主机或网络设备）进行监控。针对 Pod 或容器的网络监控，更常见的是关注延迟、丢包率、连接错误等更高级别的指标。直接监控单个容器收到的错误包数量通常不是一个标准的或容易获取的容器监控指标。

总结:

监控 Pod 容器收到的绝对错误包数量不是一个常见或直接的容器监控指标。更常用的和有意义的指标是错误包率或更高级别的网络性能指标。因此，关于 “Pod 容器错包个数” 的描述是错误的。

单选题

86/231、在编辑Jb对象的YAML文件时，应调整以下哪一项字段来规定执行当前任务的并发Pod的数量?

completions

parallelism

restartPolicy

backoffLimit

好的，答案是 parallelism。

解释:

在 Kubernetes Job 对象的 YAML 文件中：

  • parallelism: 这个字段用于指定在任何给定时间 Job 应该并行运行的期望的 Pod 数量。如果未设置或设置为 0，则 Pod 将按顺序运行。
  • completions: 这个字段用于指定 Job 需要成功完成的 Pod 的数量。一旦成功完成的 Pod 数量达到这个值，Job 将被视为完成。
  • restartPolicy: 这个字段指定 Pod 中的容器因为错误退出时应该如何处理。对于 Job，通常设置为 Never 或 OnFailure。
  • backoffLimit: 这个字段指定在 Job 被标记为失败之前，Pod 应该重试启动的次数。

因此，要规定执行当前任务的并发 Pod 的数量，您需要调整 parallelism 字段。

多选题 90/231、在K8S中，按照服务质量Qos，通常可划分为三类besteffort,burstable，和guaranteed。以下关于这三类的描述，哪些是正确的?
容器不设置requests和limits值Qos为besteffort
容器设置requests和limits但是值不一致QoS为burstable
容器设置requests和limits且值相同QoS为guaranteed
按照服务质量QoS从高到底的排序为:

好的，关于 Kubernetes (K8S) 服务质量 (QoS) 类别 besteffort、burstable 和 guaranteed 的描述，以下是正确的：

  • 容器不设置 requests 和 limits 值，QoS 为 besteffort。这是正确的。当容器没有显式地设置 requests 和 limits 时，它会被分配到 besteffort QoS 类别。这些 Pod 的调度优先级最低，并且在节点资源紧张时最容易被驱逐。
  • 容器设置 requests 和 limits 但是值不一致，QoS 为 burstable。这是正确的。当容器同时设置了 requests 和 limits，但它们的值不相等时（CPU 或内存或两者），该容器会被分配到 burstable QoS 类别。这些 Pod 保证可以获得其 requests 的资源，但在资源充足时可以突发使用超过 requests 但不超过 limits 的资源。它们在节点资源紧张时比 guaranteed 低优先级，但比 besteffort 高。
  • 容器设置 requests 和 limits 且值相同，QoS 为 guaranteed。这是正确的。当容器同时设置了 requests 和 limits，并且对于 CPU 和内存这两个资源，它们的值都相等时，该容器会被分配到 guaranteed QoS 类别。这些 Pod 具有最高的调度优先级，并且只要不超过其 limits，就不会因为节点资源紧张而被驱逐。
  • 按照服务质量 QoS 从高到底的排序为: guaranteed > burstable > besteffort。这也是正确的。guaranteed 提供了最强的资源保障，其次是 burstable，besteffort 的保障最弱。

因此，所有列出的描述都是正确的。

多选题 91/231、某业务的生产环境需要保障业务的高可用，业务正常时期节点数一般为180,业务高峰期业务量增加明显，需要不低于500节点，此时建议使用以下哪些集群部署方式?

使用CCE Turbo集群，集群规格1000节点，计算节点分布不同AZ

使用CCE 集群，控制节点数为1，集群规格1000节点，计算节点分布不同AZV

使用CCE集群，控制节点数为3，集群规格1000节点，计算节点分布不同AZ

使用CCE Turbo集群，集群规格200节点，计算节点分布不同AZ

好的，为了保障业务的高可用并在业务高峰期支持不低于 500 个节点的需求，同时在正常时期维持 180 个节点左右，以下集群部署方式是建议使用的：

  • 使用 CCE Turbo 集群，集群规格 1000 节点，计算节点分布不同 AZ。
    • 理由： CCE Turbo 集群具备更快的弹性伸缩能力，能够迅速应对业务高峰期的节点需求。1000 节点的规格可以满足峰值 500 节点的要求，并且将计算节点分布在不同的可用区 (AZ) 可以提高集群的容灾能力，即使一个可用区发生故障，其他可用区的节点仍然可以提供服务，保障高可用。
  • 使用 CCE 集群，控制节点数为 3，集群规格 1000 节点，计算节点分布不同 AZ。
    • 理由： 拥有 3 个控制节点的 CCE 集群具备高可用性控制平面，即使部分控制节点发生故障，集群的管理和调度功能仍然可以正常运行。1000 节点的规格可以满足峰值需求，并且将计算节点分布在不同的可用区可以提高业务的容灾能力。虽然 CCE 集群的弹性伸缩速度可能不如 CCE Turbo，但在合理配置和预判的情况下，仍然可以满足业务高峰期的需求。

不建议使用的选项：

  • 使用 CCE 集群，控制节点数为 1，集群规格 1000 节点，计算节点分布不同 AZ。
    • 理由： 单控制节点的 CCE 集群存在单点故障风险。一旦控制节点发生故障，整个集群的管理和调度将受到影响，无法保障高可用。
  • 使用 CCE Turbo 集群，集群规格 200 节点，计算节点分布不同 AZ。
    • 理由： 200 节点的集群规格在业务正常时期可能够用，但在业务高峰期需要不低于 500 个节点的情况下，这个规格无法满足需求。即使 CCE Turbo 的弹性伸缩能力很强，也需要集群本身具备足够的容量上限。

总结：

为了保障高可用并满足弹性伸缩的需求，建议选择 使用 CCE Turbo 集群，集群规格 1000 节点，计算节点分布不同 AZ 和 使用 CCE 集群，控制节点数为 3，集群规格 1000 节点，计算节点分布不同 AZ 这两种部署方式。CCE Turbo 在弹性伸缩方面更具优势，而具有 3 个控制节点的 CCE 集群在控制平面层面提供了高可用性。您可以根据对弹性伸缩速度和控制平面高可用性的具体需求进行选择或组合使用。