Closed Steamgjk closed 2 years ago
IIUC, Kine can be regarded as a shim layer (or an adaptor) which enables the replacement of etcd with other storage backend.
It's not so much a shim, as it provides an implementation of the GRPC functions that Kubernetes relies upon. As far as Kubernetes is concerned, it is talking to an etcd server.
Among the APIs used by Kubenetes, which have been covered (hooked) by Kine?
Among the APIs used by Kubenetes, which have been covered (hooked) by Kine?
Thanks for the pointer @brandond. A follow-up question is: What etcd APIs used by Kubernete but not supported by Kine? (I ask this question because I want to understand under what scenarios K8S can work but K3S may be cautious)
None of them. If they were required by Kubernetes and we didn't implement them, then kine wouldn't be very usable, would it.
None of them. If they were required by Kubernetes and we didn't implement them, then kine wouldn't be very usable, would it.
So you are saying, Kine has covered all the etcd APIs needed by Kubernete? That is great if it is this case!
Yes, that's why it works.
There are other things not used directly by Kubernetes, like cluster membership management, snapshotting, etc that we don't implement. We implement everything that the apiserver uses.
Yes, that's why it works.
Awesome! I like this project and I will take a deep dive into it. Thanks!
IIUC, Kine can be regarded as a shim layer (or an adaptor) which enables the replacement of etcd with other storage backend. I know etcd is much heavier and provides tons of APIs. I am just not sure: (1) What etcd APIs are used by Kubenetes? (2) Among the APIs used by Kubenetes, which have been covered (hooked) by Kine? Which have not been hooked by Kine?
Do you staff have a list of the etcd APIs used by Kubenete and the list of etcd APIs that have already been covered by Kine? I think that will be very helpful for us to understand the boundary of K3S (i.e. which K8S can do but K3S may suffer from problems) Thanks