jiebi/CodeConvo huggingface dataset:
Change:
// and should be discarded "topology.kubernetes.io/region": "us-other-west", "topology.k8s.io/region":        "us-other-west", <ins> "kubernetes.io/region":          "us-other-west", "k8s.io/region":                 "us-other-west", </ins> // Should discard labels that already exist "my.custom.label/foo": "bar", "my.custom.label/bar": "foo", <ins> // Should add labels that not match regex "app.k8snio/bar": "foo", "k8snio/bar":     "foo", </ins> }, }, existingNode: &v1.Node{

Discussion:
For cloud provider nodes, there are some k8s label names are reserved. Like and The current regex is: This will match the dot . as any single character. This block adding a label name like: app.k8snio/name The regex format is incorrect, we should escape the dot in regex so that it can match the dot as a string. Can add additional label with name like: app.k8snio/name Configure AdditionalLabels in the instanceMeta to add additional label name with app.k8snio/name. No response <detailsClient Version: v1.30.1 Kustomize Version: v5.0.4-0.- Server Version: v1.30.0 </details<details</details<details</details<details</details<details</details<details</details
/sig cloud-provider
If it make sense to fix it, i would like to take it and raise a PR. /assign
Which Kubernetes component has the bug ? (eg: kubelet) Can you explain how to reproduce the problem?
It's the node controller in the shared library Though I really don't think cloud providers should be setting node labels like "", this is technically incorrect. This restriction is only applied to labels the cloud provider controller binary running this controller would attempt to add itself.
just noticed this after our SIG meeting today, cc
/triage accepted
please go ahead and raise a PR, thanks for reporting this =)
When fixing this, consider if there are any labels that cloud provider integration might legitimately set. For example: (documented as being set by cloud provider integration code). Some labels are OK to set; we could allowlist and explicitly. When rejecting some others, maybe setting a Condition on the Node ( perhaps) would help surface what's not right. Not sure. Making the simple fix is also fine by me.
OK. Thanks I have raised a PR for this: Not sure if this change looks good.
Change:
Filter: v1beta2.PluginSet{ Enabled: []v1beta2.Plugin{ {Name: "Plugin1", Weight: pointer.Int32Ptr(2)}, <ins> {Name: "Plugin3", Weight: pointer.Int32Ptr(3)}, </ins> }, }, },

Discussion:
<!-- 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 --Recent commit: import an issue when multiple custom plugin configured in scheduler config file, and those plugins are default plugins too. It was manipulating slice with index, but the slice is updated while index is not, which will cause the index out of range, see the exceptions listed below, config file should be handled properly without such exception override multiple default plugin in scheduler's config file. Kubernetes version (use ): latest (1.22) Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /assign
/sig scheduling /triage accepted
Change:
} } <ins> if podStatus.PodIP == "" { return nil, ErrNoPodInfraContainerInPod } </ins> if len(statuses) == 0 && podStatus.PodIP == "" { return nil, ErrNoContainersInPod }

