Skip to main content
Data Infrastructure Insights
本繁體中文版使用機器翻譯，譯文僅供參考，若與英文版本牴觸，應以英文版本為準。

Kubernetes 監控 Operator 安裝與設定

貢獻者 netapp-alavoie
PDF

Data Infrastructure Insights為 Kubernetes 集合提供了 Kubernetes Monitoring Operator。導覽至 Kubernetes > Collectors > +Kubernetes Collector 來部署新的操作員。

安裝 Kubernetes Monitoring Operator 之前

查看"先決條件"在安裝或升級 Kubernetes Monitoring Operator 之前，請先閱讀文件。

安裝 Kubernetes 監控操作員

監控操作員指令 監控操作員指令

在 Kubernetes 上安裝 Kubernetes Monitoring Operator 代理程式的步驟：

  1. 輸入唯一的叢集名稱和命名空間。如果你升級與先前的 Kubernetes Operator 一樣，使用相同的叢集名稱和命名空間。

  2. 輸入這些內容後，您可以將下載命令片段複製到剪貼簿。

  3. 將程式碼片段貼到 bash 視窗並執行。將下載 Operator 安裝檔。請注意，該程式碼片段具有唯一密鑰，並且有效期為 24 小時。

  4. 如果您有自訂或私人儲存庫，請複製可選的 Image Pull 程式碼片段，將其貼上到 bash shell 中並執行它。提取圖像後，將其複製到您的私人儲存庫。確保保持相同的標籤和資料夾結構。更新_operator-deployment.yaml_ 中的路徑以及_operator-config.yaml_ 中的 docker 儲存庫設定。

  5. 如果需要，請查看可用的配置選項，例如代理或私人儲存庫設定。您可以閱讀更多關於"配置選項"。

  6. 準備好後，透過複製 kubectl Apply 程式碼片段、下載並執行它來部署 Operator。

  7. 安裝將自動進行。完成後，按一下“下一步”按鈕。

  8. 安裝完成後，按一下“下一步”按鈕。請確保刪除或安全儲存 operator-secrets.yaml 檔案。

如果您有自訂儲存庫，請閱讀使用自訂/私人 docker 倉庫。

Kubernetes 監控元件

Data Infrastructure InsightsKubernetes 監控由四個監控元件組成：

  • 集群指標

  • 網路效能和地圖（可選）

  • 事件日誌（可選）

  • 變化分析（可選）

預設情況下，每個 Kubernetes 收集器都會啟用上述選用元件；如果您決定不需要特定收集器的元件，則可以透過導覽至 Kubernetes > Collectors 並從螢幕右側收集器的「三個點」選單中選擇_修改部署_來停用它。

修改 Kubernetes Collector 清單頁上的部署選單

螢幕顯示每個元件的目前狀態，並允許您根據需要停用或啟用該收集器的元件。

修改部署選項，width=700

升級到最新的 Kubernetes Monitoring Operator

DII 按鈕升級

您可以透過 DII Kubernetes Collectors 頁面升級 Kubernetes Monitoring Operator。按一下要升級的叢集旁的選單，然後選擇“升級”。操作員將驗證影像簽名，對目前安裝進行快照並執行升級。幾分鐘內，您將看到操作員狀態從「升級進行中」進展到「最新」。如果遇到錯誤，您可以選擇錯誤狀態以了解更多詳細信息，並參考下面的按鈕升級故障排除表。

使用私有儲存庫進行按鈕升級

如果您的操作員配置為使用私人儲存庫，請確保運行操作員所需的所有映像及其簽名均可在您的儲存庫中取得。如果在升級過程中遇到缺少圖像的錯誤，只需將它們新增至儲存庫並重試升級。若要將圖像簽名上傳到您的儲存庫，請使用以下 cosign 工具，確保上傳 3 下指定的所有圖像的簽名可選：將操作員圖像上傳到您的私人儲存庫 > 圖像拉取片段

cosign copy example.com/src:v1 example.com/dest:v1
#Example
cosign copy <DII container registry>/netapp-monitoring:<image version> <private repository>/netapp-monitoring:<image version>

回滾到之前運行的版本

如果您使用按鈕升級功能進行升級，並且在升級後七天內遇到當前版本的操作員的任何困難，則可以使用升級過程中建立的快照降級到先前執行的版本。按一下要回滾的叢集旁邊的選單，然後選擇「回滾」。

