使用k-mib进行Kubernetes监控：入门介绍 – wiki基地

作者： /

使用 kube-state-metrics 进行 Kubernetes 监控：入门介绍

在现代云原生架构中，Kubernetes 已成为容器编排的事实标准。随着业务系统的复杂性不断增加，有效监控 Kubernetes 集群的健康状况和运行状态变得至关重要。监控不仅能帮助我们及时发现并解决问题，还能优化资源分配，提升系统稳定性。

本文将深入探讨如何使用一个在 Kubernetes 监控领域中扮演核心角色的工具——kube-state-metrics（有时可能被用户简称为“k-mib”或类似的术语，尽管其官方名称是 kube-state-metrics）。我们将从基础概念出发，逐步了解 kube-state-metrics 是什么，为什么它如此重要，如何部署，以及如何利用它提供的数据构建强大的监控和告警系统。

1. Kubernetes 监控的挑战与 kube-state-metrics 的定位

监控一个 Kubernetes 集群与监控传统主机或虚拟机有很大不同。Kubernetes 是一个高度动态的环境，包含各种抽象层：节点（Nodes）、Pod、Deployment、Service、Volume、Namespace、ReplicaSet 等等。这些对象的数量和状态都在不断变化。传统的基于主机资源（CPU、内存、网络、磁盘）的监控虽然仍然必要，但远不足以反映集群整体的健康状况和应用服务的运行情况。

Kubernetes 监控通常需要关注以下几个方面：

  • 资源监控 (Resource Monitoring): 监控节点、Pod、容器的 CPU、内存、网络、磁盘等资源使用情况。这通常通过 metrics-server (或 Prometheus Node Exporter, cAdvisor 等) 来完成。
  • 日志监控 (Log Monitoring): 收集、存储和分析应用程序以及集群组件（如 kubelet, apiserver）生成的日志。这通常使用 EFK (Elasticsearch, Fluentd, Kibana) 或 PLG (Promtail, Loki, Grafana) 等堆栈。
  • 事件监控 (Event Monitoring): 监控 Kubernetes 事件，这些事件记录了集群中发生的关键操作和状态变化（如 Pod 调度、镜像拉取失败、容器启动/停止）。
  • 状态监控 (State Monitoring): 监控 Kubernetes 对象本身的状态。例如，有多少个 Pod 处于 Pending 状态？有多少个 Deployment 的期望副本数与当前可用副本数不符？哪些 Node 处于 NotReady 状态？哪些 PersistentVolumeClaim (PVC) 处于 Pending 状态？

kube-state-metrics 正是专注于第四点：状态监控。它不监控资源的使用率（如 CPU 使用百分比），而是监控 Kubernetes API 中暴露的各种对象的状态、数量和配置信息。可以将其理解为一个“状态信息转换器”，它通过与 Kubernetes API Server 交互，获取各种对象的状态数据，并将这些数据转换成标准的 Prometheus 指标格式暴露出来。

因此，如果用户提到“k-mib”并用于 Kubernetes 监控，很大程度上可能是在指代或需要了解 kube-state-metrics 这个工具，因为它提供了关于 Kubernetes 对象 MIB (Management Information Base，管理信息库，借用网络管理的术语，此处引申为“管理状态信息集合”) 的指标。

2. kube-state-metrics 是什么？

kube-state-metrics 是一个简单服务，运行在 Kubernetes 集群内部，通过监听 Kubernetes API Server 生成关于 Kubernetes 对象状态的指标。这些指标以 Prometheus 可以抓取和处理的格式暴露出来。

它提供的信息是关于 Kubernetes 控制平面 管理的各种资源的元数据和当前状态的快照，而不是这些资源的实际资源消耗。例如：

  • Pod 的生命周期阶段 (Pending, Running, Succeeded, Failed, Unknown)
  • Deployment 的期望副本数、当前副本数、就绪副本数、可用副本数
  • Node 的状态 (Ready, MemoryPressure, DiskPressure, NetworkUnavailable)
  • PersistentVolumeClaim (PVC) 的状态 (Pending, Bound, Lost)
  • Job 的完成次数和失败次数
  • DaemonSet 的期望 Pod 数、当前调度 Pod 数、就绪 Pod 数
  • ResourceQuota 的使用情况和限制
  • …以及更多 Kubernetes 对象的关键状态信息。

