The revolving door of hosted projects within the Cloud Native Computing Foundation continued to turn this week as the organization welcomed in a new incubated project and saw one of its prized pupils walk the graduation stage.

Coming into CNCF is the CRI-O container runtime, which is an implementation of the Kubernetes container runtime interface (CRI) that provides an integration path between Open Containers Initiative (OCI) conformant runtimes and Kubernetes kubelets. It was initially developed by Red Hat and Google under the guise of the OCI Daemon and adopted in CNCF in late 2016.

A container runtime basically provides an API and tools that abstract low-level technical details in the container. CRI-O was developed as a “slimmer” version of regularly available container runtime options.

“A founding principal of CRI-O was to ‘not reinvent the wheel’ but to use shared components and refine approaches tested in production, and existing, battle tested code,” said Brendan Burns, a CNCF Technical Oversight Committee (TOC) representative, project sponsor, and one of the co-founders of Kubernetes. “As CRI-O is specifically tailored for Kubernetes, it is tuned for performance, stability, compatibility, and adherence to standards, particularly the Kubernetes Conformance tests. CRI-O is a building block of any Kubernetes cluster, and facilitates the life cycle of containers as required by the Kubernetes CRI.”

CRI-O also fills in nicely for the recent graduation of the containerd container runtime project from CNCF.

Speaking of graduation, Fluentd is the latest CNCF project to grab its diploma. Fleuntd is a logging platform that was adopted into CNCF in late 2016. It was the sixth project accepted into CNCF, and appropriately, it’s the sixth to graduate.

Gaining graduation status requires a project to meet CNCF’s list of criteria. This includes demonstration of “thriving” adoption; a documented, structured governance process; and a strong commitment to its community. Incubated projects, which is one step below graduation, must also adopt the CNCF code of conduct, define their own governance structure, and establish a steering committee.

The five proceeding CNCF graduated projects include Kubernetes, Prometheus, Envoy, CoreDNS, and containerd.

Fluentd was initially created by Sadayuki Furuashim, co-founder of Treasure Data, as an open source data collector for building a unified logging layer. This layer can then unify data collection and consumption for easier use or understanding of that data.

As of its graduation, Fluentd has four active maintainers, more than 160 contributors, and more than 4,400 commits.

Google’s move this week to enhance and rename its Cloud Services Platform as Anthos drew a number of new partners into its ecosystem. Two focused on the storage aspect of container deployments included Robin.io and Portworx.

Robin.io said it was working with Google to design standardized APIs for data management capabilities needed for running data-centric workloads in Google’s Kubernetes Engine (GKE). And, the Robin Storage platform has been validated to support enterprise workloads in Anthos.

Robin.io Chief Marketing Officer Radhesh Menon said the move follows on the company’s pivot toward Kubernetes last August. That move allowed for simplifying the management and deployment of big data workloads by adding a Kubernetes layer to deal with stateful container applications running on premises or in a public cloud.

“Now that we have embraced Kubernetes, our value proposition is that if you have Kubernetes we will help you run stateful apps by bring storage and advanced storage management,” Radhesh explained.

Portworx, for its part, said its Enterprise product is now able to run on GKE and GKE On-Prem. This allows enterprise workloads like databases to run on the Google Anthos platform.

Portworx launched the Enterprise version of its storage product in mid-2016. It has since updated the product to better integrate with the growing use of Kubernetes as the container orchestration platform of choice.

Both the Robin.io and Portworx platforms target the ability to run stateful applications in Kubernetes, which was designed for stateless applications. This means that it was not created to handle data storage. This is not a problem for cloud native web services like a web server or a front-end web user interface that do not depend on the local container storage for the workload.

However, stateful applications are services that save data to storage and use that data to run the application. These include databases and complex applications like big data and artificial intelligence (AI) use cases that involve large-scale data processing, data science, and machine learning (ML).

The Knative community recently unveiled the latest 0.5 version of the Kubernetes-based serverless platform. The latest update includes a focus on trigger and broker objects targeted at simplifying the developer experience for building event-driven systems on Knative; and improving overall observability of autoscaling, queue proxy, and Istio telemetry.

Knative is an open source set of components that allows for the building and deployment of container-based serverless applications that can be transported between cloud providers. Basically Knative is using the market momentum behind Kubernetes to provide an established platform on which to support serverless deployments that can run across different public clouds. It can act as the “infrastructure” layer for the deployment of functions-as-a-service (FaaS) similar to how Kubernetes is being used as the infrastructure layer for broader network applications.

It was developed by Google, IBM, Pivotal, SAP, and Red Hat and unveiled last July. It has since began to garner accolades as a platform that could allow for greater portability of serverless applications.