Confluent Operator のトラブルシューティング¶
以降のセクションでは、Confluent Platform デプロイのトラブルシューティングについて説明します。
メトリクス¶
- JMX メトリクスは、各ポッドのポート 7203 で使用できます。
- Jolokia(JMX メトリクス用の REST インターフェイス)は、各ポッドのポート 7777 で使用できます。
デバッグ¶
Operator の使用中に起こりうる問題には以下の 2 種類があります。
- インフラストラクチャレベルに存在する問題。Kubernetes レイヤーで何か問題が発生したという意味です。
- アプリケーションレベルに存在する問題。インフラストラクチャに問題はないが、Confluent Platform そのものに問題が発生したという意味です。通常は構成が原因です。
まず、Kubernetes の障害 を探してください。
以下のコマンドを入力して、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 の構成など、データセンターインフラストラクチャに起因する問題については、インフラストラクチャのシステム管理者にトラブルシューティングを依頼してください。
デプロイのテスト¶
以下のセクションの説明に従って、デプロイをテストおよび検証します。
内部アクセスの検証¶
内部通信を検証するには、以下の手順に従います。
ローカルマシンで以下のコマンドを入力して、クラスターの名前空間情報を表示します(例として名前空間 operator を使用)。この情報には、内部通信の検証に必要なブートストラップエンドポイントが含まれています。
kubectl get kafka -n operator -oyaml
ブートストラップエンドポイントは
bootstrap.servers
の行に示されます。... omitted internalClient: |- bootstrap.servers=kafka:9071
ローカルマシンで kubectl exec を使用して、クラスター内のポッドのいずれかで bash セッションを開始します。この例では、デフォルト名
kafka-0
のポッドを、デフォルト名kafka
の Kafka クラスターで使用します。kubectl -n operator exec -it kafka-0 bash
ポッドで、
kafka.properties
という名前のファイルを作成し、内容を入力します。コンテナーにはテキストエディターがインストールされていないので、このファイルの作成には以下の例に示すように cat コマンドを使用します。ファイルを保存するには、Ctrl + D
キーを押します。注釈
この例には、デフォルトの SASL/PLAIN セキュリティパラメーターが示されています。本稼働環境では、追加のセキュリティが必要です。詳細については、「Confluent Operator でのセキュリティの構成」を参照してください。
cat << EOF > kafka.properties bootstrap.servers=kafka:9071 sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="test" password="test123"; sasl.mechanism=PLAIN security.protocol=SASL_PLAINTEXT EOF
ポッドで、以下のコマンドを使用してブートストラップサーバーへのクエリを実行します。
kafka-broker-api-versions --command-config kafka.properties --bootstrap-server kafka:9071
3 つの Kafka ブローカーそれぞれにつき、以下のような出力が表示されます。
kafka-1.kafka.operator.svc.cluster.local:9071 (id: 1 rack: 0) -> ( Produce(0): 0 to 7 [usable: 7], Fetch(1): 0 to 10 [usable: 10], ListOffsets(2): 0 to 4 [usable: 4], Metadata(3): 0 to 7 [usable: 7], LeaderAndIsr(4): 0 to 1 [usable: 1], StopReplica(5): 0 [usable: 0], UpdateMetadata(6): 0 to 4 [usable: 4], ControlledShutdown(7): 0 to 1 [usable: 1], OffsetCommit(8): 0 to 6 [usable: 6], OffsetFetch(9): 0 to 5 [usable: 5], FindCoordinator(10): 0 to 2 [usable: 2], JoinGroup(11): 0 to 3 [usable: 3], Heartbeat(12): 0 to 2 [usable: 2], ... omitted
この出力をもって、クラスター内での内部通信の検証となります。
外部アクセスの検証¶
「Kafka への外部アクセス」の説明に従って、Kafka への外部アクセスと追加した DNS エントリを有効にしたら、外部通信を検証するために以下の手順に従います。
注釈
この例では、デフォルトの Confluent Platform コンポーネント名とデフォルトの Kafka ブートストラッププレフィックス kafka
が使用されます。
ローカルマシンで、 Confluent Platform をダウンロード します。Confluent CLI は、ダウンロードして
PATH
と必要な環境変数を設定するだけで使用できます。ローカルマシンで Confluent Platform を起動する必要はありません。外部通信の検証には、ローカルマシンで実行されている Confluent CLI を使用します。Confluent CLI は Confluent Platform に含まれています。
ローカルマシンで、外部クライアント用のブートストラップサーバーエンドポイントを取得するためのコマンドを実行します。
kubectl get kafka -n operator -oyaml
以下の出力例で、ブートストラップサーバーエンドポイントは
kafka.mydomain:9092
です。... omitted externalClient: |- bootstrap.servers=kafka.mydomain:9092 sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="test" password="test123"; sasl.mechanism=PLAIN security.protocol=SASL_PLAINTEXT
Confluent Platform がローカル実行されているローカルマシンで、
kafka.properties
という名前のファイルを作成し、以下の内容を入力します。上記の手順で取得した外部エンドポイントをbootstrap.servers
に割り当てます。bootstrap.servers=<kafka bootstrap endpoint> sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="test" password="test123"; sasl.mechanism=PLAIN security.protocol=SASL_PLAINTEXT
注釈
この例には、デフォルトの SASL/PLAIN セキュリティパラメーターが示されています。本稼働環境では、追加のセキュリティが必要です。詳細については、「Confluent Operator でのセキュリティの構成」を参照してください。
ローカルマシンで、ブートストラップエンドポイント
<kafka bootstrap endpoint>
を使用してトピックを作成します。以下の例では、パーティションが 1 つ、レプリカが 3 つのトピックが作成されます。kafka-topics --bootstrap-server <kafka bootstrap endpoint> \ --command-config kafka.properties \ --create --replication-factor 3 \ --partitions 1 --topic example
ローカルマシンで、ブートストラップエンドポイント
<kafka bootstrap endpoint>
を使用して新しいトピックを生成します。これ 1 つですべての Kafka ブローカーにゲートウェイアクセスが提供されることから、ブートストラップサーバーエンドポイントは必要な唯一の Kafka ブローカーエンドポイントであることにご注意ください。seq 10000 | kafka-console-producer \ --topic example --broker-list <kafka bootstrap endpoint> \ --producer.config kafka.properties
ローカルマシンの 別のターミナル で、
kafka.properties
を作成したディレクトリから、Confluent CLI コマンドを発行して新しいトピックを消費します。kafka-console-consumer --from-beginning \ --topic example --bootstrap-server <kafka bootstrap endpoint> \ --consumer.config kafka.properties
これらの手順が正常に完了したことをもって、クラスターとの外部通信の検証となります。