I have an OpenShift server I'm trying to work on. When I use:
oc apply -f
My request is successfully processed.
However, many tools I want to use for development expect kubectl
to be used to connect to the cluster. In most circumstances, I can use kubectl
with no problems.
However, in the case of kubectl apply -f
, this fails with error:
Error from server (Forbidden): unknown
While running oc apply -f
works as expected.
To try to bypass this, I created (on Windows) a symbolic link named "kubectl" to the oc
executable. Unexpectedly, this caused the oc
command to start behaving like the kubectl
command, and again receiving the same error.
Calling the full path to the link, as well as simply renaming "oc.exe" to "kubectl.exe" produces the same error. I confirmed I was indeed calling the correct bianry by running kubectl version
, and I received different results from the vanilla binary vs. the openshift wrapper.
Enabling verbose logging: kubectl apply -f service.yaml --v 6
gives this output
I0625 13:09:43.873985 11744 loader.go:357] Config loaded from file C:\Users\username/.kube/config
I0625 13:09:44.175973 11744 round_trippers.go:436] GET https://myhost:443/swagger-2.0.0.pb-v1 403 Forbidden in 286 milliseconds
I0625 13:09:44.179974 11744 helpers.go:201] server response object: [{
"metadata": {},
"status": "Failure",
"message": "unknown",
"reason": "Forbidden",
"details": {
"causes": [
{
"reason": "UnexpectedServerResponse",
"message": "unknown"
}
]
},
"code": 403
}]
Running using oc apply -f service.yaml --v 6
gives almost the same result, except that after the initial 403 error, I get the following output:
I0625 13:37:19.403259 7228 round_trippers.go:436] GET https://myhost:443/api 200 OK in 5 milliseconds
And the command continues on to work correctly.
Is there anyway I can bypass this odd behavior, and somehow use kubectl
to successfully run kubectl apply -f
against the OpenShift server?
Edit:
The oc
binary wrapper uses kubectl 1.9.
The vanilla kubectl
command uses 1.10.
The server is kubectl 1.6 and openshift 3.6.
what client and server version do you have?
kubectl attempts to do client-side validation when it creates/applies objects. to do this, it first downloads the openapi schema. when making requests to an older server, that endpoint may not be recognized, and may result in a "forbidden" error
setting --validate=false
when making the kubectl apply call will bypass that client-side validation (server-side validation is still performed)