Upgrading ECKedit

Upgrading to ECK 1.0.0-beta1 from previous versionsedit

ECK 1.0.0-beta1 includes changes that are incompatible with previous versions of the operator. Notable changes include:

  • Custom resource version has changed from v1alpha1 to v1beta1.
  • Some CRD fields have been removed and some others have been renamed to clarify their purpose.
  • Elasticsearch cluster orchestration is now managed through StatefulSet resources.

See the Elastic Cloud on Kubernetes version 1.0.0-beta1 for more information about all the features included in this release.

It is recommended to install ECK 1.0.0-beta1 in a fresh Kubernetes cluster and migrate data over from existing clusters if possible. If you wish to install ECK into an existing Kubernetes cluster that has a previous version of the operator installed, it is important to consider the following:

  • The old operator will be replaced by the new operator during the installation process.
  • Existing Elasticsearch, Kibana and APM Server resources created by an old version of the operator will continue to work but they will not be managed by the new operator. This means that the orchestration benefits provided by the operator such as rolling upgrades will no longer be available to those resources.
  • If the old operator is replaced without removing old resources first, you will have to manually disable finalizers to delete them later.
  • Existing Kubernetes manifests should be converted to the new format in order to work with the new operator.

If some downtime is acceptable, upgrading in place can be performed as follows:

These instructions are general guidelines only. You should have a thoroughly tested upgrade plan for your environment before attempting to modify any production deployments.

  1. Convert existing manifests to the new format.
  2. Create snapshots of your existing Elasticsearch clusters.
  3. Uninstall ECK.
  4. Install new version of ECK.
  5. Re-create the resources by applying the manifests converted in the first step.
  6. Restore data from the snapshots.

Convert Manifestsedit

Elasticsearch

  • Replace v1alpha1 in the apiVersion field with v1beta1
  • Rename nodes to nodeSets
  • Ensure that every nodeSets entry has a name and rename nodeCount to count
  • Remove setVmMaxMapCount. See: Virtual memory.
  • Remove groups from updateStrategy. See: Update strategy.
  • Remove featureFlags
  • If you specified secureSettings, convert secretName into an array item by prefixing it with -
-apiVersion: elasticsearch.k8s.elastic.co/v1alpha1
+apiVersion: elasticsearch.k8s.elastic.co/v1beta1
 kind: Elasticsearch
 metadata:
   name: elasticsearch-sample
 spec:
   version: 7.4.2
-  setVmMaxMapCount: true
-  featureFlags: {}
   updateStrategy:
     changeBudget:
       maxUnavailable: 1
-    groups: []
   secureSettings:
-    secretName: "gcs-credentials"
+  - secretName: "gcs-credentials"
-  nodes:
-  - nodeCount: 3
+  nodeSets:
+  - count: 3
+    name: master-nodes

Kibana

  • Replace v1alpha in the apiVersion field with v1beta1
  • Rename nodeCount to count
  • If you specified secureSettings, convert secretName into an array item by prefixing it with -
-apiVersion: kibana.k8s.elastic.co/v1alpha1
+apiVersion: kibana.k8s.elastic.co/v1beta1
 kind: Kibana
 metadata:
   name: kibana-sample
 spec:
   version: 7.4.2
-  nodeCount: 1
+  count: 1
   elasticsearchRef:
     name: "elasticsearch-sample"
   secureSettings:
-    secretName: "gcs-credentials"
+  - secretName: "gcs-credentials"

APM Server

  • Replace v1alpha in the apiVersion field with v1beta1
  • Rename nodeCount to count
  • If you specified secureSettings, convert secretName into an array item by prefixing it with -
-apiVersion: apm.k8s.elastic.co/v1alpha1
+apiVersion: apm.k8s.elastic.co/v1beta1
 kind: ApmServer
 metadata:
   name: apm-server-sample
 spec:
   version: 7.4.2
-  nodeCount: 1
+  count: 1
   elasticsearchRef:
     name: "elasticsearch-sample"
   secureSettings:
-    secretName: "gcs-credentials"
+  - secretName: "gcs-credentials"

Backwards compatibilityedit

The 1.0.0-beta version of the operator does not delete resources created by older versions of the operator, but it also does not manage them. Attempting to delete resources created with a 0.9.0 version will hang if ECK 1.0.0-beta1 is running. To unblock the deletion, remove any registered finalizer from the resource (substituting the correct name for quickstart):

kubectl patch elasticsearch quickstart --patch '{"metadata": {"finalizers": []}}' --type=merge
kubectl patch kibana quickstart --patch '{"metadata": {"finalizers": []}}' --type=merge
kubectl patch apmserver quickstart --patch '{"metadata": {"finalizers": []}}' --type=merge