jiebi/CodeConvo huggingface dataset:
Change:
{utiliptables.TableFilter, kubeProxyFirewallChain}, {utiliptables.TableFilter, kubeSourceRangesFirewallChain}, {utiliptables.TableFilter, kubeIPVSFilterChain}, <ins> {utiliptables.TableFilter, kubeIPVSOutFilterChain}, </ins> } // ipsetInfo is all ipset we needed in ipvs proxier

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:
return nodes, nil } <ins> func (nc *NodeController) recordNodeEvent(node *api.Node, event string) { ref := &api.ObjectReference{ Kind:      "Node", Name:      node.Name, UID:       types.UID(node.Name), Namespace: "", } glog.V(2).Infof("Recording %s event message for node %s", event, node.Name) // TODO: This requires a transaction, either both node status is updated // and event is recorded or neither should happen, see issue #6055. nc.recorder.Eventf(ref, event, "Node %s is now %s", node.Name, event) } </ins> // For a given node checks its conditions and tries to update it. Returns grace period to which given node // is entitled, state of current and last observed Ready Condition, and an error if it ocured. func (nc *NodeController) tryUpdateNodeStatus(node *api.Node) (time.Duration, api.NodeCondition, *api.NodeCondition, error) {

Discussion:
/cc
Is this from head? I've never seen this before, maybe changed anything recently. Anyway, the code in question will be deleted by
I saw this in the Travis run for an unrelated PR (Kubelet test refactoring). If it's going away, then that's ho we'll fix it :)
Yup. It'll go away. I'll assign it to myself - I'll run test few times after to make sure it's gone.
another example: https://travis-
Just hit this again: https://travis-
I was hoping we could finish getting rid of this code this week, which is why I had been ignoring this. But we ran out of time and Poland has a holiday on Monday, so I guess we need to fix this race. I'll take a look.
Thanks. This is becoming a real nuisance that is masking other failures.
To repro I assume I just type the commands from Travis, e.g. the shell stuff in https://travis- ?
Never mind, I got it. Though the first time I ran it all the tests passed.
I don't think the failure is deterministic, but yes.
This is super annoying, it happens way too much of the time...
Sigh, I was hoping we can get rid of the code this week. I think the problem comes from someone changes the event recording. I'll send a PR
It seems to be basically always failing now, except when some other flake fails first.
It would be fine with me if we just temporarily disabled event generation there.
If I'm reading the stack traces correctly, what's going on is that NewNodeController [] calls StartRecordingToSink() [] which calls StartEventWatcher() which calls eventHandler() which calls StartRecordingToSink() which calls sink.Create() which is Create() in , which appends to c.Fake.Actions. At the same time, the last line of the test tries to print "item.fakeNodeHandler.Actions" and these are presumably the same variable. I'm not sure why these are running at the same time, though.
+1 to Braians idea to temporary disable event generation.
Re-titled issue.
Re-titled issue.
Change:
import ( "encoding/json" "fmt" <ins> "runtime" </ins> "time" "k8s.io/kubernetes/cmd/kubeadm/app/images"

Discussion:
Right now we create 3 daemonsets for in , but will only give use image names for , so this feature is broken. We should only deploy one daemon set for the native architecture, but ensure it has the right label selectors, so we don't try to run pods on nodes of different architecture. We should also make sure all addons have architecture labels, and not just . If user is building heterogeneous clusters, the will need to take about deploying addons for additional architectures, we shouldn't pre-deploy multiple things knowing that they will most likely remain unschedulable.
I have the same issue as well. I tried to create a cluster with x86 (Intel NUC) and arm (Raspberry-Pi) and I see that the kube-proxy is crashing. Here's the log entry from kube-proxy Logs from kube-proxy exec user process caused "exec format error" Attached is the kube-proxy yaml file. I see that its picking up arm image Don't know how to fix this.
Change:
package gc import ( <ins> "fmt" </ins> "strings" "testing" <del> "k8s.io/apimachinery/pkg/api/meta/testrestmapper" </del> <ins> corev1 "k8s.io/api/core/v1" extensionv1beta1 "k8s.io/api/extensions/v1beta1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema"

Discussion:
/kind flake /sig testing /sig auth we are injecting a restMapper into this admisson controller while in its test, the restMapper somehow become empty when we remove internal clientset/informer dependency from it (). now we come up with a walkaround in which we manually init the legacy schema via a dry import so that the built-in resources can be installed. this failing test suggests that the test is not quite correct logically.
/assign Are you up for trying to figure out how to avoid requiring the internal types?
What test does this break? Links?
link here: w/o the dry import, then will fail with output:
sure. will be looking into it
OK, setting priority so that I know this isn't a 1.13 blocker. /priority important-longterm
Change:
{utiliptables.TableFilter, utiliptables.ChainInput, kubeProxyFirewallChain, "kube-proxy firewall rules"}, {utiliptables.TableFilter, utiliptables.ChainForward, kubeProxyFirewallChain, "kube-proxy firewall rules"}, {utiliptables.TableFilter, utiliptables.ChainInput, kubeIPVSFilterChain, "kubernetes ipvs access filter"}, <ins> {utiliptables.TableFilter, utiliptables.ChainOutput, kubeIPVSOutFilterChain, "kubernetes ipvs access filter"}, </ins> } var iptablesChains = []struct {

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:
// TODO(vinaykul,InPlacePodVerticalScaling): Investigate doing this in HandlePodUpdates + periodic SyncLoop scan //     See: https://github.com/kubernetes/kubernetes/pull/102884#discussion_r663160060 if kl.podWorkers.CouldHaveRunningContainers(pod.UID) && !kubetypes.IsStaticPod(pod) { <del> kl.handlePodResourcesResize(pod) </del> <ins> pod = kl.handlePodResourcesResize(pod) </ins> } }

Discussion:
mutates the pod object in place (vs creating a copy first). That's illegal and can cause data races or potentially panics (the panic is unlikely here but I can't rule it out). This line should be: This should be fixed because we might serialize the object in the middle of this from somewhere else and if the object changes midway the protobuf object we create may not be valid, leading to panics in kubelets with this gate turned on. /sig node /priority critical-urgent /kind bug /assign No mutation of pod objects from within methods (in fact no mutation of should occur in most loops). N/A No response <details</details<details</details<details</details<details</details<details</details<details</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
ACK. I'll fix it shortly.
is similar. is my try for both data races that we found.
One small , thanks.
Please review
This Issue/PR has been marked as release blocker. Please have the fix merged by eod today otherwise the feature has to be reverted. For the Issue/PR owner: please have a revert/feature disable PR open today in case the fix failed to get in. Thank you! See the -- Kubernetes 1.27 release manager
Change:
Name:      "items_per_watch", Help:      "How many items an API watch returns to the reflectors", }, []string{"name"}) <ins> lastResourceVersion = prometheus.NewGaugeVec(prometheus.GaugeOpts{ Subsystem: reflectorSubsystem, Name:      "last_resource_version", Help:      "Last resource version seen for the reflectors", }, []string{"name"}) </ins> ) func init() {

Discussion:
I'm seeing a large number of unique prometheus series showing up (due to the logging we for anonymous reflectors). This is a small cluster but I believe this may have unbounded cardinality.
we storing the resource version in the metric name?
cc
Came into the same problem, checked the code, seems we use + + as metric names, for most reflector, they use a default name provided by which is go filename. I think the proper way is use as the metric name, and add a label, like
opened a pr to fix this, ptal thanks :)
Change:
sched.finishBinding(logger, fwk, assumed, targetNode, status) }() <del> bound, err := sched.extendersBinding(assumed, targetNode) </del> <ins> bound, err := sched.extendersBinding(logger, assumed, targetNode) </ins> if bound { return framework.AsStatus(err) }

