Cilium動手實驗室: 精通之旅---19.Golden Signals with Hubble and Grafana

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以生成更多簡歷,并運行crawlerresumes的更多副本來增加請求量 部署。

運行:

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. 提示1

首先查看傳入的請求和相關錯誤。

瀏覽 Grafana 上的三個儀表板(coreapiloaderelasticsearch-master)。

其中一項服務返回錯誤,是哪一項?

另一個服務根本不接受傳入請求,是哪一個?

加載程序服務的請求數會減少,但這不是問題。這只是因為我們已將請求速率重置為其原始值。

  1. 提示2

分析跟蹤以查找中斷的請求。

在 Tempo 中打開一個跟蹤,在跟蹤中查找失敗的服務以及重試的提示。這說明了服務失敗的什么情況?

  1. 提示3

使用 Hubble UI 查看組件如何相互鏈接。

這將幫助您了解哪些缺失的依賴項會導致組件失敗。

  1. 提示4

檢查組件副本。

確定哪個服務失敗后,請使用 kubectl 檢查它有多少個副本正在運行。

當心:Kubernetes 中有不止一種類型的工作負載控制器,請考慮所有類型。

  1. 提示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

此時Grafana這邊也正常了

請添加圖片描述

看來應該沒什么問題了.提交!

請添加圖片描述

新徽章GET!
請添加圖片描述

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/news/909261.shtml
繁體地址,請注明出處:http://hk.pswp.cn/news/909261.shtml
英文地址,請注明出處:http://en.pswp.cn/news/909261.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

常見文件系統格式有哪些

PART.01 常見文件系統格式有哪些 常見的文件系統格式有很多&#xff0c;通常根據使用場景&#xff08;Windows、Linux、macOS、移動設備、U盤、硬盤等&#xff09;有所不同。以下是一些主流和常見的文件系統格式及其特點&#xff1a; 一、Windows 常見文件系統格式 Digital …

React Native 彈窗組件優化實戰:解決 Modal 閃爍與動畫卡頓問題

&#x1f4cc; 前言 在移動端開發中&#xff0c;用戶對動畫的流暢性和過渡自然性有著極高的期待。最近我對一個使用 react-native-modal 實現的 Alert 彈窗組件進行了優化&#xff0c;成功解決了閃爍和卡頓問題&#xff0c;并顯著提升了用戶體驗。 本篇博客將帶你深入了解優化…

智能客服系統開發方案:RAG+多智能體技術實現

智能客服系統開發方案:RAG+多智能體技術實現 一、系統架構設計 #mermaid-svg-hKDXil2J0xV064Q5 {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-hKDXil2J0xV064Q5 .error-icon{fill:#552222;}#mermaid-svg-hKDXil2…

【Kafka】消息隊列Kafka知識總結

【Kafka】消息隊列Kafka知識總結 【一】消息隊列【1】什么是消息隊列【2】消息隊列有什么用&#xff08;1&#xff09;異步處理&#xff08;2&#xff09;削峰/限流&#xff08;3&#xff09;降低系統耦合性&#xff08;4&#xff09;實現分布式事務&#xff08;5&#xff09;順…

微信小程序開發 RangeError: Maximum call stack size exceeded

通常是由于??調用棧深度超限??&#xff08;如無限遞歸、過深的函數調用鏈或數據綁定循環&#xff09;導致。以下是具體解決方案&#xff1a; 一、核心原因分析 ??無限遞歸?? 函數直接或間接調用自身且無終止條件&#xff0c;例如事件處理函數中錯誤觸發自身。??數據…

mapbox進階,切片網格生成實現

????? 主頁: gis分享者 ????? 感謝各位大佬 點贊?? 收藏? 留言?? 加關注?! ????? 收錄于專欄:mapbox 從入門到精通 文章目錄 一、??前言1.1 ??mapboxgl.Map 地圖對象1.2 ??mapboxgl.Map style屬性1.3 ??line線圖層樣式1.4 ??symbol符號圖層…

Mysql 函數concat、concat_ws和group_concat

1.concat concat()函數是將多個字符串組合在一起&#xff0c;形成一個大的字符串&#xff1b;如果連接的字符串中存在一個為NULL&#xff0c;則輸出的結果為NULL&#xff0c;語法格式為&#xff1a; concat(str1,str2,....strn) -- 1、字符之間不加連接符 mysql> select c…

“在同一事務中“ 的含義

一、"在同一事務中" 的核心含義 "在同一事務中" 指多個數據庫操作共享同一個事務上下文&#xff0c;具有以下特點&#xff1a; 原子性保證&#xff1a;所有操作要么全部成功提交&#xff0c;要么全部失敗回滾。隔離性共享&#xff1a;操作使用相同的隔離…

【Create my OS】從零編寫一個操作系統

前言&#xff1a; 相信每個自學操作系統的同學&#xff0c;大致學習路線都離不開 HIT-OS、MIT-6.S081、MIT-6.824、MIT-6.828等經典的公開課。但學習完這些經典公開課并完成相應的Lab&#xff0c;很多同學腦海中對于操作系統的知識其實都是零散的&#xff0c;讓你從頭開始編寫一…

