In previous installments in this series, we looked at the origins of Kubernetes and the building blocks of Kubernetes. In this installment, we’ll take a look at the organization that oversees Kubernetes—the Cloud Native Computing Foundation (CNCF).
What Is the CNCF?
The CNCF is the foundation responsible for managing, stewarding, and guiding the Kubernetes project, as well as many other projects. Because a lot of the technologies that go into modern and cloud-native applications are open source, foundations like the CNCF are needed to help guide them. Otherwise, issues can arise when there isn’t a structure, an organization, or a company overseeing these open source apps.
Increasingly, a lot of these projects are donated to a foundation, similar to the Linux model. In fact, the CNCF is part of the Linux Foundation. Kubernetes started at Google and was donated to the CNCF.
The CNCF is made up of sponsoring organizations and end users. It comes up with the rules for managing the various projects it oversees. For example, different people and companies in the foundation can determine how many members are on the board of directors, who gets elected to the technical committee, and so on.
Pure Storage® is a member of the Linux Foundation and the CNCF. Pure participates in technical projects, along with other companies and open source contributors, to make sure that Kubernetes is as good as it can be.
The CNCF Cloud Landscape
The CNCF is broader than just Kubernetes. The CNCF Cloud Native Interactive Landscape includes nearly a thousand projects for cloud-native storage, observability and analysis, container runtime, security and compliance, scheduling and orchestration, and more. These are different segments or groups of functionality that are necessary when you’re building a cloud-native application. For example, if you’re building a large-scale distributed system, you need a lot of different segments within the broader architecture. These include monitoring, networking, and storage. All the different services also need to communicate together, which is called a service mesh.
The Cloud Native Interactive Landscape provides a view of these projects. If a member of the CNCF develops a solution that fits into one of these buckets, it can be added to this landscape.
CNCF Projects
There are various stages before a project is added to the CNCF Landscape. First, a company creates software that they open source and donate to the CNCF. But, not every good idea makes it into production and something that customers use. So, the CNCF designates different stages for projects: a sandbox project, an incubating project, and finally, a graduated project.
Kubernetes is a graduated project. Google donated it many years ago. It went through a maturation phase before reaching the point where it is today—being used by enterprises worldwide on a massive scale. So reaching the graduated stage is the highest level of distinction for a CNCF project.
Examples of Graduated Projects
There are a lot of other CNCF projects besides Kubernetes. etcd is a graduated project that serves as the central database for the Kubernetes cluster. More specifically, it’s a key-value store database and a foundational database that Kubernetes runs. It’s not the database that your application uses, though. For that, you would use MongoDB, Cassandra, Kafka, or ElasticSearch. etcd is a very specific type of database that allows a distributed set of Kubernetes servers to communicate and keep in sync. etcd was created by CoreOS. This innovative company was influential in mainstreaming the adoption of Kubernetes. It was acquired by RedHat and is now a key part of RedHat OpenShift.
Another graduated Kubernetes project is Helm, a package manager for Kubernetes. In a previous blog post, we looked at how Kubernetes is all about distributed applications, and some of these have multiple parts. Each one of those parts has a container image, a bunch of configuration, and some volumes associated with it. Think about how incredibly complicated it would be to describe an application like a major streaming service in terms of the hundreds or even thousands of different microservices that make it up. And if we wanted to deploy that streaming service in a new region, for instance, we would need to bring all of that information together in some logical way and deploy it. That’s essentially what Helm does. It describes these large-scale, distributed, complex applications in a way that Kubernetes can interpret for deployments.
Prometheus is another graduated project. Kubernetes applications aren’t managed by a human administrator like a database administrator or a VMware administrator who uses their skills, knowledge, and intuition to manage a system. Kubernetes doesn’t work that way. Computers manage a system of distributed applications that run across many servers. For computers to make decisions about which app should run when and where and when things should be moved or restarted, full visibility into that application is essential. So monitoring, metrics, observability, and telemetry are really important. That’s where Prometheus comes in. It’s the most popular way to monitor a Kubernetes application.
The CNCF doesn’t represent only open source projects on the Cloud Native Interactive Landscape, though. The CNCF also lists other products on the Landscape from members of the CNCF. Portworx’s Kubernetes storage solution is on the Landscape because, for example, Portworx® Enterprise works really well with Kubernetes applications. It’s in the Container Native Storage section of the Landscape.
So that’s a little background on the CNCF and the Cloud Native Interactive Landscape. In our next installment, we’ll investigate what CSI is and what it does.