Discussion:
I use extenders to add webhook for default-scheduler: And set to ignore scheuler error when scheduler extender is not working. But I got an error: . I suppose work fine in predicate path, but not work fine in bind path. The Ignorable logic in kube-scheduler: 637: and, 905: the is not judge in . Schedule should not error when set . extenders to kube-scheduler config(which has filterVerb and bindVerb and ignorable flag), example: and add config flag in kube-scheduler pod start up command. a scheduler-extender() and then stop it. a pod and you will see the schedule error. No response <details</details<detailsLocal environment </details<details</details<details</details<details</details<details</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 scheduling
/cc
/assign
Maybe this is not a bug but as designed, because bind is more critical than filter, what would you do in bind? I have no history context, cc
Hi, Kerthcet, in my scene, I use extender to bind IP(from my own network system) to my pod's annotaion. I'm aware of the critical of binding path, but, what If the extender is broken, how to skip it and continue? The scheduler extender design has supported ignorable, but only work for filter path make no sense for extender both has filter and bind. Maybe we can add an option to allow user to chose what can be ignored. Thanks for your reply anyway~
Reiterating the mentions to trigger a notification: <detailsIn response to : Maybe this is not a bug but as designed, because bind is more critical than filter, what would you do in bind? I have no history context, cc I'm aware of the critical of binding path, but, what If the extender is broken, how to skip it and continue?

