Using the New Apache Flink Kubernetes Operator in a Production Deployment
Download as PPTX, PDF0 likes970 views
The document discusses the Apache Flink Kubernetes Operator and its application in production environments, emphasizing its benefits such as self-management of services and upgrades. It outlines essential topics including the operator maturity model, enhancements in security and stability, and a live demo showcasing the operator's functionalities. The presentation concluded with a Q&A session addressing common challenges in deploying Flink in Kubernetes.
Using the New Apache Flink Kubernetes Operator in a Production Deployment
- 1. The Apache Flink® Conference San Francisco 2022 August 3
- 2. Using the New Apache Flink Kubernetes Operator in a Production Deployment Jim Busche, IBM Ted Chang, IBM
- 3. Agenda 1. Introduction ○ Problems we are we solving. 2. Overview of Kubernetes operators and their benefits. ○ Five levels of the operator maturity model. ○ Introduce the newly released Apache Flink Kubernetes Operator. 3. Flink Kubernetes Operator Container Image modifications ○ UBI images ○ IBM Java 4. Enhancements we're making in: ○ Versioning/Upgradeability/Stability ○ Security 5. Demo OLM managed Custom Flink Operator in action 6. Q&A
- 4. Problems we Are Solving ❖ How to support products requires different Flink versions? ❖ How to upgrade Flink Operator running in production? ❖ How to make Flink more secure? ❖ Reduce duplicate effort among
- 5. What is Kubernetes operators The Operator pattern aims to ❖ Capture the key aim of a human operator who is managing a service or set of services. ➢ Operands: The Managed Services. Typically backing services. ❖ Have deep knowledge how the service ought to behave, how to deploy it. ❖ React if there are problems. “The Twelve-Factor App: IV. Backing services” https://12factor.net/backing-services
- 6. How are operators helpful An operator makes a service self-managing ❖ Embeds domain-specific knowledge about the service and its lifecycle ❖ Installs the service, upgrades it, keeps it running, tracks metrics, etc. Hybrid cloud: The service is hosted in the customer’s cluster ❖ The customer is responsible for managing the service ❖ Customer may lack staff, skills, interest ❖ A service manages itself is much more appealing
- 7. Operator Maturity Model Operator Maturity Model Level 1: Basic Install Level 2: Seamless Upgrades Level 3: Full Lifecycle Level 4: Deep Insights Level 5: Auto Pilot https://docs.openshift.com/container-platform/4.10/operators/understanding/olm-what-operators-are.html#olm-maturity-model_olm-what-operators-are
- 8. Apache Flink Kubernetes Operator and CR The Flink Kubernetes Operator extends the Kubernetes API with the ability to manage and operate Flink Deployments. The operator features the following amongst others: ● Deploy and monitor Flink Application and Session deployments ● Upgrade, suspend and delete deployments ● Full logging and metrics integration ● Flexible deployments and native integration with Kubernetes tooling
- 9. Benefit of Using the Flink Kubernetes Operator Operator handles the following tasks declaratively using the the CR ❖ Deploying jobs ❖ Configuration ❖ Upgrade ❖ Backup ❖ Restore ❖ High Availability ❖ Metrics Monitoring
- 10. Flink in our products Watson AIOPs Flink is used by the log anomaly detection data prep pipeline and for the event lifecycle. https://www.ibm.com/cloud/blog/watson-aiops-bringing-ai-to-it-operations-management Business Automation Insights Data ingestion and processing relies on Apache Flink data processing framework
- 11. Software Compliance in Production ✓ Platform: Red Hat OpenShift ✓ Container Image: UBI ✓ Security ✓ Package Management: Operator Lifecycle Management (OLM) Before we can Flink into our product, certain requirements must be met. For example:
- 12. Red Hat OpenShift ❖ Enterprise-grade Kubernetes features including 7/24 Support ❖ Built-in Security Context Constraint (SSC) provides default execution policies, increasing the entire Kubernetes cluster security level. ❖ Role-based access control (RBAC) in OpenShift is a non-optional feature, enabling role-based permissions as required. ❖ Containers required to run as non-root
- 13. Dockerfile modifications ❖ If building your own image, make sure you do latest OS update to get the latest security patches. For example: ➢ https://github.com/apache/flink- kubernetes- operator/blob/main/Dockerfile#L62 ➢ ARG SKIP_OS_UPDATE=true Change to ARG SKIP_OS_UPDATE=false ❖ You can use/create your own DockerFile/base image, for example we used the Red Hat UBI image with IBM Java 11 ❖ What benefit do we have for swapping UBI base? For production environments that require an enterprise version of Linux.
- 14. Security Pipeline ❖ Tekton based Security Scan Pipeline running the following ➢ Twistlock vulnerability and compliance ■ Scans containers for vulnerabilities. ➢ Whitesource/Mend ■ WhiteSource is an open-source vulnerability scanner that scans source code for known OSS vulnerabilities and for compliance. ■ Recommend fixes. ➢ Scorecard scorecard --local=./flink-kubernetes-operator RESULTS ------- Aggregate score: 5.0 / 10
- 15. Operator Lifecycle Manager Open source toolkit to manage Operators in a Kubernetes Cluster ❖ Over-the-Air Updates and Catalogs ❖ Dependency Model ❖ Discoverability ❖ Cluster Stability ❖ Declarative UI controls
- 16. Demo of the Apache Flink Kubernetes Operator in-action See the prepared recording ❖ Demo of the Apache Flink Operator in-action. ➢ Apply the catsrc ➢ Apply the Subscription (Recommended installPlanApproval: Manual) ➢ Approve the install plan ➢ Check the csv and Flink Kubernetes Operator
- 17. Summary, and Q&A - Q&A - Thank you for attending!
Editor's Notes
- #8: This is from the operator framework website which is also where the operator sdk comes from. And these are the operator capability levels as you can see there are 5 of them. Basically the higher the level the operator is the more sophisticated they get and the more stuff they can do for you. So level 1 is the operator can only install the service that's about it. But even that is valuable because that way if you have the operator to install your service. The operation team, the SRE, the cluster admin don’t have to learn how to install your service. All they have to learn is to install the operator which is very easy because all operators installation work the same way. On one hand the basica install doesn't do much but on the other hand is valuable. Then Level 2 is seamless upgrade. The operator should be able to upgrade a stateful workload. The operator is not doing anything magic. The workload itself has to be upgradable to begin with. So if there is a way to upgrade the workload from version 1 to version 2 but it's a very manual process. well then you can add that logic into the operator then you are making it into a level 2 operator. Level 3 it can manage the full lifecycle. So a lot of what that mean is these are stateful workloads. A lot of time a level 3 operator should be able to do is to backup and restore from somewhere. Or when there is a failure the operator should be able to recover from the crash and resume where it left off. Level 4 is that the operator is able to gather metrics on the service and tell you how it's doing. And optionally you can even display that in a dashboard that sort of thing. The level 5 is the auto scaling stuff which the operator can grow and shrink the service according to the workload stress level. There are three main ways to implement an operator. You can use Helm, ansible or go. Something like 70% operators use go.
- #9: With all the basic knowledge of an operator in mind, it should be easier to explain the new and official Flink kubernetes operator. Obviously, this is the operator that deploys and manages Flink applications in a kubernets or openshift cluster. This operator is implemented using the Java Operator SDK because the Flink itself is written in Java and the the Flink community has a lot of experienced Java developers. There are third party Flink operators based on Go but some are either not maintained nor integrated well to manage Flink applications because the Flink is written in Java. The Flink Operator is an application that deploy and manage the lifecycle of Flink applications. Once you have the operator installed into your kubernetes cluster deploying a Flink application becomes easy. First we need to define a Custom Resource(CR) of FlinkDeployment. It is basically a yaml file that defines the name and also the specs the your Flink job that you want the operator to install and manage. And then you can apply the yaml file using the kubectl command to create an instance of a Flink application. The operator will create an instance of Flink application for each of the yaml file with a unique name and manage those Flink application instances for you.
- #10: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/ It basically makes a SRE life easier. Using the CR, someone can configure, deploy, a flink job and have the Flink operator manage the life cycle such as upgrade, backup, restore, and collect metrics for you. Which also makes the Flink operator somewhat at least a level 4 operator.
- #14: https://developers.redhat.com/products/rhel/ubi