Closed rombert closed 3 years ago
@rombert I have just tested this with similar configuration to yours, for it me it works fine , do you still have this issue?
@markrity - I'll double-check and let you know
@markrity - this still fails for me. In the meantime I upgraded kubectl
to 1.17.0, but that did not help.
I tried debugging a bit myself, and have some extra information, maybe that rings some bells:
The following scenarios work:
The following scenarios do not work:
I ran the velero -v 9 version
command for both working and failing scenarios, and the HTTP calls seem to be the same for both. Notably, the server IP is the correct one.
The C file references a development cluster running on a private network on my machine, e.g.
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: <REDACTED>
server: https://10.24.0.70:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
namespace: datadog
user: kubernetes-admin
name: homelab
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
user:
client-certificate-data: <REDACTED>
client-key-data: <REDACTED>
A couple of questions:
-v 9
.Thanks!
@rombert The only scenario that is missing in my point of view is KUBECONFIG=C
.
Because it looks like that it is the common value for a failure.
I will take a deeper look soon, thanks for providing more information !
@markrity - I did not try that since the cluster is configured with file A, so using C would not lead to a meaningful result.
@rombert @markrity Thank you both for looking into this!
Velero's been updated with new Kubernetes APIs since January - is this still happening with v1.4.x and v1.5.x? Admittedly I'm not running against multiple clusters, but if it's still happening, I'll get it allocated into the backlog.
@nrb - I just checked and the problem does not seem to be there anymore
$ velero version
Client:
Version: v1.4.2
Git commit: 56a08a4d695d893f0863f697c2f926e27d70c0c5
Server:
Version: v1.3.1
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df", GitTreeState:"clean", BuildDate:"2020-10-15T00:00:00Z", GoVersion:"go1.15.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.12", GitCommit:"5ec472285121eb6c451e515bc0a7201413872fa3", GitTreeState:"clean", BuildDate:"2020-09-16T13:32:12Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}
@rombert Interesting, thanks! I'm going to close this issue out for now. Of course, feel free to comment again if you run into further problems.
I use Velero v1.8.1 and i am a same problem.
When I use a multiples contexts :
$ echo $KUBECONFIG
~/.kube/config:~/.kube/config:/home/xxxxx/Documents/XXX/k8s-ovh/kubeconfig.yml
I have error connect :
$ velero debug
.2022/06/17 14:38:19 Collecting velero resources in namespace: velero
An error occurred: exec failed: Traceback (most recent call last):
velero-debug-collector:23:13: in <toplevel>
<builtin>: in kube_get
Error: could not initialize search client: invalid configuration: [context was not found for specified context: kubernetes-admin@XXX, cluster has no server defined]
But, the context error message disappears if i reconfigure my KUBECONFIG with only one context :
$ export KUBECONFIG='/home/xxxxx/Documents/XXX/k8s-ovh/kubeconfig.yml'
$ velero debug
2022/06/17 14:54:32 Collecting velero resources in namespace: velero
2022/06/17 14:54:34 Collecting velero deployment logs in namespace: velero
2022/06/17 14:54:35 Generated debug information bundle: ~/bundle-2022-06-17-14-54-32.tar.gz
It's a bug or bad use ?
What steps did you take and what happened:
I am using the velero CLI with a KUBECONFIG env variable set to multiple files, e.g.
The CLI is unable to authenticate by default:
On the other hand, when settubg the env variable to a single file - which is the cluster where velero is deployed - velero works
What did you expect to happen:
The CLI tool should support the same type of KUBECONFIG setings that
kubectl
does and shouldThe output of the following commands will help us better understand what's going on:
(not applicable)
Environment:
Velero version (use
velero version
):Velero features (use
velero client config get features
):Kubernetes version (use
kubectl version
):Kubernetes installer & version:
not sure
Linode Kubernetes Engine
/etc/os-release
):