手動升級

確定現有 Operator 是否存在 AgentConfiguration（如果您的命名空間不是預設的 netapp-monitoring，請替換為適當的命名空間）：

 kubectl -n netapp-monitoring get agentconfiguration netapp-ci-monitoring-configuration
如果存在 AgentConfiguration：

如果 AgentConfiguration 不存在：

  • 記下Data Infrastructure Insights識別的叢集名稱（如果您的命名空間不是預設的 netapp-monitoring，請替換為適當的命名空間）：

     kubectl -n netapp-monitoring get agent -o jsonpath='{.items[0].spec.cluster-name}'
* 建立現有 Operator 的備份（如果您的命名空間不是預設的 netapp-monitoring，請替換為適當的命名空間）：
     kubectl -n netapp-monitoring get agent -o yaml > agent_backup.yaml
* <<to-remove-the-kubernetes-monitoring-operator,解除安裝>>現有的營運商。
* <<installing-the-kubernetes-monitoring-operator,安裝>>最新的操作員。

    • 使用相同的叢集名稱。

    • 下載最新的 Operator YAML 檔案後，在部署之前將 agent_backup.yaml 中找到的任何自訂內容移植到下載的 operator-config.yaml 中。

    • 確保您拉取最新的容器鏡像如果您使用自訂儲存庫。

停止並啟動 Kubernetes 監控操作員

要停止 Kubernetes Monitoring Operator：

 kubectl -n netapp-monitoring scale deploy monitoring-operator --replicas=0
啟動 Kubernetes Monitoring Operator：
kubectl -n netapp-monitoring scale deploy monitoring-operator --replicas=1

解除安裝

刪除 Kubernetes Monitoring Operator

請注意，Kubernetes Monitoring Operator 的預設命名空間是「netapp-monitoring」。如果您設定了自己的命名空間，請在這些命令和所有後續命令和檔案中取代該命名空間。

可以使用以下命令卸載較新版本的監控操作員：

kubectl -n <NAMESPACE> delete agent -l installed-by=nkmo-<NAMESPACE>
kubectl -n <NAMESPACE> delete clusterrole,clusterrolebinding,crd,svc,deploy,role,rolebinding,secret,sa -l installed-by=nkmo-<NAMESPACE>

如果監控操作員部署在其自己的專用命名空間中，請刪除該命名空間：

 kubectl delete ns <NAMESPACE>
注意：如果第一個命令返回“未找到資源”，請使用以下說明卸載舊版本的監控操作員。

按順序執行以下每個命令。根據您目前的安裝，其中一些命令可能會傳回「未找到對象」訊息。您可以安全地忽略這些訊息。

kubectl -n <NAMESPACE> delete agent agent-monitoring-netapp
kubectl delete crd agents.monitoring.netapp.com
kubectl -n <NAMESPACE> delete role agent-leader-election-role
kubectl delete clusterrole agent-manager-role agent-proxy-role agent-metrics-reader <NAMESPACE>-agent-manager-role <NAMESPACE>-agent-proxy-role <NAMESPACE>-cluster-role-privileged
kubectl delete clusterrolebinding agent-manager-rolebinding agent-proxy-rolebinding agent-cluster-admin-rolebinding <NAMESPACE>-agent-manager-rolebinding <NAMESPACE>-agent-proxy-rolebinding <NAMESPACE>-cluster-role-binding-privileged
kubectl delete <NAMESPACE>-psp-nkmo
kubectl delete ns <NAMESPACE>

如果先前建立了安全上下文約束：

kubectl delete scc telegraf-hostaccess

關於 Kube-state-metrics

NetApp Kubernetes Monitoring Operator 安裝自己的 kube-state-metrics 以避免與任何其他實例發生衝突。

有關 Kube-State-Metrics 的信息，請參閱"本頁"。

配置/自訂操作員

這些部分包含有關自訂操作員配置、使用代理程式、使用自訂或私人 docker 儲存庫或使用 OpenShift 的資訊。

配置選項

最常修改的設定可以在_AgentConfiguration_自訂資源中配置。您可以在部署操作員之前透過編輯 operator-config.yaml 檔案來編輯此資源。該文件包含已註解掉的設定範例。查看列表"可用設定"以取得最新版本的操作員。

