Question: func TestNonRootValidate(t *testing.T) { goodUID := types.UnixUserID(1) badUID := types.UnixUserID(0) <ins> untrue := false unfalse := true </ins> s, err := NewRunAsNonRoot(&extensions.RunAsUserStrategyOptions{}) if err != nil { t.Fatalf("unexpected error initializing NewMustRunAs %v", err) } <del> container := &api.Container{ SecurityContext: &api.SecurityContext{ RunAsUser: &badUID, </del> <ins> tests := []struct { container   *api.Container expectedErr bool msg         string }{ { container: &api.Container{ SecurityContext: &api.SecurityContext{ RunAsUser: &badUID, }, }, expectedErr: true, msg:         "in test case %d, expected errors from root uid but got none: %v", }, { container: &api.Container{ SecurityContext: &api.SecurityContext{ RunAsUser: &goodUID, }, }, expectedErr: false, msg:         "in test case %d, expected no errors from non-root uid but got %v", }, { container: &api.Container{ SecurityContext: &api.SecurityContext{ RunAsNonRoot: &untrue, }, }, expectedErr: true, msg:         "in test case %d, expected errors from RunAsNonRoot but got none: %v", }, { container: &api.Container{ SecurityContext: &api.SecurityContext{ RunAsNonRoot: &unfalse, RunAsUser:    &goodUID, }, }, expectedErr: false, msg:         "in test case %d, expected no errors from non-root uid but got %v", }, { container: &api.Container{ SecurityContext: &api.SecurityContext{ RunAsNonRoot: &unfalse, RunAsUser:    &badUID, }, }, expectedErr: true, msg:         "in test case %d, expected errors from root uid but got %v", </ins> }, } <del> errs := s.Validate(nil, container) if len(errs) == 0 { t.Errorf("expected errors from root uid but got none") } container.SecurityContext.RunAsUser = &goodUID errs = s.Validate(nil, container) if len(errs) != 0 { t.Errorf("expected no errors from non-root uid but got %v", errs) } container.SecurityContext.RunAsUser = nil errs = s.Validate(nil, container) if len(errs) != 0 { t.Errorf("expected no errors from nil uid but got %v", errs) </del> <ins> for i, tc := range tests { errs := s.Validate(nil, tc.container) if (len(errs) == 0) == tc.expectedErr { t.Errorf(tc.msg, i, errs) } </ins> } }

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): PodSecurityPolicy RunAsNonRoot 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 ): 1.7.0-beta, 1.8.0 (HEAD) Environment: Enable PodSecurityPolicy Cloud provider or hardware configuration: gce, probably any OS (e.g. from /etc/os-release): gci Kernel (e.g. ): Install tools: Others: What happened: The PSP admission controller ignores the specified RunAsNonRoot, and overwrites it. What you expected to happen: the admission controller is not supposed to overwrite user specified fields in the podsecuritycontext and securitycontext. How to reproduce it (as minimally and precisely as possible): enable psp, and create a pod with [only] RunAsNonRoot=false specified in a securitycontext. Anything else we need to know:
/sig auth
there are actually 2 bugs here. fails to properly restrict this field when matching against a PSP, which is a latent bug as long as we overwrite the value anyway. overwrites the user-supplied setting for the securitycontext/podsecuritycontext. I suspect the best fix will be to use the API's deep copy function. We are also doing a couple other sketchy things: assigning the "copy" built-in as a variable, and creating an "sc" shadow variable.

I have a half fix in but we should probably fix it in a separate PR, because we may want to patch 1.6.
the effect is that PSP can overly restrict a pod that wanted to run as root, but expressed that as instead of since the workaround is easy (set in your pod if you want to run as root), I don't anticipate backporting the fix.
SGTM. I'll try and get the unit tests in after the GKE summit (on friday).


Question: "type": "integer" } }, <del> "type": "object" </del> <ins> "type": "object", "x-kubernetes-map-type": "atomic" </ins> }, "io.k8s.apimachinery.pkg.apis.meta.v1.APIResource": { "description": "APIResource specifies the name of a resource and whether it is namespaced.",

I created an Ingress resource with a port number manually, and then tried to use an Operator with server-side apply to update the resource from a port number to a port name. This failed with the error message "cannot set both port name & port number". I expected the port number to be cleared as the operator would take over the ownership of the ServiceBackendPort. To simulate the behavior in the operator in a most simple example I use : ingress- ingress- This will print: It seems to me that the merge type for the struct ServiceBackendPort should to be set to "atomic" , so that the Operator updating the port should take over the whole struct, and two applications shouldn't update single fields in it. Red Hat OpenShift on AWS OS version of the client: NAME="Fedora Linux" VERSION="40 (Workstation Edition)" Linux 6.9.6-200.fc40.x8664 SMP PREEMPTDYNAMIC Fri Jun 21 15:48:21 UTC 2024 x86_64 GNU/Linux
/sig network
So, on one hand you made a problem when you used two different owners to manage one aspect of the object. On the other hand, I think you're right that it SHOULD work. Probably. is not a super common tag, and ingress way predates it, so no surprise it isn't used. I ACK the issue and reproduced it. I ran update-codegen and built a KinD cluster from HEAD.
this may be something you want to look at for DRA API - I didn't even realize this was a thing until today :)
The API uses for , which is very similar. So using it for LGTM. SSA will auto-migrate existing resources using once the change is released.
/triage accepted
"this" being "add "? I can see where this might be useful, probably on all one-of structs and perhaps on those containing a discriminator because otherwise SSA leaves fields set which should be cleared when some other owner takes over. Is this important enough to put into I don't see a big need for SSA in general and even less for SSA with different owners at the moment - this will change once we do more with status.
No, not urgent. This is the first time it has come up in my awareness ever. But now that I know about it, I could see how it applies to dra.

Thank to everyone involved here to resolve this! This will make things simpler in the Keycloak operator once it is released.
Thanks for filing a good (and easy to fix :) bug. Easy repro means we can jump on it.


Question: MUST cause pods created by that RC to be orphaned. release: v1.9 file: test/e2e/apimachinery/garbage_collector.go <ins> - testname: Namespace, apply update to a namespace codename: '[sig-api-machinery] Namespaces [Serial] should apply an update to a Namespace [Conformance]' description: When updating the namespace it MUST succeed and the field MUST equal the new value. release: v1.26 file: test/e2e/apimachinery/namespace.go </ins> - testname: Namespace, apply changes to a namespace status codename: '[sig-api-machinery] Namespaces [Serial] should apply changes to a namespace status [Conformance]'

[X] Test approval issue: [X] Test PR: 27 Aug 2022 [x] Two weeks soak end date: 9 Sept 2022 [x] Test promotion PR: According to this APIsnoop query, there are still a remaining Namespace endpoint which is untested. replaceCoreV1Namespace Using a number of existing e2e test practices a new has been created for 1 Namespace endpoint. The e2e logs for this test are listed below. This query shows the following endpoints are hit within a short period of running this e2e test If a test with these calls gets merged, test coverage will go up by 1 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen 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


Question: "k8s.io/kubernetes/pkg/kubelet/cadvisor" "k8s.io/kubernetes/pkg/kubelet/server/stats" kubetypes "k8s.io/kubernetes/pkg/kubelet/types" <ins> "k8s.io/utils/clock" </ins> ) var (

<!-- 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 --When curling the endpoint for stats we don't see network stats. Network stats to be included when calling the summary. This works with dockershim for windows. This happens because Windows containerd uses hcsv2 to create containers and we query for the networks stats using hcsv1: This will be address eventually with move to CRI only metrics KEP: but is still several releases away. 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 windows /assign
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 Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:


Question: import ( "context" <ins> "time" </ins> "github.com/onsi/gomega"

pull-kubernetes-node-e2e-containerd ci-cos-containerd-node-e2e ci-kubernetes-e2e-node-canary Containers should use the image defaults if command and args are blank At least 7th June: ! No response /sig node
/cc This also flake in
/triage accepted /assign
/priority backlog
couple more flakes
Opened up to see if we can resolve this.


Question: errors, err := c.verify(plat) if err != nil { serialFprintf(os.Stderr, "ERROR(%s): failed to verify: %vn", plat, err) <ins> f = true </ins> } else if len(errors) > 0 { for _, e := range errors { // Special case CGo errors which may depend on headers we

make verify WHAT=typecheck-providerless outputs /cc /milestone v1.19
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
see example successful run:
For reference -
fix in
screaming


Question: "golang.org/x/net/context" "k8s.io/api/core/v1" k8stypes "k8s.io/apimachinery/pkg/types" <del> "k8s.io/apimachinery/pkg/util/wait" </del> "k8s.io/client-go/informers" "k8s.io/client-go/tools/cache" v1helper "k8s.io/kubernetes/pkg/apis/core/v1/helper"

In 1.9 vSphere cloud provider creates a new client, new shared informer factory and lists nodes IMO, the cloud provider should not create it's own client at all. GCE uses , called by controller-manager to initialize the cloud provider. This way, GCE does not need extra policy and it shares the informer with all the controllers. is called only in controller-manager process, i.e. for provisioning and attach/detach. Do you need the informer really in kubelet and/or API server? It's quite odd to list all nodes there. /kind bug /sig storage /sig auth
issue regarding is getting fixed with creating and binding with ServiceAccount. See is there a way in kubernetes, we can fix this without assigning permissions to serviceaccount? We will look into SetInformer interface GCE uses.
cloud provider specific roles should be applied externally as we prepare for moving cloud provider specific components out of tree. had feedback on the way that was wired in that would be good to adjust before copying that pattern
thanks for the pointer to old issue. I reworked this one to remove vsphere's own client (and policy).
/assign rohitjogvmw
GitHub didn't allow me to assign the following users: rohitjogvmw. Note that only and repo collaborators can be assigned. <detailsIn response to : /assign rohitjogvmw 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
Running into this same issue (manifested as "Kubernetes node nodeVmDetail details is empty" error upon pvc build using vsphere). Commenting to watch progress. Happy to help debug if needed.
/assign divyenpatel

Here if we with , then we are only able to watch the latest change. In this case if the key is modified after the returns but before the we call the , then we will miss the event. To avoid the window time, we'd better specify the to be the index in the response of the . BTW, I think if we use with , we can probably eliminate the first call.
This is fixed in


Question: "golang.org/x/net/context" "k8s.io/api/core/v1" k8stypes "k8s.io/apimachinery/pkg/types" <del> "k8s.io/apimachinery/pkg/util/wait" </del> "k8s.io/client-go/informers" "k8s.io/client-go/tools/cache" v1helper "k8s.io/kubernetes/pkg/apis/core/v1/helper"

Here if we with , then we are only able to watch the latest change. In this case if the key is modified after the returns but before the we call the , then we will miss the event. To avoid the window time, we'd better specify the to be the index in the response of the . BTW, I think if we use with , we can probably eliminate the first call.
This is fixed in


Question: // ListAlgorithmProviders lists registered algorithm providers. func ListAlgorithmProviders() string { <del> r := NewRegistry() var providers []string for k := range r { providers = append(providers, k) } sort.Strings(providers) return strings.Join(providers, " | ") </del> <ins> return fmt.Sprintf("%s | %s", ClusterAutoscalerProvider, schedulerapi.SchedulerDefaultProviderName) </ins> } func getDefaultConfig() *schedulerapi.Plugins {

Using scheduler like or , it always get unwanted output like: It simply because when adding the flags in scheduler, it will try to look up the And this will invoke: Since flag already has to prevent running other code when having : We should not print the klog info when using or right?
/sig scheduling
that's annoying. Can you help to fix it?
Ok I'll take care of this. /assign


Question: testcases+=("${arg}") fi done <ins> if [[ ${#testcases[@]} -eq 0 ]]; then testcases=($(kube::test::find_dirs)) fi </ins> set -- "${testcases[@]+${testcases[@]}}" <ins> # TODO: this should probably be refactored to avoid code duplication with the # coverage version. </ins> if [[ $iterations -gt 1 ]]; then if [[ $# -eq 0 ]]; then set -- $(kube::test::find_dirs)

Our test- script invokes 'go test' serially for each pkg - currently taking 2 minutes on my laptop. Running a single 'go test' for all pkgs cuts the time down to 45 seconds. Even running with -race is only 1:15. As far as I can tell, the only time we HAVE to run serially is when coverage is on. Does anyone have time to fix this?
I'd created on Friday to fix this, though it's not yet been reviewed.
I cobbled together but I'll review yours since it is probably better :) , Jeff Grafton wrote:


Question: expected: false, }, { <ins> msg: "rule names match while idletimeout unmatch should return false", existingRule: []network.LoadBalancingRule{ { Name: to.StringPtr("httpRule"), LoadBalancingRulePropertiesFormat: &network.LoadBalancingRulePropertiesFormat{ IdleTimeoutInMinutes: to.Int32Ptr(1), }, }, }, curRule: network.LoadBalancingRule{ Name: to.StringPtr("httpRule"), LoadBalancingRulePropertiesFormat: &network.LoadBalancingRulePropertiesFormat{ IdleTimeoutInMinutes: to.Int32Ptr(2), }, }, expected: false, }, { msg: "rule names match while idletimeout nil should return true", existingRule: []network.LoadBalancingRule{ { Name:                              to.StringPtr("httpRule"), LoadBalancingRulePropertiesFormat: &network.LoadBalancingRulePropertiesFormat{}, }, }, curRule: network.LoadBalancingRule{ Name: to.StringPtr("httpRule"), LoadBalancingRulePropertiesFormat: &network.LoadBalancingRulePropertiesFormat{ IdleTimeoutInMinutes: to.Int32Ptr(2), }, }, expected: true, }, { </ins> msg: "rule names match while LoadDistribution unmatch should return false", existingRule: []network.LoadBalancingRule{ {

<!-- 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: Azure cloud provider is sending unexpected LoadBalancer update requests even if the LoadBalancer rules are already identical. The reason is GetIdleTimeout() returns nil when the annotation is not set While find rule doens't check whether it is nil or not. What you expected to happen: Azure cloud provider shouldn't send unexpected LoadBalancer updates. It is easily to get throttled if there're too many services running on the cluster. How to reproduce it (as minimally and precisely as possible): kubectl annotate service nginx testlabel=value 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: /kind bug /area provider/azure /assign
/sig cloud-provider


Question: "io" "os" "os/exec" <del> "runtime" </del> "strings" "syscall"

<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently, the kubectl plugins system - when running under Windows - will determine that a plugin is executable by looking at the plugin's extension, comparing it to '.exe'. I think we should allow plugins w/ a few more known extensions (.bat, .com, .cmd; for example). Why is this needed: This would give more of a similar experience to plugins under *nix, where shell scripts are often used.
/sig cli
Please see the PR below:


Question: package core import ( <ins> "fmt" </ins> "hash/fnv" "sync"

in the integration test in an seemingly unrelated PR
/assign
It is known that may be nil during testing, and we've checked this case in some other places. But not sure why this happens in TestTaintNodeByCondition right now. Looking looking ...
Another case in another unrelated PR https://k8s-
, thanks for your input, I'd like to see what will happen after merged :)
still seeing this: panic: runtime error: invalid memory address or nil pointer dereference [recovered] panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x1103224] goroutine [running]: (0x0, 0x0, 0x0) +0x107 panic(0x361b8e0, 0x71ac100) +0x229 (ObjectMeta).GetName(...) (EquivalenceCache).RunPredicate(0xc42500cd40, 0x3f62748, 0x3e2aa3f, 0x11, 0xc42f9a2380, 0x523ab40, 0xc4345c8e10, 0x0, 0xc4235e5d50, 0x528e060, ...) +0xc4 (0xc42f9a2380, 0x523ab40, 0xc4345c8e10, 0x0, 0xc4339a3320, 0x528e060, 0xc42436fa40, 0xc42500cd40, 0x527b2c0, 0xc43b40ee70, ...) +0x1de (*genericScheduler).findNodesThatFit.func1(0x0) +0x19a (0xc4235e5d90, 0xc42cdbad20, 0xc43bb83dc0) +0x96 created by +0x10b https://k8s-
is the failing code live in master or feature gated? is this a release blocker?
The failing code is live in master(, we enabled the feature gate in the test), where as the equivalence cache is still in alpha.

While the issue is something needs to be fixed in ecache code which is working on, this shouldn't be be blocking 1.11 release as we are still planning to graduate ecache to beta and that has not yet happened. I will send a PR to disable test till the promotion happens. While promoting ecache we can re-enable it.
Equivalence cache implementation is behind a feature gate, and still alpha.


Question: // DebuggingConfiguration holds configuration for Debugging related features. type DebuggingConfiguration struct { // enableProfiling enables profiling via web interface host:port/debug/pprof/ <del> EnableProfiling bool `json:"enableProfiling"` </del> <ins> EnableProfiling *bool `json:"enableProfiling,omitempty"` </ins> // enableContentionProfiling enables lock contention profiling, if // enableProfiling is true. <del> EnableContentionProfiling bool `json:"enableContentionProfiling"` </del> <ins> EnableContentionProfiling *bool `json:"enableContentionProfiling,omitempty"` </ins> } // ClientConnectionConfiguration contains details for constructing a client.

What would you like to be : Change the external DebuggingConfiguration member variables to pointer types. Why is this needed: So that we can set their default values to something different from golang's, for example enable profiling by default. /sig api-machinery /cc
The label(s) cannot be applied. These labels are supported: <detailsIn response to : What would you like to be : Change the external DebuggingConfiguration member variables to pointer types. Why is this needed: So that we can set their default values to something different from golang's, for example enable profiling by default. /cc 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
done in


Question: for k, v := range s.filterTags { filters = append(filters, newEc2Filter("tag:"+k, v)) } <ins> if len(filters) == 0 { // We can't pass a zero-length Filters to AWS (it's an error) // So if we end up with no filters; just return nil return nil } </ins> return filters }

From Slack, we got a report that "my service controller is trying to delete a ELB ( im running k8s in ews ) thats is not there, and for that reason its failing over and over again with the message " It turns out the user had deleted the ELB manually. We should tolerate this better.
I think this was actually caused by a failure to tag the cluster, which triggered another bug where we can't pass an empty filters list to the AWS API


Question: "sh", "-c", // use the dd tool to attempt to allocate huge block of memory which exceeds the node allocatable <del> "sleep 5 && dd if=/dev/zero of=/dev/null iflag=fullblock count=10 bs=10G", </del> <ins> "sleep 5 && dd if=/dev/zero of=/dev/null iflag=fullblock count=10 bs=1024G", </ins> }, SecurityContext: &v1.SecurityContext{ SeccompProfile: &v1.SeccompProfile{

ci-cgroupv1-containerd-node-arm64-e2e-serial-ec2-eks ci-cgroupv1-containerd-node-e2e-serial-ec2-eks It has been failing consistently for a long time. No response /sig node
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
/cc
There's another bug that was filed a long time ago. But there's no update on it and the same test in gce jobs seem to be green now.
cc


Question: readOnly: true hostNetwork: true serviceAccountName: kube-proxy <del> tolerations: - operator: Exists </del> volumes: - name: kube-proxy configMap:

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: After joining a new ppc64le node to the k8s cluster, the kube-proxy DaemonSet fails on the new node. What you expected to happen: It was expected that the kube-proxy DS would "just work" as it does when adding an amd64 node to the cluster. How to reproduce it (as minimally and precisely as possible): Set up an amd64 based k8s cluster, then join a ppc64le node (or any non-amd64 arch) to the cluster. See the pod fail via 'kubectl -n kube-system get pods' because it's pulling the amd64 kube-proxy docker image instead of the ppc64le image. Anything else we need to know?: The yaml for the DaemonSet specifies the image: <versionIt would be preferable to have a manifest so that the image in the DS could be specified as <versionand could "just work" on any platform. See: Environment: Kubernetes version (use ): v1.10.3 Cloud provider or hardware configuration: self - cluster installed via kubeadm OS (e.g. from /etc/os-release): NAME="Ubuntu" VERSION="16.04.3 LTS (Xenial Xerus)" ID=ubuntu IDLIKE=debian PRETTYNAME="Ubuntu 16.04.3 LTS" VERSIONID="16.04" HOMEURL="" SUPPORTURL="" BUGREPORTURL="" VERSIONCODENAME=xenial UBUNTU_CODENAME=xenial Kernel (e.g. ): N/A Install tools: N/A Others: N/A
if you are running multi-architecture nodes, your daemonsets should specify a node selector to limit their arch-specific image to run on matching nodes
/close
I am well aware that a node selector can be used. That is what we are doing now. But it is a hack. The default should "just work". Adding a new non-amd64 node should not result in kube-proxy immediately failing on it because the default daemon set is amd64 arch specific. If kube-proxy is meant to "just work" clusterwide, a node selector should not be needed.

Please use the manifest-tool so that the default "just works". Please see the weave-net plugin. They are using the manifest-tool and it "just works" on amd64 and ppc64le. Their daemon set does not require/use a nodeSelector.
The current kube-proxy daemon set implementation is not properly architected, IMHO. Please re-open this
Reiterating the mentions to trigger a notification: <detailsIn response to : The current kube-proxy daemon set implementation is not properly architected, IMHO. Please re-open this </details
ah, this was a comment about the kube-proxy image, not the daemonset functionality /reopen
the kube-proxy addon daemonset is probably the multi-arch kube-proxy image to support that daemonset might be
Looks like it's coming from here: /assign /sig cluster-lifecycle Lucas, Do we want to avoid the references?
A dirty workaround for this is to pull and rename to . The kube-proxy is running as daemonset, created during . That means the kube-proxy image arch keeps consistent with your master node. Currently we don't have a multi-arch kube-proxy image yet. We have to explicitly specify the right name, like .
Hi .. Yes, we just created a separate daemonset with a ppc64le node slector that refers to the ppc64le image directly. But it's a bit of a hack. That is why I opened this ticket looking for a multi-arch image. Thanks!
I don't know that mixed-ISA clusters are supported. cc
The requirement is: only use "" in DaemonSet yaml file, and the k8s will download the correct image according to the ARCH info. It's more about image registry's feature; and it seems some registries had supported that: .
Yeah, has already supported multi-arch. But actually all the images now are architecture specific, like and . We've not built any multi-arch images right now.
for the test images we have the ball rolling here - - so if you can do the same (or similar) for other images, that would be great!
I have pending PR in releases project for creating manifest for those -
The manifest images created in kubernetes/release should work for future released versions, but will they be created during CI testing?

if you see one of the jobs that pushes images say you can grep for that's basically from the same files that got changed in so i fully expect the images pushed to CI will reflect the changes made in 516.
please confirm that i am reading this right ^ :)
I was more concerned with ci jobs that do not use cross builds, such as https://k8s-
please open an issue about pushing manifests in CI as well


Question: } match := label.Matches(labels.Set(controller.Labels)) if match { <del> pods, _ := r.ListPods(ctx, labels.Set(controller.Spec.Selector).AsSelector()) </del> <ins> pods, err := r.ListPods(ctx, labels.Set(controller.Spec.Selector).AsSelector()) if err != nil { glog.Warningf("Error listing pods: %v", err) // No object that's useable so drop it on the floor return false } if pods == nil { glog.Warningf("Pods list is nil.  This should never happen...") // No object that's useable so drop it on the floor return false } </ins> controller.Status.Replicas = len(pods.Items) } return match

Test log with failure: https://travis- Stack trace of panicing thead:
I think there are two issues: integration test should not have failed with fatal error. Not sure why, but probably related to the 501 error. the anonymous function inside got passed a bad value.


Question: package azure import ( <ins> "context" </ins> "strings" "sync" "time"

<!-- 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: Recently we upgraded our cluster from 1.14.4 to 1.14.7. Then we started to observe tons of following errors: I guess the cause may be related to this line which was introduced recently: As we have hundreds of services with LoadBalancer type, and we also enable cluster-autoscaler, the nodes list change very often. For each service, there will be one call to GetScaleSet. The quota will be exhausted quickly. When fails, new nodes created by cluster-autoscaler will lose connectivity to load balancer. What you expected to happen: Kubernetes should not hit VMSS throttling threshold. How to reproduce it (as minimally and precisely as possible): a cluster with aks-engine. Use VMSS. 200 services with LoadBalancer type. up VMSS to 50 nodes down VMSS to 60 nodes scaling up and down VMSS Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.7 Cloud provider or hardware configuration: Azure, VMSS OS (e.g: ): Ubuntu Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area provider/azure
I create a PR to mitigate the issue.
do we have a rough num about how this PR would mitigate this issue? looks like we need to cherry-pick this PR to old releases. it's better if we have a rough estimation.
The revised version of code calls instead of azure API. The cache refreshes itself every 10 min. I believe this will solve the throttling issue.
I believe we're being affected by this. Apart from getting the - when creating our to use a pre-configured Azure Public IP, the ingress appears to be getting a different IP each time
Thank you all!
The PR is merged. Does your issue remain?

pls cherry-pick that fix to old release, thanks
Cherry picked to release 1.14-1.16
I’ll retry today and let you know Wysłane z iPhone'a
Issue returned in K8S 1.15.4 Warning UpdateLoadBalancerFailed service/nginx-ingress-controller Error updating load balancer with new hosts map[<nodes names]: [EnsureHostInPool(ingress/nginx-ingress-controller): backendPoolID(/subscriptions/<subscription/resourceGroups/<rg/providers/Microsoft.Network/loadBalancers/<rg/backendAddressPools/<rg) - failed to ensure host in pool: "azure - cloud provider rate limited(read) for operation:VMSSGet", EnsureHostInPool(ingress/nginx-ingress-controller):


Question: ### SEE ALSO * [kubectl](kubectl.md)	 - kubectl controls the Kubernetes cluster manager <del> ###### Auto generated by spf13/cobra at 2015-05-21 10:33:11.188518514 +0000 UTC </del> <ins> ###### Auto generated by spf13/cobra at 2015-05-28 20:57:46.689818993 +0000 UTC </ins> [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/kubectl_proxy.md?pixel)]()

Without , works just fine, With '--api-prefix=xxx-api', it stops work: My version: could you take a look? Thanks.
--api-prefix was in . could you take a look? This appears to be completely broken, so we should fix it or rip it out.
Reading the code and I find the way to fix it. You need to use , note the slashes. I will fix the man page.
What's an example command line that works?
then
Ah, the default flag value has leading and trailing slashes: The example in the documentation is wrong: Re-opening for doc fix.
The trailing slash is not necessary. and duplicate each other.


Question: framework.ExpectNoError(err) }) <ins> /* Create a ClusterIP service with an External IP that is not assigned to an interface. The IP ranges here are reserved for documentation according to [RFC 5737](https://tools.ietf.org/html/rfc5737) Section 3 and should not be used by any host. */ ginkgo.It("should be possible to connect to a service via ExternalIP when the external IP is not assigned to a node", func() { serviceName := "externalip-test" ns := f.Namespace.Name externalIP := "203.0.113.250" if framework.TestContext.ClusterIsIPv6() { externalIP = "2001:DB8::cb00:71fa" } jig := e2eservice.NewTestJig(cs, ns, serviceName) ginkgo.By("creating service " + serviceName + " with type=clusterIP in namespace " + ns) clusterIPService, err := jig.CreateTCPService(func(svc *v1.Service) { svc.Spec.Type = v1.ServiceTypeClusterIP svc.Spec.ExternalIPs = []string{externalIP} svc.Spec.Ports = []v1.ServicePort{ {Port: 80, Name: "http", Protocol: v1.ProtocolTCP, TargetPort: intstr.FromInt(9376)}, } }) framework.ExpectNoError(err) err = jig.CreateServicePods(2) framework.ExpectNoError(err) execPod := e2epod.CreateExecPodOrFail(cs, ns, "execpod", nil) err = jig.CheckServiceReachability(clusterIPService, execPod) framework.ExpectNoError(err) }) </ins> // TODO: Get rid of [DisabledForLargeClusters] tag when issue #56138 is fixed. ginkgo.It("should be able to change the type and ports of a service [Slow] [DisabledForLargeClusters]", func() { // requires cloud load-balancer support

What would you like to be : e2e test for service ExternalIPs Why is this needed: There is no test covering Service ExternalIPs Since we can not assume that the e2e binary will have connectivity against the nodes and that we can add routes to the environment, we are going to test it from a pod. I've verified that this works locally with the following commands: The test should leverage current framework, maybe something as A good example is here, maybe adding a ?
/sig network /help wanted /triage accepted
/help wanted /good-first-issue
/assign
I'd like to pick this up!
Ok,I'm not started :) /unassign /assign
There are two different externalIP codepaths, one for the case where the claimed external IP exists as an IP on the default interface, and one for where it does not. I suppose we could just temporarily add an IP to the default interface...
good idea Dan Please remember, it has to work for IPv6 and for IPv4 ... anyway, we can address these things during the review
This has been partially implemented with . Covering the code path for when an IP is does not exist on a node. I'll assign this back to you so you can split this issue or close it in favor of another issue. Thanks! /unassign /assign
what is the different codepath for ExternalIPs that already exist on the host? ~My reading is that the only difference is that it opens a local socket on that port, can you expand on this?~ Found it
so, it seems that this work in some environments because they are not using the bridge plugin why is not allowed that pods can reach ExternalIPs?
Wow, this is ancient and needs some fixing. This is not about preventing pod traffic from reaching those IPs. I had to really stare at it, and I am not 100% in my interpretation. First, we recognize such traffic from "off machine" (!physdev-is-in && !src=LOCAL, which we should probably switch to localDetector) and steer it to the Service. Second, we recognize ANY such traffic that is destined for a LOCAL address and shortcut that to the Service, Implicitly, traffic destined for this IP where the IP is not local goes to the system's default routing logic.

The reliance on the bridge plugin is awful and archaic and I will buy a beverage of your choice for whomever gets rid of that. I think localDetector can cover this, but not 100% sure
but the ExternalIP belongs to a service and we(kube-proxy) "knows" where to send it (to the service) , that is the part I'm not sure to understand, because whatever the user is doing with that ExternalIP it has to send it back to the cluster to reach the service. However, there is always context that is important and maybe I'm missing something. Assuming we want to handle ALL the ExternalIP traffic with kube-proxy, the logic will be much simpler: traffic to an externalIP will be ALWAYS sent to the Service (DNAT) if traffic is NOT LOCAL, we also SNAT
/remove-good-first-issue /remove-help-wanted


Question: case v1.ResourceMemory: q, err := parsePercentage(v) if err != nil { <del> return nil, err </del> <ins> return nil, fmt.Errorf("failed to parse percentage %q for %q resource: %w", v, k, err) </ins> } reservations[v1.ResourceName(k)] = q default:

During kubelet start up if the system reserved or kube reserved values failed to parse, the kubelet won't start up. The error logged looks like, However, it doesn't not inform the user which system reserved or kube reserved quantity has failed and what was the corresponding value of that quantity. The error log should also container quantity type and the value that failed to parse, so that user can fix them easily. Try to start kubelet with unparsable values of system reserved, something like, The error logged would look like, As you can see above, it doesn't say was not able to parse with the value No response <details</details<details</details<details</details<details</details<details</details<details</details
/kind feature /sig node
/assign
Thanks for Should I close in favour of yours?
Oh sorry, I didn't see your PR. Either way works for me. You can either incorporate ideas from my PR and I'll drop mine, or drop your PR. I don't feel strongly either way.
/triage accepted /priority backlog /assign
Let's go with yours!
Thanks /close (in favor of )
Closing this issue. <detailsIn response to : Thanks (in favor of ) 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


Question: "context" "fmt" "net/http" <ins> "strings" </ins> "time" "github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2019-06-01/storage"

<!-- Please only use this template for submitting enhancement requests --What would you like to be : PR() already proves that old api-version on Azure stack works on global Azure too, we could support azure stack in azure cloud provider lib, and then make sure following components works in Azure stack: CSI drivers: azure disk, azure file CCM Since it's mainly api-version change, we could also add e2e tests against global Azure too. Why is this needed: /assign /priority important-soon /sig cloud-provider /area provider/azure
there is blocking issue here(also need azure stack supports latest data model struct): just making the change in interfaces and not go-sdk but facing this error, since we don't have a switch inside go-sdk, we only do switch in azure cloud provider lib,
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. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale


Question: AllowInvalidTopologySpreadConstraintLabelSelector bool // Allow node selector additions for gated pods. AllowMutableNodeSelectorAndNodeAffinity bool <ins> // Allow projected token volumes with non-local paths AllowNonLocalProjectedTokenPath bool </ins> // Allow namespaced sysctls in hostNet and hostIPC pods AllowNamespacedSysctlsForHostNetAndHostIPC bool // The top-level resource being validated is a Pod, not just a PodSpec

Originally posted by in
Hello, I'm new here. Can I try solving this? it seems like a good first issue
sure, context is the change is needed here: We have to tolerate existing pods / pod specs that fail this validation, so we should only do this additional validation on create or if the existing object passes this validation. To do this: an field to , initialize that field to false, and then conditionally override it to if is non-nil and has a projected token volume path that fails (will have to export the function to check this) , if is false, call the validation on the path:
Hi, I'd like to work on this if there is no one is proceeding on. /assign


Question: KUBE_PROXY_TOKEN: $(yaml-quote ${KUBE_PROXY_TOKEN:-}) ADMISSION_CONTROL: $(yaml-quote ${ADMISSION_CONTROL:-}) MASTER_IP_RANGE: $(yaml-quote ${MASTER_IP_RANGE}) <del> CA_CERT: $(yaml-quote ${CA_CERT_BASE64}) </del> <ins> CA_CERT: $(yaml-quote ${CA_CERT_BASE64:-}) </ins> EOF if [[ "${master}" == "true" ]]; then

We need to be squelching the auth variables on upgrade anyways, but this complaint gets issued (and it proceeds anyways): cc


Question: <ins> # Disable inheritance as this is an api owners file options: no_parent_owners: true </ins> approvers: - api-approvers reviewers:

I believe this owners file should not inherit permissions from parent OWNERS files; only api approvers should be able to approve api changes.
/kind feature /sig architecture
opened to do this


Question: broadcaster.StartLogging(glog.Infof) broadcaster.StartRecordingToSink(&v1core.EventSinkImpl{Interface: v1core.New(kubeClient.Core().RESTClient()).Events("")}) recorder := broadcaster.NewRecorder(scheme.Scheme, v1.EventSource{Component: "service-controller"}) <del> broadcaster.StartLogging(glog.Infof) </del> if kubeClient != nil && kubeClient.Core().RESTClient().GetRateLimiter() != nil { metrics.RegisterMetricAndTrackRateLimiterUsage("service_controller", kubeClient.Core().RESTClient().GetRateLimiter())

<!-- 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?: /kind bug /sig cluster-lifecycle What happened: introduced a redundant call on StartLogging in the service controller. It's called on line What you expected to happen: Should only be called once Anything else we need to know?: cc


Question: return []string{} } <del> return filepath.SplitList(envVarValue) </del> <ins> fileList := filepath.SplitList(envVarValue) // prevent the same path load multiple times return deduplicate(fileList) </ins> } func (o *PathOptions) GetLoadingPrecedence() []string {

/kind bug /sig cli What happened: The same path was multiple times to KUBECONFIG env variable. 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 ): Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-10-05T00:40:04Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"darwin/amd64"} Cloud provider or hardware configuration**: Irrelevant OS (e.g. from /etc/os-release): MacOS Sierra 10.12.6 Kernel (e.g. ): Darwin Kernel Version 16.7.0 Install tools: brew install kubernetes-cli Others:
I would help fix it.
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. 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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close


Question: t.Errorf("The code did panic") } }() n.OnNodeUpdate(oldNode, node) }) } } <ins> func customExit(exitCode int) { panic(strconv.Itoa(exitCode)) } </ins>

There are some cases when kube-proxy has to exit and restart, in order to do that we panic, but this has the problem that the log output shows a literal "panic" message and engineers, support, customers and automation gets confused, thinking that is a problem when is the expected behavior. As suggested by in , we can replace by /sig network /help /kind cleanup
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : There are some cases when kube-proxy has to exit and restart, in order to do that we panic, but this has the problem that the log output shows a literal "panic" message and engineers, support, customers and automation gets confused, thinking that is a problem when is the expected behavior. /help /kind cleanup </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
/assign I would like to raise a PR to fix this.


Question: # Update a kubernetes cluster with latest source function kube-push { get-kubeconfig-basicauth <ins> get-kubeconfig-bearertoken </ins> create-provision-scripts vagrant provision }

I have a running cluster in vagrant, had to make some code changes and push back but fails with:
cc:
Adding to queue of vagrant stuff to look at tomorrow.
Fixed by


Question: } for _, epInfo := range proxier.endpointsMap[svcPortName] { <ins> if onlyNodeLocalEndpoints && !epInfo.GetIsLocal() { continue } </ins> newEndpoints.Insert(epInfo.String()) }

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The test is flaky with the error something like: What you expected to happen: Test should pass /assign
/sig network /area ipvs
/close
Cases are green now. :tada:


Question: } return lastEvent, nil } <ins> func checkReplicationControllerStatusReplicaCount(f *framework.Framework, rcName string, quantity int32) func() (bool, error) { return func() (bool, error) { framework.Logf("Get Replication Controller %q to confirm replicas", rcName) rc, err := f.ClientSet.CoreV1().ReplicationControllers(f.Namespace.Name).Get(context.TODO(), rcName, metav1.GetOptions{}) if err != nil { return false, err } if rc.Status.Replicas != quantity { return false, nil } framework.Logf("Found %d replicas for %q replication controller", quantity, rc.Name) return true, nil } } </ins>

[X] Test approval issue: [X] Test PR: 29 Sept 2022 [X] Two weeks soak end date: 14 Oct 2022 [X] Test promotion PR: According to this APIsnoop query, there are still two remaining ReplicationControllerScale endpoints which are untested for conformance. readCoreV1NamespacedReplicationControllerScalereplaceCoreV1NamespacedReplicationControllerScale Using a number of existing e2e test practices a new has been created for two ReplicationControllerScale endpoints. The e2e logs for this test are listed below. This query shows which scale endpoints are hit within a short period of running this e2e test If a test with these calls gets merged, test coverage will go up by 2 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen 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


Question: expectedConfigModes := []string{"1", "0"} for i, configMode := range configModes { <ins> t.Run(fmt.Sprintf("validate token from cfg with configMode %v", configMode), func(t *testing.T) { const ( serverID     = "fakeServerID" clientID     = "fakeClientID" tenantID     = "fakeTenantID" accessToken  = "fakeToken" environment  = "fakeEnvironment" refreshToken = "fakeToken" expiresIn    = "foo" expiresOn    = "foo" ) cfg := map[string]string{ cfgConfigMode:   string(configMode), cfgApiserverID:  serverID, cfgClientID:     clientID, cfgTenantID:     tenantID, cfgEnvironment:  environment, cfgAccessToken:  accessToken, cfgRefreshToken: refreshToken, cfgExpiresIn:    expiresIn, cfgExpiresOn:    expiresOn, } fakeSource := fakeTokenSource{token: newFakeAzureToken("fakeToken", time.Now().Add(3600*time.Second))} persiter := &fakePersister{cache: make(map[string]string)} tokenCache := newAzureTokenCache() tokenSource := newAzureTokenSource(&fakeSource, tokenCache, cfg, configMode, persiter) azTokenSource := tokenSource.(*azureTokenSource) token, err := azTokenSource.retrieveTokenFromCfg() if err != nil { t.Errorf("failed to retrieve the token form cfg: %s", err) } if token.apiserverID != serverID { t.Errorf("expecting token.apiserverID: %s, actual: %s", serverID, token.apiserverID) } if token.clientID != clientID { t.Errorf("expecting token.clientID: %s, actual: %s", clientID, token.clientID) } if token.tenantID != tenantID { t.Errorf("expecting token.tenantID: %s, actual: %s", tenantID, token.tenantID) } expectedAudience := serverID if configMode == configModeDefault { expectedAudience = fmt.Sprintf("spn:%s", serverID) } if token.token.Resource != expectedAudience { t.Errorf("expecting adal token.Resource: %s, actual: %s", expectedAudience, token.token.Resource) } }) </ins> t.Run("validate token against cache", func(t *testing.T) { fakeAccessToken := "fake token 1" fakeSource := fakeTokenSource{token: newFakeAzureToken(fakeAccessToken, time.Now().Add(3600*time.Second))}

<!-- 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 using kubectl, authentication fails with the below error For some reason kubectl is adding a lot of s to the start of the SPN - this can be observed in What you expected to happen: Authentication works as in previous versions of Kubectl How to reproduce it (as minimally and precisely as possible): Create a cluster using Azure AD authentication. Authenticate from a client and wait until the token expires. Use Kubectl and have it automatically refresh the token; it will fail due to the extra 'spn:' entries. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: on-premise OS (e.g: ): macOS 10.14.6 Kernel (e.g. ): Darwin Hostname 18.7.0 Darwin Kernel Version 18.7.0: Mon Feb 10 21:08:45 PST 2020; root:xnu-4903.278.28~1/RELEASEX8664 x86_64 Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others:
/sig cli
Kubectl version 1.18.0 Kubernetes version 1.16.6
can you confirm whether your original kubeconfig already has in apiserver-id or not? in the mean time, you may try it can convert your kubeconfig from azure module to exec module and do the token thing outside kubectl
At this point if I remove the tokens and try to reauth i get the error described above. I've tried it both ways with apiserver-id having an initially and not, both lead to the same behavior in the end.
i know what's going on now. will prepare a fix. the root cause is that token's target resource (adal.Token.Resource) needs to have prefix and this prefix gets unexpectedly to as well, which gets written back to kubeconfig. So every time kubectl is run, it adds to apiserver-id
/priority important-soon
I'm seeing this with kubectl 1.17.3 and kubernetes 1.16.7.

It's unclear to me what versions are impacted and in what version it is fixed, since only version 1.18 is mentioned.
This still happens on kubectl 1.16.12 and 1.17.8
This still happens on kubectl v1.18.5
same
can you guys share your kubectl version --client and kubeconfig with me? you can find me on kubernetes slack. the slack user name is same as my github handle.
Version 1.17.6 works fine.
Since I was mistaken thinking was still causing this for me, I figured I would just drop a note for others in case it's helpful. Turns out my problem was actually due to and looks to have been resolved as of the v3.3.0 release.
This issue has now reappeared for me - although not necessarily the same root cause. AKS 1.19.0 Authentication works, but it spams frequently.


Question: import ( "context" <ins> "encoding/json" </ins> "fmt" "strconv" "time" <ins> kubeletconfigv1beta1 "k8s.io/kubelet/config/v1beta1" kubeletconfig "k8s.io/kubernetes/pkg/kubelet/apis/config" kubeletconfigscheme "k8s.io/kubernetes/pkg/kubelet/apis/config/scheme" </ins> v1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/kubernetes/test/e2e/framework" <del> e2ekubelet "k8s.io/kubernetes/test/e2e/framework/kubelet" </del> e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper" imageutils "k8s.io/kubernetes/test/utils/image"

ci-kubernetes-e2e-aks-engine-azure-master-windows-containerd-serial-slow Kubernetes e2e suite: [sig-windows] [Feature:Windows] Memory Limits [Serial] [Slow] Allocatable node memory should be equal to a calculated allocatable memory value expandmore this month No response_ /sig windows
/assign
/triage accepted /priority important-soon


Question: "github.com/onsi/ginkgo" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/util/wait"

<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-serial Which test(s) are failing: [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to add nodes [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to delete nodes Since when has it been failing: These tests have been failing since 6/28 Failures coincide with the following changes: Testgrid link: Reason for failure: The failure messages look as follows: [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to add nodes [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to delete nodes /cc /milestone v1.16 /priority critical-urgent /kind failing-test /cc
/sig cluster-lifecycle
For more context, the code for the failing tests is here The error for both comes through  - some Pod is not responding. It is failing to find pods prefixed with "my-hostname-add-node". Within the logs we can see this: So the Pods are stuck in a Pending state. The Pods are supposed to be created by a ReplicationController in , which itself uses this method from the e2e framework . However, after being in a Pending state (after the "failed to wait for pods responding: timed out waiting for the condition" error is registered), they do seem to reach a Ready state
/assign for triage.
I think agnhost needs to be passed , but did not do so in /assign sig-testing
GitHub didn't allow me to assign the following users: sig-testing. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : I think agnhost needs to be passed , but did not do so in 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
Reopen to monitor job /reopen
Reopened this issue.

<detailsIn response to : Reopen to monitor job /reopen 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
Thank you for working on the PR to solve this. indeed solved the issue reported here. /close
Closing this issue. <detailsIn response to : Thank you for working on the PR to solve this. /close 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


Question: rbacv1 "k8s.io/api/rbac/v1" apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/types" </ins> "k8s.io/apimachinery/pkg/util/sets" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/apimachinery/pkg/util/wait" <ins> watch "k8s.io/apimachinery/pkg/watch" </ins> "k8s.io/kubernetes/plugin/pkg/admission/serviceaccount" "k8s.io/kubernetes/test/e2e/framework" e2ekubectl "k8s.io/kubernetes/test/e2e/framework/kubectl"

[ ] Promotion created According to this APIsnoop query, there are still some remaining ServiceAccount endpoints which are untested. Create a ServiceAccount with a static label Create a Secret Patch the ServiceAccount with a new Label and a new Secret Get the ServiceAccount to ensure it's patched List all ServiceAccounts in all Namespaces find the ServiceAccount(1) ensure that the ServiceAccount is found and is patched Delete Namespaced ServiceAccount(1) via a Collection with a LabelSelector Delete the Secret Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
Fine with moving forward You don't need to check the status of the secret as part of the test. In other places we check that the resource in question happens, we don't have to follow.
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
/retitle Write CoreV1ServiceAccount resource lifecycle test+promote - +3
/close close this Issue in favour of and place in In Progress Issues on org dashboard
Closing this issue. <detailsIn response to : /close close this Issue in favour of and place in In Progress Issues on org dashboard </details


Question: package prereleaselifecyclegenerators import ( <ins> "fmt" </ins> "reflect" <ins> "strconv" </ins> "testing" "k8s.io/gengo/types" <ins> "k8s.io/klog/v2" </ins> ) var mockType = &types.Type{

The commands under will benefit of a batter unit test coverage as seen in Originally posted by in
/sig api-machinery /assign
GitHub didn't allow me to assign the following users: damiansawicki. Note that only with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /sig api-machinery 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
Hi I would like to work on this issue. Could you tell me how many test files are needed per PR under this issue?
Hi the issue is already assigned to me. Would you consider contributing to other issues to avoid duplication?
Hi do you mind if I work on this issue along with you? I would only like to write tests on limited number of files, if that's okay with you...
Hi thanks for your engagement! If you also want to work on this particular issue, we should coordinate. Are you working on something other than ?
Hey currently I'm thinking of shifting to Do let me know if you are already working on that particular directory. Also I could assist you in any of your work on this issue as I'm not preoccupied at the moment.


Question: framework.Failf("expected IsNotFound error, got %#v", err) } }) <ins> ginkgo.It("should patch a pod status", func() { ns := f.Namespace.Name podClient := f.ClientSet.CoreV1().Pods(ns) podName := "pod-" + utilrand.String(5) label := map[string]string{"e2e": podName} ginkgo.By("Create a pod") testPod := e2epod.MustMixinRestrictedPodSecurity(&v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:   podName, Labels: label, }, Spec: v1.PodSpec{ TerminationGracePeriodSeconds: pointer.Int64(1), Containers: []v1.Container{ { Name:  "agnhost", Image: imageutils.GetE2EImage(imageutils.Agnhost), }, }, }, }) pod, err := podClient.Create(context.TODO(), testPod, metav1.CreateOptions{}) framework.ExpectNoError(err, "failed to create Pod %v in namespace %v", testPod.ObjectMeta.Name, ns) framework.ExpectNoError(e2epod.WaitForPodRunningInNamespace(f.ClientSet, pod), "Pod didn't start within time out period") ginkgo.By("patching /status") podStatus := v1.PodStatus{ Message: "Patched by e2e test", Reason:  "E2E", } pStatusJSON, err := json.Marshal(podStatus) framework.ExpectNoError(err, "Failed to marshal. %v", podStatus) pStatus, err := podClient.Patch(context.TODO(), podName, types.MergePatchType, []byte(`{"metadata":{"annotations":{"patchedstatus":"true"}},"status":`+string(pStatusJSON)+`}`), metav1.PatchOptions{}, "status") framework.ExpectNoError(err, "failed to patch pod: %q", podName) framework.ExpectEqual(pStatus.Status.Message, "Patched by e2e test", fmt.Sprintf("Status.Message for %q was %q but expected it to be "Patched by e2e test"", podName, pStatus.Status.Message)) framework.ExpectEqual(pStatus.Status.Reason, "E2E", fmt.Sprintf("Status.Reason for %q was %q but expected it to be "E2E"", podName, pStatus.Status.Reason)) framework.Logf("Status Message: %q and Reason: %q", pStatus.Status.Message, pStatus.Status.Reason) }) </ins> }) func checkPodListQuantity(f *framework.Framework, label string, quantity int) func() (bool, error) {

[X] test approval issue : [X] test pr : 28/07/2022 [X] two weeks soak end date : 12/07/2022 [X] test promotion pr : The endpoint as seen on the website is tested but not part of conformance. The APIsnoop query below shows that there is no conformance test for this endpoint. patchCoreV1NamespacedPodStatus Using a number of existing e2e test practices a new has been created for this pod status endpoint. The e2e logs for this test are listed below. This query shows the pod status endpoints hit within a short period of running the e2e test. If a test with these calls gets merged, test coverage will go up by 1 point. This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance /sig node
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale targeting this for 1.25
/reopen
Reopened this issue. <detailsIn response to : /reopen 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


Question: }, }, { <del> name: "Reverse default plugins order with changing score weight", </del> <ins> name: "reverse default plugins order with changing score weight", </ins> plugins: config.Plugins{ QueueSort: &config.PluginSet{ Enabled: []config.Plugin{

has compatibility tests for Policy v1. We are lacking similar tests for other options of , such as: [x] : This can be right away to test that default plugins can be disabled, changed order, etc. [x] : This one is trickier, as it requires a new method in to expose all configurations and a new method in so that they can say which args they used. /sig scheduling /help /kind cleanup
/assign
you can work on the first one. I'll have a PR soon that should clarify how the second one should be done.
I have sent a pr for the first one. And I'm working on the second one, I think it's better to keep 2 PRs for this issue? If so, PTAL at the first one, thanks.
Yes, 2 PRs is ideal. I'll review later today.
I have one small question about do I need to mock some fake plugins for testing , or just testing the default plugins?
You should use the existing plugins, because these are compatibility tests.
Okay
Actually, I think adding a new method such as to interface is a little redundant. In fact, most plugins don't need any argument for building them, so we are talking about adding a new method that needs to be implemented by all of the existing and coming plugins. And users who write out-of-tree plugins also hardly have the need for using this method. IMO, it would be more meaningful to move up to the interface. Then by this method, we can simply implement for default plugins who actually need args. WDYT?
should remain unexported because it provides pointers. However, I agree that might be too much to ask for all plugins. Instead, we can add a new interface and then plugins can opt-int. Not sure if we should follow this extension pattern Any thoughts
On the other hand, simply returning doesn't seem like much.
Sure, then I will add like what we want before(add this method to interface), and if there is any better idea later, please let me know.
I think we should just add it to the plugins that actually have args, this will require custom code in the test, but I think it is better than having all plugins implement a function means something to only 1% of them.
Thanks, but now there is a problem that we can't get the registered plugins with current API.

So, I'm not sure if we can just implement the method in with some reflect code for checking if one plugin has implement method? This could help us with keeping the interface clean. cc
you don't need to check if it implements BuildArgs, since this is for testing, we can hardcode which plugins should have their args verified.
The test will not be pretty, but I think it is worth the tradeoff.
Do you mean that we don't test the default plugins, but define some custom plugins in the test file? And we don't need the ListPluginArgs method anymore, am I right?
and I discussed this offline and arrived to this conclusion: For the compatiblity test, we can mock ( in ) to capture the arguments the configuration that is being passed. This can also be used by with We want another test for that checks the build args for the in-tree plugins accessing the internal pointers. These 2 tests should cover the whole stack. Sorry for the back-and-forth. Sometimes it's useful to see a full PR to realize that the initial idea wasn't good enough. Thanks a lot for it.
Sure, that sounds much more clear, thanks. :D
One more question, the is under package , and the compatibility test is under package . So for mocking , we need to change to a function variable in , and add a method for it, right It will look like: Maybe we can add something like to , but that's the implementation details. I want to make sure if the above design is proper.
Or rather, you could add something like: . Then you can call the capturer from if there is one defined.
Got your message in slack, let me reply here. sounds good, and do I need to revert the change in ? I think is not necessary now.
I think they will still be useful for the other test:
Hello are you still working on this?
Ah, I'm so sorry that I'm so busy in the last few weeks, but I will send prs fot this issue in this weekend. Sorry for my delay again.


Question: Image: container.Image, State: defaultWaitingState, } <del> // Apply some values from the old statuses as the default values. if oldStatus, found := oldStatuses[container.Name]; found { status.RestartCount = oldStatus.RestartCount status.LastTerminationState = oldStatus.LastTerminationState </del> <ins> oldStatus, found := oldStatuses[container.Name] if found { if isInitContainer && oldStatus.State.Terminated != nil { // Do not update status on terminated init containers as // they be removed at any time. status = &oldStatus } else { // Apply some values from the old statuses as the default values. status.RestartCount = oldStatus.RestartCount status.LastTerminationState = oldStatus.LastTerminationState } </ins> } statuses[container.Name] = status }

Hit an issue with the pet set states switching from running state to init state. Initially I thought the pods aren't running but later figured out that the containers are actually running but the container state is not consistent with the pod state in kubernetes api.
This sounds like a bug introduced by init containers. Thanks for such detail issue reports and will try to reproduce it. cc/
Just saw a flake test , which might have the same cause as this issue.
I couldn't reproduce the issue at all. Also the flake reported at is never re-occur. I will leave this issue open for a while.
I believe we're hitting this issue too - running a zookeeper petset with init containers, the pod starts up, init containers run, main container runs. Then a short time later the pod status goes back to Init 0/1, but the main container is still running If I can reproduce it reliably what debug output would be helpful?
you are hitting this with 1.4 release? how many kubelet nodes?
If you can reproduce the issue, could you please provide the following information: 1) docker info 2) zookeeper petset podspec 3) kubectl describe pod <pod-id4) related kubelet logs Thanks
This needs to be triaged as a release-blocker or not for 1.5
Not a blocker because we have had no recreations.
Hi, I've hit a similar issue here, running Kubernetes on CoreOS, except it doesn't even create all the pods, just the first one. If there's anything else you need, please let me know. CoreOS Version Kubernetes Cluster Version kubectl get pods state kubectl describe pod Container State kubectl describe service kubectl describe petset kubectl get nodes kubectl describe node docker info PV Spec pv mount state inside container
Hi, Nevermind, I got the zookeeper example working. It was a problem with a miss configuration on kube-controller.

