Cilium动手实验室: 精通之旅---19.Golden Signals with Hubble and Grafana

1. Lab 环境
2. 部署测试应用
- 2.1 7层可见性的网络
- - 2.1.1 允许所有命名空间
  - 2.1.2 DNS 可见性
  - 2.1.3 L7-egress-visibility
- 2.2 检查 Deployments
- 2.3 在 Hubble UI 中查看
3. Grafana 选项卡
- 3.1 Grafana 中的 Hubble L7 HTTP 指标
- 3.2 L7 Hubble 仪表板
4. 吞吐量
- 4.1 提高请求速率
5. 增加错误率
6. 延迟
- 6.1 增加请求持续时间
7. 跟踪集成
- 7.1 介绍
- 7.2 Grafana 中的痕迹
- 7.3 访问 Tempo
8. 最终实验
- 8.1 题目
- 8.2 解题
- - 8.2.1 图形化界面确认问题
  - 8.2.2 命令行下确认问题

1. Lab 环境

LAB访问地址

https://isovalent.com/labs/hubble-grafana-golden-signals/

在本实验中，我们部署了：

启用 Hubble 和度量标准的 Cilium 1.17.1
Kube Prometheus Stack Helm 图表（包括 Prometheus 和 Grafana）

特别是，使用了以下 Cilium Helm 参数（完整的值文件位于 /tmp/helm/cilium-values.yaml）：

root@server:~# yq /tmp/helm/cilium-values.yaml 
kubeProxyReplacement: true
k8sServiceHost: kind-control-plane
k8sServicePort: 6443
operator:# only 1 replica needed on a single node setupreplicas: 1prometheus:enabled: trueserviceMonitor:enabled: true
hubble:relay:# enable relay in 02# enabled: trueservice:type: NodePortprometheus:enabled: trueserviceMonitor:enabled: truemetrics:serviceMonitor:enabled: trueenableOpenMetrics: trueenabled:- dns- drop- tcp- icmp- "flow:sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity"- "kafka:labelsContext=source_namespace,source_workload,destination_namespace,destination_workload,traffic_direction;sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity"- "httpV2:exemplars=true;labelsContext=source_ip,source_namespace,source_workload,destination_ip,destination_namespace,destination_workload,traffic_direction;sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity"dashboards:enabled: truenamespace: monitoringannotations:grafana_folder: "Hubble"ui:# enable UI in 02# enabled: trueservice:type: NodePort
prometheus:enabled: trueserviceMonitor:enabled: true

在本实验中，我们将使用 Cilium 的 Hubble 子系统生成的 Prometheus 指标来监控 HTTP 黄金信号。

具体而言，我们使用以下命令启用了 httpv2 Hubble 指标：

httpV2:exemplars=true;labelsContext=source_ip,source_namespace,source_workload,destination_ip,destination_namespace,destination_workload,traffic_direction;sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity

这是一条相当长的队伍。让我们拆分选项以了解它们的作用：

examplars=true 将允许我们将应用程序跟踪中的 OpenTelemetry 跟踪点显示为 Grafana 图形上的叠加层
labelsContext 设置为向指标添加额外的标签，包括源/目标 IP、源/目标命名空间、源/目标工作负载以及流量方向（入口或出口）
sourceContext 设置源标签的构建方式，在这种情况下，尽可能使用工作负载名称，否则使用保留身份（例如 world）
destinationContext 对目标执行相同的作

检查 Cilium 是否已正确安装并准备就绪

