Question: }{ { expected: api.VolumeMount{ <del> Name:      "pki", </del> <ins> Name:      "k8s", </ins> MountPath: "/etc/kubernetes/", ReadOnly:  true, },

<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--What keywords did you search in Kubernetes issues before filing this one? controller /etc/ssl/certs kubeadm /etc/ssl/certs 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 ): 5 custom built master I also use a custom built hyperkube image instead of the single app images for apiserver, controller, ... Environment: Cloud provider or hardware configuration: azure OS (e.g. from /etc/os-release): CentOS 7.2 Kernel (e.g. ): Linux ma-kub8ms0 3.10.0-327.36.3.el7.x8664 SMP Mon Oct 24 16:09:20 UTC 2016 x8664 x8664 x8664 GNU/Linux Install tools: kubeadm Others: deployed with Azure RM template and ansible What happened: controller is not able to do https, including calls to the Azure RM API What you expected to happen: https should work as usual How to reproduce it (as minimally and precisely as possible): Use kubeadm to install kubernetes on CentOS exec into the controller and try "curl " Anything else do we need to know: It looks like caused this issue. On CentOS, I see these files on the host OS: I suspect the symlinks to /etc/pki/... being the problem here, as they are not available inside the hyperkube Debian image. I also tried to verify this with It seems to not be based on Debian and thus gives a different error: I see 2 possible solutions: of host mounting /etc/ssl/certs into the controller pod, the ca certificates could be installed into the image.


Question: }{ { expected: api.VolumeMount{ <del> Name:      "pki", </del> <ins> Name:      "k8s", </ins> MountPath: "/etc/kubernetes/", ReadOnly:  true, },

This is already done for hyperkube and would work out of the box when the host mount would be omitted. could try to figure out if /etc/pki should also be host mounted and add this to the controller manifest if required. I'd be happy to provide a fix by myself, I just need to know which solution you would prefer.
Same problem seems to apply to the apiserver. Not sure however if it actually does https calls.
implements solution 2.
This issue was moved to kubernetes/kubeadm


Question: fifo := cache.NewDeltaFIFO(cache.MetaNamespaceKeyFunc, nil, downstream) // Let's do threadsafe output to get predictable test results. <del> outputSetLock := sync.Mutex{} outputSet := util.StringSet{} </del> <ins> deletionCounter := make(chan string, 1000) </ins> cfg := &framework.Config{ Queue:            fifo,

From shippable, I noticed there are several failed cases, for example, E0413 17:34:38. ] watch of *api.Pod ended with: Stop requested --- FAIL: Example (0.61s) got: want: a-hello b-controller c-framework FAIL coverage: 85.9% of statements FAIL 7.652s cc/
another example:
ah-- this is a different thing. I will fix this, too.
I'm seeing this from an unrelated change
Yeah I think that's the one I expected to see.


Question: } output, err := json.Marshal(agg) require.NoError(t, err) <del> // Content-type is "aggregated" discovery format. w.Header().Set("Content-Type", AcceptV2Beta1) </del> <ins> // Content-type is "aggregated" discovery format. Add extra parameter // to ensure we are resilient to these extra parameters. w.Header().Set("Content-Type", AcceptV2Beta1+"; charset=utf-8") </ins> w.WriteHeader(http.StatusOK) w.Write(output) }))

We are using (and ) to interact with Kubernetes clusters behind a couple of proxy layers. One of these proxies completes the headers to include character encoding details. This was working fine until recently, when client-go/kubectl have started to fail when interacting with the discovery API. It seems that a recent change has made kubectl more restrictive of the content-type that it expects. I suspect that it is related to this commit: For example, this is an error from a kubectl command: We can of course try to fix it on our end, removing that charset information. However, it is a valid content-type and the way kubectl is handling the content-type there seems like it is relying on implementation details of kube-apiserver (that it does not add metadata to the content-type). I propose to fix this issue in , by properly parsing and handling the content-type.
cc /kind regression /kind bug /sig api-machinery /priority important-soon looks like the switch statement in downloadLegacy() needs to be more tolerant of the variety of content-types it can get from a server (including text/plain or no content-type if old servers could have returned that...)
/transfer kubernetes/kubernetes
Something went wrong or the destination repo kubernetes/kubernetes/kubernetes does not exist. <detailsIn response to : /transfer kubernetes/kubernetes 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
/transfer kubernetes
Yep, the string comparison for the content-type is flimsy, let's address that. Thanks for the report!
/assign
/triage accepted
/cc
The fix is being cherry-picked back to: : :