I have this issue also with the new StatefulSets on 1.5.1 This is a pod and the StatefulSet:
This line: Get https://10.10.4.50:6443/api/v1/namespaces/default/secrets/default-token-jd4sr: dial tcp 10.10.4.50:6443: getsockopt: connection refused  Usually implies you have an error in your cluster configuration or some sort of transient problem. It is unlikely to be related to StatefulSets themselves, but a more general pod problem.
We have also seen this problem with pods. in 1.3.9. The pod has a init container. It looks like the init container actually completes successfully and later on the container starts and runs correctly ( with the output of the init container). However the pod state is stuck at pending. I will follow up with more information and try to isolate the problem in a way that I can share in this thread.
From what I see, these issues are related to configuration of the StatefulSet and init containers for particular workloads, rather than being issues with the features themselves.
We have run into what appears to be a similar issue. Pod phase is "Pending", but the container is running and ready. Aside from and VerifyControllerAttachedVolume logs, the only ones I see for this pod are
As an update to my previous comment, the pods start up in the expected state, so they will be in the "Running" phase and "ready=true". However, when the pod is restarted (for example when the coreOS cluster kubernetes is running on updates itself), the pods start up in the bad state with the "Pending" phase, but the container is running and ready.
I have encountered this problem too,hope someone can solve.
The initial issue was filed against init container feature. It looks like initial container is finished, all user containers are running properly, but the initContainer itself stuck at waiting state which cause the entire pod stuck at pending phase. But we never reproduce the issue, and e2e test only reported once with the similar failures since the day the issue was reported. The following issues reported by the users are normally caused by misconfigured cluster or bad initContainer itself. I am unassign this from myself, and re-tagged it for sig/apps since I don't think the issue is initContainer feature itself.

