Confluent for Kubernetes のトラブルシューティング¶

このトピックでは、Confluent Platform デプロイのトラブルシューティングや使用可能なツールに関する一般的な情報を紹介します。また、遭遇する可能性のあるいくつかの問題とそのトラブルシューティング方法について説明します。

サポートバンドル¶

サポートバンドルを作成すると、デバッグに必要なすべての情報を Confluent に提供することができます。

注釈

CFK サポートバンドルは、Windows についてはサポートされていません。

イベント、Kubernetes のバージョン、ログ、Confluent API のステータスなどの情報は、ユーザーが Confluent サポートサイトにアップロードできるよう、Confluent for Kubernetes （CFK）によって自動的に tar.gz ファイルに集約されます。

サポートバンドルには、以下の情報が収集されています。

Kubernetes クラスター（最上位ディレクトリ）の場合:
- Kubernetes イベント（kubectl get events）
- Kubernetes サーバーバージョン（kubectl version）
For each Confluent Platform component (in the /clusters/component directory):
- CFK によってコンポーネント用に生成された構成マップ
- コンポーネントサービス内の各ポッドのポッドログ（kubectl logs <pod-name>）
- コンポーネントのカスタムリソースオブジェクト（kubectl get <component_cr_type> <component_name>）
- CFK によってコンポーネント用に生成された StatefulSet オブジェクト（kubectl get sts <component-sts-name>）
For the Confluent for Kubernetes Operator deployment (in the /clusters/component/operator directory):
- CFK Operator ポッドログ（kubectl logs confluent-operator）
- CFK Operator 用に生成されたデプロイオブジェクト（kubectl get deployment confluent-operator -oyaml）

サポートバンドルを作成するには、Confluent プラグインを使用して、次のコマンドを実行します。

kubectl confluent support-bundle --namespace <namespace>

サポートバンドルのカスタマイズに使用できる他のフラグを表示するには、以下を実行します。

kubectl confluent support-bundle -h

サポートバンドルのサンプルについては、「付録: サポートバンドルの内容のサンプル」を参照してください。

ログ¶

ログはポッドごとに STDOUT へ直接送られます。ポッドのログを表示するには、以下のコマンドを使用します。

kubectl logs <pod-name> -n <namespace>

さらに、コンポーネントのカスタムリソースで、構成のオーバーライド機能を使用してログレベルを DEBUG に変更できます。たとえば、以下を Kafka の CR に追加して、Kafka のログにさらに詳細を追加できます。

spec:
  configOverrides:
    log4j:
      - log4j.rootLogger=DEBUG, stdout

メトリクス¶

JMX メトリクスは、各ポッドのポート 7203 で使用できます。
Jolokia（JMX メトリクス用の REST インターフェイス）は、各ポッドのポート 7777 で使用できます。

デバッグ¶

Confluent for Kubernetes （CFK）の使用中に起こりうる問題には、いくつかの種類があります。

CFK のデプロイ中に発生する問題。
インフラストラクチャレベルに存在する問題。

Kubernetes レイヤーで何か問題が発生したという意味です。
アプリケーションレベルに存在する問題。

インフラストラクチャに問題はないものの、Confluent Platform 自体に何か問題が発生しています。通常、Confluent Platform コンポーネントの構成方法が原因で起こります。

デプロイの問題をデバッグするには、Helm のインストールコマンドを実行する際に --set debug="true" を指定して冗長出力を有効にします。

helm upgrade --install confluent-operator \
  confluentinc/confluent-for-kubernetes \
  --namespace <namespace> \
  --set debug="true"

まず Kubernetes の問題を探してから Confluent Platform をデバッグしてください。

