Clearing up any Confusion around Kubernetes Operators – InApps 2022

Earlier this month, Red Hat’s Operator Framework, which consists of the Operator SDK and Operator Lifecycle Manager (OLM), became an incubating project in the Cloud Native Computing Foundation (CNCF). While you can find plenty of examples of CNCF members discussing how the foundation accepts competing projects and is not in the “kingmaking” business, joining the CNCF certainly highlights projects and gives them a bit of a PR boost. For some, it may even give the impression that these projects are the ones to choose, as the vetting process they go through as part of joining the foundation ensures they meet certain standards regarding governance, adoption, security, and so on.

All that said, there’s certainly still plenty of room for disagreement, and this week Rancher Chief Technology Officer Darren Shepherd took to Twitter to express his particular disagreement, or “strong negative reaction” if you will, to Operator Framework’s dominance in discussions around operators. (Rancher, which itself offers a Kubernetes distribution, is about to be acquired by SUSE).

Before we get to that, we need some basic definitions. Operators are “software extensions to Kubernetes that make use of custom resources to manage applications and their components,” according to Kubernetes documentation, and this right here is a key point of Shepherd’s distaste for the Operator Framework project.

Operators as a concept is great. It helps people understand the value of a group of k8s controllers. Operator Framework though is a specific implementation that is very closely related to Red Hat and OpenShift and has really confused the hell out of everyone. 2/9

— Darren Shepherd (@ibuildthecloud) July 17, 2020

“When customers understand the value of operators the concept they immediately think they need operator framework,” he further writes, pointing to the fact that even the “discussion of ‘operator vs helm chart’ [shows] just how confused everyone is.” On this point, even the Red Hat folks we spoke with earlier this month stressed the difference between Helm Charts and operators, offering perhaps another example of the confusion in this realm.

Going beyond the conflation of the idea of the operator with the usage of the Operator Framework, which he rightfully points out as completely unnecessary in the building of a Kubernetes operator, Shepherd takes further issue with the fact that, having been a Red Hat dominated project, the Operator Framework “obviously align with how Red Hat distributes software.” Not that this is a problem, he says, “but the irritating thing is the concept of operators is getting so closely tied to a Red Hat thing that just doesn’t need to be.”

Shepherd is not alone in his sentiment and others point out a variety of tools, including the soon-to-be CNCF sandbox project KUDO and Kubebuilder, upon which Operator Framework is built, among others.

I DON’T CARE WHAT YOU BUILT FOR FUN AND PROFIT

FUN IS FOR CHILDREN

JUST BUILD THINGS FOR PROFIT

— PHP CEO (@PHP_CEO) July 19, 2020

This Week in Programming

• Clean Notebooks With Gather VS Code Extension: Microsoft has introduced a new way to clean notebooks with the release of the experimental extension Gather, a “notebook cleaning tool that analyzes and determines the necessary code dependencies within a notebook and performs code cleanup, automating this difficult, annoying, and time-consuming task.” Basically, it helps you to extract only the relevant code segments needed to re-create a particular cell output and works by continuously analyzing and keeping track of your notebook execution as you execute cells. Gather analyzes which lines of code in your notebook are needed to produce the output as well as the order those lines were run in, then creates a new notebook or Python file with just that code. Currently, Gather fully supports the matplotlib, NumPy, pandas, random, and sklearn packages, as well as a set of built-in Python functions/keywords.

Software developers are just people with better-than-average Googling skills.

— James Tucker (@tucker_dev) July 19, 2020

• Running Containers in ACI with VS Code Extension: Another addition to the Visual Studio Code realm this week arrives with Microsoft’s latest release of the VS Code Docker extension, which allows you to run containers in Azure Container Instances (ACI). Version 1.4 allows you to build, manage, and deploy containerized applications, and now you can view and troubleshoot containers deployed in ACI directly from within VS Code.
• Rust Opts for GitHub Actions Over Azure Pipelines: The Rust team has been evaluating whether or not GitHub Actions or Azure Pipelines would serve them best for nearly a year now, with the final decision coming this week to move Rust’s CI to GitHub Actions. The entire process was actually at the behest of both Microsoft and GitHub, and the Rust team says the move will “considerably improve the experience for compiler contributors.” The team notes that waiting for pull requests (PRs) to be merged was one of the primary pain points, and this, alongside their extensive continuous integration (CI) system meant PRscould wait in the queue for days before being tested. GitHub Actions, they write, “provides most of the features we loved about Azure Pipelines while being integrated with GitHub’s permissions and UI, which made the switch even more fruitful.” And before we leave the topic of Rust, GitLab this week offers an inside look at the Rust programming language with a talk by Antony Saba, a senior security engineer with Strategic Security at GitLab. Read on for a brief summary or give the entire talk a gander below:

• GitLab 13.2 Addresses Working From Home: The latest release of GitLab 13.2 has introduced, as usual, a number of new features, with some specifically addressing those issues you might run into when your workforce, ahem, suddenly moves to being completely remote. The updates look to help teams streamline project planning with milestone iterations, provide better collaboration with diff changes for wiki pages, and improve overall performance/efficiency with load performance testing.
• Interviewing The Maintainers: For those of you with an interest in open source, developer and blogger Shawn Wildermuth has launched a new series of videos we thought we would highlight. Called The Maintainers, the video series is “all about the open source projects you use every day,” wherein Wildermuth interviews the maintainers of those open source projects talking about why open source is important to them.  Side note — if you head over to the blog, yes, that picture of Wildermuth IS blinking and ever-so-slightly moving. It’s not your imagination.

• Kotlin/Native Explores New Memory Management: Kotlin/Native, the Kotlin solution for integration with native platform-specific environments, is looking ahead at its memory management roadmap, noting that its current implementation has limitations when it comes to concurrency. Thus, they are looking at a replacement, and JetBrains offers up a dive into the history of the issue and what is being considered as a solution in a blog post. Kotlin/Native, they write, wants to be “to C-compatible languages what Kotlin/JVM is to JVM languages — a pragmatic, concise, safe, and tooling-friendly language for writing code.” This is the root of the issue, due to how memory management works in Objective-C, which Kotlin/Native aims to be interoperable with. Unfortunately, the current approach “has a number of deficiencies that hinder wider Kotlin/Native adoption,” they write, and so the team has begun working on an “alternative memory manager for Kotlin/Native that would allow us to lift restrictions on object sharing in Kotlin/Native, automatically track and reclaim all unused Kotlin memory, improve performance, and provide fully leak-free concurrent programming primitives that are safe and don’t require any special management or annotations from the developers.”

I’m working on a systems project rn and when I want to freak out the people I’m sprinting with I show them my 666 tattoo and gets them pretty upset. pic.twitter.com/EFJqrgKXRw

— devon (@devonbl) July 21, 2020

The Cloud Native Computing Foundation, GitLab, and Red Hat are sponsors of InApps.

Feature image by Bruno /Germany from Pixabay

At this time, InApps does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: [email protected].

List of Keywords users find our article on Google: