Helm チャートのトラブルシューティング

このガイドでは、Tenable Kubernetes Helm チャートのデプロイ中によく発生する一般的な問題について説明します。

ここから開始:

ターミナルでエラーが発生して helm install 終了した場合は、「 helm install fails」を参照してください。
コマンドが完了したがクラスタが欠落している、または間違ったアカウントで表示されている場合は、「 helm install succeeds but something is wrong」を参照してください。
デプロイが成功した後にポッドがクラッシュしている場合、または接続が切断された場合は、「デプロイ後にポッドが失敗する、または接続が切断される」を参照してください。

helm のインストールが失敗する

これらのエラーは helm install中に発生します。プレインストールフック (チャートのデプロイ中に実行される検証ジョブ) を完了できないか、指定されたアカウントの詳細が正しくないために、コマンドがターミナルで失敗します。

インストール前フックの失敗(プロキシ/ネットワークのブロック)

症状:helm install コマンドが失敗し、タイムアウトまたはフックが失敗したことを示すエラーが表示されます。

端末出力:

コピー

Error: UPGRADE FAILED: pre-upgrade hooks failed: 1 error occurred: job kubernetes-cluster-pre-install-job failed: BackoffLimitExceeded

診断: 失敗したジョブのログを調べて、原因を特定します。

注意: Pod 名には、ランダムなサフィックス (例: kubernetes-cluster-pre-install-job-vkknz) が付きます。

正確なポッド名を見つけます。
コピー
```
kubectl get pods -n <your-namespace>
```
ログを確認します。

コピー

kubectl logs job/kubernetes-cluster-pre-install-job-<suffix> -n <your-namespace>

ログエラーを探す:

コピー

System.Net.Http.HttpRequestException

原因: これは、ネットワークが詰まる可能性があることを示します。企業のプロキシ、ファイアウォール、ディープパケット検査ツールがTenableのバックエンド(app.tenable.com)への接続を傍受しているか、ポッドがプロキシ経由で内部Kubernetes APIトラフィックをルーティングしようとしています。

解決策

プロキシの設定values.yamlで、proxyUrlが正しく設定されていることを確認します。Helm のオプションのコマンドパラメーター (CLI) を参照してください。
設定NO_PROXY: Kubernetes API サーバードメイン (例: kubernetes.default.svc) を含めるように NO_PROXY 環境変数を設定する必要があります。これがない場合、ジョブはプロキシを介してローカル API へのアクセスを試みますが、失敗します。

注意: NO_PROXY設定していない場合、インストール前ジョブは内部 Kubernetes API トラフィックを企業プロキシ経由でルーティングし、失敗します。これは、プロキシ環境におけるフック障害の最も一般的な原因です。

コピー

JSON

"containerEnvironmentVariables": [
  {
    "name": "NO_PROXY",
    "value": "kubernetes.default.svc,10.0.0.0/8,.svc.cluster.local"
  }
]

イメージプルの失敗(403 Forbidden)

症状:helm installがハングするか、ポッドがステータスImagePullBackOffまたはErrImagePullで失敗します。

イベント出力: Failed to pull image... 403 Forbidden

原因:

ファイアウォール: 企業のファイアウォールがパブリックレジストリ containers.tenable.comへのアクセスをブロックしています。
キャッシング: Helm クライアントが、サポートされている最新バージョンではなく、古いチャートバージョン (1.1.2 など) をローカルキャッシュから抽出しようとしています。

解決策

リポジトリの更新:helm repo update tenableを実行して、クライアントに最新のタグを強制的にフェッチさせます。
テスト接続: クラスター内のノードまたはポッドから wget または curl -v https://containers.tenable.com を実行して、到達可能性を確認します。
プライベートレジストリ: クラスタがエアギャップされている場合は、イメージをプライベートレジストリにミラーリングし、values.yamlのregistry、registryUsername、registryPassword値を更新します。プライベートプライベートレジストリを持つクラスタを参照してください。

アカウント検証の失敗 (TenantNotExist)

症状:helm installはBackoffLimitExceededで失敗しますが、ジョブログはネットワーク例外ではなく論理エラーを明らかにします。

ログエラー:

コピー

Failure { ... httpResponseMessageContent="TenantNotExist" ... }

原因: Helm コマンドで指定された accountId が正しくないか、インストールを実行する前にターゲットのクラウドアカウントが Tenable One Cloud Exposure にオンボーディング (接続) されていません。

解決策

オンボーディングファースト クラウドアカウント (AWS/Azure/GCP) が Tenable コンソールで完全に接続されていることを確認します。
ID の検証: オンプレミスクラスタにインストールする場合は、[Kubernetes クラスタ (エージェント)] ウィザードでアカウント ID を検証し、明示的に渡します。 --set accountId=<ID>。