以下のコマンドを入力して、Kubernetes エラーの可能性を確認します。
```
kubectl get events -n <namespace>
```
以下のコマンドを入力して（リソースタイプの例として pods を使用）、特定のリソースの問題を確認します。
```
kubectl describe pods <podname> -n <namespace>
```
上記のコマンドを実行したが何も問題がなさそうだった場合は、以下のコマンドを使用してポッドごとにログをチェックします。
```
kubectl logs <pod name> -n <namespace>
```
Confluent Platform コンテナーは、アプリケーションログが STDOUT に出力されるように構成されています。ログは、以下のコマンドで直接読むことができます。無効な構成など、アプリケーションレベルで何か問題があった場合は、ログではっきりわかります。

注釈

クラッシュを理由にポッドが置き換えられている状態で、以前のポッドのログを確認するには、上記のコマンドの末尾に --previous を追加します。

仮想マシン（VM）のファイアウォールルールや DNS の構成など、データセンターインフラストラクチャに起因する問題については、インフラストラクチャのシステム管理者にトラブルシューティングを依頼してください。

既知の問題のトラブルシューティング¶

このセクションでは、Confluent Platform のデプロイ中に遭遇する可能性のあるいくつかの潜在的な問題を取り上げ、その問題のトラブルシューティング手順について説明します。

注: このセクションの例では、「CFK の名前空間の作成」で設定したデフォルトの名前空間を想定しています。

問題: Confluent Control Center で、自動生成された MDS または Confluent Cloud Schema Registry の証明書を使用できない¶

TLS が有効で、Confluent Control Center が MDS または Confluent Cloud Schema Registry との通信に別の TLS 証明書を使用している場合、Control Center は MDS または Confluent Cloud Schema Registry との接続に自動生成された TLS 証明書を使用することができません。

解決策: MDS または Confluent Cloud Schema Registry への Confluent Control Center トラフィックを暗号化するには、次のようにしてカスタムの TLS 証明書を指定します。

Confluent Cloud Schema Registry または MDS を信頼するために、ルート CA を含むカスタムトラストストアを Confluent Control Center の TLS シークレットに追加します。
Confluent Control Center のカスタムリソース（CR）で、上記のシークレット名を次のように使用します。
```
spec:
  dependencies:
    mds:
      tls:
        secretRef: <custom Root CA>
```
Confluent Control Center のカスタムリソースで、次のようにして自動生成された証明書を無効にし、RootCA を指定します。
```
spec:
  tls:
    autoGeneratedCerts: false
    secretRef: <custom Root CA>
```
Confluent Control Center をデプロイまたは再デプロイします。

問題: ksqlDB で、自動生成された Confluent Cloud の証明書を使用できない¶

ksqlDB が Confluent Cloud と通信する場合、ksqlDB は自動生成された TLS 証明書を使用できません。

解決策: Confluent Cloud への ksqlDB トラフィックを暗号化するには、次のようにしてカスタムの TLS 証明書を指定します。

Let's Encrypt ルート CA を含むカスタムトラストストアを指定します。
ksqlDB のカスタムリソースで、次のようにして自動生成された証明書を無効にし、RootCA を指定します。
```
spec:
  tls:
    autoGeneratedCerts: false
    secretRef: <custom Root CA>
```
ksqlDB をデプロイまたは再デプロイします。

問題: レプリケーション係数が一致しないため Schema Registry の実行がエラーになる¶

Confluent for Kubernetes によりデプロイされた Schema Registry は、内部トピックにデフォルトのレプリケーション係数 3 を使用します。Schema Registry と Kafka を同時にデプロイしていて、Kafka ブローカーが完全には起動していない場合、Schema Registry はレプリケーション係数が 3 より少ないトピックを作成するため、その後の Schema Registry の起動がエラーにより失敗します。

たとえば、Kafka で 1 つのブローカーが動作していて、Schema Registry が起動しようとすると、レプリケーション係数が 1 のトピックが作成されます。その後、3 つすべてのブローカーが起動すると、Schema Registry はレプリケーション係数が 1 のみで作成されたトピックがあることを表示して起動が失敗します。

解決策: Schema Registry のデプロイを削除し、Kafka が完全に起動した後で再度デプロイします。または、トピックを再度構成して、Schema Registry のデフォルトのレプリケーション係数 3 に一致させます。

