Troubleshoot Kubernetes and container runtime compatibility 🔗

注釈

こちらも参照してください：

Kubernetes では、クラスター内の各ノードにコンテナランタイムをインストールし、そこでポッドを実行できるようにする必要があります。Splunk Distribution of the Collector for Kubernetes は、containerd、CRI-O、Docker、Mirantis Kubernetes Engine (旧 Docker Enterprise/UCP) などのコンテナランタイムをサポートしています。

バージョンや構成に互換性のないコンテナランタイムを使用している Kubernetes クラスターでは、次のような問題が発生する可能性があります：

コンテナ、ポッド、またはノードからの統計が存在しないか、不正な形式です。その結果、これらの統計を必要とするCollectorは、望ましい対応するメトリクスを生成しません。
コンテナ、ポッド、ノードが正常に起動しない、またはきれいに停止しません。
ノード上のkubeletプロセスが停止状態にあります。

特定の Kubernetes のバージョンとコンテナランタイムの互換性レベルは異なる可能性があるため、互換性があることが分かっている Kubernetes のバージョンとコンテナランタイムを使用してください。方法については以下を参照してください：コンテナランタイムの互換性のトラブルシューティング。

ランタイムの詳細については、コンテナランタイムを参照してください。

コンテナランタイムの互換性のトラブルシューティング 🔗

Kubernets とコンテナランタイムの互換性に問題があるかどうかを確認するには、以下の手順に従ってください：

kubectl get nodes -o wide を実行して、使用されている Kubernetes とコンテナランタイムのバージョンを確認します。

-o wide フラグを指定すると、追加情報を含むプレーンテキスト形式の出力が出力されます。ポッドの場合は、ノード名が含まれる。以下の例では、node-1 は Kubernetes 1.19.6 と containerd 1.4.1を使用しています：
kubectl get nodes -o wide
NAME         STATUS   VERSION   CONTAINER-RUNTIME
node-1       Ready    v1.19.6   containerd://1.4.1

Kubernetesのバージョンと互換性のあるコンテナランタイムを使用していることを確認します。コンテナランタイムの互換性については、以下のベンダーのドキュメントを参照してください：

containerd

CRI-O

Mirantis

コンテナ統計の完全性をチェックします。方法は、コンテナ統計の完全性をチェックするを参照してください。
Check that you have the right certificate.

#. In non production environments, try skipping the certificate verification with the following command: agent.config.receivers.kubeletstats.insecure_skip_verify=true.

コンテナ統計の完全性をチェックする 🔗

コンテナ、ポッド、およびノードの統計情報を確認するには、Kubelet Summary API を使用します。Kubelet は、/stats エンドポイントを通じて利用可能なノードごとの要約された統計情報を検出および取得するための Summary API を提供します。

以下の例では、CollectorがKubelet Stats Receiverメトリクスの生成に使用するCPU、メモリ、およびネットワークの統計情報が存在することを確認する方法を示します。これらのテクニックを拡張して、利用可能な他のKubernetes統計を評価することができます。

これらの例で示されている統計情報は、特に断りのない限りすべて存在するはずです。出力に統計値がない、または統計値が異なるフォーマットで表示される場合は、Kubernetesクラスターとコンテナランタイムが完全に互換していない可能性があります。

ノードの統計情報を確認する 🔗

ノードの統計情報を確認します：

以下のコマンドを実行してクラスター内のノード名を取得し、ノードの1つから生のリソース使用統計情報を取り出します：
```
kubectl get nodes -o wide
```
評価するノードを選び、その名前を環境変数に設定します。以下の例では、ノードの名前は node-1 です：
```
NODE_NAME=node-1
```

ノードが適切な統計情報を持っていることを確認します：

kubectl get --raw "/api/v1/nodes/"${NODE_NAME}"/proxy/stats/summary" | jq '{"node": {"name": .node.nodeName, "cpu": .node.cpu, "memory": .node.memory, "network": .node.network}} | del(.node.network.interfaces)'
{
  "node": {
    "name": "node-1",
    "cpu": {
      "time": "2022-05-20T18:12:08Z",
      "usageNanoCores": 149771849,
      "usageCoreNanoSeconds": 2962750554249399
    },
    "memory": {
      "time": "2022-05-20T18:12:08Z",
      "availableBytes": 2701385728,
      # Could be absent if node memory allocations were missing.
      "usageBytes": 3686178816,
      "workingSetBytes": 1421492224,
      "rssBytes": 634343424,
      "pageFaults": 18632526,
      "majorPageFaults": 726
    },
    "network": {
      "time": "2022-05-20T18:12:08Z",
      "name": "eth0",
      "rxBytes": 105517219156,
      "rxErrors": 0,
      "txBytes": 98151853779,
      "txErrors": 0
    }
  }
}

参考のため、次の表にノード統計名とCollectorメトリクス名の対応を示します：

ノード統計名	Collector のメトリクス名
`cpu.usageNanoCores`	`k8s.node.cpu.utilization`
`cpu.usageCoreNanoSeconds`	`k8s.node.cpu.time`
`memory.availableBytes`	`k8s.node.memory.available`
`memory.usageBytes`	`k8s.node.filesystem.usage`
`memory.workingSetBytes`	`k8s.node.memory.working_set`
`memory.rssBytes`	`k8s.node.memory.rss`
`memory.pageFaults`	`k8s.node.memory.page_faults`
`memory.majorPageFaults`	`k8s.node.memory.major_page_faults`
`network.rxBytes`	`k8s.node.network.io{direction="receive"}`
`network.rxErrors`	`k8s.node.network.errors{direction="receive"}`
`network.txBytes`	`k8s.node.network.io{direction="transmit"}`
`network.txErrors`	`k8s.node.network.error{direction="transmit"}`

ポッドの統計情報を確認する 🔗

注釈

このセクションを完了する前に、ノードの統計情報を確認するのステップ1と2を完了する必要があります。

ポッドの統計情報を確認する

以下のコマンドを実行して、選択したノードのポッド名を取得し、ポッドの1つから生のリソース使用統計を取り出します：
```
kubectl get --raw "/api/v1/nodes/"${NODE_NAME}"/proxy/stats/summary" | jq '.pods[].podRef.name'
```
評価するポッドを選択し、その名前を環境変数に設定します。以下の例では、ポッドの名前は splunk-otel-collector-agent-6llkr です：
```
POD_NAME=splunk-otel-collector-agent-6llkr
```

ポッドが適切な統計情報を持っていることを確認します：

kubectl get --raw "/api/v1/nodes/"${NODE_NAME}"/proxy/stats/summary" | jq '.pods[] | select(.podRef.name=='\"$POD_NAME\"') | {"pod": {"name": .podRef.name, "cpu": .cpu, "memory": .memory, "network": .network}} | del(.pod.network.interfaces)'
{
  "pod": {
    "name": "splunk-otel-collector-agent-6llkr",
    "cpu": {
      "time": "2022-05-20T18:38:47Z",
      "usageNanoCores": 10774467,
      "usageCoreNanoSeconds": 1709095026234
    },
    "memory": {
      "time": "2022-05-20T18:38:47Z",
      "availableBytes": 781959168,
      # Could be absent if pod memory limits were missing.
      "usageBytes": 267563008,
      "workingSetBytes": 266616832,
      "rssBytes": 257036288,
      "pageFaults": 0,
      "majorPageFaults": 0
    },
    "network": {
      "time": "2022-05-20T18:38:55Z",
      "name": "eth0",
      "rxBytes": 105523812442,
      "rxErrors": 0,
      "txBytes": 98159696431,
      "txErrors": 0
    }
  }
}

参考のため、次の表にPod stat名とCollectorメトリクス名のマッピングを示します：

ポッド統計名	Collector のメトリクス名
`pod.cpu.usageNanoCores`	`k8s.pod.cpu.utilization`
`pod.cpu.usageCoreNanoSeconds`	`k8s.pod.cpu.time`
`pod.memory.availableBytes`	`k8s.pod.memory.available`
`pod.memory.usageBytes`	`k8s.pod.filesystem.usage`
`pod.memory.workingSetBytes`	`k8s.pod.memory.working_set`
`pod.memory.rssBytes`	`k8s.pod.memory.rss`
`pod.memory.pageFaults`	`k8s.pod.memory.page_faults`
`pod.memory.majorPageFaults`	`k8s.pod.memory.major_page_faults`
`pod.network.rxBytes`	`k8s.pod.network.io{direction="receive"}` または `pod_network_receive_bytes_total`
`pod.network.rxErrors`	`k8s.pod.network.errors{direction="receive"}` または `pod_network_receive_errors_total`
`pod.network.txBytes`	`k8s.pod.network.io{direction="transmit"}` または `pod_network_transmit_bytes_total`
`pod.network.txErrors`	`k8s.pod.network.error{direction="transmit"}` または `pod_network_transmit_errors_total`

コンテナの統計情報を確認する 🔗

注釈

このセクションを完了する前に、ノードの統計情報を確認するとポッドの統計情報を確認するの両方でステップ1と2を実行してください。

コンテナの統計情報を確認します：

以下のコマンドを実行して、選択したポッド内のコンテナ名を取得し、コンテナの1つから生のリソース使用統計情報を取り出します：
```
kubectl get --raw "/api/v1/nodes/"${NODE_NAME}"/proxy/stats/summary" | jq '.pods[] | select(.podRef.name=='\"$POD_NAME\"') | .containers[].name'
```
評価するコンテナを選択し、その名前を環境変数に設定します。以下の例では、コンテナの名前は otel-collector です：
```
CONTAINER_NAME=otel-collector
```