root@server:~# cilium status --wait/¯¯\/¯¯\__/¯¯\    Cilium:             OK\__/¯¯\__/    Operator:           OK/¯¯\__/¯¯\    Envoy DaemonSet:    OK\__/¯¯\__/    Hubble Relay:       disabled\__/       ClusterMesh:        disabledDaemonSet              cilium                   Desired: 3, Ready: 3/3, Available: 3/3
DaemonSet              cilium-envoy             Desired: 3, Ready: 3/3, Available: 3/3
Deployment             cilium-operator          Desired: 1, Ready: 1/1, Available: 1/1
Containers:            cilium                   Running: 3cilium-envoy             Running: 3cilium-operator          Running: 1clustermesh-apiserver    hubble-relay             
Cluster Pods:          8/8 managed by Cilium
Helm chart version:    1.17.1
Image versions         cilium             quay.io/cilium/cilium:v1.17.1@sha256:8969bfd9c87cbea91e40665f8ebe327268c99d844ca26d7d12165de07f702866: 3cilium-envoy       quay.io/cilium/cilium-envoy:v1.31.5-1739264036-958bef243c6c66fcfd73ca319f2eb49fff1eb2ae@sha256:fc708bd36973d306412b2e50c924cd8333de67e0167802c9b48506f9d772f521: 3cilium-operator    quay.io/cilium/operator-generic:v1.17.1@sha256:628becaeb3e4742a1c36c4897721092375891b58bae2bfcae48bbf4420aaee97: 1

2. 部署测试应用

我们在后台部署了 jobs-app demo 工作负载应用程序，以生成将要分析的 HTTP 流量。

2.1 7层可见性的网络

jobs-app 应用程序附带一组 Cilium 网络策略资源，这些资源使用 Cilium 的 Envoy 代理实现第 7 层可见性。

List them with: 列出它们：

root@server:~# kubectl -n tenant-jobs get cnp
NAME                         AGE     VALID
allow-all-within-namespace   3m30s   True
dns-visibility               3m30s   False
l7-egress-visibility         3m30s   True
l7-ingress-visibility        3m30s   True

2.1.1 允许所有命名空间

使用以下命令检查策略：

root@server:~# kubectl -n tenant-jobs get cnp allow-all-within-namespace -o yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:annotations:meta.helm.sh/release-name: jobs-appmeta.helm.sh/release-namespace: tenant-jobscreationTimestamp: "2025-06-03T09:02:53Z"generation: 1labels:app.kubernetes.io/managed-by: Helmname: allow-all-within-namespacenamespace: tenant-jobsresourceVersion: "4789"uid: 9de56664-8f96-4eb2-a842-09f215f7685f
spec:description: Allow all within namespaceegress:- toEndpoints:- {}endpointSelector: {}ingress:- fromEndpoints:- {}
status:conditions:- lastTransitionTime: "2025-06-03T09:02:53Z"message: Policy validation succeededstatus: "True"type: Valid

此策略可确保默认情况下允许所有流量。虽然从安全角度来看，这不是最佳实践，但它使本练习的设置更加容易。查看 Zero Trust Visibility 实验室，了解有关保护命名空间的最佳方法的更多信息。

2.1.2 DNS 可见性

使用以下命令检查策略：

root@server:~# kubectl -n tenant-jobs get cnp dns-visibility -o yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:annotations:meta.helm.sh/release-name: jobs-appmeta.helm.sh/release-namespace: tenant-jobscreationTimestamp: "2025-06-03T09:02:53Z"generation: 1labels:app.kubernetes.io/managed-by: Helmname: dns-visibilitynamespace: tenant-jobsresourceVersion: "4819"uid: c2739fed-3c39-451d-85bc-a2481eef3446
spec:egress:- toEndpoints:- matchLabels:k8s:io.kubernetes.pod.namespace: kube-systemk8s:k8s-app: kube-dnstoPorts:- ports:- port: "53"protocol: ANYrules:dns:- matchPattern: '*'- toFQDNs:- matchPattern: '*'- toEntities:- allendpointSelector:matchLabels: {}
status:conditions:- lastTransitionTime: "2025-06-03T09:02:53Z"message: FQDN regex compilation LRU not yet initializedstatus: "False"type: Valid

此策略允许命名空间中的 Pod 访问 Kube DNS 服务。它还添加了一个 DNS 规则，用于通过 Cilium 的 DNS 代理获取 DNS 流量，这使得解析 Hubble 流中的 DNS 名称成为可能。

2.1.3 L7-egress-visibility

使用以下命令检查策略：

root@server:~# kubectl -n tenant-jobs get cnp l7-ingress-visibility -o yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:annotations:meta.helm.sh/release-name: jobs-appmeta.helm.sh/release-namespace: tenant-jobscreationTimestamp: "2025-06-03T09:02:53Z"generation: 1labels:app.kubernetes.io/managed-by: Helmname: l7-ingress-visibilitynamespace: tenant-jobsresourceVersion: "4829"uid: 0a049efb-6bd8-475f-a607-adbfebaccc5f
spec:description: L7 policyendpointSelector: {}ingress:- toPorts:- ports:- port: "9080"protocol: TCP- port: "50051"protocol: TCP- port: "9200"protocol: TCPrules:http:- {}
status:conditions:- lastTransitionTime: "2025-06-03T09:02:53Z"message: Policy validation succeededstatus: "True"type: Valid

最后一个策略允许从命名空间中的所有 Pod 到 TCP 中的端口 9080、50051 和 9200 的入口流量。它强制这些流量通过 Cilium 的 Envoy 代理来实现第 7 层可见性。

2.2 检查 Deployments

让我们等到一切准备就绪。这可能需要几分钟时间才能部署所有组件：

kubectl rollout -n tenant-jobs status deployment/coreapi
kubectl rollout -n tenant-jobs status deployment/crawler
kubectl rollout -n tenant-jobs status deployment/jobposting
kubectl rollout -n tenant-jobs status deployment/loader
kubectl rollout -n tenant-jobs status deployment/recruiter
kubectl rollout -n tenant-jobs status deployment/resumes

2.3 在 Hubble UI 中查看

检查 Hubble UI 是否已正确部署：

root@server:~# cilium status --wait/¯¯\/¯¯\__/¯¯\    Cilium:             OK\__/¯¯\__/    Operator:           OK/¯¯\__/¯¯\    Envoy DaemonSet:    OK\__/¯¯\__/    Hubble Relay:       OK\__/       ClusterMesh:        disabledDaemonSet              cilium                   Desired: 3, Ready: 3/3, Available: 3/3
DaemonSet              cilium-envoy             Desired: 3, Ready: 3/3, Available: 3/3
Deployment             cilium-operator          Desired: 1, Ready: 1/1, Available: 1/1
Deployment             hubble-relay             Desired: 1, Ready: 1/1, Available: 1/1
Deployment             hubble-ui                Desired: 1, Ready: 1/1, Available: 1/1
Containers:            cilium                   Running: 3cilium-envoy             Running: 3cilium-operator          Running: 1clustermesh-apiserver    hubble-relay             Running: 1hubble-ui                Running: 1
Cluster Pods:          21/21 managed by Cilium
Helm chart version:    1.17.1
Image versions         cilium             quay.io/cilium/cilium:v1.17.1@sha256:8969bfd9c87cbea91e40665f8ebe327268c99d844ca26d7d12165de07f702866: 3cilium-envoy       quay.io/cilium/cilium-envoy:v1.31.5-1739264036-958bef243c6c66fcfd73ca319f2eb49fff1eb2ae@sha256:fc708bd36973d306412b2e50c924cd8333de67e0167802c9b48506f9d772f521: 3cilium-operator    quay.io/cilium/operator-generic:v1.17.1@sha256:628becaeb3e4742a1c36c4897721092375891b58bae2bfcae48bbf4420aaee97: 1hubble-relay       quay.io/cilium/hubble-relay:v1.17.1@sha256:397e8fbb188157f744390a7b272a1dec31234e605bcbe22d8919a166d202a3dc: 1hubble-ui          quay.io/cilium/hubble-ui-backend:v0.13.1@sha256:0e0eed917653441fded4e7cdb096b7be6a3bddded5a2dd10812a27b1fc6ed95b: 1hubble-ui          quay.io/cilium/hubble-ui:v0.13.1@sha256:e2e9313eb7caf64b0061d9da0efbdad59c6c461f6ca1752768942bfeda0796c6: 1

