How to upgrade all the currently running application instances

[simonzhong1985]

@devdattakulkarni
Hi, firstly thanks for your work on this cool project.
I have created two tenants/namespaces according to wordpress example you provide.
They works.
In real world, we always need to deploy new version once new features are done.
I don't find the best practice to upgrade running applications here. Just based on my understanding, I updated chartURL of ResourceComposition to new chart version where I defined new version of image. I thought all running WordPress applications should be updated to new version. However, the update action wasn't applied to running WordPress applications. Could you help to give detailed steps how to upgrade all the currently running application instances?

Thanks,
Simon

[devdattakulkarni]

@simonzhong1985 Thank you for the question. Application upgrade is a feature that is coming up soon.

Your approach of updating the ResourceComposition with a new chart URL is correct. That is how the upgrade will be initiated. We will keep you posted here as we make progress on the implementation of this feature. It is currently in the works.

[simonzhong1985]

@devdattakulkarni Thanks for you quick response. Do you mean the approach of updating the ResourceComposition with a new chart URL is not implemented now? If yes, could you provide an approximate time ? Then we evaluate our plan. One more thing, are there any other methods to upgrade running applications for now?

[devdattakulkarni]

@simonzhong1985 Let me know what timeline you are looking at. Also, if you can share the details a bit about your use case that will help. If more convenient, you can email me at devdatta at cloudark dot io.

[simonzhong1985]

@devdattakulkarni I mean when will this feature upgrading running applications be released, roughly? And before the release, are there any other recommended methods or best practice to upgrade running applications for now?

[devdattakulkarni]

@simonzhong1985 We should be able to complete it by June end/early July.

In the meantime, you can upgrade running instances as follows. Let's take the example of Wordpress.
You would split the chart into two charts - a chart for MySQL and a chart for Wordpress app. Create two APIs, one for MySQL and another for Wordpress (WordpressV1). First, instantiate the MySQL API instance. Then create WordpressV1 instance in the same namespace as that of MySQL instance (if a namespace is provided then KubePlus will not create a new namespace). Make sure that the connection between Wordpress instance and MySQL instance is established properly by setting the name of the WORDPRESS_DB_HOST environment variable in the Wordpress chart to the name of the Service object representing the MySQL instance.

In order to update this instance, register a new Wordpress API (say, WordpressV2) using a new ResourceComposition (with new Wordpress chart with the new image). Create an instance of WordpressV2 in the same namespace as the earlier instance. Set the name of the WORDPRESS_DB_HOST to the value of the same MySQL instance as that for WordpressV1 instance. Once the new instance is up and running, delete the old instance.

[simonzhong1985]

@devdattakulkarni Thanks a lot. The time line seems OK for us,
Regarding the steps you listed above, I'm not clear about some of them.
Create two APIs, one for MySQL and another for Wordpress (WordpressV1). --- What does API mean here?
register a new Wordpress API (say, WordpressV2) using a new ResourceComposition (with new Wordpress chart with the new image). ----What does API mean here?

Based on my knowledge, I tested such way to upgrade running applications as below. It's possible the method is not good choice. Hope you can offer some comments.

1. find all active namespaces generated by kubeplus
2. loop these namespaces and execute below command.
   kubectl patch deployment wp-tenant1 -n wp-tenant1 --type=json --patch="[{'op': 'replace', 'path': '/spec/template/spec/containers/0/image', 'value': '<<new version>>'}]" --kubeconfig=kubeplus-saas-provider.json
   After executing the command, the application can be upgraded to expected new version. Any comments?

[devdattakulkarni]

@simonzhong1985 Your method looks fine and should work.

In the steps that I listed, API == CRD.
Essentially, the steps that I listed involve creating a new CRD and a new instance of that.
Your steps have the advantage that they don't require generating a new CRD. The advantage of generating new CRD is there remains traceability of what image is being used in a given application instance.
If the steps that you have listed above worked fine for you, I would suggest continuing with them.

[simonzhong1985]

@devdattakulkarni Hi, any progress about upgrading running applications via updating the ResourceComposition with a new chart URL?

[devdattakulkarni]

@simonzhong1985 Thanks for your patience. Our team has been working on a couple of other improvements that are necessary for the correct handling of ResourceComposition updates. These improvements are almost complete now. We will be taking up ResourceComposition updates next.

cc: @eminalparslan

[simonzhong1985]

@devdattakulkarni Thanks a lot for your cool work. In fact, if we want to use it in our product, there are still some concerns. Could you help to give comments?

1.The project doesn't have many or often releases which has impact on its security as it's using outdated versions with security vulnerabilities.
for instance:
a.gcr.io/cloudark-kubeplus/platform-operator:3.0.4 has 75 potential vulnerabilities reported by scanner
b.image has bash inside ( from sec perspective we would prefer distroless )
c.lack of K8s copmatibility matrix ? like which version works | supports which version of k8s
d.based on dependencies version like https://github.com/cloud-ark/kubeplus/blob/master/platform-operator/go.mod it's safe to use it with k8s 1.24 which will be EoL end of July

2.Helm chart templating, for instance:
a.doesn't provide templating for images repository
b.Lack of securityContext in deployment, lack of seccompProfile usage

[devdattakulkarni]

@simonzhong1985 These are great questions. I am thrilled to hear that you are considering including KubePlus as part of your product.

I acknowledge that we have not been tagging releases of the codebase as often as we would have liked. Instead, we have focused on updating the functionality and releasing updates to the KubePlus Helm chart frequently. That said, we do plan on updating the KubePlus components to address the vulnerabilities reported by the scanner. As part of this, we can definitely take a look at rebuilding the KubePlus component images using distroless base images. With regards to the Kubernetes compatibility matrix, yes, that is another aspect that we will publish soon. Typically, we have been striving to be compatible with the latest version of Kubernetes.

Regarding Helm charts, we have an outstanding PR that will address a) (#1103). As for b), we can definitely enhance the Helm chart with securityContext (I would request a PR for this if you have something specific in mind. That way, it will be easier for us to accommodate exactly that spec definition that you want).

Strategically speaking, we plan to submit KubePlus as a CNCF Sandbox project in the near future. That will help attract community and resources which will help us address such issues and concerns in a timely manner. Your usage of KubePlus (or better yet, a PR in KubePlus) will immensely help in the Sandbox process. In this regard, if you can share your current usage (or plan of using) KubePlus, that will be great!