what do you mean "when the coreOS cluster kubernetes is running on updates itself"? Do you mean in-place upgrade Kubelet and docker binaries on the node? I noticed all following failure cases are reported on CoreOS. That might be the cause here.
it doesn't look like it is necessarily upgrading the Kubelet or docker binaries, but it looks like it happens whenever the kubernetes node running the service goes down and the service is rescheduled and started on another node.
Given the number of reports and all being on CoreOS, as said, it looks related to CoreOS. Can someone from CoreOS side try to reproduce this? who would be the right people for this?
I've also seen this issue, and we are not running CoreOS. We are running kubernetes 1.5.5
Box has also hit this issue on 1.3.9 and 1.4.7.
Expanding upon my above comment, we've seen this on a variety of resource types. It seems to affect StatefulSets as people have said above, but is also affecting our Deployment resources. It affects resources both with and without PVC. The one unifying pattern is they all have init containers.
Ditto, it's affecting our Deployments as well.
What's the status on this? It seems like a major bug, I'm not sure how it has gone on for so long. When impacted by this bug, scaling, restarting, etc of pods with higher ordinals do not work on StatefulSet. That is, if you have 3 pods for your StatefulSet, and they go into state and you lose mypod-2, kubernetes will never replace it until you manually kill/restart mypod-0 and mypod-1 to remove the state.
/cc
Hi I think I have hit the same issue with init-containers though it is not related to a petset, coreos, or any application. We had our application up and running for several days and suddenly on one machine the pods went back to state from .

