Flink Kubernetes Operator Quiz
Check installation, state recovery and autoscaling for Operator 1.15.0 / Flink 2.2.1.
- How do Deployment and SessionJob differ?
Show Answer
Answer: Deployment defines an Application/Session cluster; SessionJob defines a job on an existing managed Session cluster.
Explanation: Separate SessionJob management does not isolate shared cluster resources or failures.
- Is a historical Kubernetes 1.21+ minimum enough to validate a current EKS deployment?
Show Answer
Answer: No. Check current EKS support, client skew and Operator/webhook/CRD compatibility.
Explanation: The introduction date of namespace labeling is not a complete support or feature-validation matrix.
- Does a blue/green CR automatically switch Kafka/S3 writes without duplicates?
Show Answer
Answer: No. Design consumer groups, transactional IDs, sink output and state compatibility separately.
Explanation: Managing transitions between child deployments is different from end-to-end data guarantees and needs extra transition capacity.
- Is a savepoint upgrade always the safest, slowest, stop-the-world choice?
Show Answer
Answer: No universal ranking applies; timing, restorability and fallback depend on the job and state changes.
Explanation: Creating a snapshot does not prove serializer, UID or connector compatibility.
- What does last-state recovery of an unhealthy job require?
Show Answer
Answer: Accessible HA metadata/checkpoints, compatible state, credentials and storage.
Explanation: It may avoid a new savepoint, but does not automatically solve metadata loss or stale checkpoints.
- Does setting last-state in SessionJob YAML complete stateful-upgrade preparation?
Show Answer
Answer: No. The effective Session/job configuration needs checkpointing, storage and recovery prerequisites.
Explanation: Check the validator and restore path, not just the mode string.
- What is the main scaling target of the Flink autoscaler?
Show Answer
Answer: Parallelism of individual job-graph vertices.
Explanation: This differs from HPA replica scaling; actual pod/node counts depend on slot allocation and resource-management layers.
- Is a downstream target rate just the sum of current upstream output rates?
Show Answer
Answer: It combines upstream target rates multiplied by edge output ratios and propagates backlog-processing targets.
Explanation: Output selectivity and required future capacity matter.
- Does the autoscaler ignore every CPU/memory signal?
Show Answer
Answer: The main parallelism model uses rates/busy time, but memory/GC pressure, quotas and optional memory tuning also exist.
Explanation: Memory tuning defaults to false; this is still different from CPU-based HPA.
- Must Flink parallelism always be a divisor of maximum parallelism?
Show Answer
Answer: No. Autoscaler alignment preferences for balanced key groups/partitions differ from Flink's allowed range.
Explanation: Check alignment mode, keyed inputs and source partitions. Changing maximum parallelism for existing state needs compatibility review.
- Is every autoscaler rescale a full last-state upgrade?
Show Answer
Answer: No. Where possible it uses in-place resource-requirements APIs; conditions can require redeployment.
Explanation: In-place scaling does not guarantee absence of task restarts or state-recovery costs.
- Why do these examples use Flink 2.2.1 rather than the latest 2.3.0?
Show Answer
Answer: To pin an integration baseline checked alongside published Operator/connector compatibility tables.
Explanation: A newer value accepted by a CRD enum does not prove runtime compatibility.
- Does a chart logging configuration prove reporter JARs and collection servers are installed?
Show Answer
Answer: No. Distinguish chart files, runtime-image JARs, reporter activation and the collection backend.
Explanation: The 1.15 chart includes Log4j/Logback configuration, but YAML alone does not create an entire metrics pipeline.
- What else should be checked when setting watchNamespaces?
Show Answer
Answer: Target namespace existence, generated job service accounts/Roles/RoleBindings and other grants.
Explanation: An empty list watches all namespaces. Watch scope alone does not fully isolate tenants.
- Is a ten-minute metrics window optimal for every workload?
Show Answer
Answer: No. Tune the window, stabilization and scale-down interval together with actual SLOs.
Explanation: Short windows can amplify noise; long ones can delay response. Use observation and load tests.
- Does the default webhook installation require cert-manager?
Show Answer
Answer: Yes. The reviewed chart creates Certificate and Issuer resources and has no internal certificate-generation Job.
Explanation: Check controllers/webhook/cainjector and Certificate readiness, not only CRD existence.
- Can a default Flink image run a fictitious order-events JAR?
Show Answer
Answer: Not unless the JAR was packaged into it. The chapter uses the bundled StateMachineExample to verify the execution path.
Explanation: A stateless demo is separate from durable-checkpoint/HA recovery validation.
- Which settings collect recommendations without applying scaling?
Show Answer
Answer: job.autoscaler.enabled=true and job.autoscaler.scaling.enabled=false.
Explanation: Use current utilization.target/min/max keys and validate recommendations, state recovery and quotas before enabling actions.
- Which condition is used to wait for initial FlinkDeployment readiness?
Show Answer
Answer: Running, not Available.
Explanation: It reflects observed job/JM state. After updates, distinguish a stale condition from actual reconciliation of the new spec.
- For 6,000 backlog records, how does reducing catch-up.duration from 600 to 60 seconds change the extra target rate?
Show Answer
Answer: It increases from 10 to 100 records/second.
Explanation: A shorter recovery target requires more capacity. This is not a grace period for ignoring backlog; zero disables backlog-based scaling.