★ FEATURED ARTICLE 1. 摘掉 9200 的证书之前先把 ECK 那三层 TLS 分清楚Kubernetes 上用 ECKElastic Cloud on Kubernetes部署 Elasticsearch 7.17跑内网测试环境客户端一堆Java 服务、Logstash、Filebeat、还有几个同事本地 curl。每次接一个新客户端第一件事就是问「CA 证书在哪」「为什么连上去报 PKIX path building failed」。折腾两轮之后大家的共识就变成一句话能不能把 TLS 关了就用账号密码连这个诉求本身没毛病但动手之前得先知道你要关的是哪一层。ECK 从 1.0 开始就把 TLS 当默认配置塞进去了而且不是一层是三层混在一起改很容易把集群搞成 CrashLoopBackOff 还找不到原因。1.1 HTTP 层、transport 层、operator 管理面各管各的第一层是HTTP 层也就是 9200 端口你 curl、Kibana、Logstash 连的都是它。这一层的证书由 ECK 自动生成一对自签证书放在集群名-es-http-certs-public这类 Secret 里同时挂进 Pod 的/usr/share/elasticsearch/config/http-certs/。客户端要跳过校验要么关校验要么把 CA 塞进 truststore。这层是可以干净关掉的CRD 里有对应字段后面详细说。第二层是transport 层9300 端口节点之间互相通信、选主、分片复制都走它。这层的证书由 operator 生成在集群名-es-transport-certs里。注意这一层跟你的客户端完全没有关系——外部客户端永远不会连 9300。很多人以为「关 TLS」要把 9300 也关掉其实纯属多此一举而且 ECK 的 CRD 里根本没给你留关闭 transport TLS 的开关。第三层是operator 自己的管理面包括它跟 API Server 之间的 validating webhook 证书。这层跟 Elasticsearch 集群的 TLS 是两码事你改 CR 里的http.tls字段不会影响到它。所以真正要动的是第一层。我在实际项目里踩过一次坑某个同学看到报错说证书问题直接在nodeSets[].config里手写了xpack.security.transport.ssl.enabled: false想着「一次性全关了省事」。结果 operator 重建 StatefulSet 的时候把它自己生成的 transport 配置又合并回去最终 Pod 里的elasticsearch.yml出现了两组互相矛盾的配置ES 起不来日志里刷的是节点间握手失败。这个坑后面第 5 节还会展开。1.2 关掉 9200 的 TLS 之后谁受益谁遭殃先把账算清楚。受益的一方很明确所有走 REST 接口的外部客户端包括 Java 的 RestHighLevelClient、Python 的 elasticsearch-py、Logstash 的 elasticsearch output、Filebeat 的 output.elasticsearch、curl、Kibana。它们不用再加载 CA不用配ssl.certificate_authorities连接串从https://改成http://就完事。遭殃的一方也要说清楚。明文传输意味着同 VLAN 内任何人抓包就能拿到你的 Basic Auth 头也就是拿到了账号密码。这不是危言耸听内网横向移动的第一步就是抓明文凭据。所以这个方案只适合两种场景一是纯测试/开发集群里面没有真实业务数据二是集群前面有明确的网络隔离比如只有特定的几个 Pod 能访问到 9200且这个网段本身是可信的。我个人的判断标准很粗暴只要集群里有真实用户数据或者生产流量就不会关 HTTP TLS。测试环境怎么折腾都行生产环境关 TLS 省下的那点配置成本远不够后面出事之后的补救成本。1.3 一个容易被忽略的连带影响Kibana 的地址协议ECK 管 Kibana 的时候是通过 association 机制自动注入elasticsearch.hosts的你不允许在 Kibana 的spec.config里手写这个字段——写了会被 operator 的校验拦住。那么它注入的是http://还是https://这取决于 operator 读到的 ES CR 状态。在 ECK 2.x 里operator 会判断 ES 的 HTTP TLS 是否启用然后选择对应的 scheme。也就是说你把 ES 的http.tls.selfSignedCertificate.disabled设成true之后Kibana 的 association 会自动跟着变成 http。这一点实测是好的但前提是你的 operator 版本足够新、且 ES 集群状态已经 Reconciliation 完成。如果改完 CR 立刻看 Kibana 的日志可能会看到短暂的连接失败等 operator 走完一轮就好。2. operator 版本先钉死能认 7.17 的只有 ECK 2.x 这条线这一节的内容是我觉得整篇文章里最值钱的版本选错后面全是白工。2.1 兼容矩阵ECK 3.x 不认 7.17ECK 的版本策略跟 Elasticsearch 大版本是绑定的。2.x 这条线覆盖了 Elasticsearch 7.17 一直到 8.x 的相当一部分版本而 3.0 之后官方把 7.x 的支持移除了只面向 8.16 以上和 9.x。这意味着什么如果你图省事直接kubectl apply了官网首页给的「最新版」operator.yaml很可能装上去的是 3.x。这时候你提交一个version: 7.17.25的 Elasticsearch CRoperator 会拒绝或者在 status 里挂一个 unsupported version 的 conditionPod 根本不会被创建。所以第一步不是写 CR是把 operator 的版本号写进你的部署脚本里当成一个常量管理。我一般会这么干# 锁死 operator 版本别用 latest ECK_VERSION2.16.0 OPERATOR_NSelastic-system kubectl create namespace ${OPERATOR_NS} --dry-runclient -o yaml | kubectl apply -f - # 先装 CRD再装 operator顺序不能反 kubectl apply -f https://download.elastic.co/downloads/eck/${ECK_VERSION}/crds.yaml kubectl apply -f https://download.elastic.co/downloads/eck/${ECK_VERSION}/operator.yaml装完确认一下kubectl -n elastic-system get pods kubectl -n elastic-system logs -f statefulset.apps/elastic-operator --tail50正常情况下你会看到一个elastic-operator-0处于 Running日志里没有持续刷 error。如果 Pod 一直起不来八成是 RBAC 或者 webhook 证书的问题看日志里的failed to create webhook之类的关键字。2.2 CRD 和 operator 的顺序以及 webhook 那点事上面脚本里我特意把crds.yaml和operator.yaml分成两条命令这是有原因的。ECK 的 CRD 文件比较大而且注册了 conversion webhook 和 validating webhook。如果你先 apply operator 再 apply CRDoperator 启动时找不到 CRD会进入一个半死不活的状态虽然最后可能自己恢复但中间那几分钟的日志噪音很烦人。另一个跟 webhook 相关的坑删了 operator 但没删 CRD 和 webhook 配置。下次重装的时候API Server 会去调一个已经不存在的 webhook service导致所有 Elasticsearch CR 的创建/更新请求超时失败报错类似failed calling webhook elastic-es-validation-v1.k8s.elastic.co。遇到这个检查一下kubectl get validatingwebhookconfigurations | grep elastic kubectl get mutatingwebhookconfigurations | grep elastic该删的删掉再重装。2.3 7.17 的小版本号怎么选spec.version这一栏填的是完整的 Elasticsearch 版本号比如7.17.25。这里有个细节ECK 会拿这个版本号去拉镜像docker.elastic.co/elasticsearch/elasticsearch:7.17.25如果你的集群拉不到外网镜像需要提前做镜像同步并且在 CR 里通过spec.image覆盖成你私有仓库的地址。spec: version: 7.17.25 image: your-registry.local/elasticsearch:7.17.25注意version字段还是得填operator 靠它做兼容性判断和配置生成image只是覆盖实际拉取的地址。这两个字段的含义不一样别只填一个。至于具体选哪个 7.17 补丁号原则是选当前 7.17 分支上最新的补丁版本因为 7.17 是长期维护分支补丁版本主要是修 bug 和安全问题。写这篇文章的时候我用的示例是 7.17.25你实际部署前建议看一眼官方 release notes 确认一下最新的补丁号别直接用我这里的数字。还有一个隐性约束operator 升级要谨慎。你锁了 2.16.0跑了半年某天想升到 2.17这个动作本身通常没问题但如果新版本对 ES 7.17 的支持发生变化比如某个字段被废弃可能会触发预期外的滚动重启。我的建议是只要集群稳定operator 别乱动把它当成基础设施的一部分冻结起来。3. 一份能直接 apply 的非 TLS 清单逐字段讲清楚为什么这么写到这一步环境准备好了operator 跑起来了可以写 CR 了。我把完整清单列出来然后一个字段一个字段解释。3.1 命名空间、StorageClass 与前置检查先把命名空间建好然后确认 StorageClass 可用。这一步听起来废话但我见过太多次 Pod 卡在 Pending最后发现是 PVC 绑不上——集群里压根没有默认 StorageClass或者默认的那个是WaitForFirstConsumer模式而节点亲和性又配错了。kubectl create namespace es-demo # 确认有没有默认 StorageClass kubectl get storageclass # 输出里 DEFAULT 列有 * 的那个就是默认的如果没有默认的你在volumeClaimTemplates里必须显式写storageClassName: xxx不然 PVC 永远 PendingES Pod 也永远 Pending而kubectl get elasticsearch的 HEALTH 列会一直显示空。3.2 Elasticsearch CR 的完整写法apiVersion: elasticsearch.k8s.elastic.co/v1 kind: Elasticsearch metadata: name: es-plain namespace: es-demo spec: version: 7.17.25 # 关键关闭 HTTP 层自签证书 http: tls: selfSignedCertificate: disabled: true nodeSets: - name: default count: 3 config: # 显式声明方便排查时一眼看到 xpack.security.enabled: true # 3 节点小集群全角色够用 node.roles: [master, data, ingest] # 如果没法改宿主机 sysctl用这个开关兜底 node.store.allow_mmap: false podTemplate: spec: initContainers: - name: sysctl securityContext: privileged: true runAsUser: 0 command: - sh - -c - | sysctl -w vm.max_map_count262144 containers: - name: elasticsearch resources: requests: cpu: 2 memory: 4Gi limits: memory: 4Gi env: - name: ES_JAVA_OPTS value: -Xms2g -Xmx2g volumeClaimTemplates: - metadata: name: elasticsearch-data spec: accessModes: - ReadWriteOnce resources: requests: storage: 50Gi storageClassName: standard3.3 selfSignedCertificate.disabled 到底做了什么这是整份清单里最关键的一行spec: http: tls: selfSignedCertificate: disabled: true它的语义是不要为 HTTP 层自动生成自签证书。operator 在 reconcile 的时候会检查 HTTP TLS 的状态判断逻辑大致是「有没有用户提供的证书 Secret没有的话自签是不是被显式禁用了」如果两个答案都是「没有」和「是」operator 就会在生成的elasticsearch.yml里写入xpack.security.http.ssl.enabled: false同时把 readiness probe 的 scheme 从 HTTPS 改成 HTTPService 也不再挂证书文件。这里有个非常容易踩的坑不要同时在nodeSets[].config里手写xpack.security.http.ssl.enabled。operator 生成的配置和用户配置合并的时候同名 key 会产生冲突表现是 Pod 起不来或者配置被覆盖成非预期值。我在第 5 节会教你一招直接 exec 进 Pod 看最终的elasticsearch.yml这是判断「配置到底生效没有」的唯一可靠手段。另外如果你之前给这个集群配过spec.http.tls.certificate用户自备证书要一并删掉。因为certificate和selfSignedCertificate.disabled是互斥的只要certificate.secretName有值operator 就认为你要用 TLSdisabled: true会被忽略。判断依据还是那句看 Pod 里的配置文件别猜。3.4 transport 层怎么办认了别硬刚前面说过ECK 的 CRD 里没有 transport TLS 的关闭开关。我试过往nodeSets[].config里塞xpack.security.transport.ssl.enabled: falseoperator 在组装配置的时候会把它自己生成的那份合进来最终结果要么是你的值被覆盖要么是两份配置并存导致节点间握手失败Pod 直接 CrashLoop。所以我的做法是transport 层保持 ECK 默认的 TLS一点都不动。反正 9300 只在集群内部通信客户端感知不到安全上也没有额外负担。你真正要摘掉的是 9200 的证书这就够了。如果你确实因为某些极端原因比如要做流量镜像调试必须让 9300 也明文那就得绕开 operator 的配置管理比如自己维护 StatefulSet 而不用 ECK或者用 initContainer 在启动前改配置文件。这两种做法都超出了「正常使用 ECK」的范围维护成本很高我不建议。3.5 vm.max_map_count 的三种解法选哪个ES 对vm.max_map_count的要求是 262144低于这个值启动时会直接报错退出日志里是max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]。这个错误很显眼但新手第一次看到容易懵。三种解法我列个表对比方案做法优点缺点宿主机预配置在每台 node 上写/etc/sysctl.d/99-es.conf一次配置永久生效性能最好需要 node 权限托管 K8s 可能改不了initContainer特权容器启动前 sysctl -w随 Pod 走不依赖宿主机需要 privileged部分集群的安全策略会拦关闭 mmapconfig 里设node.store.allow_mmap: false零权限要求最省事性能下降官方不推荐生产用我的选择是能改宿主机就改宿主机改不了就用 initContainer两个都不行才用node.store.allow_mmap: false。上面那份清单里我把 initContainer 和 allow_mmap 都写上了实际用的时候二选一——如果你用了 initContainer 且它生效了allow_mmap: false就可以删掉让 ES 用 mmap 获得更好的性能。3.6 资源与 JVM 堆的配比关系ES_JAVA_OPTS里的-Xms2g -Xmx2g和容器的memory: 4Gi之间的关系是堆内存占容器内存的 50%剩下 50% 留给 Lucene 的堆外内存文件系统缓存、段合并的临时缓冲等。这个 50% 不是随便定的是 Elastic 官方推荐的配比。两个红线一是堆大小不要超过物理内存的 50%超了会 OOMKilled而且是被内核杀的日志里看不到 Java 的 OOM 堆栈只有Exit Code: 137很容易误判成应用 bug二是堆不要超过 31g超过这个值 JVM 会关闭指针压缩实际可用内存反而变少属于负优化。小集群 3 节点每节点 2g 堆总共 6g 堆内存跑测试环境和中小规模数据完全够。如果数据量上来了优先加节点数而不是无脑加堆。3.7 apply 之后五分钟内该看什么kubectl apply -f es-plain.yaml # 持续观察 kubectl -n es-demo get elasticsearch es-plain -w关注HEALTH和PHASE两列。正常演进是空 →ProcessorsPending→ApplyingChanges→ReadyHEALTH 最后变成green单节点或数据少时或者yellow有副本未分配多节点初始状态常见。yellow不算故障等分片分配完会变绿。同时看 Podkubectl -n es-demo get pods -l elasticsearch.k8s.elastic.co/cluster-namees-plain kubectl -n es-demo logs es-plain-es-default-0 -f日志里看到Security is enabled和HttpSslEnabled或者http ssl disabled相关的行基本就稳了。4. 账号密码这条链路secret 在哪、用户怎么加、客户端怎么连TLS 关掉了认证还得留着。ES 的账号密码体系在 ECK 下有一套自动化的东西搞清楚 Secret 的分布后面加用户、改密码都有章法。4.1 operator 自动生成的那些 Secret集群 Ready 之后kubectl -n es-demo get secret会看到一堆名字带前缀的 Secret我按用途归类Secret 名称内容用途es-plain-es-elastic-userkey 为elastic的超级用户密码你的日常管理入口es-plain-es-internal-userskibana_system、beats_system等内部账号operator 给 Kibana/Beats 自动注入用es-plain-es-transport-certstransport 层证书节点间通信别动es-plain-es-http-certs-publicHTTP 层证书关掉 TLS 后这个通常不再生成取 elastic 密码kubectl -n es-demo get secret es-plain-es-elastic-user \ -o jsonpath{.data.elastic} | base64 -d echo这里有个细节不要-o yaml去看输出的是 base64。用jsonpath加base64 -d一步到位 echo是为了补一个换行不然密码会粘在你的 shell 提示符前面。密码是 operator 随机生成的长字符串。测试环境图省事可以直接改kubectl -n es-demo patch secret es-plain-es-elastic-user \ --type merge \ -p {data:{elastic:$(echo -n MyPssw0rd123 | base64)}}改完等几十秒operator 会把新密码同步到 ES 的用户体系里。这个机制是 ECK 的一个便利点Secret 是密码的唯一真相来源改了 Secret 就等于改了 ES 密码不需要你去调_security/user/_password接口。注意生产环境不要手工改这个 Secret让 operator 自己生成随机密码然后通过你的密钥管理系统去取。手改的弱密码是安全审计的高频问题。4.2 建业务账号走 API 还是走 file realmECK 2.x 提供了spec.auth.fileRealm这个字段可以在 CR 里声明用户和角色operator 会生成对应的 file realm 配置和 Secret。写法大概是这样spec: auth: fileRealm: - secretName: es-app-users对应的 Secret 里放user:hashed_password格式的内容。这个方案的优点是声明式跟 GitOps 流程契合缺点是需要你先生成 bcrypt hash而且每次加用户都得改 CR 触发 reconcile。我个人的做法是测试环境用 API 直接建生产环境如果上了 GitOps 再考虑 file realm。API 建用户很直接而且能顺便建角色ES_PASS$(kubectl -n es-demo get secret es-plain-es-elastic-user -o jsonpath{.data.elastic} | base64 -d) kubectl -n es-demo port-forward svc/es-plain-es-http 9200:9200 # 建角色 curl -s -u elastic:${ES_PASS} -X POST http://localhost:9200/_security/role/app_writer \ -H Content-Type: application/json \ -d { cluster: [monitor], indices: [ { names: [logs-*], privileges: [create_index, index, write, read, view_index_metadata] } ] } # 建用户并绑定角色 curl -s -u elastic:${ES_PASS} -X POST http://localhost:9200/_security/user/app_writer \ -H Content-Type: application/json \ -d { password: AppWr1ter2024, roles: [app_writer], full_name: log writer service }注意权限收窄的原则给业务方单独的账号和角色不要图省事全用 elastic。一旦出问题你能从访问日志里定位到具体是哪个服务在干什么。角色里的indices.names用通配符logs-*而不是*防止某个服务误操作把系统索引删了。验证一下curl -s -u app_writer:AppWr1ter2024 http://localhost:9200/_cat/indices?v curl -s -u app_writer:AppWr1ter2024 -X PUT http://localhost:9200/logs-test-000001/_doc/1 \ -H Content-Type: application/json -d {msg:hello}第二条能成功写入说明角色配置正确。4.3 三种客户端的连接串写法curl / Postman最简单http://es-plain-es-http.es-demo.svc.cluster.local:9200加-u user:pass。如果是集群外访问先kubectl port-forward或者把 Service 改成 NodePort/LoadBalancer。Java 客户端7.17 用 RestHighLevelClientfinal CredentialsProvider credentialsProvider new BasicCredentialsProvider(); credentialsProvider.setCredentials( AuthScope.ANY, new UsernamePasswordCredentials(app_writer, AppWr1ter2024) ); RestClientBuilder builder RestClient.builder( new HttpHost(es-plain-es-http.es-demo.svc.cluster.local, 9200, http)) .setHttpClientConfigCallback( httpClientBuilder - httpClientBuilder.setDefaultCredentialsProvider(credentialsProvider)); RestHighLevelClient client new RestHighLevelClient(builder);关键在两处HttpHost的第三个参数是http不是https凭据走CredentialsProvider而不是手动拼 header这样连接池的每个请求都会带上认证信息。我见过有人在拦截器里手动加Authorization结果连接池复用时偶尔丢头排查了很久。Logstash 输出插件output { elasticsearch { hosts [http://es-plain-es-http.es-demo.svc.cluster.local:9200] user app_writer password ${ES_PASSWORD} index logs-%{YYYY.MM.dd} } }密码用环境变量注入别硬编码在配置文件里。Logstash 7.17 的输出插件对 http 地址支持得很好不需要额外配置。Filebeat的filebeat.ymloutput.elasticsearch: hosts: [http://es-plain-es-http.es-demo.svc.cluster.local:9200] username: app_writer password: ${ES_PASSWORD}Beats 在 7.x 里对 http 协议是兼容的。但注意如果你用的是 8.x 的 Beats 连 7.17 的 ES版本兼容性要单独确认跨大版本通常不推荐。5. 起来之后才开始疼探针、Kibana 与滚动重启集群绿了不代表活干完了后面几个问题会在你「觉得已经搞定」的时候冒出来。5.1 Kibana 到底会不会自动跟着变成 http理论上会实际上要验证。部署 Kibana 的 CRapiVersion: kibana.k8s.elastic.co/v1 kind: Kibana metadata: name: kb-plain namespace: es-demo spec: version: 7.17.25 count: 1 elasticsearchRef: name: es-plain http: tls: selfSignedCertificate: disabled: true podTemplate: spec: containers: - name: kibana resources: requests: cpu: 500m memory: 1Gi limits: memory: 1GiKibana 自己也要关 HTTP TLS不然浏览器访问 5601 还是得吃自签证书警告一边关一边不关很别扭。部署之后验证它连 ES 用的是不是 httpPOD$(kubectl -n es-demo get pod -l kibana.k8s.elastic.co/namekb-plain -o jsonpath{.items[0].metadata.name}) kubectl -n es-demo exec ${POD} -- cat /usr/share/kibana/config/kibana.yml | grep -A3 elasticsearch如果看到hosts: [http://es-plain-es-http.es-demo.svc:9200]说明 association 正确识别了非 TLS 状态。如果看到https://那就是 operator 版本或者 reconcile 状态有问题最直接的排查路径是kubectl -n es-demo describe kibana kb-plain看 Events 和 Status 里的 association 相关信息。ECK 的 association 出错时会在 status 里留下明确的 message比如association failed或证书相关的错误。还有一种情况Kibana 起来了浏览器能打开登录页但登录报Unable to authenticate。这通常是kibana_system用户的密码同步问题。glass 的排查手段是看 Kibana Pod 日志里的security_exception详细信息然后确认es-plain-es-internal-users这个 Secret 里kibana_system的密码跟 ES 里的一致。ECK 正常情况下会自动同步如果不同步重启一次 Kibana 的 StatefulSet 通常能解决。5.2 从带 TLS 的旧集群改成非 TLS路径怎么走这是最容易被低估的操作。改 CR 本身就是改几行 YAML 的事但 operator 会触发 StatefulSet 滚动重启每个 Pod 依次重建。如果你的集群里有数据这个过程会触发分片重分配短则几分钟长则几十分钟取决于数据量。我的操作顺序是这样的先确认集群是绿的有未分配分片的话先处理掉带病滚动风险高。备份。测试环境可以不做但如果是重要的测试数据用 snapshot 存一份。ECK 支持 snapshot用snapshotRepository配置 S3 或者本地 PVC 都行。改 CR 里的http.tls.selfSignedCertificate.disabled: truekubectl apply。盯着kubectl get pods -w看滚动顺序ECK 一般是一个一个重建不会全杀。如果发现两个 Pod 同时 Terminating说明updateStrategy配置有问题。滚动完之后验证新 Pod 里的elasticsearch.yml里有xpack.security.http.ssl.enabled: falsecurl http://...:9200能通。有一个非常隐蔽的坑如果你之前的客户端走 https改完之后它们会全部连不上报错是Unrecognized SSL message, plaintext connection?。这个错误的含义是「客户端发的是 TLS 握手包但服务端在说 HTTP 明文」。反过来如果客户端用 http 连一个还在 TLS 的服务端报错是received plaintext http traffic on an https channel。这两个报错信息我建议你记下来方向判断非常快。所以切换窗口期内客户端和集群的配置要同步改。要么先改客户端配http://要么接受一段时间的连接失败。测试环境无所谓生产环境必须做灰度。5.3 排查链路实录Pod 起不来 / 401 / 连接被拒这一节我把三个高频故障的排查顺序完整写出来你可以照着走一遍。故障一ES Pod 一直 CrashLoopBackOffkubectl -n es-demo logs es-plain-es-default-0 --previous先看倒数第二次的日志。三类典型输出max virtual memory areas vm.max_map_count [65530] is too low→ 回到 3.5 节处理 sysctl。java.nio.file.AccessDeniedException或者 data 目录权限问题 → PVC 挂载的 fsGroup 不对。ECK 默认给 Pod 设了fsGroup: 1000某些 NFS 或者 hostPath 的 StorageClass 不遵守这个语义需要手动在podTemplate.spec.securityContext里补fsGroup。failed to load plugin或者配置解析错误 → 去 exec 看/usr/share/elasticsearch/config/elasticsearch.yml大概率是你手写的 config 跟 operator 生成的冲突了。故障二curl 返回 401curl -u elastic:$ES_PASS http://localhost:9200401 只有三种原因密码错、用户名错、没带认证头。先确认 Secret 里取出来的密码没有多余的空格或者换行base64 -d之后不加echo容易在命令替换时出问题。再确认你连的是对的 Service
阅读完成 · 觉得有帮助？
