I am facing permission denied errors when using kubectl for all commands, be get pods or apply, but I am able to use helm and login with k9s to perform destructive actions. I am using the same context for all of these actions.
kubectl get nodes
# error: You must be logged in to the server (Unauthorized)
kubectl apply -f some-manifest.yaml
# error: You must be logged in to the server (the server has asked for the client to provide credentials)
Does anyone have a hint as to why this is happening or what to look further into? I am using a managed k8s on Vultr, a smaller cloud provider.
Don't know what specifically the issue was but I rebuilt my .kube/config file slowly with all my contexts and it ended up working again.
Very strange though that helm worked and kubectl didn't though...
I am pretty sure that this is a "kubernetes context" problem
Check the solution here: helm and kubectl context mismatch
Solution for k9s can be found here: https://k9scli.io/topics/commands/
Related
I am creating mongodb cluster using following documentation.
https://github.com/mongodb/mongodb-kubernetes-operator/blob/master/docs/deploy-configure.md
I am trying to create custom resources as following.
kubectl apply -f config/samples/mongodb.com_v1_mongodbcommunity_cr.yaml
It is saying created successfully but I am unable to see any replicaset created for that and also no pods are being created for the same. I am using minikube to generate resources.
Got the issue as I came to know how can we check logs of custom "kind" in Kubernetes.
As I checked mongodbcommunity kind as follows. And it was giving failed stage.
kubectl get mongodbcommunity
Then I checked the following command for mongodbcommunity.
kubectl describe mongodbcommunity
It was showing errors as secrets are not found. I had changed credentials in custom resources but didn't update in secrets. So it was failing.
In the dashboard, nothing was happening and even during executing yaml no errors were showing up and were showing as "created".
So I just didn't know how to check the issue for this but figured way and after correcting the username properly MongoDB cluster is working fine now.
I am trying to install Greenplum on GKE using the directions here
I make it to step 12: but my operator pod is failing because it cannot pull the secret:
kubectl logs -l app=greenplum-operator -n greenplum
{"level":"INFO","ts":"2020-03-10T18:20:50.803Z","logger":"operator-setup","msg":"Go Info","Version":"go1.13.7","GOOS":"linux","GOARCH":"amd64"}
{"level":"INFO","ts":"2020-03-10T18:20:50.803Z","logger":"operator-setup","msg":"creating operator"}
W0310 18:20:50.803978 1 client_config.go:541] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work.
W0310 18:20:50.804036 1 client_config.go:546] error creating inClusterConfig, falling back to default config: open /var/run/secrets/kubernetes.io/serviceaccount/token: permission denied
It looks like a permissions issue pulling the image, but the image pull test earlier in the instructions succeeded:
job.batch/greenplum-operator-fetch-test created
GREENPLUM-OPERATOR TEST OK
job.batch "greenplum-operator-fetch-test" deleted
Has anyone else run into this issue?
There's a bug the current documentation. You most likely did everything right. However, creating a GKE cluster with "Enable Kubernetes alpha features in this cluster" as listed on the prerequisites page (https://greenplum-kubernetes.docs.pivotal.io/1-12/prepare-gke.html) is no longer necessary. In fact, it's currently causing the exact issue you seem to be having. Try creating a GKE cluster following all of the documentation except make sure to NOT enable GKE "alpha features".
What is the best way to troubleshoot when kubectl doesn't responde or exit with timeout? How to get it work again?
I'm having my kubectl as well as helm on my cluster down when installing a helm chart.
General advice:
Check if your kubectl is connecting to the correct kube-api endpoint. You could take a look at your kubeconfig. It is by default stored in $HOME/.kube. Try simple CURL to make sure that it is not DNS problem, etc.
Take a look at your nodes' logs by ssh into the nodes that you have: see this for more details instructions and log locations.
Once you have more information, you could get yourself started in the investigation of problems.
In the guide https://istio.io/docs/tasks/traffic-management/egress.html, there is a way to access non-http traffic by includingIPRanges. However, when I follow the instructions I still am unable to access anything. Should this rule allow me to bypass istio for egress as I think it should or am I missing something?
I run a version of this command
kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml --includeIPRanges=172.30.0.0/16,172.20.0.0/16,10.10.10.0/24) is the command it suggests for bluemix users, but this does not work for me. When I try to store from my app in cloud object store I get a 500 error, however with no istio sidecar the store function works perfectly.
It works fine for me using Istio 0.2.10 on a Bluemix free tier cluster. Are you saying that the egress task doesn't even work for you, i.e., you can't do the curl suggested in the task?
kubectl exec -it $SOURCE_POD -c sleep curl http://httpbin.org/headers
A 500 error doesn't sound like a problem related to reach-ability anyway. That sounds like the server you're calling is crashing?
I've created a Kubernetes cluster using CoreOS on AWS and I'm having trouble communicating with nodes from the master.
For example, operations like kubectl exec or kubectl logs fail an error similar to the following:
Error from server: dial tcp: lookup ip-XXX-X-XXX-XXX.eu-west-1.compute.internal: no such host
I've found some issues on Github that describe the problem so I know the team knows about this bug, but I would like to ask here if its possible to use some workaround until it gets addressed somehow.
One workaround mentioned was to use the --hostname-override flag but as I'm on AWS, this flag is ignored (see #22984)
Related issues on GitHub: #22770 #22063.
Have you made sure you're using the right context?
kubectl config use-context my-cluster-name