Kubernetes 上的 Elasticsearch 运维面试题

8 道题

分类: Kubernetes
子分类: middleware-ops
题目数: 8 道

已阅读 0 / 8 题

1 ECK 的 Operator、自定义资源定义（CRD）和 Elasticsearch 自身分别负责什么？

答案：

Elastic Cloud on Kubernetes（ECK）是 Elastic 提供的 Kubernetes Operator。它通过自定义资源定义（CRD）接收期望状态，再持续协调 Elasticsearch、Kibana、Elastic Agent、 Logstash 等工作负载对应的原生资源、证书、服务和凭据。

Elasticsearch、Kibana、Agent 等自定义资源是业务声明的真源。
Operator 负责把声明落成受管的 StatefulSet、Service、Secret、PersistentVolumeClaim 等资源，并处理证书轮换、拓扑变化和受控滚动操作。
CRD 是集群级资源；具体的 Elasticsearch 和 Kibana 对象通常是命名空间级资源。安装 Operator 时要按实际管理范围授予权限，不要默认给全局权限。
Operator 不能替你决定索引映射、分片数量、备份保留期、网络边界或业务恢复目标。这些仍是使用方的设计责任。

kubectl get elasticsearch -A
kubectl get kibana -A
kubectl describe elasticsearch logs-prod -n observability
kubectl get events -n observability --sort-by=.lastTimestamp

不要直接修改 Operator 生成的 StatefulSet、Pod 或 Secret 来“修复”配置。下一轮协调会把这些漂移覆盖掉，且会让故障根因更难判断。应修改自定义资源或其引用的受管配置。删除 CRD 会删除全部对应自定义资源，属于高风险操作，不能作为卸载或排障的常规手段。

2 如何用节点集（NodeSet）设计 ECK 中的 Elasticsearch 节点拓扑？

答案：

ECK 用 nodeSets 表示一组 Elasticsearch 节点。一个 NodeSet 内的节点共享相同的 Elasticsearch 配置、Pod 模板和卷声明；不同角色、硬件规格或故障域应拆成不同 NodeSet。

下面的示例把主节点候选和承担热数据、内容数据的节点分开。版本号仅用于说明当前 API 形状，上线前必须依据 ECK 与 Elastic Stack 的支持矩阵核验。

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: logs-prod
  namespace: observability
spec:
  version: 9.5.4
  nodeSets:
    - name: masters
      count: 3
      config:
        node.roles: ["master"]
      volumeClaimTemplates:
        - metadata:
            name: elasticsearch-data
          spec:
            accessModes: ["ReadWriteOnce"]
            storageClassName: fast-ssd
            resources:
              requests:
                storage: 30Gi
    - name: hot-content
      count: 3
      config:
        node.roles: ["data_hot", "data_content", "ingest"]
      podTemplate:
        spec:
          containers:
            - name: elasticsearch
              resources:
                requests:
                  cpu: "2"
                  memory: 8Gi
                limits:
                  memory: 8Gi
      volumeClaimTemplates:
        - metadata:
            name: elasticsearch-data
          spec:
            accessModes: ["ReadWriteOnce"]
            storageClassName: fast-ssd
            resources:
              requests:
                storage: 500Gi

几个容易混淆的点：

所有节点仍会承担协调职责。只有在请求汇总确实成为瓶颈时，才额外设置无显式角色的专用协调节点。
主节点候选也需要持久化数据路径，因为它保存集群元数据；不要把它当成完全无状态组件。
ECK 会维护发现和投票相关配置。不要在 NodeSet 中手工固化 discovery.seed_hosts、cluster.initial_master_nodes 或旧的 Zen 参数。
单节点、无副本索引或某个数据层只有一个节点时，任何滚动操作都可能造成相应分片短暂不可用。

3 持久卷声明（PVC）、存储类（StorageClass）、故障域调度与分片感知应怎样一起规划？

答案：

Elasticsearch 的数据安全依赖持久卷、分片副本和集群外快照三层，而不是其中任意一层。 Kubernetes 调度分散 Pod 与 Elasticsearch 跨故障域分配副本是两件事，需要同时设计。