您也可以在部署操作員後使用以下命令編輯此資源：

 kubectl -n netapp-monitoring edit AgentConfiguration
若要確定您部署的操作員版本是否支援 AgentConfiguration，請執行下列命令：
 kubectl get crd agentconfigurations.monitoring.netapp.com
如果您看到「伺服器錯誤（未找到）」訊息，則必須先升級您的操作員才能使用 AgentConfiguration。

配置代理支援

您可以在租戶的兩個地方使用代理程式來安裝 Kubernetes Monitoring Operator。這些可能是相同或獨立的代理系統：

  • 執行安裝程式碼片段（使用“curl”）期間需要代理，以將執行程式碼片段的系統連接到您的Data Infrastructure Insights環境

  • 目標 Kubernetes 叢集與您的Data Infrastructure Insights環境通訊所需的代理

如果您對其中一個或兩個都使用代理，為了安裝 Kubernetes 操作監視器，您必須先確保您的代理程式配置為允許與您的Data Infrastructure Insights環境進行良好的通訊。如果您有代理並且可以從您希望安裝 Operator 的伺服器/VM 存取Data Infrastructure Insights，那麼您的代理可能配置正確。

對於用於安裝 Kubernetes Operating Monitor 的代理，在安裝 Operator 之前，請設定 http_proxy/https_proxy 環境變數。對於某些代理環境，您可能還需要設定 no_proxy environment 變數。

若要設定變量，請在安裝 Kubernetes Monitoring Operator*之前*在系統上執行下列步驟：

  1. 為目前使用者設定 https_proxy 和/或 http_proxy 環境變數：

    1. 如果正在設定的代理程式沒有身份驗證（使用者名稱/密碼），請執行以下命令：

       export https_proxy=<proxy_server>:<proxy_port>
.. 如果正在設定的代理確實具有身份驗證（使用者名稱/密碼），請執行以下命令：
      export http_proxy=<proxy_username>:<proxy_password>@<proxy_server>:<proxy_port>

對於用於 Kubernetes 叢集與Data Infrastructure Insights環境通訊的代理，請在閱讀所有這些說明後安裝 Kubernetes 監控操作員。

在部署 Kubernetes Monitoring Operator 之前，請先設定 operator-config.yaml 中 AgentConfiguration 的代理程式部分。

agent:
  ...
  proxy:
    server: <server for proxy>
    port: <port for proxy>
    username: <username for proxy>
    password: <password for proxy>

    # In the noproxy section, enter a comma-separated list of
    # IP addresses and/or resolvable hostnames that should bypass
    # the proxy
    noproxy: <comma separated list>

    isTelegrafProxyEnabled: true
    isFluentbitProxyEnabled: <true or false> # true if Events Log enabled
    isCollectorsProxyEnabled: <true or false> # true if Network Performance and Map enabled
    isAuProxyEnabled: <true or false> # true if AU enabled
  ...
...

使用自訂或私有的 Docker 倉庫

預設情況下，Kubernetes Monitoring Operator 將從Data Infrastructure Insights儲存庫中提取容器映像。如果您有 Kubernetes 叢集作為監控目標，且該叢集配置為僅從自訂或私人 Docker 儲存庫或容器註冊表中提取容器映像，則必須配置對 Kubernetes 監控操作員所需容器的存取權。

從NetApp Monitoring Operator 安裝圖塊運行「Image Pull Snippet」。此命令將登入Data Infrastructure Insights儲存庫，為操作員提取所有影像依賴項，並登出Data Infrastructure Insights儲存庫。出現提示時，輸入提供的儲存庫臨時密碼。此命令下載操作員使用的所有影像，包括選用功能。請參閱下文以了解這些圖像的用途。

核心 Operator 功能和 Kubernetes 監控

  • netapp-監控

  • ci-kube-rbac-代理

  • ci-ksm

  • 西電訊報

  • distroless-root 用戶

事件日誌

  • ci-fluent-bit

  • ci-kubernetes-事件導出器

網路效能和地圖

  • ci-net-觀察者

根據您的公司政策將操作員 docker 映像推送到您的私人/本地/企業 docker 儲存庫。確保儲存庫中這些圖像的圖像標籤和目錄路徑與Data Infrastructure Insights儲存庫中的一致。

