Hello Peter,

The answer is yes to both your questions, but I suspect that it is simpler to extend the Kanister-tools image to include the applications you need. The offline mode is not pertinent to the scenario described.

The official Kanister-tools image balances the conflicting needs of including everything (such as your examples) versus required base-level functionality for testing, which minimizes the attack surface for security updates.

Kanister documentation is a little sparse, but there is an example of how to modify the Dockerfile = https://docs.kanister.io/tooling.html#docker-image

Let me recommend you join the Kanister Slack channel!
https://join.slack.com/t/kanisterio/shared_invite/enQtNzg2MDc4NzA0ODY4LTU1NDU2NDZhYjk3YmE5MWNlZWMwYzk1NjNjOGQ3NjAyMjcxMTIyNTE1YzZlMzgwYmIwNWFkNjU0NGFlMzNjNTk

Cheers,
--Mark

Hi @mark.lavi ,

Thanks for your response, I really appreciate it. But I’m still not sure how we could utilize the private registry in the Blueprints. What we want to achieve is to replace the following image registry:

With our ECR private registry:

We tried to set the `global.imagePullSecret` in the Helm Chart with name of the secret containing ECR registry credentials, but there is no visible reference of the secret in the scheduled kanister pod, which is why we’re getting the 401 Unauthorized errors when trying to pull the image from the registry:

I didn’t see any other places where I could configure the pull secret. Does the Kanister have the functionality I’ve described above or you can only pull public images and offline images in air-gapped environment?

Peter,

For a timely response, I’ll give a tentative answer and ask others to review and confirm.

Installing Kanister, by itself, would require modifying other Helm arguments for this chart, see this document: https://github.com/kanisterio/kanister/blob/master/helm/kanister-operator/README.md#installing-the-chart

But from your question, I suspect you’re installing Kanister in context with K10. I’ll ask how a public Helm K10 install can be overridden with a custom Kanister tools image. If that’s not possible, then you may need to resort to an entire K10 private registry scenario, essentially air-gapped mode, see  https://docs.kasten.io/latest/install/offline.html

So I’ll ask for confirmation, but in the meantime:
can you clarify if you’re installing Kanister standalone or with Kasten K10’s chart?

Thanks,
--Mark

> The sidecar injection is done automatically by mutating admission webhook.

Hi Peter,

Just for my understanding when you talk about sidecar injection, did you use K10’s sidecar injection or you have some separate mechanism that is injecting the sidecar in your application?

About your questions

1. Most of the times, we would need to create the blueprint only once for an application. So when we are creating the blueprint we can configure the imagePullSecret for the kanister functions (KubeTask etc) using the podOverride field itself. We dont have  a helm field to set this up. Example can be found in the docs here https://docs.kanister.io/functions.html#kubetask. Please feel free to get back to us if you face any challenge configuring this.
2. If you are talking about the kanister-sidecar image that we configure while specifying a function (KubeTask etc) in kanister blueprint, you can specify any image that you want to, using the function argument `image`. 

I hope this answers your questions, if not, please feel free to get back to us and we would be more than happy help you with this.

Hi guys, sorry for the lack of response throughout the weekend.

@mark.lavi We’re using Kanister only in conjunction with Kasten, so we’re only installing K10 using Helm and all other tools (such as Kanister) are already bundled in.

We deploy Kasten through ArgoCD, therefore our values for Helm look as follows:

Hopefully it’ll give you an idea how we’re using Kasten and Kanister.

@viveksinghggits Your solution (1. point) is actually what we need to cover all our questions about Blueprints, thanks! Now, we’re able to build custom images, store them in private ECR registry and have them pulled from ECR by the scheduled Blueprint (KubeTask) pods. Awesome!

The second question remains open - if the above is possible for injected kanister-sidecar containers in a pod.

We found the following section in a documentation: https://docs.kasten.io/latest/kanister/override.html#kanister-pod-override which talks about overriding the pod specification, but I assume it applies to the Blueprints job pods, which we now have covered.

We would like to override the specification for kanister-sidecar container in all pods or in a specific pod, without manually adding the second container to the pod with given specification, which of course would work.

The summarized course of action would be:

1. We enable injection of kanister sidecar to corresponding workflows
2. Now we have two containers inside a pod - one is our workload, second one is kanister-sidecar

   

3. The kanister-sidecar pod has a default image, with tag matching the Kasten version:

   

4. We would like to override this image, so we can have whatever tools we need  in this sidecar container. If the tool support remote backup we can use KubeTask and perform the backup. If we need to e.g. tar the directory structure of the volume mount wee need KubeExec targeting kanister-sidecar, since it has the same volume mounts as the actual workload. That’s why we are so relentless of finding out the way to override the image - the current default image does not have the tools we need.

Nonetheless, thanks for every answer and hint @mark.lavi, @viveksinghggits , we wouldn’t be able to discover that by ourselves.

Hi @peterturnip ,

Thank you, glad to know the answers helped.

If you want we would be more than happy to help you achieve what you want to do.

If I understood you correctly, you have a blueprint with a kanister function in it. And want to change the image for that kanistter function, Is that right?

If that is the case, when do you want to change the image? Do you want to change it whenever you run a backup (action)? And would you have diff image every time you run an action (backup)?

What is the use case of giving different image, every time we run an action. Because like I said earlier, when a blueprint is written we know which application the blueprint is being written for, so we can just create a image once and have that image in the blueprint. I think I am not able to understand the use case of changing that image to something else.