生产环境为每个 NodeSet 明确声明 volumeClaimTemplates；默认的小容量卷只适合快速体验。卷名使用 elasticsearch-data 时，ECK 会按默认数据路径正确挂载。
选择 StorageClass 时评估 IOPS、吞吐、可用区绑定、扩容能力、快照能力和节点故障后的恢复方式。使用本地盘时，更要验证节点故障和滚动更新后 PVC 能否重新调度。
使用 Pod 反亲和性或拓扑分布约束，让同一 NodeSet 的 Pod 尽量跨宿主机和可用区；约束过严而集群容量不足时，更新中的 Pod 会停在 Pending。
如果希望主副本跨可用区，Elasticsearch 的分配感知属性必须与调度使用的故障域一致。只做反亲和性并不会让 Elasticsearch 自动理解可用区。

podTemplate:
  spec:
    affinity:
      podAntiAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              topologyKey: kubernetes.io/hostname
              labelSelector:
                matchLabels:
                  elasticsearch.k8s.elastic.co/cluster-name: logs-prod

扩容已有 PVC 前，先确认 StorageClass 允许卷扩展、底层存储有足够容量，并在预发环境验证 ECK 状态和 Elasticsearch 的磁盘水位反应。不要删除 PVC 以“重新挂盘”；这会把调度问题升级为数据恢复事件。

4 ECK 默认如何处理传输层加密（TLS）和访问凭据？对外暴露时要注意什么？

答案：

ECK 默认会为 Elasticsearch 的 HTTP 和传输层启用 TLS，并创建 elastic 用户的密码 Secret、HTTP CA 证书 Secret 和集群内 Service。应用应校验证书链后访问 Service，而不是在生产环境使用 curl -k 跳过验证。

kubectl get service logs-prod-es-http -n observability
kubectl get secret logs-prod-es-elastic-user -n observability
kubectl get secret logs-prod-es-http-certs-public -n observability

集群内客户端通常经 <名称>-es-http Service 访问。默认服务会指向集群节点；如果要让查询流量只进入协调或摄取节点，应按 ECK 的流量拆分方式创建目标明确的 Service。
需要外部访问时，使用 LoadBalancer、Ingress 或网关，并为外部域名配置可验证的证书。端口转发只适合本地诊断。
网络策略（NetworkPolicy）要同时允许必要的 HTTP、节点传输、DNS、对象存储和监控路径。仅放行 9200 可能让节点间通信或快照任务失败。
不要把 ECK 管理的 Secret 原样复制到其他命名空间；先确认 owner reference、证书主题和密码轮换关系，再使用受控的外部密钥管理或专门的引用方案。

Kubernetes 的 ServiceAccount 与 Elasticsearch 的用户角色是两层独立授权。前者控制 Pod 访问 Kubernetes API，后者控制数据与管理 API；两层都要遵循最小权限。

5 Kibana、Elastic Agent、Fleet Server 与 Elasticsearch 应如何关联部署？

答案：

Kibana 通过 elasticsearchRef 关联 Elasticsearch；ECK 会处理连接所需的受管凭据和证书。采集侧优先评估 Elastic Agent 与 Fleet：Fleet Server 负责管理 Agent 策略，节点级日志和 Kubernetes 元数据采集通常用 DaemonSet，集中式接入任务可用 Deployment。

apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
  name: kibana-prod
  namespace: observability
spec:
  version: 9.5.4
  count: 1
  elasticsearchRef:
    name: logs-prod
apiVersion: agent.k8s.elastic.co/v1alpha1
kind: Agent
metadata:
  name: elastic-agent
  namespace: observability
spec:
  version: 9.5.4
  kibanaRef:
    name: kibana-prod
  fleetServerRef:
    name: fleet-server
  mode: fleet
  policyID: eck-agent
  daemonSet:
    podTemplate:
      spec:
        serviceAccountName: elastic-agent
        automountServiceAccountToken: true

Fleet Server 自身需要引用 Kibana 和目标 Elasticsearch；处于 Fleet 模式的普通 Agent 由 Fleet Server 下发输出配置，通常不单独配置 elasticsearchRefs。
Kubernetes 集成需要读取 API 时才授予对应 ServiceAccount 的 RBAC，且应限制到实际需要的资源与范围。
采集策略要明确命名空间范围、容器日志路径、索引或数据流、字段映射和保留周期。先做少量节点灰度，避免错误规则瞬间放大日志量。
Beats 仍可用于存量场景，但新方案应先判断 Elastic Agent 是否已覆盖需求；不要无理由同时部署两套采集器。

版本、集成包与策略变更都会影响采集链路。发布后应检查 Agent 健康、Fleet 策略状态、数据流写入速率和映射变化，而不是只看 DaemonSet 是否有 Pod 在运行。