选择 tenant-jobs 命名空间以可视化应用程序组件以及它们如何相互通信。

请添加图片描述

组件在相互通信时出现，因为 Hubble 显示服务之间的实时流。

请注意，某些块（例如 zookeeper）具有端口号，后跟 TCP，而其他块则具有额外的 HTTP 标签。这是因为该流量通过 Cilium 的 Envoy Proxy 进行重定向，用于第 7 层解析，从而提供应用层可观察性。

例如，单击 coreapi 块。您将看到使用 HTTP 协议从 resumes 组件到端口 9080/TCP 的通信。该块实际上显示 /applications 路径上的 resumes 应用程序正在使用 POST 方法访问该服务：

请添加图片描述

我们之前描述的 l7-ingress-visibility Cilium 网络策略强制通过 Envoy 代理在端口 9080/TCP 上传输入口流量，从而允许 Hubble 提供这些额外的数据。

3. Grafana 选项卡

3.1 Grafana 中的 Hubble L7 HTTP 指标

在本实验中，我们设置了一个 Grafana 服务器，其数据源指向 Prometheus，并导入了 L7 HTTP 指标控制面板以可视化 Hubble 相关指标。

控制面板中的所有内容都使用 Hubble HTTP 指标，应用程序不需要任何插桩，也不需要向应用程序注入任何内容。

请添加图片描述

Incoming Requests by Source and Response Code 图表应在 0.3 到 0.4 req/s 之间变化。

3.2 L7 Hubble 仪表板

导航仪表板。

请注意您现在如何访问各种 HTTP 指标：

Incoming Request Volume
Incoming Request Success Rate
Request Duration
Requests by Response Code

请注意如何按源查看指标（第二部分， 按来源划分的请求 ，带有三个面板）或按目标（第三部分， 按目标划分的请求 ，具有三个面板）。这将使您能够找到异常所在的位置。

在 Requests by Source 部分中，检查 HTTP Request Duration by Source。请注意，有几个可用的统计数据：P50、P95 和 P99。我们通常用第 99 个百分位或 P99 来描述延迟。

如果我们基于 HTTP 的 Web 应用程序的 P99 延迟小于或等于 2 毫秒，则意味着 99% 的 Web 调用的响应时间低于 2 毫秒。相反，只有 1% 的调用获得超过 2 毫秒的延迟响应。

4. 吞吐量

4.1 提高请求速率

找到页面顶部的 Destination Workload 变量，并确保已选择 loader。

请添加图片描述

接下来，通过配置crawler以生成更多简历，并运行crawler和resumes的更多副本来增加请求量部署。

运行：

helm upgrade jobs-app ./helm/jobs-app.tgz \--namespace tenant-jobs \--reuse-values \--set crawler.replicas=3 \--set crawler.crawlFrequencyLowerBound=0.2 \--set crawler.crawlFrequencyUpperBound=0.5 \--set resumes.replicas=2

观察 Incoming Requests by Source and Response Code 面板。当爬网程序向加载程序提交简历时，您应该会看到请求速率增加，因为爬网程序的简历生成速率增加。速率应稳定在 3 req/s 左右。

现在，选择 coreapi 作为页面顶部的 Destination Workload 变量。

在 Incoming Requests by Source and Response Code 视图中，您还应该看到 coreapi 的请求速率增加。速率应稳定在 6 req/s 左右。

请添加图片描述

5. 增加错误率

让我们部署一个新的 jobs-app 配置，并使用我们的指标来查看请求错误率的变化。

helm upgrade jobs-app ./helm/jobs-app.tgz \--namespace tenant-jobs \--reuse-values \--set coreapi.errorRate=0.5 \--set coreapi.sleepRate=0.01

确保选择 coreapi 作为 Destination Workload。

大约一分钟后，您将看到 Incoming Request Success Rate （non-5xx responses） By Source （按源） 图表开始下降。

最后，Incoming Request Success Rate （non-5xx responses） 面板应稳定在 93% 左右。

请添加图片描述

6. 延迟

6.1 增加请求持续时间

接下来，我们将升级 jobs-app 设置以增加响应之间的睡眠时间，从而延长请求持续时间。

运行：

helm upgrade jobs-app ./helm/jobs-app.tgz \--namespace tenant-jobs \--reuse-values \--set coreapi.sleepRate=0.2 \--set coreapi.sleepLowerBound=0.5 \--set coreapi.sleepUpperBound=5.0

并选择 coreapi 作为 Destination Workload。

大约一分钟后，您将看到 HTTP Request Duration by Source （按源划分的 HTTP 请求持续时间 ）图表中的值增加到 800 毫秒左右。

请添加图片描述

请注意，P50、P95 和 P99 的三条曲线具有截然不同的值。这意味着延迟会增加，但仅限于一小部分请求。

例如，上面的屏幕截图显示，虽然 99% 的请求的延迟低于 ~1 秒（P99 曲线），但其中 95% 的请求延迟低于 600 毫秒（P95 曲线），其中 50% 的请求速度要快得多（P50 曲线）。

单击图形下的 tenant-jobs/resumes P50 标签，仅查看以下值：

请添加图片描述

您可以看到 50% 的请求实际上需要 ~30 毫秒才能得到处理。

检查图表图例中每个序列的最小值、最大值和平均值。这对于识别延迟问题非常有用。

7. 跟踪集成

7.1 介绍

Grafana Tempo 以及 OpenTelemetry Operator 和 Collector 已添加到集群中。

升级 jobs-app 设置以启用 OpenTelemetry 跟踪。

运行：

helm upgrade jobs-app ./helm/jobs-app.tgz \--namespace tenant-jobs \--reuse-values \--set tracing.enabled=true

这将使应用程序生成 OpenTelemetry 跟踪。

当 Cilium 的 Envoy 代理处理第 7 层数据时，Hubble 将能够从 HTTP 标头中提取 Trace ID，并将它们与 Hubble 的数据相关联，以丰富 Grafana 仪表板。

7.2 Grafana 中的痕迹

选择 coreapi 作为 Destination Workload（目标工作负载 ）。

在 HTTP Request Duration by Source/Destination 面板中，您应该开始看到示例显示为点，并位于折线图可视化图表旁边。

请添加图片描述

这些示例中的每个示例都表示单个请求的持续时间，并链接到跟踪 ID。

您可以通过将鼠标悬停在点上来查看跟踪详细信息。选择图表顶部的跟踪点。检查详细信息。

请添加图片描述

7.3 访问 Tempo

接下来，单击弹出窗口底部的 “Query with Tempo” 按钮。这将允许您可视化应用程序的 OpenTelemetry 跟踪。

请添加图片描述

请注意， 加载程序请求的末尾（第 3 行，带有深粉色标记）和简历回复的开头（第 4 行，带有非常浅的粉红色标记）之间有一个长空格。这解释了为什么此请求具有较高的延迟（这是因为您从图表顶部选择了一个示例）。

在 Trace View 的顶部，有一个 Node graph 面板。打开它可查看显示交易中花费时间的有向图。

请添加图片描述

使用 Web 浏览器中的后退⬅️按钮返回预览视图。

现在，在图表的最底部选择一个请求，然后单击 “Query with Tempo” 按钮：

请添加图片描述

您很可能会在跟踪中看到 coreapi 服务的错误。resumes 组件正在尝试连接到 coreapi 但请求没有通过。resumes 实际上会多次重试连接，从而导致多个错误，直到成功为止。

如果您打开 Node graph （节点图形 ）视图，您也将在那里重试：

请添加图片描述

8. 最终实验

8.1 题目

应用程序已使用原始参数再次部署，但其中一个服务已损坏。

使用每项服务的 Grafana 控制面板，确定哪个服务损坏并修复它。