計算機視覺與深度學習 | 低照度圖像增強算法綜述(開源鏈接,原理,公式,代碼)

低照度圖像增強算法綜述 1 算法分類與原理1.1 傳統方法1.2 深度學習方法2 核心算法詳解2.1 多尺度Retinex (MSRCR) 實現2.2 SCI自校準光照學習2.3 自適應伽馬校正2.4 WaveletMamba架構3 開源資源與實現3.1 主流算法開源庫3.2 關鍵代碼實現4 評估與實驗對比4.1 客觀評價指標4.2 …

【工具教程】批量PDF識別提取區域的內容重命名,將PDF指定區域位置的內容提取出來改名的具體操作步驟

在企業運營過程中&#xff0c;時常會面臨處理海量 PDF 文件的挑戰。從 PDF 指定區域提取內容并用于重命名文件&#xff0c;能極大地優化企業內部的文件管理流程&#xff0c;提升工作效率。以下為您詳細介紹其在企業中的應用場景、具體使用步驟及注意事項。? 詳細使用步驟? 選…

【Java多線程從青銅到王者】定時器的原理和實現(十一)

定時器 定時器時我們日常開發中會用到的組件工具&#xff0c;類似于一個"鬧鐘"&#xff0c;設定一個時間&#xff0c;等到了時間&#xff0c;定時器最自動的去執行某個邏輯&#xff0c;比如博客的定時發布&#xff0c;就是使用到了定時器 Java標準庫里面也提供了定時…

深入剖析AI大模型:Prompt 優化的底層邏輯

記得看到一篇NLP的文章&#xff0c;就 Prompt 時序效應的論文揭示了一個有趣現象&#xff0c;文章中說&#xff1a;模型對指令的解析存在 "注意力衰減" 特性 —— 就像人類閱讀時會更關注段落開頭&#xff0c;模型對 Prompt 前 20% 的內容賦予的權重高達 60%。這個發…

【備忘】PHP web項目一般部署辦法

【PHP項目一般部署辦法】 操作步驟 代碼&#xff1a; 把php項目代碼clone到指定位置如www/下新建php站點&#xff0c;填寫域名&#xff0c;把站點根目錄設置為項目根目錄項目入口設置&#xff0c;一般為public/項目權限改為766(特殊時候可設置為777)&#xff0c;如果有特殊要求…

【60 Pandas+Pyecharts | 箱包訂單數據分析可視化】

文章目錄 &#x1f3f3;??&#x1f308; 1. 導入模塊&#x1f3f3;??&#x1f308; 2. Pandas數據處理2.1 讀取數據2.2 數據信息2.3 去除訂單金額為空的數據2.5 提取季度和星期 &#x1f3f3;??&#x1f308; 3. Pyecharts數據可視化3.1 每月訂單量和訂單金額分布3.2 各季…

玩轉Docker | 使用Docker部署vaultwarden密碼管理器

玩轉Docker | 使用Docker部署vaultwarden密碼管理器 前言一、vaultwarden介紹Vaultwarden 簡介主要特點二、系統要求環境要求環境檢查Docker版本檢查檢查操作系統版本三、部署vaultwarden服務下載vaultwarden鏡像編輯部署文件創建容器檢查容器狀態檢查服務端口安全設置四、配置…

晶振的多面舞臺:從日常電子到高精尖科技的應用探秘

在現代科技的宏大舞臺上&#xff0c;晶振宛如一位低調卻至關重要的幕后主角&#xff0c;以其穩定的頻率輸出&#xff0c;為各類電子設備賦予了精準的“脈搏”。從我們日常生活中須臾不離的電子設備&#xff0c;到引領時代前沿的高精尖科技領域&#xff0c;晶振都發揮著不可替代…

uni-app 小程序 Cannot read property ‘addEventListener‘ of undefined, mounted hook

在用 uni-app 開發微信小程序時&#xff0c;提示 Cannot read property addEventListener of undefined, mounted hook document.addEventListener("mousemove", this.touchmove) 在小程序開發里&#xff0c;addEventListener 并非通用的標準 API&#xff0c;不過與…

《專業小詞開課啦》——冪等

在系統對接過程中&#xff0c;當出現接口調用異常的情況時&#xff0c;程序員可能會用一些專業術語來答疑......對于0基礎同學&#xff0c;自然是需要自行百度一番&#xff0c;學習一下&#xff01; 接下來&#xff0c;先學習【冪等】 PS&#xff1a; 小白參考1.1~1.4內容即…

滲透實戰PortSwigger Labs指南:自定義標簽XSS和SVG XSS利用

阻止除自定義標簽之外的所有標簽 先輸入一些標簽測試&#xff0c;說是全部標簽都被禁了 除了自定義的 自定義<my-tag onmouseoveralert(xss)> <my-tag idx onfocusalert(document.cookie) tabindex1> onfocus 當元素獲得焦點時&#xff08;如通過點擊或鍵盤導航&…