6 在 ECK 上配置快照仓库和快照生命周期管理（SLM）的正确方式是什么？

答案：

ECK 不会默认创建快照仓库或快照生命周期管理（SLM）策略。正确路径是：把对象存储凭据放在 Kubernetes Secret，通过 secureSettings 注入 Elasticsearch keystore，再用 Elasticsearch API 注册仓库和创建 SLM 策略。

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: logs-prod
  namespace: observability
spec:
  secureSettings:
    - secretName: snapshot-credentials

PUT /_snapshot/primary-repository
{
  "type": "s3",
  "settings": {
    "bucket": "<受控备份桶>",
    "base_path": "logs-prod"
  }
}

POST /_snapshot/primary-repository/_verify

从 Elasticsearch 8.0 起，S3、GCS 和 Azure 仓库支持随发行版提供；其他仓库类型或旧版本要按实际插件与版本要求处理。凭据更新、证书信任和对象存储网络策略也应一起验证。

不要把 PersistentVolume 的快照、复制或目录备份当成 Elasticsearch 快照的替代品。恢复演练至少应验证仓库可读、目标集群安全、索引和功能状态选择、恢复耗时，以及应用流量的回切步骤。

7 ECK 管理的扩缩容、滚动重启和升级应怎样控制风险？

答案：

NodeSet 的 count、资源、节点角色、配置和 version 都由 ECK 协调。Operator 会在条件允许时迁移数据、复用持久卷，并按 Elasticsearch 的安全约束滚动操作；它不能让单节点、单副本缺失或容量不足的拓扑凭空实现零中断。

上线前的检查顺序建议如下：

核对 ECK、Elastic Stack、Kubernetes 与存储驱动的支持组合，阅读目标版本破坏性变更。
确认集群为 Green，索引副本和数据层容量能承受一次节点离线，快照最近一次成功。
缩容数据 NodeSet 前检查分片迁移和余量；缩容主节点候选前确认投票可用性。
一次只提交一种高影响变更，观察 Elasticsearch 资源状态、Pod 事件、分片恢复和业务指标。
完成后复核版本、节点角色、分片分布、写入与查询延迟，并清理临时操作标记。

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: logs-prod
  namespace: observability
  annotations:
    eck.k8s.elastic.co/restart-trigger: "2026-09-21T10:00:00Z"
spec:
  version: 9.5.4

该注解可请求一次受控滚动重启，不能代替变更前检查。不要为了让 Operator 强行继续而自动化禁用升级安全谓词；文档明确将其视为高风险手段，只有在已完成事故决策和数据风险评估后才可能使用。

8 Kubernetes 上 Elasticsearch 的生产就绪检查与排障路径是什么？

答案：

排障要把“编排层问题”和“Elasticsearch 问题”分开。Pod 未就绪不等于分片坏了；集群 Yellow 也不必然由 Kubernetes 调度导致。

kubectl get elasticsearch logs-prod -n observability
kubectl describe elasticsearch logs-prod -n observability
kubectl get pods,pvc -n observability
kubectl get events -n observability --sort-by=.lastTimestamp
kubectl logs deploy/elastic-operator -n elastic-system --tail=200

然后进入 Elasticsearch 侧确认：

GET /_cluster/health?level=shards
GET /_cat/shards?v=true
GET /_cluster/allocation/explain
GET /_cat/allocation?v=true

常见路径如下。

Pod Pending：检查请求资源、亲和性或拓扑约束、节点污点、PVC 绑定和本地卷可调度性。
OOMKilled 或频繁重启：检查容器内存限制、JVM 自动堆大小、堆外内存与文件系统缓存，不要只把堆调大。
PVC 挂载、扩容或磁盘告警：检查 StorageClass、卷状态、云盘配额与 Elasticsearch 磁盘水位。
HTTP 连不上：检查 Service、证书、网络策略、入口配置和客户端 CA 信任；不要用跳过 TLS 校验掩盖证书问题。
分片未分配：在 allocation/explain 中读取决定器原因，再处理节点、容量、分配规则或副本；不要先删除 Pod 或 PVC。

生产就绪至少包括：多副本或明确定义的单副本风险、跨故障域调度、持久卷与容量余量、TLS 和最小权限、外部快照与恢复演练、指标告警、升级回滚预案，以及一次真实的节点故障或演练验证。

参考：Elastic 官方 ECK 文档中的部署、节点编排、访问服务、加密设置、快照仓库与 Fleet 配置章节。