6 min read
I'll start a series of blog post where I'll share the work I did during the week on Free Software.
This is the opportunity to make visible a work that is not often visible to people. And also a way to test ideas and the way to explain them.
I hope you'll like it, and feedback is really appreciated.
Resume of last week
My current focus is on Standard CRDs, it is a bit the mother of the battles for me at the moment. This is a long shot, and I'd like to get feedback from the kube community.
What is a Resource in Kubernetes
Let's step back and define what is Kubernetes. Kubernetes is becoming The cloud API. With it, you can schedule compute, storage and LoadBalancers. You have a nice abstraction to deploy your workload the same way on different cloud vendors or on premises.
This API is based on the Kubernetes Resource Model. I recommend you to read this really nice document explaining the management of these resources. It looks like an academic recipe to build distributed system, but it is already implemented!
Most of the resources are defined upstream. As it is a cloud API, you can find the following resources:
- pods - compute
- endpoints, services, ingress - network
- PersistentVolume, VolumeSnapshot - storage
All you need to make a good cloud API.
The Kubernetes API is also nice to work with as you get, out of the box, the following features:
- authentication (OpenIdConnect, ldap, there are many plugins)
- authorization with RBAC
- versioning of all the objects
What is a CRD
CRD stands for Custom Resource Definition. It is a standard way to extend Kubernetes API. The amazing part is that it is really easy to add new building blocks to Kubernetes API. You deploy your object definition (CRD) then the associated controller. And then you are ready to deploy instances of your objects.
For example, you can create a
PostgreSQL object. Then you deploy the associated controller (some people call this an operator). And then, as a user, you can create PostgreSQL instances, just by deploying the configuration of it.
Why do we need a standard
Currently, just for PostgreSQL, I counted 5 different implementations. From my experience, when there is no standards, there is FUD in the market (Fear Uncertainty and doubts). I experienced that 2 times in the container ecosystem.
When CoreOS introduced rkt, suddenly I felt a little halt in the growth of the container ecosystem. Especially in the Enterprise market, these technology shifts are really expensive. And if you are betting on the wrong technology, the consequences can be dramatic. The OpenContainerInitiative was a response to these doubts. The initial problem is that, docker was used by everybody. But the governance of docker was in the hand of one company. And Docker Inc behaved badly with the community. Hence, there was a need for a well defined standard. CoreOS, a company betting on the container adoption understood early that it was a threat to their business. That's why they introduced rkt, to force Docker Inc join the Open Container Initiative. One year later, the market normalized again and everybody was confident that the technology they were using would be indeed useful for the next 10 years.
It happened the same with the Orchestrator. I remember spending months to watch this space. Who will be the winner between DockerSwarm, Kubernetes, Nomad, Marathon. When RedHat joined Google to develop Kubernetes, this was already a signal that this is a good bet. Then Google donated this Project to the Linux Foundation and created the Cloud Native Computing Foundation. This is why Kubernetes started to sky rocket. It was then a standard supported by the Linux foundation.
I really believe in standards, and these are good to enable mass adoption of technologies.
That's why we need to define what is a PostgreSQL instance upstream in Kubernetes. This would enable a greater adoption of this functionality and allow more collaboration between the different implementations.
What is a KEP
A Kubernetes Enhancement Proposal (KEP) is a way to propose, communicate and coordinate on new efforts for the Kubernetes project.
Think of it as an RFC in the Internet world.
Standard CRD KEP
So now you can understand why I'm so fascinated by that this week. And the good news is that I found a KEP already opened since many months. I then started to work on an implementation proposal.
You can find the presentation of the kubernetes enhancement proposal.
You can discuss the associated issue.
And here is my concrete proposal to solve this.
Next week objective
- This Monday, there is a sig-apps meeting where I'd like to discuss the standard CRD idea.
- On Friday, we meet with other librehosters. On Saturday, I'll help with Decentralized Internet and Privacy devroom .
- And Sunday, I'll be in FOSDEM wondering around. If you want to discuss about kubernetes or libre.sh, please PM me or email me :)
- flannel is still supported and it is good to know
- ceph on rook: I got some info that we might have a RedHat tech preview in less than 6 months \o/.
- MongoDB license issue
- I'm also maintaining this document that list nice resources to get started with kubernetes.
Toot of the week
If you arrived until here, I'd like to thank you for your precious time.
If you could react on what you want more, and what you want less, this would be helpful to make this more interesting for you.
If you found it interesting and you know someone that could be interested, please share around.
Last thing, if you have a question, please ask here, next week, I'll answer one.