編輯 operator-deployment.yaml 中的 monitoring-operator 部署，並修改所有映像引用以使用您的私人 Docker 儲存庫。

image: <docker repo of the enterprise/corp docker repo>/ci-kube-rbac-proxy:<ci-kube-rbac-proxy version>
image: <docker repo of the enterprise/corp docker repo>/netapp-monitoring:<version>

編輯 operator-config.yaml 中的 AgentConfiguration 以反映新的 docker repo 位置。為您的私人儲存庫建立一個新的 imagePullSecret，有關更多詳細信息，請參閱 https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/

agent:
  ...
  # An optional docker registry where you want docker images to be pulled from as compared to CI's docker registry
  # Please see documentation link here: link:task_config_telegraf_agent_k8s.html#using-a-custom-or-private-docker-repository
  dockerRepo: your.docker.repo/long/path/to/test
  # Optional: A docker image pull secret that maybe needed for your private docker registry
  dockerImagePullSecret: docker-secret-name

OpenShift 說明

如果您在 OpenShift 4.6 或更高版本上執行，則必須編輯 operator-config.yaml 中的 AgentConfiguration 以啟用 runPrivileged 設定：

# Set runPrivileged to true SELinux is enabled on your kubernetes nodes
runPrivileged: true

Openshift 可能會實施額外的安全級別，從而阻止對某些 Kubernetes 元件的存取。

容忍度和污點

netapp-ci-telegraf-ds、netapp-ci-fluent-bit-ds 和 netapp-ci-net-observer-l4-ds DaemonSet 必須在叢集中的每個節點上安排一個 pod，以便正確收集所有節點上的資料。操作員已配置為容忍一些眾所周知的*污點*。如果您在節點上配置了任何自訂污點，從而阻止 Pod 在每個節點上運行，則可以為這些污點建立 *容忍度*"在_AgentConfiguration_中" 。如果您已將自訂污點套用至叢集中的所有節點，則您也必須向操作員部署新增必要的容忍度，以允許調度和執行操作員 pod。

了解有關 Kubernetes 的更多信息"污點和容忍度"。

返回"* NetApp Kubernetes 監控操作員安裝* 頁面"

關於秘密的說明

若要刪除 Kubernetes Monitoring Operator 查看叢集範圍機密的權限，請在安裝之前從 operator-setup.yaml 檔案中刪除下列資源：

 ClusterRole/netapp-ci<namespace>-agent-secret
 ClusterRoleBinding/netapp-ci<namespace>-agent-secret

如果這是升級，也請從叢集中刪除資源：

 kubectl delete ClusterRole/netapp-ci-<namespace>-agent-secret-clusterrole
 kubectl delete ClusterRoleBinding/netapp-ci-<namespace>-agent-secret-clusterrolebinding

如果啟用了變更分析，請修改 AgentConfiguration 或 operator-config.yaml 以取消註解變更管理部分，並在變更管理部分下包含 kindsToIgnoreFromWatch: '"secrets"'。請注意此行中單引號和雙引號的存在和位置。

change-management:
  ...
  # # A comma separated list of kinds to ignore from watching from the default set of kinds watched by the collector
  # # Each kind will have to be prefixed by its apigroup
  # # Example: '"networking.k8s.io.networkpolicies,batch.jobs", "authorization.k8s.io.subjectaccessreviews"'
  kindsToIgnoreFromWatch: '"secrets"'
  ...

驗證 Kubernetes 監控 Operator 鏡像簽名

操作員的映像及其部署的所有相關映像均由NetApp簽署。您可以在安裝前使用 cosign 工具手動驗證映像，或設定 Kubernetes 准入控制器。如欲了解更多詳情，請參閱"Kubernetes 文檔"。

用於驗證鏡像簽名的公鑰可在「監控操作員」安裝磁貼中找到，位於「可選：將操作員鏡像上傳到您的私人儲存庫 > 鏡像簽署公鑰」下

若要手動驗證影像簽名，請執行下列步驟：

  1. 複製並運行圖像拉取片段

  2. 出現提示時複製並輸入儲存庫密碼

  3. 儲存圖片簽署公鑰（範例中為 dii-image-signing.pub）

  4. 使用 cosign 驗證映像。請參閱以下 cosign 用法範例

