Apache Flink Kubernetes Operator

repository·main·Indexed 21 days ago

https://github.com/apache/flink-kubernetes-operator

Automates the deployment and management of Apache Flink clusters on Kubernetes, enabling developers to manage Flink jobs as native Kubernetes resources. Includes guides for running PyFlink jobs, Apache Beam applications, and SQL scripts via a custom SQL Runner, as well as examples for Flink Kubernetes Autoscaling.

Tokens
152.1K
Snippets
279
Records
557
Agent score
76%

What's inside Apache Flink Kubernetes Operator

  1. Overview of Flink Kubernetes Operator capabilities

    main

    The Flink Kubernetes Operator extends the Kubernetes API with custom resources to manage the full operational lifecycle of Flink applications. It automates several key operational tasks:

    • Lifecycle Management: Handles deployment, stateful upgrades, rollbacks, and self-healing.
    • Zero-Downtime Upgrades: Uses blue/green deployment strategies, switching to new versions only after they are verified as healthy.
    • Autoscaling: Continuously adjusts parallelism and memory based on observed workload.
    • Kubernetes-Native Operations: Provides integrated support for Helm installation, RBAC, high availability, metrics, logging, and ingress.
  2. Overview of Flink Kubernetes Operator Custom Resources

    main

    The Flink Kubernetes Operator uses Kubernetes Custom Resources (CRs) in the flink.apache.org API group, version v1beta1, to manage Flink clusters and jobs. These resources allow you to declare the desired state of your Flink environment, which the operator then reconciles.

    Available Resources

    Resource (kind)Short namePurpose
    FlinkDeploymentflinkdepRuns a Flink Application cluster (one managed job) or a bare Session cluster.
    FlinkSessionJobsessionjobRuns a single job on an existing Session cluster.
    FlinkStateSnapshotflinksnpRepresents a savepoint or checkpoint taken against a job (Experimental).
    FlinkBlueGreenDeploymentflinkbgdepPerforms a zero-downtime, blue/green rollout over two child FlinkDeployments (Experimental).

    Short names can be used with kubectl, for example: kubectl get flinkdep.

  3. Overview of Apache Flink Kubernetes Operator

    main

    The Apache Flink Kubernetes Operator is a Java-based Kubernetes operator designed to manage the lifecycle of Apache Flink applications. It enables users to deploy, monitor, and manage Flink deployments (including Application, Session, and Job modes) using native Kubernetes tooling such as kubectl.

    Key capabilities include:

    • Deploying and monitoring Flink Application, Session, and Job deployments.
    • Performing lifecycle operations like upgrading, suspending, and deleting deployments.
    • Integrating with Kubernetes logging and metrics.
    • Utilizing a Flink Job Autoscaler for dynamic resource management.
  4. What is Flink Autoscaler Standalone?

    main

    The Flink Autoscaler Standalone is a separate Java process implementation of the Flink Autoscaler. It monitors metrics such as processing rate and busy time to compute the optimal parallelism for all job vertices.

    It performs in-place rescaling using the Externalized Declarative Resource Management REST API via the RescaleApiScalingRealizer implementation.

    Note: While it can be used for various cluster types, it is strongly recommended to use the Kubernetes Operator directly for Flink jobs running on Kubernetes. Standalone mode is primarily intended for non-Kubernetes environments.

  5. Manage Flink job lifecycles and operations

    main

    The Flink Kubernetes Operator provides several mechanisms for managing Flink jobs in a Kubernetes cluster. You can manage the following operational aspects:

    • Job Management: Control the lifecycle of jobs, including starting, stopping, deleting, upgrading, and recovering jobs.
    • Snapshot Management: Manage Flink's state using savepoints and checkpoints.
    • Blue/Green Deployments: Perform zero-downtime rollouts of Flink jobs.
    • Autoscaler: Enable automatic right-sizing of Flink jobs based on workload.
    • Autotuning: Enable automatic tuning of Flink configurations.
  6. Understand Flink Kubernetes Operator core features

    main

    The Flink Kubernetes Operator extends the Kubernetes API with custom resources to manage the full operational lifecycle of Flink applications. Key capabilities include:

    • Lifecycle Management: Handles deployment, stateful upgrades, rollbacks, and self-healing.
    • Zero-Downtime Upgrades: Uses blue/green deployment strategies, switching to new versions only after they are verified as healthy.
    • Autoscaling: Automatically adjusts parallelism and memory based on observed workload.
    • Kubernetes-Native Operations: Supports Helm installation, RBAC, high availability, metrics, logging, and ingress.
  7. Manage Flink Jobs with the Kubernetes Operator

    main

    The Flink Kubernetes Operator provides several mechanisms for managing the lifecycle and operational state of Flink jobs. Key management capabilities include:

    • Job Management: Controlling the lifecycle of jobs, including starting, stopping, deleting, upgrading, and recovering jobs.
    • Snapshot Management: Managing state consistency through checkpoints and savepoints.
    • Blue/Green Deployments: Performing zero-downtime rollouts of Flink jobs.
    • Autoscaler: Automatically right-sizing Flink jobs based on workload.
    • Autotuning: Automatically adjusting Flink configurations for optimal performance.
  8. Core capabilities of the Flink Kubernetes Operator

    main

    The operator provides automated management across several key domains:

    Lifecycle & Deployment

    • Lifecycle Management: Automates deployment, suspension, deletion, and restarts of unhealthy jobs.
    • Zero-Downtime Upgrades: Supports blue/green deployments to switch to new versions only after they are proven healthy, preventing stream interruption.
    • Snapshot Management: Declaratively triggers and tracks Flink savepoints and checkpoints via custom resources.
    • High Availability: Integrates with Flink's Kubernetes HA services (standby JobManagers) and provides leader election for the operator itself.

    Scaling & Optimization

    • Autoscaling: Continuously right-sizes per-vertex parallelism based on observed workload utilization.
    • Autotuning: Automatically adjusts TaskManager memory based on observed usage, often applied alongside scaling actions.

    Configuration & Extensibility

    • Custom Resources: Manages application clusters, session clusters, and session jobs.
    • Pod Templates: Allows native pod definitions with layering for base, JobManager, and TaskManager configurations.
    • Plugins: Supports custom validators, mutators, listeners for custom resources, and pluggable phases in the autoscaler loop.
    • Ingress: Provides dynamic ingress templates for accessing the Flink Web UI.

    Operations & Observability

    • Metrics & Logging: Built on the Flink metric system with pluggable reporters and detailed Kubernetes API metrics.
    • Events: Emits Kubernetes events on custom resources to trace deployments, upgrades, snapshots, and scaling decisions.
  9. Core Operator Deliverables

    main

    A standard installation of the Flink Kubernetes Operator provides several automated capabilities for production workloads:

    • Lifecycle Management: Automates deployment, suspension, deletion, and stateful/stateless upgrades. It handles automatic restarts for unhealthy jobs and rollbacks for failed upgrades.
    • Zero-Downtime Upgrades: Uses blue/green deployment strategies to bring up new versions alongside old ones, switching over only after the new version is proven healthy to ensure uninterrupted streams.
    • Autoscaling: Continuously right-sizes per-vertex parallelism based on real-time workload and tunes TaskManager memory to maintain throughput targets without over-provisioning.
    • Kubernetes-Native Operations: Integrates with standard Kubernetes practices including Helm, RBAC, High Availability (HA), metrics, logging, and ingress.
  10. Explore Flink Kubernetes Operator documentation categories

    main

    The documentation is organized into several key areas to help you manage Flink workloads:

    • Concepts: Provides a high-level overview of the operator's architecture and how it works.
    • Custom Resource Reference: Detailed descriptions of the Kubernetes custom resources used to declare Flink deployments.
    • Managing Flink Jobs: Practical guidance for day-to-day operations and job management.
    • Deployment: Instructions for production-grade setups, including Helm installation, configuration, security, and high availability of the operator itself.
  11. Operator features that require Flink Job HA

    main

    Several advanced operator features depend on Flink Job HA being enabled. If HA is not active, the following features will not work or will be rejected:

    • last-state upgrades: Restores a job from the latest checkpoint recorded in HA metadata without requiring a savepoint. The operator verifies HA metadata availability before suspending a job for a stateful upgrade.
    • Automatic rollback: The operator requires HA to perform rollbacks. If you set kubernetes.operator.deployment.rollback.enabled: true without HA enabled, the operator will reject the configuration with the error: HA must be enabled for rollback support..
    • JobManager recovery: If a JobManager deployment is lost, the operator can redeploy it and allow Flink to recover the job state from the HA metadata.
  12. How the Autoscaler estimates True Processing Rate (TPR)

    main

    The Flink Kubernetes Operator's autoscaler determines the TRUE_PROCESSING_RATE (TPR) to decide how to scale a job. TPR represents how fast a vertex could process at full utilization. The autoscaler calculates this using two distinct methods—Busy-Time Estimate and Backpressure Estimate—and selects the most appropriate one based on specific rules.

    1. Busy-Time Estimate

    This method calculates capacity based on how much time a vertex spends 'busy'. If a vertex achieves rate R while busy a fraction b of the time, the estimated capacity is R / b.

    The calculation depends on the job.autoscaler.metrics.busy-time.aggregator configuration:

    busy-time.aggregatorbusyTimeAvg (denominator)inputRateForTpr (numerator)
    MAX or MIN (default MAX)windowed mean of LOAD × 1000windowed mean of NUM_RECORDS_IN_PER_SECOND (fallback to NUM_RECORDS_IN)
    AVGwindowed rate of ACCUMULATED_BUSY_TIME / parallelismwindowed rate of NUM_RECORDS_IN

    2. Backpressure Estimate

    Used primarily for sources when busy-time becomes unreliable due to sustained backpressure. It divides the achieved rate by the fraction of time the vertex was not blocked:

    OBSERVED_TPR = numRecordsInPerSecond / (1 − backPressuredTimeMsPerSecond / 1000)

    This estimate is only considered valid for sources that are 'catching up' (where LAG is greater than or equal to the rate multiplied by the job.autoscaler.observed-true-processing-rate.lag-threshold, which defaults to 30s).

    Observation StateOBSERVED_TPR Value
    Catching up (backpressure < 1000 ms/s)The formula above
    Idle (numRecordsInPerSecond = 0)+∞ (allows scale-down)
    Fully backpressured (≥ 1000 ms/s)NaN
    OtherwiseHistorical average (or NaN if below min-observations, default 2)

    3. Estimate Selection Logic

    The autoscaler selects the final TPR using the following priority rules:

    1. If observedTprAvg is NaN $\rightarrow$ use busyTimeTpr.
    2. If busyTimeTpr is NaN or +∞ $\rightarrow$ use OBSERVED_TPR.
    3. If busyTimeTpr > observedTprAvg × (1 + switch-threshold) (default 0.15) $\rightarrow$ use OBSERVED_TPR.
    4. Otherwise $\rightarrow$ use busyTimeTpr.

    Summary: Most vertices use busyTimeTpr. The autoscaler switches to the more conservative OBSERVED_TPR for heavily backpressured sources where idle time relative to busy time exceeds the switch-threshold.

    // Busy-Time Formula
    busyTimeTpr = inputRateForTpr / (busyTimeAvg / 1000)
    
    // Backpressure Formula
    OBSERVED_TPR = numRecordsInPerSecond / (1 − backPressuredTimeMsPerSecond / 1000)