The scheduler extender design has supported ignorable, but only work for filter path make no scence for extender both has filter and bind. Maybe we can add an option to allow user to chose what can be ignored. thanks for your reply anyway~ 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
So even the extender bind failed, will not impact your pod scheduling, right?
Yup
Right, if the field is there, we should support it. It's up to the cluster administrator to judge whether it makes sense to ignore a failed extender during bind.
Change:
// InfoObject is an implementation of the Object interface. It gets all // the information from the Info object. type InfoObject struct { <ins> Remote  runtime.Unstructured </ins> Info    *resource.Info Encoder runtime.Encoder Parser  *parse.Factory

Discussion:
/kind bug /sig cli /area kubectl Hello. This is my first interaction with the Kubernetes community, so please forgive me if i have left out any crucial details, or if, perhaps, this is PEBKAC after all! I am keen to have a working feature, as described in and I am running K8s v1.9.3 and realise that this feature is in alpha, but i thought i would ask anyway. We're not on v1.9.4 yet, but the changelog doesn't mention the feature. What you expected to happen: I have some services deployed to Kubernetes with YAML files, that has been working reliably. We always use to deploy things. When a service is already deployed, and i make a minor change in the config file, for example the service port, i expect to see that in the diff. Instead, gives no output and exits with a . How to reproduce it (as minimally and precisely as possible): Consider the file : I make sure that it is correctly running on the cluster: Great, looking good. Now, i change the value to use Docker image tag and save. Now, i run: The stderr/stdout output is empty, and the exit code is . Anything else we need to know?: Environment: Kubernetes version: Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-02-09T21:50:44Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3+coreos.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-02-10T01:42:55Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
I have this same issue - if I change, say, to in my , running returns empty. If I try tweaking the version I'm diffing (which I don't understand) - e.g. - then I see a bunch of differences, but not actually the change I was expecting in the number of replicas.
I'll take this. Sorry for the inconvenience.
Change:
// ValidateEvent makes sure that the event makes sense. func ValidateEvent(event *api.Event) errs.ValidationErrorList { allErrs := errs.ValidationErrorList{} <del> if event.Namespace != event.InvolvedObject.Namespace { </del> <ins> // TODO: There is no namespace required for minion if event.InvolvedObject.Kind != "Node" && event.Namespace != event.InvolvedObject.Namespace { </ins> allErrs = append(allErrs, errs.NewFieldInvalid("involvedObject.namespace", event.InvolvedObject.Namespace, "namespace does not match involvedObject")) } if !util.IsDNS1123Subdomain(event.Namespace) {