問題: Confluent Platform 6.2.x をデプロイするときに、コンテナープロセスとディレクトリ権限でエラーが発生する¶

CFK を使用して ZooKeeper と他の Confluent Platform 6.2.x コンポーネントを起動すると、権限エラーが発生することがあります。以下に例を示します。

Error: failed to start container "zookeeper": Error response from daemon: OCI
runtime create failed: container_linux.go:367: starting container process
caused: chdir to cwd ("/home/appuser") set in config.json failed: permission
denied: unknown

Confluent Platform 6.2.x は、ベースディレクトリ /home/appuser を使用して、デフォルトユーザー appuser を 1000 にマッピングするよう構成します。

解決策: ポッドセキュリティコンテキストを新しい Confluent Platform 構成と一致するよう設定します。

すべての Confluent Platform コンポーネントのカスタムリソース（CR）で、podSecurityContext の構成を次のように変更します。
```
spec:
  podTemplate:
    podSecurityContext:
      fsGroup: 1000
      runAsUser: 1000
      runAsNonRoot: true
```
各コンポーネントの CR の変更を適用します。
```
kubectl apply -f <component CR>
```

問題: Kubernetes リソースを削除できない¶

たとえば、他のリソースより前に CFK ポッドが削除されたり、CFK がリソースを削除できなかったり、名前空間が終了ステートだったりした場合には、Kubernetes リソースを削除することができません。

解決策: 次のコマンドを使用してファイナライザーを削除します。

kubectl get <resource> --no-headers | \
  awk '{print $1 }' | \
  xargs kubectl patch <resource> -p '{"metadata":{"finalizers":[]}}' \
  --type=merge

問題: ConfluentRoleBindings が DELETING で停止する¶

ConfluentRoleBindings カスタムリソース（CR）は、関連付けられた Kafka クラスターが削除された場合に、DELETING ステートで停止する可能性があります。

解決策: 以下の例に従って、ConfluentRoleBindings CR のファイナライザーを手動で削除します。

次のコマンドで、ConfluentRoleBindings カスタムリソースのステータスを確認します。

kubectl get cfrb

出力には次のように、DELETING ステータスが表示されます。

NAME                         STATUS     KAFKACLUSTERID           PRINCIPAL        ROLE
c3-connect-operator-7gffem   DELETING   8itASw0_S6qDfdl72b7Uyg   User:c3          SystemAdmin
c3-ksql-operator-7gffem      DELETING   8itASw0_S6qDfdl72b7Uyg   User:c3          ResourceOwner
c3-operator-7gffem           DELETING   8itASw0_S6qDfdl72b7Uyg   User:c3          ClusterAdmin
c3-sr-operator-7gffem        DELETING   8itASw0_S6qDfdl72b7Uyg   User:c3          SystemAdmin
connect-operator-7gffem-0    DELETING   8itASw0_S6qDfdl72b7Uyg   User:connect     SystemAdmin
connect-operator-7gffem-1    DELETING   8itASw0_S6qDfdl72b7Uyg   User:connect     SystemAdmin
internal-connect-0           DELETING   8itASw0_S6qDfdl72b7Uyg   User:connect     SecurityAdmin
internal-connect-1           DELETING   8itASw0_S6qDfdl72b7Uyg   User:connect     ResourceOwner
internal-connect-2           DELETING   8itASw0_S6qDfdl72b7Uyg   User:connect     DeveloperWrite

次のコマンドで、各 ConfluentRoleBindings CR のファイナライザーを削除します。

for rb in $(kubectl get cfrb --no-headers | grep "DELETING" | awk '{print $1}'); \
  do kubectl patch cfrb $rb -p '{"metadata":{"finalizers":[]}}' \
  --type=merge; \
  done