kube-state-metrics 本身不存储历史数据，也不提供图表展示或告警功能。它的核心职责是 生成并暴露指标。这些指标需要由一个时序数据库（如 Prometheus）来抓取、存储和查询，然后通常结合可视化工具（如 Grafana）进行展示，并配合告警系统（如 Prometheus Alertmanager）来触发通知。

3. 为什么 kube-state-metrics 如此重要？

kube-state-metrics 提供了其他监控工具难以提供的独特视角，它是构建全面 Kubernetes 监控体系不可或缺的一部分：

  • 集群概览 (Cluster Overview): 通过统计各种对象（如 Pod、Deployment、Service）的数量和状态，可以快速了解整个集群的健康度和繁忙程度。例如，通过查看不同 Namespace 下的 Pod 数量，可以了解各业务线的资源消耗情况。
  • 问题早期预警 (Early Problem Detection): 许多 Kubernetes 问题首先体现在对象状态的变化上。例如，大量的 Pending Pod 可能意味着资源不足或调度器问题；Deployment 的可用副本数长时间低于期望值可能意味着应用部署失败或持续崩溃。这些信息 kube-state-metrics 都能提供， enabling proactive identification of issues.
  • 容量规划和资源优化 (Capacity Planning & Optimization): 监控 ResourceQuota 和 LimitRange 的使用情况可以帮助理解资源是如何被消耗和限制的，从而进行更合理的容量规划和资源分配。
  • 自动化决策支持 (Automation Support): kube-state-metrics 提供的状态指标是许多自动化流程的基础，例如 Horizontal Pod Autoscaler (HPA) 或 Vertical Pod Autoscaler (VPA) 可以结合 Pod 状态指标（虽然 HPA 通常基于资源指标，但某些高级场景可能考虑状态），或者自定义控制器可能根据 Deployment 状态来触发运维操作。
  • 提升可观测性 (Enhancing Observability): 结合资源监控、日志监控和事件监控，kube-state-metrics 提供的状态指标完善了 Kubernetes 集群的可观测性，使我们能够更全面地理解系统的运行状况。

没有 kube-state-metrics，你将很难获得集群层面的宏观状态信息，仅凭资源使用率数据很难判断应用是否健康运行，或者集群控制平面是否正常工作。

4. kube-state-metrics 在监控体系中的位置

一个典型的 Kubernetes 监控堆栈通常包括：

  1. 数据收集层:
    • kube-state-metrics: 收集 Kubernetes 对象状态指标。
    • node-exporter (运行在每个节点): 收集物理/虚拟机节点的资源指标。
    • cAdvisor (集成在 kubelet 中): 收集 Pod 和容器的资源指标 (常通过 metrics-server 或直接被 Prometheus 抓取)。
    • Fluentd/Logstash/Promtail: 收集日志。
    • Kubernetes Events: 集群事件流。
  2. 数据存储层:
    • Prometheus: 存储时序指标数据 (来自 kube-state-metrics, node-exporter, cAdvisor)。
    • Elasticsearch/Loki: 存储日志数据。
  3. 数据展示层:
    • Grafana: 可视化 Prometheus 数据，构建仪表盘。
    • Kibana/Grafana: 可视化日志数据。
  4. 告警层:
    • Prometheus Alertmanager: 处理 Prometheus 生成的告警规则，发送通知 (邮件、Slack、Webhook 等)。

在上述体系中，kube-state-metrics 作为关键的指标数据源，与 Prometheus 紧密集成。Prometheus 定期从 kube-state-metrics 暴露的 /metrics 端点拉取 (scrape) 指标数据并存储。然后，Grafana 查询 Prometheus 中的 kube-state-metrics 数据来绘制图表，Alertmanager 根据基于这些指标定义的规则来触发告警。

5. 部署 kube-state-metrics

部署 kube-state-metrics 最常见和推荐的方式是使用 Helm 包管理器。许多 Prometheus 相关的 Helm Chart (如 kube-prometheus-stack) 都会将 kube-state-metrics 作为其依赖项之一自动安装和配置。但你也可以单独安装它。

这里以单独使用 Helm 部署为例：