如果您遇到困难，请考虑以下提示。

提示1

首先查看传入的请求和相关错误。

浏览 Grafana 上的三个仪表板（coreapi、loader 和 elasticsearch-master）。

其中一项服务返回错误，是哪一项？

另一个服务根本不接受传入请求，是哪一个？

加载程序服务的请求数会减少，但这不是问题。这只是因为我们已将请求速率重置为其原始值。

提示2

分析跟踪以查找中断的请求。

在 Tempo 中打开一个跟踪，在跟踪中查找失败的服务以及重试的提示。这说明了服务失败的什么情况？

提示3

使用 Hubble UI 查看组件如何相互链接。

这将帮助您了解哪些缺失的依赖项会导致组件失败。

提示4

检查组件副本。

确定哪个服务失败后，请使用 kubectl 检查它有多少个副本正在运行。

当心：Kubernetes 中有不止一种类型的工作负载控制器，请考虑所有类型。

提示5

使用 kubectl 修复问题。该特定服务应使用一个副本运行。

8.2 解题

8.2.1 图形化界面确认问题

coreapi看上去没有数据

请添加图片描述

loader有返回

请添加图片描述

elasticsearch-master看上去好像也没数据

请添加图片描述

进一步调查发现coreapi是存在问题的

请添加图片描述

8.2.2 命令行下确认问题

查看下tenant-jobs下的pod情况

显然问题出在elasticsearch-master.tenant-jobs.svc.cluster.local:9200这个服务上

root@server:~# k get po -n tenant-jobs 
NAME                                        READY   STATUS     RESTARTS   AGE
coreapi-54dfb497c4-n8t5p                    1/1     Running    0          19m
coreapi-585f9f77bb-48twp                    0/1     Init:0/1   0          3m57s
crawler-77886f5878-g84qj                    1/1     Running    0          18m
jobposting-67c6445f96-7dtll                 1/1     Running    0          19m
jobs-app-entity-operator-7bc4cd6568-tg5ck   3/3     Running    0          22m
jobs-app-kafka-0                            1/1     Running    0          22m
jobs-app-zookeeper-0                        1/1     Running    0          23m
loader-dd4b97f64-f8d7q                      1/1     Running    0          19m
recruiter-5c7b8dd845-clx42                  1/1     Running    0          19m
resumes-6954d48bf-s5tpl                     1/1     Running    0          19m
strimzi-cluster-operator-699cd75b77-nb4fw   1/1     Running    0          23m
root@server:~# k describe po -n tenant-jobs coreapi-585f9f77bb-48twp 
Name:             coreapi-585f9f77bb-48twp
Namespace:        tenant-jobs
Priority:         0
Service Account:  default
Node:             kind-worker2/172.18.0.3
Start Time:       Wed, 04 Jun 2025 02:33:28 +0000
Labels:           app=coreapipod-template-hash=585f9f77bb
Annotations:      <none>
Status:           Pending
IP:               10.244.2.233
IPs:IP:           10.244.2.233
Controlled By:  ReplicaSet/coreapi-585f9f77bb
Init Containers:wait-for-elasticsearch:Container ID:  containerd://4e12c079de57cdc32f0dc851a3185de25c4ac3011afa8f578efa04bcd07fd650Image:         curlimages/curl:latestImage ID:      docker.io/curlimages/curl@sha256:d43bdb28bae0be0998f3be83199bfb2b81e0a30b034b6d7586ce7e05de34c3fdPort:          <none>Host Port:     <none>Command:sh-cuntil curl -s -o /dev/null http://elasticsearch-master.tenant-jobs.svc.cluster.local:9200; do echo waiting for elasticsearch; sleep 5; doneState:          RunningStarted:      Wed, 04 Jun 2025 02:33:29 +0000Ready:          FalseRestart Count:  0Environment:    <none>Mounts:/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-dmpxc (ro)
Containers:coreapi:Container ID:   Image:          quay.io/isovalent/jobs-app-coreapi:v0.10.0Image ID:       Port:           9080/TCPHost Port:      0/TCPState:          WaitingReason:       PodInitializingReady:          FalseRestart Count:  0Environment:ES_ENDPOINT:                        http://elastic:changeme@elasticsearch-master.tenant-jobs.svc.cluster.local:9200/BOOTSTRAP:                          trueDEBUG:                              falseENABLE_TRACING:                     trueLOG_SPANS:                          falseOTL_EXPORTER_ENABLED:               trueHOST_IP:                             (v1:status.hostIP)OTEL_EXPORTER_OTLP_ENDPOINT:        http://$(HOST_IP):4317ERROR_RATE:                         0.01SLEEP_RATE:                         0.1SLOW_REQUEST_DURATION_LOWER_BOUND:  0.1SLOW_REQUEST_DURATION_UPPER_BOUND:  0.2Mounts:/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-dmpxc (ro)
Conditions:Type                        StatusPodReadyToStartContainers   TrueInitialized                 FalseReady                       FalseContainersReady             FalsePodScheduled                True
Volumes:kube-api-access-dmpxc:Type:                    Projected (a volume that contains injected data from multiple sources)TokenExpirationSeconds:  3607ConfigMapName:           kube-root-ca.crtConfigMapOptional:       <nil>DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300snode.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:Type    Reason     Age    From               Message----    ------     ----   ----               -------Normal  Scheduled  4m10s  default-scheduler  Successfully assigned tenant-jobs/coreapi-585f9f77bb-48twp to kind-worker2Normal  Pulling    4m9s   kubelet            Pulling image "curlimages/curl:latest"Normal  Pulled     4m9s   kubelet            Successfully pulled image "curlimages/curl:latest" in 664ms (664ms including waiting). Image size: 9555383 bytes.Normal  Created    4m9s   kubelet            Created container wait-for-elasticsearchNormal  Started    4m9s   kubelet            Started container wait-for-elasticsearch

