Kubectl apply -o json issue

I am trying to deploy a simple deployment.yaml using “deploy raw Kubernetes YAML” step.

I am getting the attached error. Can you please help get this resolved please?

Hi @manjunatha.karekal,

Thanks for reaching out.

I guess the first thing to ask is, what version of kubectl are you running on your worker?
You should be able to find out by using the command kubectl version.

Have you tried using a worker with the latest kubectl version, for example: octopuslabs/k8s-workertools? You can utilise this image as an execution container.

Let me know if this works or not, and we can continue to diagnose what the issue may be.



Hi Dane,
Thanks for responding. Please note that I am using v1.23 of Kubectl which was earlier suggested by Octopus only. To integrate with AWS EKS kubernetes cluster. Can you pls confirm if I use the latest version of Kubernetes, wont it break the integration between Octopus and Kubernetes?

Hi @manjunatha.karekal,

My apologies. I didn’t realize this was part of an ongoing issue.

I was purely addressing the error in your logs. If there are some underlying reasons why you need to use 1.23 of kubectl then I will need to understand the reasons why that version was suggested. Often there will be a need to stay on a particular version for a short time, while our steps ‘catch up’ with the latest syntax changes etc, however I’ve reached out to the other support team members to see if they know of a reason why this might be the case, but nobody is aware of the context of this suggestion.

I’ve also looked through your previous tickets, but am unable to pinpoint where this was suggested.

Please let me know the background of that suggestion and I will do my best to find a solution for you.



Hi Dane,
I think the main reason of this issue could be difference. Pls refer to the attached screenshot. It seems octopus is trying to create customresource.yml and the access is forbidden. Can you please help?

Can we please come on call to close this issue? This is delaying our environment delivery.

Hi @manjunatha.karekal,

I am happy to organise a call if necessary - but at this point in time, a call would involve me asking the same questions as I’ve already asked, and then going away and investigating so would not be a great time investment for anyone involved.

I need to understand why there was a request to keep kubectl at version 1.23. I still have been unable to find that recommendation. Was the recommendation made because you are on an older version of Octopus or you have some legacy requirements?

When you mentioned that the latest version of Kubernetes might break the integration between Octopus and Kubernetes, using an execution container would allow you to try the latest Kubernetes version and then if it didn’t work, you would be able to change the step back to using your current worker setup.

The next step, would be for me to attempt a reproduction on my end. If I was able to deploy successfully, then the problem would likely be localized permissions issue, that you may need to address. In order for me to perform the reproduction, I will need to understand your deployment process and get some details about your worker setup

At this point, the errors in the logs, point to two areas which should be your main focus of concern. The user receiving a “Forbidden” response and kubectl requesting an upgrade of kubectl.

If you could provide the following information and if I’m unable to find a reason for the issue your facing, I would be happy to jump on a call to have a closer look.

  1. Can you upload your raw deployment process for the project? If there is an issue with sharing the entire raw deployment process, then please provide it for just the step you are having issues with.

  2. Can you provide the deployment logs (just Step 5 from this guide for the deployment.

  3. Can you please let me know why you were asked to keep kubectl at version 1.23? Alternatively, if you could point me in the direction of the ticket or individual who provided that advice - I can chase up the answer from my end.

  4. Additionally can you double check the permissions for system:node:ip-10-69-17-42.eu-west-2.compute.internal. This tells you exactly what you will need to check.

So that you aren’t sharing these logs in our public forum, I have created this secure file upload link for you.

Please let me know if you have uploaded files using that link by responding to this ticket, as I’m not automatically informed of any uploads.

Hopefully we can get you unstuck quickly.



This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.