たとえば、名前空間が終了ステートで停止したためすべての ConfluentRoleBindings を削除する必要があるなどの理由で、ステータスにかかわらず名前空間内のすべての ConfluentRoleBindings CR のファイナライザーを削除する場合は、次のコマンドを実行します。
```
for rb in $(kubectl get cfrb --no-headers -ojsonpath='{.items[*].metadata.name}'); \
  do kubectl patch cfrb $rb -p '{"metadata":{"finalizers":[]}}' \
  --type=merge; \
  done
```

問題: KafkaTopic が DELETING/DELETE_REQUESTED ステートで停止する¶

Kafka トピックを削除するときは（kubectl delete kafkatopic <topic-name>）、Kubernetes のファイナライザー機能を使用して対象の Kafka クラスターからトピックを削除します。ネットワークの問題や Kafka クラスターが使用できない（削除されている）などの理由により、ファイナライザーによる削除が失敗した場合、kubectl delete コマンドが停止します。

解決策: トピックのリソースを削除するために、以下のコマンドを使用して kafkatopic にパッチを適用します。

kubectl patch kafkatopic <topic-name> -p '{"metadata":{"finalizers":[]}}' \
  --type=merge

Confluent Platform コンポーネントポッドの削除¶

Confluent Platform コンポーネントポッドを手動で削除するには、各コンポーネントについて次のコマンドを実行します。

警告

これによりコンポーネントが完全にダウンします。データが失われるため、Kafka ポッドを削除する場合は慎重に行ってください。

kubectl delete pod -l platform.confluent.io/type=<cr-type>

<cr-type> には、kafka、zookeeper、schemaregistry、ksqldb、connect、controlcenter のいずれかを指定します。

ポッドが既に "crashloopback" ステートの場合、CFK はポッドが実行ステートに戻るまで変更内容を適用しません。この場合は、上記のコマンドに --force --grace-period=0 を使用します。

Kubernetes オブジェクトのリコンサイルのブロック¶

CFK には複数のコントローラーがあります。すべてのオブジェクトに対して、環境の実際の状態（クラスターのステートと、Kubelet の実行中コンテナーやクラウドプロバイダーのロードバランサーといった潜在的な外部状態の両方）がオブジェクトで必要とするステートと一致することを保証するのがコントローラーの役割です。このプロセスをリコンサイルと呼びます。

解決策:

リコンサイルをブロックするには（アップグレードする際に必要になることがあります）、次のコマンドを使用してアノテーションを追加します。
```
kubectl annotate <cr-type> <cluster_name> platform.confluent.io/block-reconcile=true
```
<cr-type> には、kafka、zookeeper、schemaregistry、ksqldb、connect、controlcenter のいずれかを指定します。
リコンサイルのブロックを停止するには、このアノテーションを削除します。削除しない場合、CustomResource への以降の変更は無視されます。
```
kubectl annotate <cr-type> <cluster_name> platform.confluent.io/block-reconcile-
```
リコンサイルを強制的に開始するには、次のアノテーションを追加します。
```
kubectl annotate <cluster-type> <cluster_name> platform.confluent.io/force-reconcile=true
```
リコンサイルを開始後、このアノテーションは自動的に無効になります。このコマンドは、自動生成された証明書の有効期限が切れて、新しい証明書を作成するよう CFK に通知する必要がある場合に役立ちます。

警告: Operation cannot be fulfilled, object has been modified¶

CFK が自動的に処理をやり直して変更を適用するため、次の 警告 は無視できます。

Operation cannot be fulfilled xxxx, the object has been modified please apply
your changes to the latest version and try again.

解決策: 多くの場合、これによる影響はなく、表示されなくなります。同じ種類の 警告 が繰り返される場合は、調査のためにサポートチケットを作成してください。

Issue: I have a StorageClass that does not have the reclaimPolicy set to retain¶

The StorageClass(SC) of the PersistentVolume that CFK uses must be configured with reclaimPolicy: Retain. If the StorageClass and its PersistentVolumes have been already created, the StorageClass cannot be changed. In this case, you have to patch the PersistentVolume as shown below.