It seems the simplest way to reproduce this is as follows: a pod with an init-container application come up and pod transition to Running (at this point the init container exists as an docker container) I tried doing this with a pod that had multiple init containers and it seemed like on the last (4/4) container would trigger the condition. Before doing anything: Pod status: Removal state and post: Status post removal: I also started to see these error messages in the kubelet logs: docker version: kubernetes version: In our situtation the removal of the exited containers happened when a host was getting full on disk space an automated process was trying to reclaim space.
sorry to ping but I was able to reproduce this issue pretty reliably without coreos, and with a cluster that is not misconfigured - node has been up for 100+ days, application had been running for several days without issue, I think removing the Exited init-containers might be the issue, and I'm uncertain if that is a known aspect of the design.
Nice catch! I just confirmed that our affected Stateful Sets are in the state you described (init-container Docker containers deleted). After digging further, I realized was experiencing this because our kube nodes have a cron job that deletes old terminated containers that are 2+ days old (the timing lines up perfectly). I can disable / alter our cron job, but it makes me wonder if kubelet's container cleanup routines properly handle this case as well?
Should have clarified in that previous post I did the on two separate containers (Init container 1 and init container 4). I was able to get the Pod to go from -again by running a container with the expected name, i.e.
Here's what I've been using to fix up pods in our system, YMMV: First arg is the pod name (e.g. ) Second arg is the name of the init container in the pod that is supposed to be started, (e.g. ). Seems to have fixed up everything so far, hope that helps someone.
We are having the same problem in one of our clusters. Steps to reproduce: new Deployment with one initcontainer. for it to be in Running state (initcontainer completed successfully and main pod is up and running) init container manually using command. (When we first encountered this problem, the init container was deleted by kubernetes garbage collector).

