kwok

kwok copied to clipboard

kwokctl snapshot save --path snapshot.yaml --format=k8s
kwokctl snapshot restore --path snapshot.yaml --format=k8s

Save --format=k8s: means to convert k8s yaml to protobuf format and put it in the etcd database. Restore --format=k8s: means to get the data in protobuf format from etcd and convert it to yaml.

Non goal: Ability to filtering of namespace, resource, label, etc.

/kind feature

kwokctl snapshot save --path snapshot.yaml --format=k8s
kwokctl snapshot restore --path snapshot.yaml --format=k8s

Save --format=k8s: means to convert k8s yaml to protobuf format and put it in the etcd database. Restore --format=k8s: means to get the data in protobuf format from etcd and convert it to yaml.

Non goal: Ability to filtering of namespace, resource, label, etc.

I wonder if that's backwards ? Because kwokctl snapshot save means save etcd's data to a file and kwokctl snapshot restore means resore data to etcd from a file.

In some production clusters, users may not have admin privileges and may not be able to export data from etcd, so kwokctl provides a yaml form of data import

/assign

@wzshiming Can I complete this requirement? If yes, I have the following questions:

1.format k8s means to obtain all cluster resources through the kube-apiserver interface and then back up the storage? 2.format k8s means to back up clusters created by kwokctl create cluster, in which case, should etcd data be backed up as well?

Please help provide a more detailed description

The goal is to import and export data in yaml format. I tried importing through apiserver before, but it was very slow, so this time I'm going to bypass apiserver and operate etcd directly.

@wzshiming Preliminary ideas, I understand, direct use of clientv3 connected to, to get the data, then according to the yaml format stored backup, if we need to restore data to put is down again.

However, this operation has a requirement that etcd remain in service in the backup while not allowing apiserver access.

At the same time need to implement the apiserver logic, the storage results marshal to kubernetes resource objects.

What's your opinion?

There is no need to care about the apiserver, just stop the apiserver during the import, and try to resume the cluster afterwards.

@wzshiming In the last meeting, @Huang-Wei i mentioned that it has been implemented locally

@wzshiming In the last meeting, @Huang-Wei i mentioned that it has been implemented locally

As far as I know it should be a tool for exporting resources from the production cluster, which is not duplicated by this.

@wzshiming ok I got it

@wzshiming In the last meeting, @Huang-Wei i mentioned that it has been implemented locally

As far as I know it should be a tool for exporting resources from the production cluster, which is not duplicated by this.

To clarify, this issue is aimed to dump resources from etcd instead of API Server, so it's more about a wrapper layer to parse/unparse the etcd format's data and present it in yaml?

@wzshiming In the last meeting, @Huang-Wei i mentioned that it has been implemented locally

As far as I know it should be a tool for exporting resources from the production cluster, which is not duplicated by this.

To clarify, this issue is aimed to dump resources from etcd instead of API Server, so it's more about a wrapper layer to parse/unparse the etcd format's data and present it in yaml?

Yeah, Use kubectl get or the export resource tool to export data from production, and use the functionality of this issue to quickly restore data from production in a kwok cluster.

I tried writing data directly to etcd, which seemed like a lot of work, and was very cumbersome to make compatible. Let's go in a different direction, by copying the kubectl apply and kwokctl get code, removing the parts we don't need, and removing the QPS limit. This way it's easy to implement, and we don't have to worry about compatibility.

/assign