Question: If you have questions or want to start contributing please reach out.  We don't bite! <del> The Kubernetes team is hanging out on IRC on the [#google-containers channel on freenode.net](http://webchat.freenode.net/?channels=google-containers).  We also have the [google-containers Google Groups mailing list](https://groups.google.com/forum/#!forum/google-containers) for questions and discussion as well as the [kubernetes-announce mailing list](https://groups.google.com/forum/#!forum/kubernetes-announce) for important announcements (low-traffic, no chatter). </del> <ins> The Kubernetes team is hanging out on IRC on the [#google-containers channel on freenode.net](http://webchat.freenode.net/?channels=google-containers). This client may be overloaded from time to time. If this happens you can use any [IRC client out there](http://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_clients) to talk to us. We also have the [google-containers Google Groups mailing list](https://groups.google.com/forum/#!forum/google-containers) for questions and discussion as well as the [kubernetes-announce mailing list](https://groups.google.com/forum/#!forum/kubernetes-announce) for important announcements (low-traffic, no chatter). </ins> If you are a company and are looking for a more formal engagement with Google around Kubernetes and containers at Google as a whole, please fill out [this form](https://docs.google.com/a/google.com/forms/d/1_RfwC8LZU4CKe4vKq32x5xpEJI5QZ-j0ShGmZVv9cm4/viewform) and we'll be in touch.