$ cosign verify --key dii-image-signing.pub --insecure-ignore-sct --insecure-ignore-tlog <repository>/<image>:<tag>
Verification for <repository>/<image>:<tag> --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
[{"critical":{"identity":{"docker-reference":"<repository>/<image>"},"image":{"docker-manifest-digest":"sha256:<hash>"},"type":"cosign container image signature"},"optional":null}]

故障排除

如果您在設定 Kubernetes Monitoring Operator 時遇到問題，請嘗試以下操作：

問題： 試試一下：

我沒有看到我的 Kubernetes 持久捲和相應的後端儲存裝置之間的超連結/連接。我的 Kubernetes 持久性磁碟區是使用儲存伺服器的主機名稱配置的。

請依照步驟卸載現有的 Telegraf 代理，然後重新安裝最新的 Telegraf 代理程式。您必須使用 Telegraf 2.0 或更高版本，並且您的 Kubernetes 叢集儲存必須由Data Infrastructure Insights主動監控。

我在日誌中看到類似以下內容的訊息：E0901 15：21：39.962145 1 reflector.go：178] k8s.io/kube-state-metrics/internal/store/builder.go：352：無法列出*v1.MutatingWebs/internal/store/builder.go：352：無法列出*v1.MutatingWebhookConfigurationWeb 1 reflector.go：178] k8s.io/kube-state-metrics/internal/store/builder.go：352：無法列出*v1.Lease：伺服器找不到要求的資源（取得leases.coordination.k8s.io）等。

如果您執行 kube-state-metrics 版本 2.0.0 或更高版本且 Kubernetes 版本低於 1.20，則可能會出現這些訊息。取得 Kubernetes 版本：kubectl version 取得 kube-state-metrics 版本：kubectl get deploy/kube-state-metrics -o jsonpath='{..image}' 為了防止這些訊息，使用者可以修改其 kube-state-metrics 部署以停用下列租約：pandmations_webating_webating_webPotations _volumeattachments resources 更具體地說，他們可以使用以下 CLI參數：resources=certificatesigningrequests、configmaps、cronjobs、daemonsets、deployments、endpoints、horizo​​ntalpodautoscalers、ingresses、jobs、limitranges、n amespaces、networkpolicies、nodes、persistentvolumeclaims、persistentvolumes、poddisruptionbudgets、pods、replicasets、replicationcontrollers、resourcequotas， secrets,services,statefulsets,storageclasses預設資源清單為：「certificatesigningrequests、configmaps、cronjobs、daemonsets、deployments、endpoints、horizo​​ntalpodautoscalers、ingresses、jobs、leases、limitranges、mutatingwebhookconfigurations、namespaces、networkpolicies、nodes 、persistentvolumeclaims、persistentvolumes、poddisruptionbudgets、pods、replicasets、replicationcontrollers、resourcequotas、secrets、services、statefulsets、storageclasses、validatingwebhookconfigurations、volumeattachments」

我看到 Telegraf 發出類似以下內容的錯誤訊息，但 Telegraf 確實啟動並運行：10 月 11 日 14:23:41 ip-172-31-39-47 systemd[1]: 已啟動用於將指標報告到 InfluxDB 的插件驅動的伺服器代理。 10月11日 14:23:41 ip-172-31-39-47 telegraf[1827]: time="2021-10-11T14:23:41Z" level=error msg="無法建立快取目錄。 /etc/telegraf/.cache/snowflake，錯誤：mkdir /etc/telegraf/.ca che：權限被拒絕。 ignored\n” func="gosnowflake.(*defaultLogger).Errorf” file="log.go:120” 10月11日 14:23:41 ip-172-31-39-47 telegraf[1827]: time="2021-1001010忽略。開啟 /etc/telegraf/.cache/snowflake/ocsp_response_cache.json：沒有這樣的檔案或目錄\n「func =」gosnowflake。 （*defaultLogger）.Errorf“file =”log.go：120“10月11日14:23:41 ip-172-31-39-47 telegraf [1827]：2021-10-11T14：23：41Z I！啟動 Telegraf 1.19.3

這是一個已知問題。參考"這篇 GitHub 文章"了解更多詳情。只要 Telegraf 正常運行，用戶就可以忽略這些錯誤訊息。

