Flink Kubernetes Operatorクイズ
Operator 1.15.0 / Flink 2.2.1のインストール、状態の復旧、自動スケーリングを確認します。
- DeploymentとSessionJobはどのように異なりますか？
回答を表示
回答: DeploymentはApplication/Sessionクラスターを定義し、SessionJobは既存の管理対象Sessionクラスター上のジョブを定義します。
解説: SessionJobを別に管理しても、共有クラスターのリソースや障害が分離されるわけではありません。
- Kubernetes 1.21以降という過去の最小要件だけで、現在のEKSデプロイを検証できますか？
回答を表示
回答: いいえ。現在のEKSサポート、クライアントのバージョンスキュー、Operator/webhook/CRDの互換性を確認してください。
解説: Namespaceラベル機能の導入時期だけでは、サポート状況や機能の検証に必要な条件をすべて確認できません。
- blue/green CRを使えば、重複なしでKafka/S3への書き込みが自動的に切り替わりますか？
回答を表示
回答: いいえ。コンシューマーグループ、トランザクションID、シンクの出力、状態の互換性をそれぞれ設計してください。
解説: 子デプロイメント間の切り替えを管理することと、エンドツーエンドのデータ保証は別です。移行には追加の切り替え容量が必要です。
- Savepointを使ったアップグレードは、常に最も安全で時間がかかり、システム全体を停止する方式ですか？
回答を表示
回答: 一律の優劣はありません。所要時間、復元可能性、フォールバック方法は、ジョブと状態の変更内容によって異なります。
解説: スナップショットを作成しただけでは、シリアライザー、UID、コネクターとの互換性は証明されません。
- 不健全なジョブをlast-stateで復旧するには何が必要ですか？
回答を表示
回答: アクセス可能なHAメタデータ/チェックポイント、互換性のある状態、認証情報、ストレージが必要です。
解説: 新しいsavepointを作らずに復旧できる場合がありますが、メタデータの喪失や古いチェックポイントの問題が自動的に解決されるわけではありません。
- SessionJobのYAMLでlast-stateを設定すれば、ステートフルなアップグレードの準備は完了しますか？
回答を表示
回答: いいえ。実際に適用されるSession/ジョブ設定で、チェックポイント、ストレージ、復旧の前提条件を整える必要があります。
解説: モードを表す文字列だけでなく、バリデーターと復元経路を確認してください。
- Flinkオートスケーラーが主にスケーリングする対象は何ですか？
回答を表示
回答: ジョブグラフ内の各頂点の並列度です。
解説: これはHPAによるレプリカ数のスケーリングとは異なります。実際のPod数やノード数は、スロットの割り当てやリソース管理レイヤーによって決まります。
- 下流の目標レートは、現在の上流出力レートの合計だけで決まりますか？
回答を表示
回答: 上流の目標レートにエッジの出力比率を掛けた値を組み合わせ、バックログ処理の目標も伝播させます。
解説: 出力の選択率と、将来必要になる容量も関係します。
- オートスケーラーはCPU/メモリのシグナルをすべて無視しますか？
回答を表示
回答: 主な並列度モデルではレートとビジー時間を使いますが、メモリ/GCの負荷、クォータ、任意のメモリ調整機能もあります。
解説: メモリ調整のデフォルトはfalseです。この方式はCPUを基準にするHPAとは異なります。
- Flinkの並列度は、常に最大並列度を割り切れる値にする必要がありますか？
回答を表示
回答: いいえ。キーグループやパーティションを均等にするためのオートスケーラーの調整設定と、Flinkが許可する範囲は異なります。
解説: 調整モード、キー付き入力、ソースのパーティション数を確認してください。既存状態がある場合、最大並列度の変更には互換性の確認が必要です。
- オートスケーラーによるスケール変更は、すべてlast-stateを使う完全なアップグレードですか？
回答を表示
回答: いいえ。可能な場合は、インプレースのリソース要件APIを使用します。条件によっては再デプロイが必要です。
解説: インプレースでスケールできても、タスクの再起動や状態復旧のコストが発生しないとは限りません。
- これらの例で最新の2.3.0ではなくFlink 2.2.1を使うのはなぜですか？
回答を表示
回答: 公開されているOperator/コネクターの互換性表とあわせて確認した、統合時の基準バージョンに固定するためです。
解説: CRDの列挙値として新しいバージョンが受け入れられても、実行時の互換性が証明されたことにはなりません。
- Chartのログ設定があれば、reporter JARと収集サーバーがインストール済みだと証明できますか？
回答を表示
回答: いいえ。Chartのファイル、ランタイムイメージ内のJAR、reporterの有効化、収集バックエンドを区別してください。
解説: 1.15のChartにはLog4j/Logbackの設定が含まれますが、YAMLだけでメトリクスパイプライン全体が構築されるわけではありません。
watchNamespacesを設定するとき、他に何を確認すべきですか？
回答を表示
回答: 対象Namespaceの存在、生成されるジョブのServiceAccount/Role/RoleBinding、その他の権限付与を確認します。
解説: 空のリストはすべてのNamespaceを監視します。監視範囲を限定しただけで、テナントが完全に分離されるわけではありません。
- 10分間のメトリクスウィンドウは、すべてのワークロードで最適ですか？
回答を表示
回答: いいえ。実際のSLOに合わせて、ウィンドウ、安定化時間、スケールダウン間隔をまとめて調整してください。
解説: 短いウィンドウはノイズを増幅し、長いウィンドウは応答を遅らせることがあります。観測と負荷テストを行ってください。
- デフォルトのwebhookインストールにはcert-managerが必要ですか？
回答を表示
回答: はい。確認したChartはCertificateとIssuerリソースを作成し、内部で証明書を生成するJobを持ちません。
解説: CRDの存在だけでなく、コントローラー、webhook、cainjectorとCertificateのReady状態を確認してください。
- デフォルトのFlinkイメージで、実在しないorder-events JARを実行できますか？
回答を表示
回答: JARをイメージにパッケージしていない限り実行できません。この章では、実行経路の確認に同梱のStateMachineExampleを使います。
解説: ステートレスなデモと、永続チェックポイント/HAによる復旧検証は別のものです。
- スケーリングを適用せずに推奨値だけを収集するには、どの設定を使いますか？
回答を表示
回答: job.autoscaler.enabled=trueとjob.autoscaler.scaling.enabled=falseを設定します。
解説: 現行のutilization.target/min/maxキーを使い、アクションを有効にする前に、推奨値、状態の復旧、クォータを確認してください。
- FlinkDeploymentの初回Ready状態を待つときに使用するConditionはどれですか？
回答を表示
回答: AvailableではなくRunningです。
解説: このConditionは、観測されたジョブ/JMの状態を反映します。更新後は古いConditionと、新しいspecの実際の調整状況を区別してください。
- バックログが6,000レコードあるとき、
catch-up.durationを600秒から60秒に短縮すると、追加の目標レートはどう変わりますか？
回答を表示
回答: 10レコード/秒から100レコード/秒に増加します。
解説: 復旧目標を短くするほど、多くの容量が必要です。バックログを無視してよい猶予期間ではありません。無効値の0を指定すると、バックログを基準にしたスケーリングが無効になります。