首先，确保你已经安装了 Helm 并配置了 Kubernetes 集群的访问权限。

  1. 添加 Prometheus 社区 Helm 仓库 (如果尚未添加):
    bash
    helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
    helm repo update

  2. 查找 kube-state-metrics Chart:
    bash
    helm search repo kube-state-metrics

  3. 安装 kube-state-metrics:
    选择一个 Namespace (例如 monitoring，如果不存在则创建 kubectl create namespace monitoring) 进行安装。
    bash
    helm install kube-state-metrics prometheus-community/kube-state-metrics -n monitoring --create-namespace
    这条命令会在 monitoring Namespace 下安装最新版本的 kube-state-metrics，默认创建一个 Deployment 和一个 Service。

  4. 验证部署:
    检查 Pod 是否正在运行：
    bash
    kubectl get pods -n monitoring -l app.kubernetes.io/name=kube-state-metrics
    你应该看到一个或多个 kube-state-metrics 的 Pod 处于 Running 状态。

    检查 Service 是否创建：
    bash
    kubectl get service -n monitoring -l app.kubernetes.io/name=kube-state-metrics
    你会看到一个 ClusterIP Service，它暴露了 kube-state-metrics 的指标端口 (默认为 8080)。

    可选：临时访问指标端点进行验证:
    你可以使用 kubectl port-forward 命令将 kube-state-metrics Service 的端口转发到本地，以便直接通过浏览器或 curl 查看原始指标。
    bash
    kubectl port-forward service/kube-state-metrics -n monitoring 8080:8080
    然后在一个新的终端窗口或浏览器中访问 http://localhost:8080/metrics。你将会看到大量以 kube_ 开头的指标信息。

默认安装通常已经包含了监控大多数标准 Kubernetes 对象的配置。你可以通过自定义 values.yaml 文件来调整安装参数，例如更改端口、副本数、资源限制、需要监听的资源类型等。

6. 探索 kube-state-metrics 提供的关键指标

kube-state-metrics 暴露的指标数量非常庞大，因为它涵盖了许多不同类型的 Kubernetes 对象。理解一些核心指标对于开始监控非常重要。以下是一些常见的指标系列及其含义：

  • kube_node_info: 提供关于节点的基本信息（如节点名称、内核版本、操作系统、Kubernetes 版本等）作为标签。通常其值为 1。
    • 示例用途：按节点属性进行过滤或分组。
  • kube_node_status_condition: 节点状态的布尔值指标（如 Ready, MemoryPressure, DiskPressure, NetworkUnavailable）。标签包括节点名称 (node) 和条件类型 (condition)。值为 1 表示条件为 True，0 表示 False。
    • 示例用途：监控节点是否健康或存在压力。
    • PromQL 示例：kube_node_status_condition{condition="Ready", status="true"} (查询所有 Ready 状态的节点数量)
  • kube_pod_info: 提供 Pod 的元信息（如 Pod 名称、Namespace、Node 名称、创建者信息等）作为标签。值为 1。
    • 示例用途：按 Pod 属性进行过滤或分组。
  • kube_pod_status_phase: Pod 生命周期阶段的布尔值指标（Pending, Running, Succeeded, Failed, Unknown）。标签包括 Pod 名称 (pod)、Namespace (namespace) 和阶段 (phase)。值为 1 表示 Pod 当前处于该阶段，0 表示否。
    • 示例用途：统计处于不同阶段的 Pod 数量，找出 Pending 或 Failed 的 Pod。
    • PromQL 示例：kube_pod_status_phase{phase="Pending"} (查询所有 Pending 状态的 Pod 数量)
    • PromQL 示例：sum(kube_pod_status_phase{namespace="your-namespace", phase="Running"}) (统计某个 Namespace 下 Running 状态的 Pod 数量)
  • kube_pod_container_info: Pod 中容器的元信息（如容器名称、镜像名称、Port 名称/端口等）作为标签。值为 1。
    • 示例用途：按容器或镜像进行过滤。
  • kube_pod_container_status_waiting_reason: 容器处于 Waiting 状态的原因。标签包括 Pod/容器名称、Namespace 和原因 (reason，如 ImagePullBackOff, ErrImagePull, ContainerCreating)。值为 1。
    • 示例用途：找出容器启动失败的原因。
    • PromQL 示例：kube_pod_container_status_waiting_reason{reason="ImagePullBackOff"} (找出所有由于拉取镜像失败而 Waiting 的容器)
  • kube_deployment_info: Deployment 的元信息（如名称、Namespace、Strategy 等）作为标签。值为 1。
  • kube_deployment_spec_replicas: Deployment 规范中定义的期望副本数。
  • kube_deployment_status_replicas: Deployment 当前观察到的副本总数。
  • kube_deployment_status_replicas_available: Deployment 中可用（Ready）的副本数。
  • kube_deployment_status_replicas_unavailable: Deployment 中不可用（Unavailable）的副本数。
    • 示例用途：监控 Deployment 的扩缩容状态和可用性。
    • PromQL 示例：kube_deployment_spec_replicas - kube_deployment_status_replicas_available (计算某个 Deployment 期望但尚未可用的副本数)
  • kube_daemonset_status_number_scheduled: DaemonSet 期望调度到的节点数。
  • kube_daemonset_status_number_ready: DaemonSet 已经 Ready 的 Pod 数。
    • 示例用途：监控 DaemonSet 是否在所有预期节点上正常运行。
  • kube_service_info: Service 的元信息。
  • kube_ingress_info: Ingress 的元信息。
  • kube_resourcequota: ResourceQuota 的当前使用量和限制值。标签包括 ResourceQuota 名称、Namespace 和资源类型 (resource)。
    • PromQL 示例：kube_resourcequota{resource="cpu", type="used"} (查询各 ResourceQuota 的 CPU 使用量)
    • PromQL 示例：kube_resourcequota{resource="cpu", type="hard"} (查询各 ResourceQuota 的 CPU 限制)
  • kube_limitrange: LimitRange 的默认值、最大值、最小值等。