在 Kubernetes 上，我的 Telegraf pod 會報告以下錯誤：“處理 mountstats 訊息時出錯：無法開啟 mountstats 檔案：/hostfs/proc/1/mountstats，錯誤：開啟 /hostfs/proc/1/mountstats：權限被拒絕”

如果啟用並強制執行 SELinux，則可能會阻止 Telegraf pod 存取 Kubernetes 節點上的 /proc/1/mountstats 檔案。若要克服此限制，請編輯代理程式配置並啟用 runPrivileged 設定。有關更多詳細信息，請參閱 OpenShift 說明。

在 Kubernetes 上，我的 Telegraf ReplicaSet pod 會報告以下錯誤：[inputs.prometheus] 外掛程式錯誤：無法載入金鑰對 /etc/kubernetes/pki/etcd/server.crt：/etc/kubernetes/pki/etcd/server.key:開啟 /etc/k11/kubernetes/pki/etcd/server.key:開啟 /etc/k1/1/p1/F11572 目錄：

Telegraf ReplicaSet pod 旨在在指定為主節點或 etcd 的節點上運作。如果 ReplicaSet pod 沒有在其中一個節點上執行，您將會收到這些錯誤。檢查您的 master/etcd 節點是否有污點。如果確實如此，請在 Telegraf ReplicaSet、telegraf-rs 添加必要的容忍度。例如，編輯 ReplicaSet…​kubectl edit rs telegraf-rs…​並將適當的容忍度加入規範。然後，重新啟動 ReplicaSet pod。

我有一個 PSP/PSA 環境。這會影響我的監控操作員嗎？

如果您的 Kubernetes 叢集正在執行 Pod 安全性原則 (PSP) 或 Pod 安全存取 (PSA)，則必須升級至最新的 Kubernetes 監控操作員。請依照以下步驟升級至支援 PSP/PSA 的目前業者：1.解除安裝上一個監控操作員： kubectl delete agent agent-monitoring-netapp -n netapp-monitoring kubectl delete ns netapp-monitoring kubectl delete crd agents.monitoring.netapp.com kubectl delete clusterrole agent-manager-roeteing.netapp。 clusterrolebinding agent-manager-rolebinding agent-proxy-rolebinding agent-cluster-admin-rolebinding 2.安裝監控操作員的最新版本。

我在嘗試部署操作員時遇到了問題，並且我正在使用 PSP/PSA。

1.使用以下命令編輯代理程式：kubectl -n <name-space> edit agent 2。將“security-policy-enabled”標記為“false”。這將停用 Pod 安全性原則和 Pod 安全准入並允許操作員部署。使用以下命令確認：kubectl get psp（應該顯示 Pod 安全性策略已刪除）kubectl get all -n <namespace>

grep -i psp（應該顯示未找到任何內容）

出現“ImagePullBackoff”錯誤

如果您有自訂或私有的 docker 儲存庫，並且尚未配置 Kubernetes Monitoring Operator 以正確識別它，則可能會看到這些錯誤。閱讀更多關於自訂/私人 repo 的配置。

我的監控操作員部署出現了問題，目前文件無法幫助我解決該問題。

擷取或以其他方式記錄以下命令的輸出，並聯絡技術支援團隊。

 kubectl -n netapp-monitoring get all
 kubectl -n netapp-monitoring describe all
 kubectl -n netapp-monitoring logs <monitoring-operator-pod> --all-containers=true
 kubectl -n netapp-monitoring logs <telegraf-pod> --all-containers=true

Operator 命名空間中的 net-observer（工作負載圖）pod 處於 CrashLoopBackOff 狀態