Discussion:
now shows NodePhase, NodeCondition, etc. information from NodeStatus. It should also show related events like what we did for pods.
Change:
dnsPolicy: Default containers: - name: metadata-proxy <del> image: gcr.io/google_containers/metadata-proxy:v0.1.5 </del> <ins> image: gcr.io/google_containers/metadata-proxy:v0.1.6 </ins> securityContext: privileged: true <ins> # Request and limit resources to get guaranteed QoS. </ins> resources: requests: <del> memory: "32Mi" </del> <ins> memory: "25Mi" </ins> cpu: "30m" limits: <del> memory: "32Mi" </del> <ins> memory: "25Mi" </ins> cpu: "30m" # BEGIN_PROMETHEUS_TO_SD - name: prometheus-to-sd-exporter image: gcr.io/google_containers/prometheus-to-sd:v0.2.2 <ins> # Request and limit resources to get guaranteed QoS. resources: requests: memory: "20Mi" cpu: "2m" limits: memory: "20Mi" cpu: "2m" </ins> command: - /monitor - --stackdriver-prefix={{ prometheus_to_sd_prefix }}/addons

Discussion:
Offshoot of regression - We are supporting "100 pods per node" in k8s officially () and need to make sure metadata-proxy allows those many pods to access the metadata service simultaneously. cc
cc
/assign
/sig auth
Xref
Change:
return config.f.ClientSet.Core().Namespaces() } <del> func CheckReachabilityFromPod(expectToBeReachable bool, namespace, pod, target string) { </del> <ins> func CheckReachabilityFromPod(expectToBeReachable bool, timeout time.Duration, namespace, pod, target string) { </ins> cmd := fmt.Sprintf("wget -T 5 -qO- %q", target) <del> err := wait.PollImmediate(Poll, 2*time.Minute, func() (bool, error) { </del> <ins> err := wait.PollImmediate(Poll, timeout, func() (bool, error) { </ins> _, err := RunHostCmd(namespace, pod, cmd) if expectToBeReachable && err != nil { Logf("Expect target to be reachable. But got err: %v. Retry until timeout", err)

Discussion:
Sub-issue for For AWS ELB, when an ELB is first created, is made it is very normal that it takes 2 minutes to be created, but the DNS name is reported fairly quickly.
Change:
pv := &v1.PersistentVolume{ ObjectMeta: metav1.ObjectMeta{ <del> // A.K.A InnerVolumeSpecName required to match for Unmount Name: volume.Name, </del> <ins> // Must be unique per disk as it is used as the unique part of the // staging path Name: fmt.Sprintf("%s-%s", AzureFileDriverName, azureSource.ShareName), </ins> }, Spec: v1.PersistentVolumeSpec{ PersistentVolumeSource: v1.PersistentVolumeSource{

Discussion:
Minimal Repro: Create 2 different disks Create 2 Pods each using one of the disks Start both pods on the same node You will notice one of the disks gets ed to a path: , then both disks are ed from to a target path: which is similar but at least uses the pod . Both of these volumes are being treated as the same volume in the Kubelet even though they are definitely not the same volume. Note: it may not be "treated" as the same volume - it may just be that since the paths are the same the following volumes see that the path is already a mountpoint and skip the step. This is the more likely scenario based on observations. The value is the "name" of the inline-volume. These can obviously be the same across different pods - we should actually be placing it in a more unique directory (based off the translated maybe?). /cc
/sig storage
The inline volume example I'm using (ignore the fact that is a complete misnomer): I've confirmed that changing the "name" makes inline volumes work well since there is no longer a collision on the paths
/assign
Alright, problem is sort of twofold: The referred to above for inline-volumes is set here: As we can see from the comment: it is set to the because the in-tree CSI Plugin makes a lot of naming assumptions based on the which for PVC/PVs is the PV name (unique in a cluster). Primarily, during unmount the CSI Plugin tries to from a "well known ": which happens to be some path based on the which for the inline volume is just the ( above). So we run into the problem that if we use the directory is not sufficiently unique for different disks. And if we use something else like then the unmount pathway is unable to find the . I think using is a no-go. So we need to use something sufficiently unique (like ) for the ( above) and fix up some of the other codepaths to either use different "well-known paths" to write to, or to fix up path generation code so they give us the correct locations. I'm also going to check to see whether 's refactor fixes this issue (because it might since it translates things earlier)
OK. Really good news.

your refactor in its current state actually fixes this issue if we set the to something unique here: Looks like the early translation is also making the pathway from the "correct" dir for inline migration. So I will create a PR that fixes this issue that should merge after