这只是 kube-state-metrics 提供的一小部分指标。完整的指标列表可以在其官方文档中找到，并且随着 Kubernetes 版本的更新和 kube-state-metrics 自身的迭代，指标可能会有所增减。关键在于理解指标名称的命名规范 (kube_<object>_<status/spec/info>) 和标签的含义，以便有效地查询和使用这些数据。

7. 与 Prometheus 集成

将 kube-state-metrics 集成到 Prometheus 是其核心用途。Prometheus 需要配置一个抓取目标 (scrape target) 来定期访问 kube-state-metrics 的 Service 端点 /metrics。

如果你使用的是 kube-prometheus-stack 或其他预配置的 Prometheus Helm Chart，通常它们已经包含了对 kube-state-metrics 的抓取配置。这些配置通常利用 Kubernetes Service Discovery (服务发现) 功能，通过 Service 和 Endpoints 自动发现 kube-state-metrics Pod 的地址。

一个典型的 Prometheus scrape_config 片段，用于通过 Kubernetes Service Discovery 抓取 kube-state-metrics，可能看起来像这样 (这通常是自动化生成的，你不需要手动编写，但了解其原理很有用):

“`yaml

Example scrape config for kube-state-metrics using Kubernetes Service Discovery

  • job_name: ‘kubernetes-service-endpoints’
    kubernetes_sd_configs:
  • role: endpoints
    # Relabeling rules to target the kube-state-metrics service
    relabel_configs:
    # Target the endpoint associated with the kube-state-metrics service
  • source_labels: [__meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
    regex: kube-state-metrics;http-metrics # Match service name and port name (check your service definition)
    action: keep
    # Drop default kubernetes_sd_configs labels you don’t need
  • source_labels: [__meta_kubernetes_endpoint_address]
    regex: (.*)
    target_label: instance
    replacement: $1;8080 # Replace instance label with IP and port
  • action: labelmap
    regex: __meta_kubernetes_service_label_(.+) # Map service labels as metric labels
  • source_labels: [__meta_kubernetes_namespace]
    target_label: namespace
  • source_labels: [meta_kubernetes_service_name]
    target_label: service_name
    # Keep only desired metrics (optional, but recommended for large clusters)
    # metric_relabel_configs:
    # – source_labels: [__name    ]
    # regex: kube_(pod|deployment|node|…).*
    # action: keep
    “`