pod will switch to Initializing state and will be in this state indefinitely. Docker container will be running. We are running kubernetes 1.6.3.
This issue happens regularly with almost any deployment I use that create pods with init containers. Further, it may be impacting etcd-operator, at the very least, since it sees the pod as being in an erroneous pending state and waits indefinitely, preventing normal operation. As stated previously, this pending state occurs some time after the pod was created and the init container has previously completed successfully and reported as such. In my experience this bug comes up even without any node or pod restarts, just while running for some period of time. Running k8s v1.6.4 (CoreOS, bootkube)
While a fix is being worked on, the above workarounds have worked for us for 1.5 months. Look into anything that might be deleting/garbagecollecting the containers after the init containers have executed. Disable that if possible, and you'll be unlikely to see this again.
So the bug seems to be that Kubernetes uses stopped container names/UUIDs to determine the status of a Pod with init containers. It should probably just keep the init container's state as Ready or Completed instead, to allow for garbage collection. This is not an intuitive bug to track down and this issue may be overlooked easily in searching for a workaround. Even if this issue is found, the workarounds can be lost in the weeds. With the absence of a pull request to fix the issue, could some documentation be put somewhere to help alleviate some frustration from users that experience this? I'd be happy to write it up, but where do I put it?
Is there an easy workaround like running a sidecar with the same name as the init container? I hate the idea of manually running a docker container with the right name as it won't get auto cleaned up by kube.
I tried adding a sidecar with the same name, but it unfortunately fails validation because the container name collides with the init container name.
I'm surprised this issue hasn't gotten any attention. This consistently causes confusion and pain for our users which are using kubectl. It affects both ReplicaSet and PetSet pods. There doesn't seem to be a realistic work around. Has anyone testing 1.7 to see if the situation has improved?

