You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 30, 2020. It is now read-only.
Allow major Etcd upgrades with safe roll-back (#1773)
* Safer major etcd upgrades by spinning up new etcds and preforming a migration (copy of all kubernetes data)
Simialr to the approach used during the stack migration but this time the major/minor version of etcd is used to control migration e.g 3.2.x -> 3.3.x will cause a migration.
It is safer because should the CF roll fail the previous etcd's should still be available to fall-back to.
Bring all new etcds up at same time during a migration.
Correct looking up of configsets now that the instance name has changed.
When an etcd has an attached NIC use that address rather than the machine's private dnsname
Update Etcd to 3.3.17 release
Fix etcdadm so that it can still detect cluster healthy now written to stderr
Update etcd migration to respect keys with leases
Fix building etcd endpoints where the interfaces are listed in different orders
Move to a two export process for retrieving keys and values using etcdctl 'json' export type for key/value data, and then again using its 'fields' export type in order to successfully extract key/lease data. Process the two files back together with a nod to performance.
* Fix tests by specifying etcdversion (I added some code to throw an error if the default etcd version hadn't been correctly linked into the binary - which it isn't during testing).
* Only announce the migration if the lookup of etcd endpoints have succeeded.
_panic 'cluster is not healthy, can not export keys from an unhealthy cluster'
880
875
fi
876
+
echo"FINISHED exporting kubernetes object registry, ready to import"
877
+
}
878
+
879
+
export_key_values() {
880
+
local file_name=$1
881
+
882
+
echo"exporting objects from original etcds under path /registry..."
883
+
# we have to export twice (unfortunately)
884
+
# 'json' output mangles the lease ids
885
+
# 'fields' mangles the values
886
+
# we will process both of these files in order to properly extract key/value/lease information
887
+
member_etcdctl get '/registry' --prefix --write-out="fields">"$(member_host_snapshots_dir_path)/${file_name}.fields"
888
+
member_etcdctl get '/registry' --prefix --write-out="json"| jq -r '.kvs[] | "\(.key)|\(.value)"'>"$(member_host_snapshots_dir_path)/${file_name}.kv"
889
+
echo"FINISHED exporting objects!"
890
+
}
891
+
892
+
# In order to improve performance, we process the exported data so that we can import it in batches of lease ttl
893
+
# Each etcdctl docker container and so eats time so we want to process imports in as big batches as possible.
894
+
process_export_files() {
895
+
local file=$1
896
+
897
+
create_lease_lookup "${file}.fields"
898
+
create_import_files "${file}.kv""${file}.fields"
899
+
}
900
+
901
+
# create_lease_lookup, takes a fields type export from etcdctl and creates a crude lookup structure using the last 3 chars the key as cache buckets
902
+
# the reasoning behind this is to prevent the creation of the sorted key/value files from having to grep through a single large file for every key/value.
903
+
# NOTE: it was impossible to use the lease as extracted from the etcdctl json output because it mangles the lease number by using floats and rounding
0 commit comments