再确认这个svc发现elasticsearch-master没有ep存在

root@server:~# k get svc -n tenant-jobs elasticsearch-master
NAME                   TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
elasticsearch-master   ClusterIP   10.96.117.68   <none>        9200/TCP,9300/TCP   25m
root@server:~# k get ep -n tenant-jobs elasticsearch-master
NAME                   ENDPOINTS   AGE
elasticsearch-master   <none>      25m

通过命令发现statefulset的elasticsearch-master是0/0

root@server:~# k get all -n tenant-jobs |grep ela
service/elasticsearch-master            ClusterIP   10.96.117.68    <none>        9200/TCP,9300/TCP                              26m
service/elasticsearch-master-headless   ClusterIP   None            <none>        9200/TCP,9300/TCP                              26m
statefulset.apps/elasticsearch-master   0/0     26m

调度statefulset副本数

root@server:~# k scale -n tenant-jobs statefulset --replicas=1 elasticsearch-master 
statefulset.apps/elasticsearch-master scaled

稍等片刻后tenant命名空间下面的pod都正常了

root@server:~# k get po -n tenant-jobs 
NAME                                        READY   STATUS    RESTARTS   AGE
coreapi-585f9f77bb-48twp                    1/1     Running   0          9m52s
crawler-77886f5878-g84qj                    1/1     Running   0          24m
elasticsearch-master-0                      1/1     Running   0          99s
jobposting-67c6445f96-7dtll                 1/1     Running   0          24m
jobs-app-entity-operator-7bc4cd6568-tg5ck   3/3     Running   0          28m
jobs-app-kafka-0                            1/1     Running   0          28m
jobs-app-zookeeper-0                        1/1     Running   0          29m
loader-dd4b97f64-f8d7q                      1/1     Running   0          24m
recruiter-5c7b8dd845-clx42                  1/1     Running   0          24m
resumes-6954d48bf-s5tpl                     1/1     Running   0          24m
strimzi-cluster-operator-699cd75b77-nb4fw   1/1     Running   0          29m