should we see if one of our folk has time to work on it?
Hi, I've got the exact same issue with a Deployment and a initContainer exiting correctly. Impact could be cosmetic for some (pods still running and functioning properly) or functional for the others :) (scripts / automations trusting the status state) Regards,
Any update on this issue? Is it possible to add some kind of filters for kubelet garbage collector to prevent containers matching the filter from being deleted by the collector?
Just did a cluster upgrade to v1.7.2 and this is still happening. I can confirm we have a number of pods with initcontainers created by a daemonset that ran their initcontainer command successfully and are running their container command but kubectl reports them in Init:0/1.
does the priority on this go up given that a number of us are running into issues with this in production?
i've run into this as well with the helm chart. the pods seem to be functioning correctly, but one functional side-effect is the inability to port-forward:
how to solve this issue so that the pod start


Question: "runtime" "testing" <ins> "github.com/prometheus/common/model" v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime/schema" clientset "k8s.io/client-go/kubernetes"

<!-- 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: While I was watching grafana for a single run, I noticed that GET requests are reported as LIST requests, e.g. grafana shows ~1K QPS for LIST of pods ! while kube-apiserver's logs show: (there are no pod lists that time). I'm not sure if this is intended change to metrics reporting (kind of unexpected to be honest), but this definitely affects way our scalability tests validate latency metrics: We do not validate GET API call latency at all Validation for LIST requests is also affected, as usually GET API calls are way cheaper than LIST requests, so grouping GET-LISTs and LIST-LISTs together lowers p99 for LISTs. Also perf-dash shows that GET requests simply disappeared at some point: http://perf- ! What you expected to happen: GET requests should be reported with verb=GET in apiserverrequest_total metric. 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:

