jiebi/CodeConvo huggingface dataset:
Code change:
} func (rc *resourceMetricsCollector) collectContainerStartTime(ch chan<- metrics.Metric, pod summary.PodStats, s summary.ContainerStats) { <del> if s.StartTime.Unix() == 0 { </del> <ins> if s.StartTime.Unix() <= 0 { </ins> return }

Related discussion:
text: As described in , When the pod start or stop, negative metrics generated. generate the correct metrics pod restart No response <details</details<detailsnone </details<details</details<details</details<details</details<details</details
/sig node /sig instrumentation
can you please give a little bit more information on steps to repro. Is it happens all the time? Is the root cause known (I see a linked PR). /triage needs-information
This is a feedback from contributors in kubernetes-sigs/metrics-server. It is riggered on specific conditions. From the description of several issues, the way to reproduce should be pod start or stop. such as:
Do you know if this is specific to ?
I'm not sure. However, obtains data from the kubelet endpoint. If there is a negative value, it will cause statistical problems.
/triage accepted /assign
FYI I encounter this with . seems to be an uninitialized time type. The in is create from the response of cri RPC, this maybe cause either by cri-o or the metrics collect part of Kubernetes. I have not dig into it yet.
Code change:
# TODO: split this out into args when we no longer need to pipe stdout to a file #6428 - sh - -c <del> - '/glbc --verbose=true --apiserver-host=http://localhost:8080 --default-backend-service=kube-system/default-http-backend --sync-period=600s --running-in-cluster=false --use-real-cloud=true --config-file-path=/etc/gce.conf --healthz-port=8086 1>>/var/log/glbc.log 2>&1' </del> <ins> - 'exec /glbc --verbose=true --apiserver-host=http://localhost:8080 --default-backend-service=kube-system/default-http-backend --sync-period=600s --running-in-cluster=false --use-real-cloud=true --config-file-path=/etc/gce.conf --healthz-port=8086 1>>/var/log/glbc.log 2>&1' </ins> volumes: - hostPath: path: /etc/gce.conf

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When kube-apiserver's livenessProbe suggests that pod is unhealthy, kubelet tries to kill its container with 30 seconds grace period. The container is killed ungracefully with SIGKILL when grace period passes. This happens each time. What you expected to happen: I expected that SIGTERM will be passed to kube-apiserver which will try to gracefully stop before 30 seconds pass (at least in some cases). How to reproduce it (as minimally and precisely as possible): Inject kube-apiserver failure (e.g. ) Watch kubelet logs for container's death You will see that container is killed after 30 seconds each time Anything else we need to know?: I believe the problem is that in kube-apiserver.manifest uses '/bin/sh -c CMD' as a PID1 process which doesn't pass SIGTERM signals to child process. See Environment: Kubernetes version (use ): v1.7.11
/sig node
Looks like without the pipe command will have to be removed which will make the logs hard to track. There is indeed some which makes kube-apiserver run in background and trapping SIGTERM then send a SIGTERM to apiserver's PID.
I think this is the case for all our components, not just kube-apiserver. - FYI
How about using 'exec'-based solution suggested here: In our case it means prepending 'exec': I did changed this in my cluster and the process seems to meet requirements: fd/1 and fd/2 are redirected to /var/log/kube- container is killed instantaneously If everyone is fine with such a solution, I can prepare PR adding 'exec ' in front of all kubernetes/cluster/saltbase/salt/kube-apiserver/*.manifest using '/bin/sh -c CMD' pattern.
Not sure if understand what you mean. Before there was no logs, so /bin/sh -c wasn't needed. -based solution seems to have all required properties. What is your concern about using it?
Umm. just ignore my previous comment. I just tried prepending and it works fine for me.
Code change:
# TODO: split this out into args when we no longer need to pipe stdout to a file #6428 - sh - -c <del> - '/glbc --verbose=true --apiserver-host=http://localhost:8080 --default-backend-service=kube-system/default-http-backend --sync-period=600s --running-in-cluster=false --use-real-cloud=true --config-file-path=/etc/gce.conf --healthz-port=8086 1>>/var/log/glbc.log 2>&1' </del> <ins> - 'exec /glbc --verbose=true --apiserver-host=http://localhost:8080 --default-backend-service=kube-system/default-http-backend --sync-period=600s --running-in-cluster=false --use-real-cloud=true --config-file-path=/etc/gce.conf --healthz-port=8086 1>>/var/log/glbc.log 2>&1' </ins> volumes: - hostPath: path: /etc/gce.conf

Related discussion:
text: <!-- 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.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG <!-- 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 ): 3 Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: All of the salt scripts bundled in kubernetes (for example, ) start up the component in a broken way. They use which means the shell will intercept all signals. So these daemons are not gracefully shutdown when the pod is stopped. This causes serious problems since when apiserver is killed abruptly it doesn't seem to close watches correctly. This was observed in for example. What you expected to happen: Running is incorrect. It should run the binary directly. Otherwise, it needs to perform an so the binary correctly replaces the shell script process. How to reproduce it (as minimally and precisely as possible): Run kube-apiserver inside a container with and try to stop it. You can't - eventually docker will force kill it. Anything else we need to know:
It looks like we changed from running the binaries directly to using in (from a few years ago to enable us to capture logs. or may recall why we had to use a shell since they reviewed that PR.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close.
Code change:
# TODO: split this out into args when we no longer need to pipe stdout to a file #6428 - sh - -c <del> - '/glbc --verbose=true --apiserver-host=http://localhost:8080 --default-backend-service=kube-system/default-http-backend --sync-period=600s --running-in-cluster=false --use-real-cloud=true --config-file-path=/etc/gce.conf --healthz-port=8086 1>>/var/log/glbc.log 2>&1' </del> <ins> - 'exec /glbc --verbose=true --apiserver-host=http://localhost:8080 --default-backend-service=kube-system/default-http-backend --sync-period=600s --running-in-cluster=false --use-real-cloud=true --config-file-path=/etc/gce.conf --healthz-port=8086 1>>/var/log/glbc.log 2>&1' </ins> volumes: - hostPath: path: /etc/gce.conf

Related discussion:
text: Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Code change:
} } <del> func (s *StatefulSetTester) waitForStatus(ss *apps.StatefulSet, expectedReplicas int32) { </del> <ins> // WaitForStatus waits for the ss.Status.Replicas to be equal to expectedReplicas func (s *StatefulSetTester) WaitForStatus(ss *apps.StatefulSet, expectedReplicas int32) { </ins> Logf("Waiting for statefulset status.replicas updated to %d", expectedReplicas) ns, name := ss.Namespace, ss.Name

Related discussion:
text: https://k8s- do you know the statefulset owners?
cc
I did not see this happening until recently.
The controller misses that the first pod transitioned to unready and proceeds to create the second pod. The test uses a client to hit the api server and will scale up the statefulset as soon as the broken pod is observed but the controller uses caches so it may observe the scaled up statefulset quicker than the updated pod.
I will update the test to ensure that we wait until the unreadiness is observed on StatefulSet.Status.Replicas field prior to the scaling operation
SGTM
Code change:
// cloudPublicFeatureGates consists of cloud-specific feature keys. // To add a new feature, define a key for it at k8s.io/api/pkg/features and add it here. var cloudPublicFeatureGates = map[featuregate.Feature]featuregate.FeatureSpec{ <del> LegacyNodeRoleBehavior:           {Default: false, PreRelease: featuregate.GA, LockToDefault: true}, ServiceNodeExclusion:             {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, </del> IPv6DualStack:                    {Default: true, PreRelease: featuregate.Beta}, ControllerManagerLeaderMigration: {Default: false, PreRelease: featuregate.Alpha}, }

Related discussion:
text: What is missing? Based on SIG call it's probably "tests" but I am not sure. Could use some investigation and followup - how do we get it to GA? /sig network /kind cleanup
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
This one seems not a good first one, I'll take this to myself and start bothering people in Slack to check what's missing, mostly as I've seen this is also related to cloud providers :)
I think this one originally. According to the KEP in This should have went GA in v.19 and be removed in v1.20. Given it's still marked beta, at the very least we should mark it GA in v1.20 and remove it in v1.21. anything I'm missing here?
yeap. Honest question, changing a Feature Gate to GA process is only changing the related line in and also putting a comment that this goes to GA? If so, probably this one can also be a good first issue and we can open a future issue for the removal in v1.21 once v1.20 ships. I think this will also need to be changed in the in v1.21 right? If is ok with that, I would like then to mark this as a good first issue to turn the feature GA in v1.20 :)
Well, taking a look into how secure is to move to GA: In the KEP there are some considerations about removing the IsMasterNode function, which seems to be already dealt in commit E2E tests needs to be also checked about usage of IsMasterNode(), which I could not find anymore and also seems to be removed from the same commit above. About the same Kep, it's directly related to other Feature Gate: ` So what I think that needs to be done: Promote LegacyNodeRoleBehavior to GA and Default it to false as proposed in the Kep -I'll open another issue just for this According to the LegacyNodeRoleBehavior should be removed in v1.19 but according to the Kep in v1.21, so let's stick with v1.21? ServiceNodeExclusion - Should be moved to GA, already defaulted to true. This issue is going to deal ONLY with this.
Code change:
// cloudPublicFeatureGates consists of cloud-specific feature keys. // To add a new feature, define a key for it at k8s.io/api/pkg/features and add it here. var cloudPublicFeatureGates = map[featuregate.Feature]featuregate.FeatureSpec{ <del> LegacyNodeRoleBehavior:           {Default: false, PreRelease: featuregate.GA, LockToDefault: true}, ServiceNodeExclusion:             {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, </del> IPv6DualStack:                    {Default: true, PreRelease: featuregate.Beta}, ControllerManagerLeaderMigration: {Default: false, PreRelease: featuregate.Alpha}, }

Related discussion:
text: NodeDisruptionExclusion - Should be moved to GA, already defaulted to true. I'll open another issue for this I'm afraid of this having some sort of direct impact in cloud providers, do you want me to take this to the sig-cloudproviders meet? Otherwise can we move the above Feature Gates to GA, and schedule their removal for v1.21, wdyt?
Per deprecation lifecycle it seems that a feature needs 6 months or 2 releases (the longer one) in Beta before going to GA. So this actually seems to be the missing part before moving to GA. As the 3 FeatureGates are directed related, probably this issue should be: Move all of them to GA in v1.21 Default LegacyNodeRoleBehavior to false Sounds a good approach? I can keep this opened until we reach v1.21
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/remove-triage unresolved
/retitle Move Feature gate ServiceNodeExclusion to GA and LockToDefault
/triage accepted as this FG is scheduled to be moved to GA in v1.21, do you want to tackle on this?
fixed in /close
Closing this issue. <detailsIn response to : fixed in /close </details
Code change:
fmt.Println("[reset] docker doesn't seem to be running, skipping the removal of running kubernetes containers") } <del> dirsToClean := []string{"/var/lib/kubelet", "/etc/cni/net.d", "/var/lib/dockershim"} </del> <ins> dirsToClean := []string{"/var/lib/kubelet", "/etc/cni/net.d", "/var/lib/dockershim", "/var/run/kubernetes"} </ins> // Only clear etcd data when the etcd manifest is found. In case it is not found, we must assume that the user // provided external etcd endpoints. In that case, it is his own responsibility to reset etcd

Related discussion:
text: 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 ?
Code change:
fmt.Println("[reset] docker doesn't seem to be running, skipping the removal of running kubernetes containers") } <del> dirsToClean := []string{"/var/lib/kubelet", "/etc/cni/net.d", "/var/lib/dockershim"} </del> <ins> dirsToClean := []string{"/var/lib/kubelet", "/etc/cni/net.d", "/var/lib/dockershim", "/var/run/kubernetes"} </ins> // Only clear etcd data when the etcd manifest is found. In case it is not found, we must assume that the user // provided external etcd endpoints. In that case, it is his own responsibility to reset etcd

Related discussion:
text: /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.
Code change:
fmt.Println("[reset] docker doesn't seem to be running, skipping the removal of running kubernetes containers") } <del> dirsToClean := []string{"/var/lib/kubelet", "/etc/cni/net.d", "/var/lib/dockershim"} </del> <ins> dirsToClean := []string{"/var/lib/kubelet", "/etc/cni/net.d", "/var/lib/dockershim", "/var/run/kubernetes"} </ins> // Only clear etcd data when the etcd manifest is found. In case it is not found, we must assume that the user // provided external etcd endpoints. In that case, it is his own responsibility to reset etcd

Related discussion:
text: export KUBECONFIG=$
that works for me , thanks a lot.
export kubectl get nodes is work from me
This worked!
After you have to remove $ folder and create new: mkdir -p $ sudo cp -i $ sudo chown (id -g) $
it worked! thx
Code change:
} func (udp *udpProxySocket) ProxyLoop(service proxy.ServicePortName, myInfo *serviceInfo, proxier *Proxier) { <del> activeClients := newClientCache() </del> var buffer [4096]byte // 4KiB should be enough for most whole-packets for { if info, exists := proxier.getServiceInfo(service); !exists || info != myInfo {

Related discussion:
text: Depends on UDP clients have a timeout (so we don't leak connections forever), but the test does not cover this. To do this, we probably need to track active connections, and plumb that all the way down to the goroutines spawned by the ProxyLoop routines. This is probably something we want to do anyway to be able to monitor.
Code change:
Resources: resources, }, }, <ins> InitContainers: []v1.Container{ { Name:      "init-" + cname, Resources: resources, }, }, </ins> }, } }

Related discussion:
text: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: When referencing init container's env value from its fields, kubelet complains What you expected to happen: Init container should be supported to get env values from its own fields, as to How to reproduce it (as minimally and precisely as possible): a pod with init container refering its fields value as env value kubectl create -f test-pod-1.yaml cannot be created pod events Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ):Kernel (e.g. ):Install tools: Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions 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
The err happens at this line , it seems that we should search for init containers as well
Code change:
The PUT and POST verbs on objects will ignore the "status" values. Otherwise, PUT expects the whole object to be specified. Therefore, if a field is omitted it is assumed that the client wants to clear that field's value. <del> Modification of just part of an object may be achieved by GETting the resource, modifying part of the spec, labels, or annotations, and then PUTting it back. See [concurrency control](#concurrency-control-and-consistency), below, regarding read-modify-write consistency when using this pattern. Some objects may expose alternative resource representations that allow mutation of the status, or performing custom actions on the object. </del> <ins> The PUT verb does not accept partial updates. Modification of just part of an object may be achieved by GETting the resource, modifying part of the spec, labels, or annotations, and then PUTting it back. See [concurrency control](#concurrency-control-and-consistency), below, regarding read-modify-write consistency when using this pattern. Some objects may expose alternative resource representations that allow mutation of the status, or performing custom actions on the object. </ins> All objects that represent a physical resource whose state may vary from the user's desired intent SHOULD have a "spec" and a "status".  Objects whose state cannot vary from the user's desired intent MAY have only "spec", and MAY rename "spec" to a more appropriate name.

Related discussion:
text: sending the following json to update a service: "{"apiVersion":"v1beta1","port":6380,"containerPort":6379}" fails with 422 and message: "service "" is invalid: name: required value ''" It's not clear from the message what is exactly the problem. is the "name" field missing? isn't it called "id" at the moment? if yes, another issue () points on the fact that including the id fails the request with another error.
similar issue happens when creating a service: input (based on the guestbook example) : POST fails with :
Internal names are not converted to external during rendering of the status message. Name is the newer api version field name for what used to be called id
but the input json contains "id", so why does it fail in the first place?
I'm referring to the first comment, where update failed because you omitted the ID of the service you were updating
Update requires the full resource to be specified. GET the resource, modify the fields you want to change, and do a PUT.
Using for the field name conversion problem.
As mentioned, PUT should not accept partial updates - PATCH should, and the issue for that is . This is documented in : "Otherwise, PUT expects the whole object to be specified." Where else does it need to be documented?
Code change:
cases := map[string]struct { pod        *v1.Pod pvcs       []*testPVC <ins> pvs        []*testPV </ins> trigger    func(config *testConfig) shouldFail bool }{

Related discussion:
text: Add test for "on PVC add", see Test for "on PVC update" is not needed, because it has already been tested in all volume scheduling tests.
/sig
docs: