jiebi/CodeConvo huggingface dataset:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: kubelet throws the exception when --cloud-provider=cloudstack is included: What you expected to happen: There shouldn't be an exception. How to reproduce it (as minimally and precisely as possible): Add the following line to /etc/systemd/system/kubelet.service.d/10- Environment="KUBELETEXTRAARGS=--cloud-provider=cloudstack --cloud-" and also configure the file. Anything else we need to know?: The condition check in the InstanceType() function in is wrong. It currently reads: but the correct code is (condition negated): Environment: Kubernetes version (use ): 1.8 Cloud provider or hardware configuration: cloudstack OS (e.g. from /etc/os-release): Ubuntu 16.04.3 LTS (Xenial Xerus) Kernel (e.g. ): 4.4.0-98-generic Install tools: kubeadm Others: /sig cloudstack
I will have a look
/sig cluster-lifecycle /area cloudprovider
Typo fix. Will add the PR links.
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
You don't need an issue for typo fix. Please submit the PR directly.
/kind cleanup
sure, let me close it.
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): no What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): subpath, emptyDir, mode, permissions Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-01-12T04:57:25Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-01-12T04:52:34Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: Bare metal, SSD, but also VMs OS (e.g. from /etc/os-release): Debian GNU/Linux 8 (jessie) Kernel (e.g. ): 4.8.0-0.bpo.2-amd64 Install tools: Others: Docker v1.12.6 What happened: When I mount an volume using a subpath, I'm unable to write into it if my process is not running as . When I leave out the subpath, I can. What you expected to happen: I can write to the directory in both cases.
How to reproduce it (as minimally and precisely as possible): Output is: Anything else we need to know: This issue is related to . I know this is caused by the Docker daemon creating those directories on a bind mount. Nevertheless, I expect Kubernetes to abstract this away, since this behavior is neither documented nor IMHO intuitive.
Could someone from please take a look? Thanks! cc:
cc/
attempted fix created here
I created a cherrypick PR for 1.6 here: since this bug is against 1.6. Could someone (who agrees this could be cherrypicked) please add the cherrypick-candidate label + milestone to the original PR , thank you! edit: sorry, it's against 1.5. Should it be cherrypicked back to that as well?
I'm still facing this issue with Kubernetes version 1.12.8 on a AKS cluster when I mount a Azure Storage as azureFile share. Did anyone know if the issue is fixed for all types of mounts and not only just the emptyDir?
same issue on GCP @ k8s 1.14
k8s 1.17 via eks as well
So what's the recommendation? Not using subPath?
BUG REPORT: (I think?) What happened: I ran the following steps on Ubuntu 16.04: Upon doing this, I receive: I've tried uninstalling , and a couple of times (even with ) and no matter what I do, it (kubeadm 1.7) doesn't generate a working . However, I run the following: and get: What you expected to happen: After initializing the master via , I expected to be able to use to install a network plugin; since it 's, I cannot do that. Environment: Kubernetes version (use ): 1.7 OS (e.g. from /etc/os-release): Ubuntu 16.04.2 LTS Kernel (e.g. ): Linux radium-control 4.4.0-83-generic -Ubuntu SMP Mon Jun 26 17:54:43 UTC 2017 x8664 x8664 x86_64 GNU/Linux
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig cluster-lifecycle
Unsure if this helps, but I had the same and realised I was using the old setup guide, copying into and setting . I cleared the environment variable and defaults back to using .
I'm also seeing this using kubeadm v1.7 - it's preventing nodes from joining the cluster
Same error for my installation. Try with v1.6.5 and 1.6.7 it works fine.
Same problem here. . ( seems okay) ( seems okay, too) (but fails)
do you have pointing to ?
After I set the to , now it gives me a timeout error. And now I want where the came from because there is no such statement in the I'm referencing.
From the output of the node join command:
Encountered same problem while playing with kubeadm. After and for a few times, kubelet will fail communicating with apiserver because (in kubelet logs). And also blocks for ever. After removing manually, all things come back. Maybe there are problems of cleaning certificates when running ?
/area kubeadm
I am on kubeadm 1.8 and this problem still occurs. I manually checked . It was cleaned when I ran . Not sure what the actual problem is.
ATTENTION: "To start using your cluster, you need to run (as a regular user)" [root ~]# kubectl get nodes Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes") [root ~]# su - regularuser [regularuser ~] [regularuser ~] regularuser ~: [regular_user ~]$ kubectl get nodes NAME STATUS ROLES AGE VERSION NotReady master 6m v1.8.1 NotReady <none4m v1.8.1
Thanks. It works.
Please update docs with this workaround
If you kubeadm reset and then kubeadm init again, and if you ever ran the following as root, you need to run it again (as root) to get the new config: mkdir -p $ sudo cp -i $ sudo chown (id -g) $ Then you can still run as root.
if found that if you were ever going to run "sudo kubeadm reset" you'll need to remove your .kube dir to clear the cached dirs. After that you can follow oh, be sure to set KUBECONFIG to whatever you (re)name your config file to e.g. $
tanks freind ints true.
Config as the following lines, $kubectl get nodes works:
this is likely because you have a multi master setup and have generated the on each of the masters. Rather than copying them from the first master to the rest.
I found the solution in the kubernetes documentation while following the documentation dont forgot to create .kube directory using this command Because as you need this command it will move the .kube directory
For others that might have this issue, might want to try and move the folder to backup location if it exists and retry. Very possible to have a cached root version being used that is no longer valid, as you will run kubeadm as sudo.
My problem was I had custom certificates I had created during the KubeEdge Getting Started guide. Not messing around with ssl and kubeedge made it work.
I am running into a problem with the Cinder plugin when running Kubernetes inside Docker using the kube-deploy/docker-multinode project I modified the worker and master scripts of the latter project such that: --cloud-provider and --cloud-config options are to the hyperkube command I mount a host dir with the cloud_config file into the kubelet container (with the -v option) The cinder plugin of kubernetes (for attaching Openstack Cinder volumes) attaches a volume successfully and then tries to find the corresponding device. However the cinder plugin can't find this device by disk-id: The last log entry shows a failure to run . I tried to run this command from within a bash session inside the kubelet container and then got as error: How can I solve this? Thanks for any advice
CC
It basically tries to run to probe all attachments so sym link for the disk is created in . Is this the command you tried to run from command line?
Yes. However I now see that I misread the debuglogs that the full command was the following: . But this is wrong syntax obviously I launched Kubernetes version 1.2.6 in the dockerized version of hyperkube. I assume that the error lies somewhere in the fact that certain commands don't work properly when run inside a container. To further debug, I just had a look at the code from that reported the error (see below). First an executor is created using . Then this executor is asked to execute command . The implementation of the executor will try to execute the command in a child process (hence the fork)
I think I'm running into a related issue, or at least the same root cause. When using PV+PVC Cinder volumes the Kubelet fails to confirm that they are attached (even though I see the volume is attached in Horizon). The same error shows in the kubelet logs: However, on Ubuntu 16.04 at least, is located in a different place:
Adding a symlink to the correct location seems to have resolved the issue for me:
Logs look like: originally mentioned in started a WIP PR to recreate, please see: /sig cloud-provider /sig testing cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
more comments on the original issue, it may be possible that error is a symton and the root cause is on the installation process
xref:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig storage
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
please see <img width="840" alt="image" src=""
looking at the failures could be between the following SHA(s):
the main commit there is can you please look into it?
shows the same as well. commit range is
Found the issue, proposing a fix in
https://k8s- Failed: [] [HPA] Horizontal pod autoscaling (scale resource: CPU) [] ReplicationController light Should scale from 1 pod to 2 pods {Kubernetes e2e suite} Previous issues for this test:
Builds: ci-kubernetes-e2e-gce-release-1.5 ci-kubernetes-e2e-gci-gce-release-1.5 ci-kubernetes-e2e-gci-gke-release-1.5 ci-kubernetes-e2e-gci-gke-staging-parallel Failed: [] [HPA] Horizontal pod autoscaling (scale resource: CPU) [] ReplicationController light Should scale from 1 pod to 2 pods {Kubernetes e2e suite}
Builds: ci-kubernetes-e2e-gke-release-1.5 ci-kubernetes-e2e-gke-staging-parallel Failed: [] [HPA] Horizontal pod autoscaling (scale resource: CPU) [] ReplicationController light Should scale from 1 pod to 2 pods {Kubernetes e2e suite}
There is a problem w/contacting controller service. This is already fixed by on master. The fix needs to propagated to the 1.5 branch.
ping looks like this is still occasionally happening, PTAL
Looking at the most recent issues here: it looks like there were a lot of instances where it wasn't this bug -- something else failed (like cluster networking, or connection to the API server), which caused this test to fail. There are a couple where there weren't a bunch of simultaneous failures, and on those I see some failures to collect metrics at all (but hard to tell anything w/o getting the Heapster logs). Finally, I do see a test run (https://k8s-) from 9 days ago where it looks like we are getting metrics from Heapster, just perhaps not the right ones. I'll do a bit more digging. P.S. Is there any way we can get the Heapster logs as part of the saved artifacts from test runs
How does heapster run? Is it possible to get the logs into the artifact directory?Here's the script that dumps the logs:
I've inspected https://k8s- run.
HPA correctly scales "from 2 to 1" in the previous test case, but there are no HPA logs at all for subsequent test case for "from 1 to 2". Anyway, this problem appeared to happen only once 14 days ago, many bugs have been fixed since then. Most probably the root of the problem was not related to HPA. In my opinion, this should not be a release blocker.
This Issue hasn't been active in 53 days. It will be closed in 36 days (Jun 12, 2017). cc You can add 'keep-open' label to prevent this from happening, or add a comment to keep it open another 90 days
Closing as obsolete.