在这个配置中：
* role: endpoints: Prometheus 监听 Kubernetes API，发现所有 Service 的 Endpoints。
* relabel_configs: 一系列规则，用于过滤发现的 Endpoints，只保留属于 kube-state-metrics Service 的 Endpoints，并将一些 Kubernetes 元数据 (__meta_kubernetes_*) 转换为 Prometheus 指标的标签。
* regex: kube-state-metrics;http-metrics: 匹配 kube-state-metrics Service 和其暴露指标的端口名称。你需要根据实际部署检查 Service 的名称和端口名称。默认 Helm Chart 安装的 Service 名称通常是 kube-state-metrics，指标端口名称可能是 http-metrics 或 metrics。

Prometheus 抓取到这些指标后，你就可以在 Prometheus UI 的 Graph 页面使用 PromQL 进行查询了。

8. 利用 Grafana 进行可视化

虽然 Prometheus UI 可以查询和查看指标，但 Grafana 提供了更强大的可视化能力，可以创建漂亮的仪表盘来展示 kube-state-metrics 的数据。

  1. 安装 Grafana: 同样可以通过 Helm 安装 Grafana，通常与 Prometheus 安装在同一个 Namespace 下。
  2. 配置 Prometheus 数据源: 在 Grafana 中添加 Prometheus 作为数据源，填写 Prometheus Service 的地址。
  3. 导入或创建仪表盘: Grafana 社区提供了许多针对 kube-state-metrics 的预制仪表盘。你可以在 Grafana 官方网站的 Dashboard 库中搜索 “kube-state-metrics” 找到它们，然后将其 JSON 配置导入到你的 Grafana 实例中。这些仪表盘通常已经配置好了各种面板，用于展示 Pod 状态、Deployment 健康度、Node 状态等关键信息。
    • 常见的 kube-state-metrics 相关仪表盘 ID 包括 (可能会有更新，请查阅 Grafana 官网): 1621, 13339 等。
    • 你也可以根据前面介绍的关键指标和 PromQL 示例，自己创建自定义的 Grafana 面板。例如，创建一个饼状图展示 Pod 按阶段 (phase) 的分布，或者一个时间序列图展示 Pending Pod 的数量随时间的变化。

通过 Grafana 仪表盘，你可以直观地监控集群的整体健康状况和关键应用的运行状态，无需频繁地执行 kubectl get 命令。

9. 设置告警规则

基于 kube-state-metrics 的指标设置告警是及时发现问题的关键。Prometheus Alertmanager 用于处理和发送这些告警通知。你需要在 Prometheus 中定义 Alerting Rules。

Alerting Rules 通常存储在一个单独的 YAML 文件中，并在 Prometheus 配置中引用。每条规则包含一个名称、触发条件 (PromQL 表达式) 和一些元数据 (如 severity, annotations, labels)。

以下是一些基于 kube-state-metrics 的常见告警规则示例：

  • Pending Pod 数量过多:
    如果某个 Namespace 下有超过 N 个 Pod 长时间处于 Pending 状态，可能意味着资源不足或调度器问题。
    “`yaml

    • alert: KubeNamespacePendingPods
      expr: sum(kube_pod_status_phase{phase=”Pending”}) by (namespace) > 5 # Adjust threshold as needed
      for: 5m # Trigger after 5 minutes
      labels:
      severity: warning
      annotations:
      summary: “Namespace {{ $labels.namespace }} has too many pending pods”
      description: “Namespace {{ $labels.namespace }} has {{ $value }} pending pods for more than 5 minutes.”
      “`
  • Deployment 不可用副本数过多:
    如果 Deployment 的可用副本数远低于期望副本数，表示应用可能运行不正常或更新失败。
    “`yaml

    • alert: KubeDeploymentUnavailableReplicas
      expr: kube_deployment_spec_replicas > 0 and (kube_deployment_spec_replicas – kube_deployment_status_replicas_available) > 0 and (kube_deployment_spec_replicas – kube_deployment_status_replicas_available) / kube_deployment_spec_replicas > 0.1 # More than 10% unavailable
      for: 10m # Adjust duration
      labels:
      severity: critical
      annotations:
      summary: “Deployment {{ $labels.namespace }}/{{ $labels.deployment }} has unavailable replicas”
      description: “Deployment {{ $labels.namespace }}/{{ $labels.deployment }} has {{ $value }} unavailable replicas ({{ kube_deployment_spec_replicas{namespace=$labels.namespace, deployment=$labels.deployment} | humanize }} desired).”
      “`
  • Node 处于 NotReady 状态:
    一个节点变得不可用是严重的问题。
    “`yaml

    • alert: KubeNodeNotReady
      expr: kube_node_status_condition{condition=”Ready”, status=”false”} == 1
      for: 5m # Trigger after 5 minutes
      labels:
      severity: critical
      annotations:
      summary: “Node {{ $labels.node }} is NotReady”
      description: “Node {{ $labels.node }} has been in NotReady state for more than 5 minutes.”
      “`
  • PersistentVolumeClaim (PVC) 处于 Pending 状态:
    如果 PVC 长时间无法绑定到 PV，可能意味着存储系统问题或存储类配置错误。
    “`yaml

    • alert: KubePVCPending
      expr: kube_persistentvolumeclaim_info{phase=”Pending”} == 1
      for: 10m # Adjust duration
      labels:
      severity: warning
      annotations:
      summary: “PVC {{ $labels.namespace }}/{{ $labels.persistentvolumeclaim }} is pending”
      description: “PVC {{ $labels.namespace }}/{{ $labels.persistentvolumeclaim }} has been in Pending state for more than 10 minutes.”
      “`