Discussion:
While fixing the issue on describe events for pod, I found kubelet keep restarting monitoring-heapster-controller container: I retrieved the container log, and found it exit due to database creation failure: I didn't follow up on why influxdb issue. cc/
This happens when InfluxDB service is not up. Heapster retries a few times and then eventually fails. The plan is to avoid failing completely and keep retrying DB creation until it succeeds and bubble up appropriate errors. , Dawn Chen wrote:
Influxdb is running happily without issue on the same node:
Related kube-proxy log:
It looks like a kube-proxy issue.
It looks like there are no endpoints for 'monitoring-influxdb' service. The service itself is active and there is a pod that matches the selector of the service. Here is the 'monitoring-influxdb' service: Influxdb pod that matches the selector for 'monitoring-influxdb' service is running. Here are the endpoints from the apiserver: Wonder why there are no endpoints. cc
I ran into a similar issue where endpoints for monitoring-influxdb was not configured. In my case, the pod state took a long time to move to running (even though the containers on the machine were all running fine). But the endpoints were created as soon as the pod changed to state running.
Probed a bit further and it looks like the kubelet is not populating PodIP.
cc/ Can you take a quick look at this one?
FYI: I am still working on this issue.
Here is a little bit more updates: 1) PodIP is missing on all pods running on that particular node; but pods on other nodes with exact same kubelet do have PodIP associated with. 2) docker inspect shows that every pods on bad node have proper "NetworkMode": 3) docker inspect those pod infra containers, they all have proper IP assigned by docker.
The issue is that the kubelet does not ignore old network containers while computing pod status. Working on a fix.
Nice find :) On Mar 26, 2015 5:50 PM, "Vish Kannan" wrote:
Change:
oomWatcher, err := oomwatcher.NewWatcher(kubeDeps.Recorder) if err != nil { <del> if libcontaineruserns.RunningInUserNS() { </del> <ins> if inuserns.RunningInUserNS() { </ins> if utilfeature.DefaultFeatureGate.Enabled(features.KubeletInUserNamespace) { // oomwatcher.NewWatcher returns "open /dev/kmsg: operation not permitted" error, // when running in a user namespace with sysctl value `kernel.dmesg_restrict=1`.

Discussion:
is no longer compilable on macOS in the master branch. It was compilable with Kubernetes v1.29.0 and v1.30.0-alpha.0. It should be compilable. No response <detailsmaster () (This is just the latest commit, not the commit that introduced the regression) </details<detailsN/A </details<detailsmacOS 14.2.1 (Intel) </details<detailsN/A </details<detailsN/A </details<detailsN/A </details
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
/sig testing
Regression in:
Change:
// https://github.com/kubernetes/kubernetes/issues/72236 kubeIPVSFilterChain utiliptables.Chain = "KUBE-IPVS-FILTER" <ins> // kubeIPVSOutFilterChain filters access to load balancer services from node. // https://github.com/kubernetes/kubernetes/issues/119656 kubeIPVSOutFilterChain utiliptables.Chain = "KUBE-IPVS-OUT-FILTER" </ins> // defaultScheduler is the default ipvs scheduler algorithm - round robin. defaultScheduler = "rr"

Discussion:
When using loadBalancerSourceRanges to allow access only from CIDRs outside the cluster segment, access from the K8s nodes (or pods with hostNetwork:true) should be rejected, but for proxy-mode=ipvs it works. /sig network /area kube-proxy /area ipvs Access from K8s nodes should be rejected in the same way as for proxy-mode=iptables Define a service with loadBalancerSourceRanges that allows access from a cidr outside the cluster, e.g. The K8s nodes have addresses on 192.168.1.0/24 and fd00::c0a8:100/120. Make sure a loadBalancerIP is assigned (in this example 10.0.0.0/32) and try to access it from a K8s node: Same for both ipv4 and ipv6. This is related to since a fix requires that the passed to the is correct. Please see v1.27.4 and master None Linux 6.4.4 None N/A N/A
wanted to work on this
Great! But please coordinate with I hope that one get accepted, and then ~the s (both families) passed to the proxiers should be usable.~ No, they are not, please see
Discussed this one in the SIG Network meeting today: we agree this is something we'd like to implement, however we weren't sure exactly how to do it with ipvs during the meeting. Whoever takes this on needs to come up with and communicate a clear plan of how it will be accomplished. /triage accepted
My comment is not feasible. For proxy-mode=ipvs the src and dst is both loadBalancerIP. So the nodeIP will not help :disappointed:
I did a small experimented with kind + metallb. I created a loadbalancer service backed by . loadBalancerIP: 172.18.255.200 podIP: 10.244.1.3 conntrack picks the src and dst both as loadBalancerIP. Tried to create an iptables rules matching source and destination with loadbalancerIP to drop packets but it didn't work. After some exploration I found and with the following rules I was able to prevent access to lbIP from k8s nodes / host network.

The solution looks hacky though, we only need this rule if source ranges are defined for the service and node ip is not covered by any of them. Will try to program this in the ipvs proxier.
Good find! :+1: I had missed the ipvs extension. I started to check nodeIP and the (flawed) option to experiment with setting a nodeIP as "src" for some routes to dodge the lbip-both-as-src-and-dst problem, and an old "vision" I have to not assign clusterIPs to at all, but have one rule to replace them all, like: It can be done, and in a cluster with 1000's of clusterIP's it would simplify
Change:
Rule: admissionregistrationv1.Rule{ APIGroups:   []string{""}, APIVersions: []string{"v1"}, <del> Resources:   []string{"*"}, </del> <ins> Resources:   []string{"configmaps"}, </ins> }, }}, ClientConfig: admissionregistrationv1.WebhookClientConfig{

Discussion:
/kind flake <!-- If this is a flake, please add: /kind flake --/sig storage
The last time I see the flake is in
/assign /sig apimechinery It's broken by a validation webhook with match conditions which is created by
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /assign /sig apimechinery 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
/sig api-machinery
I have raised a pr to fix it. can you help to review it?
/close duplicate of and thanks for the fix PR too.
Closing this issue. <detailsIn response to : /close duplicate of and thanks for the fix PR too. 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
/triage accepted
Change:
By(test.description) if test.messageNum > 0 { By(fmt.Sprintf("Inject %d logs: %q", test.messageNum, test.message)) <del> err := injectLog(tmpLogFile, test.timestamp, test.message, test.messageNum) </del> <ins> err := injectLog(hostLogFile, test.timestamp, test.message, test.messageNum) </ins> Expect(err).NotTo(HaveOccurred()) }

Discussion:
Leads to this avc: In general, HostPath volumes in tests are bad news for selinux.
Change:
accessModes: - ReadWriteOnce hostPath: <del> path: /tmp/pv-1 </del> <ins> path: /tmp/data/pv-1 </ins> --- apiVersion: v1 kind: PersistentVolume

Discussion:
Version: Running this example on RHEL 7.2 (assume same for centos), and using hostPath, I get a permissions error when the mysql container does a . If I set selinux to permissive on the host it works. If I manually run the container with it works. I was not able to get it to work when adding to the deployment. My fix was to locate the PVs in by changing the local- file, and doing . I this comment to local- If this issue is valid I will create a quick PR to doc this selinux solution.
See pr
Change:
if err == nil { // Volume is already attached to node. <del> glog.V(4).Infof("Attach operation is successful. volume %q is already attached to node %q at lun %d.", volumeSource.DiskName, instanceid, lun) </del> <ins> glog.V(2).Infof("Attach operation is successful. volume %q is already attached to node %q at lun %d.", volumeSource.DiskName, instanceid, lun) </ins> } else { <del> glog.V(4).Infof("GetDiskLun returned: %v. Initiating attaching volume %q to node %q.", err, volumeSource.DataDiskURI, nodeName) </del> <ins> glog.V(2).Infof("GetDiskLun returned: %v. Initiating attaching volume %q to node %q.", err, volumeSource.DataDiskURI, nodeName) </ins> getLunMutex.LockKey(instanceid) defer getLunMutex.UnlockKey(instanceid)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Current logging is not enough for azure disk diagnostics, change some log level from 4 to 2 What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig azure /assign
Change:
type are suitable for your use!) #### AWS EBS Example configuration: ```yaml apiVersion: v1 kind: Pod metadata: <del> name: testpd </del> <ins> name: test-ebs </ins> spec: containers: <del> - image: kubernetes/pause name: testcontainer </del> <ins> - image: gcr.io/google_containers/test-webserver name: test-container </ins> volumeMounts: <del> - mountPath: /testpd name: testvolume </del> <ins> - mountPath: /test-ebs name: test-volume </ins> volumes: <del> - name: testvolume </del> <ins> - name: test-volume </ins> # This AWS EBS volume must already exist. awsElasticBlockStore: volumeID: aws://<availability-zone>/<volume-id>

Discussion:
only talks about these volumes: EmptyDir HostPath GCEPersistentDisk NFS However, we many more volume types. Documentation should be updated to reflect this.
cc
Is anyone working on this? If not, I would like to do it.
go for it :) Improving PV docs is on my TODO list, too.
Sure, thank you. I will start now, hope to send a PR ASAP.
Change:
.PP JSON and YAML formats are accepted. <ins> .PP Please refer to the models in [la]https://htmlpreview.github.io/?https://github.com/GoogleCloudPlatform/kubernetes/HEAD/docs/api-reference/definitions.html[ra] to find if a field is mutable. </ins> .SH OPTIONS .PP

Discussion:
The current documentation is very vague and doesn't explain what can be updated in this way. Can I rename or stop the pod, change number of replicas in RC etc. For example it seems to be impossible to change pod name:
cc
After an in person discussion with we think the docs should point people to the swagger-ui to find if a field is mutable. I'll add this point into the docs.
Change:
to.terminated[c.Name] = channel mainContainerChannels = append(mainContainerChannels, channel) <del> // if its not a running container, pre-close the channel so nothing waits on it </del> <ins> // if it's not a running container, pre-close the channel so nothing // waits on it </ins> if _, isRunning := runningContainers[c.Name]; !isRunning { close(channel) }

Discussion:
In a situation where during the init phase of a , a native sidecar never becomes ready (because its is failing), then the is terminated, if there are multiple startup containers, a termination signal is never received by the init container and the Pod is stuck (until is hit). All running initContainer to receive the termination signal correctly. Create a with this bash script as an entrypoint: Create a deployment with two init containers (one normal one sidecar). Add an probe which means the startupProbe never passes Create the deployment, and it'll be stuck in Init, as you'd expect: the pod and you'll see the exit signal has been sent to : Delete the deployment / clean everything up. Now, add a third : As before, the process will be stuck on because of the bad probe: However when you delete the pod this time, no exit signal is sent to , the pod is now stuck until is reached. No response GKE v1.29.4-gke. Core OS on GCP <details</details<details</details<details</details
/sig node
/assign
/triage accepted confirmed that the scenario is reproduced. The problem is caused by the fact that the native sidecars should terminate in reverse order. I'll fix the code to ignore not-running init containers. /cc
Awesome, thank you :)
sig-node meeting notes: /triage accepted /priority important-soon
FYI: confirmed that the SITERM is sent to the containers after terminationGracePeriodSeconds (and wait for the application for 2 seconds before sending SIGKILL) will fix it anyway with
Change:
if err != nil { return err } <ins> // Before we overwrite the config which holds the parsed // command line parameters, we need to copy all modified // logging settings over to the loaded config (i.e.  logging // command line flags have priority). Otherwise `--config // ... -v=5` doesn't work (config resets verbosity even // when it contains no logging settings). copyLogsFromFlags(fs, &c.Logging) </ins> o.config = c if err := o.initWatcher(); err != nil {

Discussion:
introduced configuration of additional logging aspects (e.g. format) through command line flags and config file. This was merged for Kubernetes 1.28. Now the following invocation doesn't work as expected when the config file doesn't configure logging: It should run with verbosity 4. Instead it runs with verbosity 0, from the config. Run with this config file: No response 28 rc n/a No response No response No response No response
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
The problem is caused by this line: At that point, is 4 (from the command line flag), and then it gets overwritten with == 0. The normal approach would be: set up config with defaults modify config through flags modify config further by parsing a config file into it. Can kube-proxy do this? It has the downside that a config file can only overwrite fields if they are in the file. A config field doesn't get reset to defaults just by parsing the file. /cc
it looks like kube-proxy special-cases the to let a flag override config... can/should it do the same thing for verbosity? are there any other flags like this?
I don't think that's the normal approach... it's more normal to make flags and config file mutually exclusive. That's difficult for things which started as flags and moved into config
/sig network /sig instrumentation /kind bug /kind regression /milestone v1.28
let's go with and warn it and comment as much as possible, I was going with something like but Patrick is working on it so I assign to him the issue
/assign
Hey folks, v1.28 Bug Triage Lead here Just wanted to know if this is already tracked by SIG leads and someone already working actively fixing it and set a priority?
Perhaps I should have said "this is how component-base/logs was meant to be used". Somehow it worked for kubelet.

Here's my preliminary solution: It needs more testing, but I wanted to share it early because I am running out of time today.
it is , I can take over Patrick's work in case is needed
It would be nice if the logs API could distinguish between and , how about make to a pointer? But this change is supposed to be a breaking change, I'm not sure of the scope of the impact. For side, if set and at the same time, should the command flag override the config file or warn it and be discarded? I think it should be overridden.
xref:
Change:
"//vendor:k8s.io/apimachinery/pkg/util/validation/field", "//vendor:k8s.io/apimachinery/pkg/util/wait", "//vendor:k8s.io/apimachinery/pkg/util/yaml", <ins> "//vendor:k8s.io/apimachinery/pkg/version", </ins> "//vendor:k8s.io/apimachinery/pkg/watch", "//vendor:k8s.io/apiserver/pkg/util/flag", "//vendor:k8s.io/client-go/discovery",

Discussion:
<!-- 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.): "kubectl version", "kubectl version" json Is this a BUG REPORT or FEATURE REQUEST? (choose one): Feature request Kubernetes version (use ): $ kubectl version --client Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.6", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-11-12T05:22:15Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"darwin/amd64"} Environment: Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): MacOS 10.12.2 I find it difficult to parse the output of programmatically. I have to use a YAML parser to do it. I'd prefer to use JSON, or to be given just the string and asked to parse it with a regex. This is obviously a relatively low-priority request.
I wouldnt mind helping out on this, if there are no objections?
are you working on this? If not, I would like to work on it.
I plan to, but if i'll keep you posted if i get too delayed.
How can I direct message you?
didnt see this till now, felt bad i had not kept up on this so i decided to just push through it. If my email is not available in my profile, please let me know, otherwise AT gmail would be the best way to contact me.
Thanks!
Included below are some examples. Let me know what you think, my only concern is the the original output of included the key and then the object type which is a little strange. Note the output flag is optional so we don't break previous behavior and contract, which is now baked and part of e2e testing. here are the couple of samples:
Change:
Status: api.NodeStatus{ Conditions: []api.NodeCondition{ { <del> Type:               api.NodeOutOfDisk, </del> <ins> Type:               api.NodeReady, </ins> Status:             api.ConditionTrue, <del> Reason:             "KubeletOutOfDisk", Message:            "out of disk space", </del> <ins> Reason:             "KubeletReady", Message:            fmt.Sprintf("kubelet is posting ready status"), </ins> LastHeartbeatTime:  unversioned.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), LastTransitionTime: unversioned.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), }, { <del> Type:               api.NodeReady, </del> <ins> Type:               api.NodeOutOfDisk, </ins> Status:             api.ConditionTrue, <del> Reason:             "KubeletReady", Message:            fmt.Sprintf("kubelet is posting ready status"), </del> <ins> Reason:             "KubeletOutOfDisk", Message:            "out of disk space", </ins> LastHeartbeatTime:  unversioned.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), LastTransitionTime: unversioned.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), },

Discussion:
<!-- 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: I was looking into what tests were enabled for and found that the following tests: are running 1.18. From the output of the tests (): and What you expected to happen: tests to be running against the latest code for 1.19 How to reproduce it (as minimally and precisely as possible): It looks to be caused by the setting: Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig release /sig windows