Cloud Native Computing Foundation Announces Rook Graduation(cncf.io)
cncf.io
Cloud Native Computing Foundation Announces Rook Graduation
https://www.cncf.io/announcements/2020/10/07/cloud-native-computing-foundation-announces-rook-graduation/
35 comments
For the uninitiated: Rook is a deployment tool for Ceph and a few databases on Kubernetes. The heavy lifting is done by Ceph, the name is only mentioned in passing in the 10th paragraph.
Is it just me or is the CNCF ran by a bunch of marketers and product managers?
The entire 'ecosystem' is filled with worthless crap like this with stupid marketing like "incubating" and "graduation" to infer on it some level of acceptance.
Are there any foundations that don't operate like this? Are foundations good at all for anything?
The entire 'ecosystem' is filled with worthless crap like this with stupid marketing like "incubating" and "graduation" to infer on it some level of acceptance.
Are there any foundations that don't operate like this? Are foundations good at all for anything?
The graduation criteria has a distinct set of technical and project maturity hurdles that must be cleared:
https://github.com/cncf/toc/blob/master/process/graduation_c...
which includes complying with the Core Infrastructure Initiative requirements:
https://bestpractices.coreinfrastructure.org/en/criteria/0
It does have a marketing aspect, as all Linux Foundation projects do, but it's not pure fluff.
https://github.com/cncf/toc/blob/master/process/graduation_c...
which includes complying with the Core Infrastructure Initiative requirements:
https://bestpractices.coreinfrastructure.org/en/criteria/0
It does have a marketing aspect, as all Linux Foundation projects do, but it's not pure fluff.
The terms "incubating" and "graduation" have meaning to others, even if you choose to ignore them:
https://www.cncf.io/projects/
CNCF projects have a maturity level of sandbox, incubating, or graduated, which corresponds to the Innovators, Early Adopters, and Early Majority tiers of the Crossing the Chasm diagram. The maturity level is a signal by CNCF as to what sorts of enterprises should be adopting different projects.
> Are there any foundations that don't operate like this?
Presumably. My main experiences are with the Apache Software Foundation, though, which in terms of "incubation" operates similarly to CNCF.
> Are foundations good at all for anything?
The answer is foundation-specific. But in general, foundations allow for pooling of resources and wisdom such as legal services, and allow for consumers to know a lot about a project's governance and status at a glance in a way which is difficult to ascertain for a standalone project on the web or Github or wherever.
https://www.cncf.io/projects/
CNCF projects have a maturity level of sandbox, incubating, or graduated, which corresponds to the Innovators, Early Adopters, and Early Majority tiers of the Crossing the Chasm diagram. The maturity level is a signal by CNCF as to what sorts of enterprises should be adopting different projects.
> Are there any foundations that don't operate like this?
Presumably. My main experiences are with the Apache Software Foundation, though, which in terms of "incubation" operates similarly to CNCF.
> Are foundations good at all for anything?
The answer is foundation-specific. But in general, foundations allow for pooling of resources and wisdom such as legal services, and allow for consumers to know a lot about a project's governance and status at a glance in a way which is difficult to ascertain for a standalone project on the web or Github or wherever.
> allow for consumers to know a lot about a project's governance and status
Although, as you say, the specifics vary by foundation and range quite a bit in how heavyweight they are, foundations also provide something of a neutral home for projects. A company may still be somewhat dominant in a given project but it can't just take its ball and go home to the degree possible if it kept control of domains, trademarks, and so forth on its own.
Although, as you say, the specifics vary by foundation and range quite a bit in how heavyweight they are, foundations also provide something of a neutral home for projects. A company may still be somewhat dominant in a given project but it can't just take its ball and go home to the degree possible if it kept control of domains, trademarks, and so forth on its own.
I deliberately left this point ambiguous. ;) The pressure on foundations to accommodate the wishes of major donors is immense and unceasing. Different foundations respond to that pressure in different ways.
I don't think it makes sense to assume that just because a project is at a foundation that it is independent by any useful definition. It's possible for dominant players to set things up such that they maintain effective control over the governance of a project which resides at a foundation. It's possible to generalize when you know the foundation, but it's not possible to generalize across all foundations.
I don't think it makes sense to assume that just because a project is at a foundation that it is independent by any useful definition. It's possible for dominant players to set things up such that they maintain effective control over the governance of a project which resides at a foundation. It's possible to generalize when you know the foundation, but it's not possible to generalize across all foundations.
I don't disagree with any of that. Certainly there are vast differences between Apache, OpenStack, and SPI, for example. And there can be considerable differences even between projects within a single foundation to the degree that a foundation like CNCF allows considerable latitude in how individual projects choose to organize.
In any case, if most of a project's committers are with a single company, that company is going to have a lot of control even if the project is nominally under generally neutral governance.
In any case, if most of a project's committers are with a single company, that company is going to have a lot of control even if the project is nominally under generally neutral governance.
I looked at the list of graduated and incubating projects[1], and many of them from both categories are extremely important to the container landscape.
Here are ones I specifically know are important:
Graduated: kubernetes,prometheous,rook, helm, containerd, coredns
Incubating: CNI (Container Networking Interface), CRI-O, etcd, gRPC
[1] https://www.cncf.io/projects/
Here are ones I specifically know are important:
Graduated: kubernetes,prometheous,rook, helm, containerd, coredns
Incubating: CNI (Container Networking Interface), CRI-O, etcd, gRPC
[1] https://www.cncf.io/projects/
All these vendors had earlier incarnations in the open stack era (Iaas). Openstack is a big failure. Now, these vendors have moved to the next one: CNCF
There are ways to sort to limit the vendor-based solutions in the Landscape and just focus on open-source projects by the Linux Foundation and others that are considered official projects. It is an excellent invaluable resource IMO and they've done a great job so far.
most network engineering foundations (Network operator groups, IETF etc) are far more formal.
Which is both a good and a bad thing. On one hand, without marketing, getting a system adopted on a large scale is hard. (as evident by many RFC's which are not used a lot in the wild). On the other hand, the CNCF seems to have a zillion products which all solve roughly the same problem in the same problem space, which seems to make it unnecessary and complex.
Which is both a good and a bad thing. On one hand, without marketing, getting a system adopted on a large scale is hard. (as evident by many RFC's which are not used a lot in the wild). On the other hand, the CNCF seems to have a zillion products which all solve roughly the same problem in the same problem space, which seems to make it unnecessary and complex.
Branding sometimes has value too. The CNCF reminds me of the place name associations built around winery regions:
https://en.wikipedia.org/wiki/Appellation
https://en.wikipedia.org/wiki/Appellation
But the LF/CNCF is doing branding wrong by putting their brand on tons of different software, most of it bad.
I hear ya. The point I was trying to make is that some private/public consortiums that appear to be regulatory institutions are mostly marketing associations. A quick check is to see if there is a large fee associated with joining and if the largest part of the association's budget is marketing/advertising.
Maybe I'm being pedantic but what bugs me is the 'C' in CNCF. The CNCF is mostly/all 'K'ubernetes specific which is a subset of the software that targets 'C'loud Infrastrture-as-a-Service. The term cloud-native has lost some meaning, at least in search results.
Maybe I'm being pedantic but what bugs me is the 'C' in CNCF. The CNCF is mostly/all 'K'ubernetes specific which is a subset of the software that targets 'C'loud Infrastrture-as-a-Service. The term cloud-native has lost some meaning, at least in search results.
Yeah, some k8s people are trying to redefine "cloud native" as "uses k8s".
It’s cause the cncf is heavily staffed by GCP, and it shows in the way it’s run.
The warts of CNCF are the same warts of GCP
The warts of CNCF are the same warts of GCP
I worked for CNCF for two years up until about three months ago. Not one GCP person there.
In fact, there's been considerable pissiness between the CNCF and Google this year over governance of Istio and Knative although that's been somewhat worked out.
Actual project here: https://rook.io/
Block, file, object storage for K8S, powered by Ceph underneath. The project is diluted by also deploying databases for some reason, and I don't recommend using it for that.
Overall good to see more storage options for K8S with others like Longhorn, OpenEBS, StorageOS, Portworx, etc.
Block, file, object storage for K8S, powered by Ceph underneath. The project is diluted by also deploying databases for some reason, and I don't recommend using it for that.
Overall good to see more storage options for K8S with others like Longhorn, OpenEBS, StorageOS, Portworx, etc.
I’ve ran rook for a couple of months in my test lab on virtual machines. Absolutely love it and has been super stable. Does anyone run this on bare metal in production? Running this as a hyper converge k8s setup sound like its easy to scale even if you colocate your own hardware in a dc. Which is way cheaper then cloud these days. Anyone with experience?
I know a team that used to use it, but have since switched to Portworx for more features. K8S is great for bare metal although the installation and maintenance can be complicated. Rancher is a good option to outsource all that.
Has anyone used ceph in production? If so, are there are any advanatages of using Ceph over Aws S3?
It used to be pretty popular during openstack days. Lately, I havent herd much about it.
I run ~100-200 PB of Ceph object and block storage. I've run Ceph in production at my current and previous employers, both Fortune 100 companies since 2013.
Ceph is used at Fidelity, Bloomberg, OVH, Digital Ocean, CERN, Walmart, and some Canadian and European universities, and last but not least at DreamHost.
Ceph is used at Fidelity, Bloomberg, OVH, Digital Ocean, CERN, Walmart, and some Canadian and European universities, and last but not least at DreamHost.
It's advantage is being on-prem. So, it goes with the on-prem k8s like Openshift of Redhat/IBM. Who are the likely customers for on-prem solutions? Insurance, banks, healthcare, etc. That's where you see these solutions.
You can also run those (OpenShift/Ceph/Rook/etc.) both on-prem and on various public clouds which gives you a degree of portability and compatibility across platforms.
Running your own storage in public clouds doesn't make much sense though. Native object storage is generally a lot better than running your own Ceph/Minio, native block storage is better than running your own Ceph, etc.
If something works on-prem, it also works on clouds: after all, just get compute, and run. However, that's not how Redhat sells Openshift.
Running the same large scale cluster on Openshift (with a managed lifecycle) on a different cloud, is just a matter of:
`openshift-installer create install-config --dir=install_1`
edit the deployment size, and any small vendor specific tweaks like instance size ~5 lines
`openshift-installer create cluster --dir=install_1`
You'll get a different StorageClass from which you can make Persistent Volume Claims from, easy scaling of nodes using `kubectl scale machineset` or an autoscaler.
Even with bare metal setup, which requires setting up some DNS wildcards and DHCP, everything down to the layers(I think they're layers) of the OS filesystem can be managed via a K8s custom resource (backed by ignition). You can create network attachment definitions for multiple nics, you can specify the contents of a config file via a bunch of MachineConfigs. And you can just not do all of this until you need to, you can go straight ahead to creating Deployments, and load balanced services. With KubeVirt, you can use k8s resources and virtctl to manage virtual machines.
Vendor specificness is highly minimized by a management layer.
`openshift-installer create install-config --dir=install_1`
edit the deployment size, and any small vendor specific tweaks like instance size ~5 lines
`openshift-installer create cluster --dir=install_1`
You'll get a different StorageClass from which you can make Persistent Volume Claims from, easy scaling of nodes using `kubectl scale machineset` or an autoscaler.
Even with bare metal setup, which requires setting up some DNS wildcards and DHCP, everything down to the layers(I think they're layers) of the OS filesystem can be managed via a K8s custom resource (backed by ignition). You can create network attachment definitions for multiple nics, you can specify the contents of a config file via a bunch of MachineConfigs. And you can just not do all of this until you need to, you can go straight ahead to creating Deployments, and load balanced services. With KubeVirt, you can use k8s resources and virtctl to manage virtual machines.
Vendor specificness is highly minimized by a management layer.
>However, that's not how Redhat sells Openshift.
Really? There are also managed offerings on various clouds but, to the best of my knowledge (I work at Red Hat but not specifically on OpenShift), the fact that you can run it yourself on different clouds is a selling point if that's what you want to do.
Really? There are also managed offerings on various clouds but, to the best of my knowledge (I work at Red Hat but not specifically on OpenShift), the fact that you can run it yourself on different clouds is a selling point if that's what you want to do.
Digital Ocean Spaces is an S3 alternative that is powered by Ceph.
Do I understand correctly that the inclusion of YugabyteDB support in Rook's functionality is simply based on current unavailability of the relevant native Operator by Yugabyte itself? If someone from Yugabyte is reading this, I would appreciate their comment on plans to implement such Operator. That would allow people who do not need on-premise data storage to avoid establishing and maintaining an additional significant dependency in the form of Rook.
No, Yugabyte has their own K8S implementation, just like all the other databases that Rook supports.
Rook is just reusing the storage operator to also deploy databases which I find strange and don’t recommend. Best to use it for storage only.
Rook is just reusing the storage operator to also deploy databases which I find strange and don’t recommend. Best to use it for storage only.
Thank you for your reply. I have found relevant section in documentation. Speaking about using YugabyteDB independently, it appears that current Yugabyte K8s operator cannot be used in multi-zone configurations (which explains why I could not find mentioning it in relevant sections of documentation). Based on the following Crunchy Data documentation for related PostgreSQL K8s operator, multi-zone deployments require special considerations and, thus, K8s operators that are "multi-zone-enabled": https://access.crunchydata.com/documentation/postgres-operat....
If cluster experience problems to run rook pods, then other pods that uses volumes will fail too. And it may cause situation where everything fails with timeout errors...
Nothing against rook, but the idea to run k8s storage in k8s is fragile
Nothing against rook, but the idea to run k8s storage in k8s is fragile
It sounds like you’ve run into this problem before. What were the circumstances that made the problem Rook-specific? I mean to ask, was there an underlying problem affecting all pods, not just Rook pods?