这些告警规则需要加载到 Prometheus 中，然后由 Alertmanager 配置接收并发送通知到预设的渠道 (如 Slack, PagerDuty, Email)。

10. 进阶考虑和最佳实践

  • 资源消耗: kube-state-metrics 会监听整个集群的 Kubernetes 对象状态。在非常大的集群中，对象数量可能非常庞大，导致 kube-state-metrics 本身消耗较多 CPU 和内存，并且生成的指标数量巨大，增加 Prometheus 的存储和处理负担。可以通过配置限制 kube-state-metrics 监听的资源类型，或者在 Prometheus 中使用 metric_relabel_configs 丢弃不需要的指标来优化。
  • 高可用: 可以在 kube-state-metrics 的 Deployment 中增加副本数来提升其可用性。Prometheus Service Discovery 会自动发现所有 Pod 实例并抓取它们。
  • 安全性: 限制对 kube-state-metrics Service 的访问，通常只允许 Prometheus Pod 访问其指标端口。确保 Prometheus 使用 RBAC 拥有足够的权限来读取 Kubernetes API 中的资源信息，但仅限于 GET 权限，不需要修改或删除权限。
  • 指标基数 (Cardinality): 带有大量不同标签组合的指标会增加 Prometheus 的负担。kube-state-metrics 的指标通常带有 Pod 名称、Deployment 名称、Namespace 等标签，这些标签的数量与你的集群中对象的数量成正比。尽量避免在告警或查询中不加选择地使用高基数标签，除非确实需要精确定位到某个具体对象。
  • 结合其他监控: kube-state-metrics 提供的状态指标与资源使用指标、日志、事件等是互补的。一个完整的监控视图需要将这些数据结合起来。例如，当 Deployment 的不可用副本数增加时 (通过 kube-state-metrics 告警)，你可能需要查看相关 Pod 的资源使用情况 (通过 metrics-server 或 node-exporter) 或容器日志 (通过 EFK/PLG) 来定位根本原因。

11. 总结

kube-state-metrics (或者用户口中的“k-mib”等指代) 是 Kubernetes 监控体系中一个基础且关键的组件。它专注于收集 Kubernetes 对象的状态信息，并将其转换为标准的 Prometheus 指标格式。这些状态指标提供了对集群宏观健康状况和各种资源运行状态的独特洞察，是发现问题、规划容量、自动化运维以及构建完整可观测性平台的重要数据源。

通过将 kube-state-metrics 与 Prometheus 和 Grafana 集成，你可以构建强大的 Kubernetes 监控仪表盘，实时掌握集群的脉搏；通过设置基于 kube-state-metrics 指标的告警规则，你可以及时收到关于集群潜在问题的通知。

尽管它不提供资源使用率数据，但其提供的状态信息弥补了其他监控工具的不足，使得 Kubernetes 监控变得更加全面和有效。对于任何运行 Kubernetes 集群的组织来说，理解和利用 kube-state-metrics 都是构建健壮、可维护系统的必经之路。

开始探索 kube-state-metrics 提供的指标吧，它们将为你揭示 Kubernetes 集群内部运行的真实状态！

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部