This page describes the procedue to migrate your current Portworx installation to use OCI/runc containers.

Step 1: Get your current Portworx arguments

Use the following command to get arguments supplied to your current Portworx DaemonSet. We will use that to generate the new DaemonSet spec that uses OCI later in this guide.

$ kubectl get ds/portworx -n kube-system -o jsonpath='{.spec.template.spec.containers[*].args}'

[-k etcd:http://etcd1.acme.net:2379,etcd:http://etcd2.acme.net:2379 -c cluster123 \
 -s /dev/sdb1 -s /dev/sdc -x kubernetes]

Step 2: Get the Daemonset spec that uses OCI

While generating the spec using below procedure, specify the parameters from step 1.

To generate the spec file for the 1.3 release, head on to 1.3 install page.

To generate the spec file for the 1.2 release, head on to 1.2 install page.

Alternately, you can use curl to generate the spec as described in Generating Portworx Kubernetes spec using curl.

Secure ETCD and Certificates

If using secure etcd provide “https” in the URL and make sure all the certificates are in the /etc/pwx/ directory on each host which is bind mounted inside PX container.

Using Secrets to Provision Certificates

It is recommended to use Kubernetes Secrets to provide ETCD certificates to Portworx. This way, the certificates will be automatically mounted when new nodes join the cluster.

Copy all your etcd certificates and key in a folder etcd-secrets/ to create a Kubernetes secret from it.

# ls etcd-secrets
etcd-ca etcd-cert   etcd-key

Use kubectl to create the secret named px-etcd-certs from the above files:

# kubectl -n kube-system create secret generic px-etcd-certs --from-file=etcd-secrets/

Now edit the Portworx spec file to reference the certificates. Given the names of the files are etcd-ca, etcd-cert and etcd-key, modify the volumeMounts and volumes sections as follows:

  volumeMounts:
  - mountPath: /etc/pwx/etcdcerts
    name: etcdcerts
  volumes:
  - name: etcdcerts
    secret:
      secretName: px-etcd-certs
      items:
      - key: etcd-ca
        path: pwx-etcd-ca.crt
      - key: etcd-cert
        path: pwx-etcd-cert.crt
      - key: etcd-key
        path: pwx-etcd-key.key

Now that the certificates are mounted at /etc/pwx/etcdcerts, change the portworx container args to use the correct certificate paths:

  containers:
  - name: portworx
    args:
      ["-c", "test-cluster", "-a", "-f",
      "-ca", "/etc/pwx/etcdcerts/pwx-etcd-ca.crt",
      "-cert", "/etc/pwx/etcdcerts/pwx-etcd-cert.crt",
      "-key", "/etc/pwx/etcdcerts/pwx-etcd-key.key",
      "-x", "kubernetes"]

Installing behind the HTTP proxy

During the installation Portworx may require access to the Internet, to fetch kernel headers if they are not available locally on the host system. If your cluster runs behind the HTTP proxy, you will need to expose PX_HTTP_PROXY and/or PX_HTTPS_PROXY environment variables to point to your HTTP proxy when starting the DaemonSet.

Use e=PX_HTTP_PROXY=<http-proxy>,PX_HTTPS_PROXY=<https-proxy> query param when generating the DaemonSet spec.

Step 3: Verify the generated spec for migration

In the generated spec file, make sure the image for the Portworx DaemonSet is portworx/oci-monitor:<your-current-version>.

This ensures that you simply migrate to Portworx using OCI and don’t end up upgrading to a new Portworx version.

If you have custom changes to the DaemonSet spec apart from the arguments, go ahead and make those too.

Step 4: Apply and migrate

Apply the spec using kubectl apply -f <spec-file>.

As the DaemonSet upgrade strategy in RollingUpgrade, each node will migrate to Portworx using OCI one by one.

To monitor the migration process: kubectl rollout status ds/portworx -n kube-system

To monitor the Portworx pods: kubectl get pods -o wide -n kube-system -l name=portworx