POD is OOM. k8s v1.19.4+docker is OK. but v1.21+cri-o+buildah does not work properly. Why the limits are not effective.Not the container limit memory, It's physical memory centos7 kernel use limits memory use -XX:+UseContainerSupport Cannot read memory.limitinbytes k8s version cri-o version buildah version oracleJdk or openjdk have same problem It is normal to use xms and Xmx
/sig node
Supplement v19+docker v21+cri-o+buildah
/assign taking a look, thanks for opening the issue
seems relevant, have you checked your kernel supports the memory cgroup (I know docker does work, but let's sanity check first) I checked on my machine (fedora 34) and successfully can see usageinbytes in a container on our latest 1.22 branch. also, attaching the crio logs will likely help me debug
also curious about the runc version
cri-o logs runc Looks like a problem with cgroup v1
hm the memory cgroup seems to be enabled. what is the image you're using?
centos7.9.2009
/triage needs-information
what cgroup manager are you using?
kubeadm kubectl config crio ps aux|grep kubelet
I seem to have found this bug Delete the following two items to return to normal. deployment
that is unexpected... Great find!
Does the problem manifest if either are different? (hostNetwork: false, but dnsPolicy ClusterFirstWithHostNet)
hostNetwork: true hostNetwork: false delete hostNetwork and dnsPolicy
Rocky 8.4, kernel-5.4, kubernetes v1.21.4 has the same problem
ah! I found the issue
thanks for your patience
Is crio 1.21.3 fixed? This problem still occurs after the upgrade. Branch v1.21.3 did not see the commit
no the initial PR hasn't merged yet, I will try to revive it
sorry this fell through the cracks, I'll try to get this through ASAP
will get it in 1.22.1. is that sufficient or would you like it backported to 1.21?


Question: If you have questions or want to start contributing please reach out.  We don't bite! <del> The Kubernetes team is hanging out on IRC on the [#google-containers channel on freenode.net](http://webchat.freenode.net/?channels=google-containers).  We also have the [google-containers Google Groups mailing list](https://groups.google.com/forum/#!forum/google-containers) for questions and discussion as well as the [kubernetes-announce mailing list](https://groups.google.com/forum/#!forum/kubernetes-announce) for important announcements (low-traffic, no chatter). </del> <ins> The Kubernetes team is hanging out on IRC on the [#google-containers channel on freenode.net](http://webchat.freenode.net/?channels=google-containers). This client may be overloaded from time to time. If this happens you can use any [IRC client out there](http://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_clients) to talk to us. We also have the [google-containers Google Groups mailing list](https://groups.google.com/forum/#!forum/google-containers) for questions and discussion as well as the [kubernetes-announce mailing list](https://groups.google.com/forum/#!forum/kubernetes-announce) for important announcements (low-traffic, no chatter). </ins> If you are a company and are looking for a more formal engagement with Google around Kubernetes and containers at Google as a whole, please fill out [this form](https://docs.google.com/a/google.com/forms/d/1_RfwC8LZU4CKe4vKq32x5xpEJI5QZ-j0ShGmZVv9cm4/viewform) and we'll be in touch.

Thank you Both are OK, I currently use java -xmx instead.I will update in the next version. Preferably v1.21, v1.22 version I will upgrade later.
I've opened as well :)
/remove-triage needs-information /triage accepted /close as this is being tracked as a CRI-O bug
Closing this issue. <detailsIn response to : /remove-triage needs-information /triage accepted 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: var notMnt bool var err error if extensiveMountPointCheck { <del> notMnt, err = IsNotMountPoint(mounter, mountPath) </del> <ins> notMnt, err = mounter.IsNotMountPoint(mountPath) </ins> } else { notMnt, err = mounter.IsLikelyNotMountPoint(mountPath) }

<!-- 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!--What happened: There's , and . The former is used by local and nfs volume plugins, while the latter is used by , which is also used by local and nfs volume plugins. What you expected to happen: Can we consolidate these? This is really confusing and could easily be the source of bugs. <!-- DO NOT EDIT BELOW THIS LINE --/kind cleanup
cc
/assign I'd like to clean up code.


Question: import ( "fmt" "os" <ins> "sort" </ins> "strings" "github.com/spf13/cobra"

Similar to issue , building kubernetes1.23 resulted in 1 variation: builds should be fully determined by inputs on openSUSE or Debian, This bug was found while working on . <details23.0 </details<details</details<details</details<details</details<details</details<details</details
/sig release /area build-release
/assign
/sig cli
/triage accepted /assign


Question: if err != nil { framework.Logf("Failed to delete adapter deployment file: %s", err) } <del> cleanupClusterAdminBinding(namespace) </del> <ins> cleanupClusterAdminBinding() </ins> } <del> func cleanupClusterAdminBinding(namespace string) { stat, err := framework.RunKubectl(namespace, "delete", "clusterrolebinding", ClusterAdminBinding) </del> <ins> func cleanupClusterAdminBinding() { stat, err := framework.RunKubectl("", "delete", "clusterrolebinding", ClusterAdminBinding) </ins> framework.Logf(stat) if err != nil { framework.Logf("Failed to delete cluster admin binding: %s", err)

/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig autoscaling Looks like it just started happening today (@ 2020-09-15 03:54:19 +0000 UTC) !
cc the namespace from the provided object "kube-system" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=kube-system' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation.
related fix:
No I don't think that's the fix for this (that is just a little cleanup). Actually I think we have to delete namespace parameter in line : Because before , the will have no actually effect. But now with the change of , it will have namespace : at the end of the command. But the namespace in yaml file is which is different from . We should not have parameter when applying from file because this test didn't have before, right? Related PR:
/assign


Question: }, }, SchemaProps: spec.SchemaProps{ <del> Description: "List of ports to expose from the container. Exposing a port here gives the system additional information about the network connections a container uses, but is primarily informational. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. Cannot be updated.", </del> <ins> Description: "List of ports to expose from the container. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. Modifying this array with strategic merge patch may corrupt the data. For more information See https://github.com/kubernetes/kubernetes/issues/108255. Cannot be updated.", </ins> Type:        []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{

The comments in says that : However there are several cases where this is false : When using a Service with a targetPort that references a name in the ports arrays of the pod. Some software (ab)uses this API to get which ports are used (See Although unfixable, my goal is to fix the documentation so other people don't have the same problem). The Azure Load Balancer implementation does this for instance. Some other network/security software might use this information. Also, is it possible to document/reference the above issue in the comment ? Since it is described as informational I expected for the network to work without this information. But it's definitely not the case. Not needed since it's mostly a doc issue. I'm interested in contributing this patch but would like some feedbacks before doing it. :) <details</details<details</details<details</details<details</details<details</details<details</details
/sig network
/triage accepted -- thoughts? I believe the doc are due for a refresh.
I'd take this one. /assign
I didn't see that you wanted to do this patch, I am very sorry and now I unassign it. /unassign
No worries But I'm still not sure where / what to add. Should I only fix the part saying it is only informational ? Is there anything else ? (cc
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


Question: network_mode: openvswitch networkInterfaceName: eth1 etcd_servers: $MASTER_IP <ins> api_servers: $MASTER_IP </ins> cloud: vagrant cloud_provider: vagrant roles:

is sent as a fix. cc It's a test failure reported by the publishing robot.
The line it fails at:
It looks like a vendor copy vs gopath copy issue.
One possible fix is removing from the vendor/ directory. I'm testing locally.
Confirmed removing from the vendor/ directory fixed the test in robot.
We need to add the "issue filer" feature to the publishing robot, we can't rely on to report robot issues everytime :P I'm just not sure how long the publishing robot will be needed (i.e., when we will get rid of the staging/ directory) so not sure whether we should invest more time on the robot.