コンテナが適切な統計情報を持っていることを確認します：

kubectl get --raw "/api/v1/nodes/"${NODE_NAME}"/proxy/stats/summary" | jq '.pods[] | select(.podRef.name=='\"$POD_NAME\"') | .containers[] | select(.name=='\"$CONTAINER_NAME\"') | {"container": {"name": .name, "cpu": .cpu, "memory": .memory}}'
{
  "container": {
    "name": "otel-collector",
    "cpu": {
      "time": "2022-05-20T18:42:15Z",
      "usageNanoCores": 6781417,
      "usageCoreNanoSeconds": 1087899649154
    },
    "memory": {
      "time": "2022-05-20T18:42:15Z",
      "availableBytes": 389480448,
      # Could be absent if container memory limits were missing.
      "usageBytes": 135753728,
      "workingSetBytes": 134807552,
      "rssBytes": 132923392,
      "pageFaults": 93390,
      "majorPageFaults": 0
    }
  }
}

参考のため、以下の表に、コンテナ統計名とCollectorメトリクス名のマッピングを示します：

コンテナ統計名	Collector のメトリクス名
`container.cpu.usageNanoCore`	`container.cpu.utilization`
`container.cpu.usageCoreNanoSeconds`	`container.cpu.time`
`container.memory.availableBytes`	`container.memory.available`
`container.memory.usageBytes`	`container.memory.usage`
`container.memory.workingSetBytes`	`container.memory.working_set`
`container.memory.rssBytes`	`container.memory.rss`
`container.memory.pageFaults`	`container.memory.page_faults`
`container.memory.majorPageFaults`	`container.memory.major_page_faults`

報告された互換性のないKubernetesとコンテナランタイムの問題 🔗

注釈

マネージドKubernetesサービスは、変更されたコンテナランタイムを使用している可能性があり、サービスプロバイダは、変更されていないコンテナランタイムには存在しないカスタムパッチやバグ修正を適用している可能性があります。

このセクションでは、既知の非互換性とコンテナランタイムの問題について説明します。

Kubernetes 1.21.0～1.21.11とcontainerd 🔗

Kubernetes 1.21.0 から 1.21.11 を containerd と一緒に使用すると、メモリとネットワークの統計またはメトリクスが欠落する可能性があります。以下は影響を受けるメトリクスのリストです：

k8s.pod.network.io{direction="receive"} または pod_network_receive_bytes_total
k8s.pod.network.errors{direction="receive"} または pod_network_receive_errors_total
k8s.pod.network.io{direction="transmit"} または pod_network_transmit_bytes_total
k8s.pod.network.error{direction="transmit"} または pod_network_transmit_errors_total
container.memory.available
container.memory.usage
container.memory.rssBytes
container.memory.page_faults
container.memory.major_page_faults

この問題を解決するには、次のいずれかの回避策をお試しください：

Kubernetesをバージョン1.21.12以上にアップグレードします。
containerdをバージョン1.4.xまたは1.5.xにアップグレードします。

Kubernetes 1.22.0～1.22.8とcontainerd 1.4.0～1.4.12 🔗

Kubernetes 1.22.0～1.22.8をcontainerd 1.4.0～1.4.12と共に使用すると、メモリとネットワークの統計またはメトリクスが欠落することがあります。以下は、影響を受けるメトリクスのリストです：

k8s.pod.network.io{direction="receive"} または pod_network_receive_bytes_total
k8s.pod.network.errors{direction="receive"} または pod_network_receive_errors_total
k8s.pod.network.io{direction="transmit"} または pod_network_transmit_bytes_total
k8s.pod.network.error{direction="transmit"} または pod_network_transmit_errors_total
k8s.pod.memory.available
container.memory.available
container.memory.usage
container.memory.rssBytes
container.memory.page_faults
container.memory.major_page_faults

この問題を解決するには、次のいずれかの回避策をお試しください：

Kubernetesを少なくともバージョン1.22.9にアップグレードして、コンテナのメモリとポッドのネットワークメトリクスの欠落を修正します。
containerdを少なくともバージョン1.4.13または1.5.0にアップグレードして、欠落しているポッドメモリメトリクスを修正します。

Kubernetes 1.23.0～1.23.6とcontainerd 🔗

Kubernetesのバージョン1.23.0～1.23.6をcontainerdで使用すると、メモリの統計やメトリクスが欠落することがあります。以下は影響を受けるメトリクスのリストです：

k8s.pod.memory.available

現時点では、この問題の回避策はありません。

This page was last updated on 2024年08月20日.

Related Topics