這些 pod 對應於網路可觀測性的工作負載圖資料收集器。嘗試以下操作：• 檢查其中一個 pod 的日誌以確認最低核心版本。例如： ---- {“ci-tenant-id”：“your-tenant-id”，“collector-cluster”：“your-k8s-cluster-name”，“environment”：“prod”，“level”：“error”，“msg”：“驗證失敗。原因：核心版本 3.10.0 低於最低核心版本 4.18.0","time":"2022-11-09T08:23:08Z"} ---- • Net-observer pods 要求 Linux 核心版本至少為 4.18.0。使用命令“uname -r”檢查內核版本，並確保它們> = 4.18.0

Pod 在 Operator 命名空間（預設值：netapp-monitoring）中運行，但 UI 中未顯示工作負載圖或查詢中的 Kubernetes 指標的數據

檢查K8S叢集節點上的時間設定。為了準確的稽核和數據報告，強烈建議使用網路時間協定 (NTP) 或簡單網路時間協定 (SNTP) 同步代理機器上的時間。

Operator 命名空間中的部分 net-observer pod 處於 Pending 狀態

Net-observer是一個DaemonSet，在k8s叢集的每個Node中執行一個pod。 • 注意處於待處理狀態的 pod，並檢查它是否遇到 CPU 或記憶體資源問題。確保節點中具有所需的記憶體和 CPU。

安裝 Kubernetes Monitoring Operator 後，我立即在日誌中看到以下內容：[inputs.prometheus] 插件錯誤：向 http://kube-state-metrics.<namespace>.svc.cluster.local:8080/metrics 發出 HTTP 請求時出錯：獲取\http://kube-state-metrics.<namespace>.svc.cluster.local:8080/metrics：撥號 tcp：尋找 kube-state-metrics.<namespace>.svc.cluster.local：沒有這樣的主機

通常僅在安裝新操作員且 telegraf-rs pod 在 ksm pod 啟動之前啟動時才會看到此訊息。一旦所有 pod 都運行起來，這些訊息就會停止。

我確實沒有看到針對我的叢集中存在的 Kubernetes CronJobs 收集任何指標。

驗證你的 Kubernetes 版本（即 kubectl version）。如果是 v1.20.x 或更低版本，這是一個預期的限制。使用 Kubernetes Monitoring Operator 部署的 kube-state-metrics 版本僅支援 v1.CronJob。在 Kubernetes 1.20.x 及以下版本中，CronJob 資源位於 v1beta.CronJob。因此，kube-state-metrics 無法找到 CronJob 資源。

安裝操作員後，telegraf-ds pod 進入 CrashLoopBackOff，pod 日誌顯示「su: Authentication failed」。

編輯_AgentConfiguration_中的telegraf部分，並將_dockerMetricCollectionEnabled_設定為false。欲了解更多詳情，請參閱運營商的"配置選項"。 …​ 規格：…​ 電報：…​           - 名稱：docker 運作模式： - DaemonSet 取代： - 鍵：DOCKER_UNIX_SOCK_PLACEHOLDER 值：unix:///run/docker.sock …​ …

我在 Telegraf 日誌中看到類似以下內容的重複錯誤訊息：E！ [agent] 寫入輸出時發生錯誤。 http：發佈「\https://<tenant_url>/rest/v1/lake/ingest/influxdb」：超出上下文截止時間（等待標頭時超出 Client.Timeout）

編輯_AgentConfiguration_中的telegraf部分，並將_outputTimeout_增加到10秒。欲了解更多詳情，請參閱運營商的"配置選項"。

我缺少某些事件日誌的_involvedobject_資料。

確保您已按照"權限"上面的部分。

為什麼我看到兩個監控操作員 pod 正在運行，一個名為 netapp-ci-monitoring-operator-<pod>，另一個名為 monitoring-operator-<pod>？

自 2023 年 10 月 12 日起， Data Infrastructure Insights已重構了 Operator，以便更好地服務我們的用戶；為了完全採用這些更改，您必須刪除舊的操作員和安裝新的。

我的 kubernetes 事件意外停止向Data Infrastructure Insights回報。

檢索事件導出器 pod 的名稱：

`kubectl -n netapp-monitoring get pods

grep event-exporter

awk '{print $1}'

sed 's/event-exporter./event-exporter/'`
它應該是“netapp-ci-event-exporter”或“event-exporter”。接下來編輯監控代理 kubectl -n netapp-monitoring edit agent，並設定 LOG_FILE 的值以反映上一個步驟中找到的適當的事件導出器 pod 名稱。更具體地說，LOG_FILE 應該設定為“/var/log/containers/netapp-ci-event-exporter.log”或“/var/log/containers/event-exporter*.log”

…​.
fluent-bit:
…​
- name: event-exporter-ci
substitutions:
- key: LOG_FILE
values:
- /var/log/containers/netapp-ci-event-exporter*.log
…​
…​.
或者，也可以解除安裝和重新安裝代理人。

我看到 Kubernetes Monitoring Operator 部署的 pod 由於資源不足而崩潰。

參考 Kubernetes Monitoring Operator"配置選項"根據需要增加 CPU 和/或記憶體限制。

缺少影像或配置無效導致 netapp-ci-kube-state-metrics pod 無法啟動或準備就緒。現在 StatefulSet 卡住了，配置更改沒有應用到 netapp-ci-kube-state-metrics pod。

StatefulSet 位於"破碎的"狀態。修復所有配置問題後，反彈 netapp-ci-kube-state-metrics pod。

執行 Kubernetes Operator 升級後，netapp-ci-kube-state-metrics pod 無法啟動，拋出 ErrImagePull（無法拉取影像）。

嘗試手動重置 pod。

在日誌分析下，我的 Kubernetes 叢集中觀察到「事件因超過 maxEventAgeSeconds 而被丟棄」訊息。

修改 Operator agentconfiguration，將 event-exporter-maxEventAgeSeconds（即增加到 60s）、event-exporter-kubeQPS（即增加到 100）和 event-exporter-kubeBurst（即增加到 500）增加。有關這些配置選項的更多詳細信息，請參閱"配置選項"頁。

Telegraf 因可鎖定記憶體不足而發出警告或崩潰。

嘗試增加底層作業系統/節點中 Telegraf 可鎖定記憶體的限制。如果無法增加限制，請修改 NKMO 代理程式配置並將 unprotected 設為 true。這將指示 Telegraf 不要嘗試保留鎖定的記憶體頁面。雖然這可能會帶來安全風險，因為解密的秘密可能會被交換到磁碟，但它允許在無法保留鎖定記憶體的環境中執行。有關 unprotected 配置選項的更多詳細信息，請參閱"配置選項"頁。

我看到來自 Telegraf 的類似以下內容的警告訊息：W！ [inputs.diskio] 無法收集「vdc」的磁碟名稱：讀取 /dev/vdc 時發生錯誤：沒有此檔案或目錄

對於 Kubernetes 監控操作員來說，這些警告訊息是良性的，可以安全地忽略。  或者，編輯 AgentConfiguration 中的 telegraf 部分，並將 runDsPrivileged 設為 true。如欲了解更多詳情，請參閱"操作員的配置選項"。

我的 fluent-bit pod 出現以下錯誤：[2024/10/16 14:16:23] [錯誤] [/src/fluent-bit/plugins/in_tail/tail_fs_inotify.c:360 errno=24] 開啟的檔案太多 [2024/10/1tail. [2024/10/16 14:16:23] [錯誤] [引擎] 輸入初始化失敗

嘗試更改叢集中的 fsnotify 設定：

 sudo sysctl fs.inotify.max_user_instances (take note of setting)

 sudo sysctl fs.inotify.max_user_instances=<something larger than current setting>

 sudo sysctl fs.inotify.max_user_watches (take note of setting)

 sudo sysctl fs.inotify.max_user_watches=<something larger than current setting>

重新啟動 Fluent-bit。

注意：為了讓這些設定在節點重新啟動後仍然有效，您需要在 /etc/sysctl.conf 中新增以下幾行

 fs.inotify.max_user_instances=<something larger than current setting>
 fs.inotify.max_user_watches=<something larger than current setting>

telegraf DS pods 報告與 kubernetes 輸入外掛程式相關的錯誤，由於無法驗證 TLS 憑證而無法發出 HTTP 要求。例如：E！ [inputs.kubernetes] 外掛程式錯誤：向下列物件發出 HTTP 請求時發生錯誤"https://<kubelet_IP>:10250/stats/summary":得到"https://<kubelet_IP>:10250/stats/summary":tls：無法驗證證書：x509：無法驗證 <kubelet_IP> 的證書，因為它不包含任何 IP SAN

如果 kubelet 使用自簽名證書，和/或指定的證書未在證書_Subject Alternative Name_ 清單中包含 <kubelet_IP>，則會發生這種情況。為了解決這個問題，使用者可以修改"代理配置"，並將 telegraf:insecureK8sSkipVerify 設為 true。這將配置 telegraf 輸入插件以跳過驗證。或者，使用者可以設定 kubelet"伺服器TLSBootstrap" ，這將觸發來自「certificates.k8s.io」API 的憑證請求。

更多資訊可從"支援"頁面或在"數據收集器支援矩陣"。