helm のインストールは成功するが、何か問題がある

これらのエラーは、 helm install が正常に完了した後に表示されます。クラスタが間違ったアカウント範囲に関連付けられているか、リソースがダッシュボードに入力されていません。

間違ったアカウントに関連付けられたクラスタ

症状: Helm チャートは正常にインストールされますが、クラスタは特定のクラウドアカウント範囲 (AWS/Azure など) ではなく、 オンプレミスのデフォルトアカウント の下に表示されます。

原因: Tenable がクラウドプロバイダーを自動的に検出します。Helm をインストールする前にクラウドアカウントが Tenable と統合されていない場合、システムはデフォルトでオンプレミスの範囲になります。「クラスタアカウントの場所を参照してください。

解決策: アカウント間でライブクラスタを移動することはできません。再インストールが必要です。

helm uninstall tenable-cloud-security-kubernetes-cluster -n <namespace>を実行してください。
クラウドアカウントが Tenable ユーザーインターフェースで接続されていることを確認します。
helm installを再実行してください。

リソース同期のハングアップ

症状: インストールは成功しますが、ダッシュボードにリソースは表示されません。ログに「リージョンのクエリに失敗しました」と表示される場合があります。

原因: ターゲットテナントまたはアカウントが Tenable バックエンドで無効になっているため、リージョンのクエリができません。

解決策: Tenable プラットフォーム設定でアカウントステータスを確認し、テナントが有効になっていることを確認します。

デプロイ後にポッドが失敗する、または接続が切断される

これらの問題は、インストールコマンドが成功した後に発生します。Helm が「デプロイ済み」と報告されていても、コンポーネントが接続に失敗したり、クラッシュしたりする可能性があります。

コネクタ Pod のエラーとリバーストンネルの障害

症状: Tenable コンソールの状態が [接続失敗] です。

診断: Helm が成功した場合でも、コネクタポッドが実行されていることを確認し、そのログを確認してください。

ステータスの確認:

コピー

kubectl get pods -l app.kubernetes.io/name=kubernetes-cluster-connector -n <namespace>

ログのチェック

コピー

kubectl logs -l app.kubernetes.io/name=kubernetes-cluster-connector -n <namespace>

特定のチェック (トンネル): ポッドがトンネルエンドポイントに到達できないことを示すエラー (例: us1-tunnel.internal.app.tenable.com や connect to server error) を探します。コネクタには、API (app.tenable.com) と専用トンネルエンドポイントの両方にアクセスする必要があります。

原因:

ゾンビトンネル: バックエンドは、Kubernetes API へのリバーストンネルを確立できませんでした。
Duplicate Install: コネクタの 2 つの同時インストール (たとえば異なる名前空間) により、競合が発生しています。

解決策

ポッドを再起動: コネクタポッドを削除して強制的に再起動し、トンネルハンドシェイクを再開します。

コピー

kubectl delete pod -l app.kubernetes.io/name=kubernetes-cluster-connector -n <namespace>

注意: 通常これにより、同期ステータスがすぐに解決されます。

複数のインストールのチェック: 次のコマンドを使用して、異なる名前空間に同一のデプロイがないかチェックします。

コピー

kubectl get pod -l app.kubernetes.io/name=kubernetes-cluster-connector -A

センサーのアクセス許可拒否 (PSS)

症状: センサーポッド (DaemonSet) が起動に失敗する、クラッシュする、またはログにアクセス許可エラーが表示される。

原因: センサーには、ノードをスキャンするために特権アクセス (hostPID: true、 privileged: true、 hostPath マウント) が必要です。クラスタの Pod Security Standards (PSS) がこれらのアクセス許可をブロックしています。

解決策: 制限ポリシーから Tenable 名前空間を除外します。

コピー

kubectl label namespace <namespace> pod-security.kubernetes.io/enforce=privileged

注意: コネクタ (リソース同期) とアドミッションコントローラーは、特権ステータスを必要としません。センサーのみが知ることができます。

循環的再起動 (オンプレミス)

症状: オンプレミスクラスタ内のノードは、センサーのインストール後に再起動ループに入ります。

原因: Tenable センサー (eBPF プローブ) と特定の OS/カーネルバージョン間の非互換性。

解決策: センサーを直ちに無効にし、カーネルログを Tenable サポートに連絡してください。

コピー

helm upgrade tenable-cloud-security-kubernetes-cluster tenable/tenable-cloud-security-kubernetes-cluster --set sensor.enabled=false