FYI
I managed to narrow the issue by bisecting the runs of which runs load tests using master k/k every 1 hour. This is the last test run that had GETs reported correctly: This is the first test run that has no GETs reported: Looking at the k/k repo commits' hashes inside artifacts in both runs and at what happened between each of them it looks as if might be the culprit.
From the former run's artifacts: This is (among others) what we miss in the latter run - this is understandable from the point of view of this if condition: Why did the reported GETs have as the scope instead of in the first place, however??
It seems that our handing is incorrect: vs Or my understanding of it was incorrect.

It seems that the semantic is: cluster - for cluster-scope requests namespace - for namespace-scoped requests request - for subresources I think the assumption in the monitoring path was: cluster - for cluster-scope requests namespace - for namespace-scope requests requests - for requests touching a single resource (not necessary subresource) I'm not 100% sure which semantic we should use - based on the finding we should fix one or the other place...
cc There should probably be a unit test mapping URL paths to the expected label values.
is opened to fix that.
/triage accepted


Question: Conntracker            Conntracker // if nil, ignored ProxyMode              string NodeRef                *v1.ObjectReference <del> CleanupIPVS            bool </del> MetricsBindAddress     string BindAddressHardFail    bool EnableProfiling        bool

<!-- 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: kube-proxy don’t clean ipvs rules with . What you expected to happen: kube-proxy clean ipvs rules with by default. How to reproduce it (as minimally and precisely as possible): Run kube-proxy in ipvs mode, and clean rules with . Anything else we need to know?: Based on , should cleanup all rules by default, including ipvs rules. And also retains functionality. Environment: Kubernetes version (use ): v1.20.0-bate.0 Cloud provider or hardware configuration: OS (e.g: ): centos7 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig network
it seems that this flag entered deprecation, so I think that recovering functionaly is not the right approach you were involved in the discussion with this flag in , can you take a look at this?
thanks for your reply. The was in , to avoid removing IPVS rules which are not created by kube-proxy. According to , It seems that deleting ipvs rules by default is expected, but it is not so. I think that keeping --cleanup-ipvs is meaningful, unless kube-proxy can only delete the IPVS rules created by itself.
/assign
sorr for the late answer , but the flag must have the same functionality than , actually I can see that it has implemented. In case that the is not working we should fix it, but not recover the deprecated flag
Agree
sorry if I'm missing something. I just try to make the function of as described, not to recover the flag. The problem I see is: The can't flush IPVS. Because the IPVS flush process is still controlled by . Beforce , it was assigned by flag, but now it is not assigned, always false. currently does not have any functionality, just stored by . So, should we keep the function of temporarily by assigning it to ,or just make always flushing IPVS regardless of the ?

I prefer the former because the flag is not completely abandoned :)
it seems that is what the flag description says, you have to use to flush the ipvs entries if that is the case it seems that we are ok, right? no changes needed
In fact, can't flush ipvs entries. The reason is what I described above.
I´m sorry, I think I got it know, the flag is not exposed, but the option is there and initialized to true, this is what I see so, it seems that flush IPVS by default
yes, should flush IPVS by default, but it doesn’t actually
... and finally I got it, so sorry :bow: the ProxyServer is not being instantiated with the flag, despite is set :facepalm: you are more familiar with the IPVS implementation than me, I personally think that, if the flag deprecation has started, we should make that always flush IPVS and totally remove ... it seems aligned with the other proxy implementations
/triage accepted
Actually, after doing some code archaeology, this was the expectation per And the flag clearly mentions that --cleanup must flush IPVS entries too I think that we can go ahead and remove the --cleanup-ipvs flag and make --cleanup to flush ipvs too, right now is a mess and is not working at all , are you going to submit a PR?
thanks for digging up the history on this. That lines up with my recollection and the KEP around kube-proxy's clean up logic
OK, I will create a PR to remove the flag


Question: } func (f *flexVolumeUnmounter) TearDownAt(dir string) error { pathExists, pathErr := mount.PathExists(dir) <del> if !pathExists { klog.Warningf("Warning: Unmount skipped because path does not exist: %v", dir) return nil } if pathErr != nil && !mount.IsCorruptedMnt(pathErr) { return fmt.Errorf("Error checking path: %v", pathErr) </del> <ins> if pathErr != nil { // only log warning here since plugins should anyways have to deal with errors klog.Warningf("Error checking path: %v", pathErr) } else { if !pathExists { klog.Warningf("Warning: Unmount skipped because path does not exist: %v", dir) return nil } </ins> } call := f.plugin.NewDriverCall(unmountCmd)

<!-- 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: pod could not be terminated when pod volume path is corrupted, and it looks like it mainly affect flexvolume, not sure What you expected to happen: How to reproduce it (as minimally and precisely as possible): a pod with smb mount (we use flexvol in this case, driver is ) smb server password the pod could not be terminated forever Anything else we need to know?: Environment: Kubernetes version (use ): master Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: /sig storage /assign cc
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. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Workaround on agent node, run “mount | grep cifs” to get all cifs mounts check every cifs mount, failed (in above example), run: And then the pod will be in terminated soon.


Question: //     apiVersion: kubeadm.k8s.io/v1beta2 //     kind: ClusterConfiguration // <del> //     apiVersion: kubelet.config.k8s.io/v1beta2 </del> <ins> //     apiVersion: kubelet.config.k8s.io/v1beta1 </ins> //     kind: KubeletConfiguration // //     apiVersion: kubeproxy.config.k8s.io/v1alpha1

<!-- 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: references and a broken link to this (because it doesn't exist!) I'm guessing this was a bad find and replace when copying kubeadm's own v1beta1 to v1beta2 What you expected to happen: accurate documentation How to reproduce it (as minimally and precisely as possible): read the docs Anything else we need to know?: this template has a lot of fields :^) Environment: anything Kubernetes version (use ): n/a Cloud provider or hardware configuration: n/a OS (e.g: ): n/a Kernel (e.g. ): n/a Install tools: kubeadm Network plugin and version (if this is a network-related bug): n/a Others: n/a /assign /sig cluster-lifecycle