tmattausch / k8s-cluster-export Goto Github PK

student@master01:~$ ./k8s-cluster-export -g
NAME STATUS AGE
app-team1 Active 71d
cpu-top Active 70d
default Active 72d
echo Active 70d
ing-internal Active 71d
ingress-nginx Active 71d
internal Active 70d
kube-node-lease Active 72d
kube-public Active 72d
kube-system Active 72d
my-app Active 70d

⎈ ⎈ ☃ ⎈ ⎈

---- start export resources for ns ----

-------------- export sc --------------

-------------- export pv --------------

---- export pv01 config ----

Error: parsing expression: Lexer error: could not match text starting at 1:1 failing at 1:1.
unmatched text: "d"

Hi, I only want to save time to new users like me :-)

The script requires yq version <4 from mikefarah project. There are other projects with the same name like this https://github.com/kislyuk/yq (it seems like no one controls duplicate names)

I could run on centos 7 with yq version 3 (deprecated) -> https://github.com/mikefarah/yq/releases/tag/3.4.1.
Also yq requires jq (yum install jq). And.. to avoid diff warnings need diff >= 3.4 because 3.3 doesn't recognize --colour args. I get v3.7 bin from an ubuntu 20.04.

Hope it helps!

Thanks Thomas for the project.
Regards

When PVC is pv pending during export, "pv_null" yaml file is included in export and yq errors are printed in stderr and stdout. I understand from reading the script that it's intended to grab some PV data along with every PVC, so that resources can be safely detached and reattached. For my pending PVs, this may not be possible.

I'm not sure what I should expect to happen, because my cluster is basically in an error state before I started the export. Several PVs are currently Pending on my cluster for some time, and due to some provider mismatch likely won't be fulfilled. The resulting script behavior is probably as good as can be expected in the circumstances.

I planned to export and try again on another cluster, or fill out the PV with data from my cloud provider and try to reattach the orphaned PVs by hand. The k8s-cluster-export output was just a little bit less than tolerant of this error state, lots of this:

09:19:16 main [ERRO] asked to process document index 0 but there are only 0 document(s)
Error: asked to process document index 0 but there are only 0 document(s)
Usage:
  yq delete [yaml_file] [path] [flags]

Aliases:
  delete, d

but, the script execution was not terminated, proceeded through the remaining resources including several deployments that I had, and finally completed successfully. There was not any harm I could see, other than a couple hundred lines of spurious yq error output, that grabbed my attention and alerted me to the error. Maybe that's exactly what should happen.

As you perhaps expected, or maybe not, when the PVC is exported without a PV bound to it, an empty file is written into namespace/2_pv/pv_null.yaml. That is not really going to harm anything, but is spurious and probably shouldn't have been written as part of the export.