primordic/IssueDupesLite huggingface dataset:
Repository: kubernetes-sigs/descheduler

Issue #211: Prefered scheduling
Created: 2020-01-03T19:02:50Z
It will be nice if we can have soft  check like "preferredDuringSchedulingIgnoredDuringExecution"
to calculate if there is a node with better weight  than the node where the pod is running to evict the pod and therefore be scheduled in the better node.
For Example because network routes I prefer my deployment PODS run on ZoneA but if not possible because Nodes there are offline then I aceept to be deployed on ZoneB, but if ZoneA is reachable again I want to reschedule back to zoneA.

Duplicate issue #250: RemovePodsViolatingInterPodAntiAffinity ignores preferredDuringSchedulingIgnoredDuringExecution
Created: 2020-03-10T11:23:28Z
The strategy silently assumes requiredDuringSchedulingIgnoredDuringExecution is used
https://github.com/kubernetes-sigs/descheduler/blob/master/pkg/descheduler/strategies/pod_antiaffinity.go#L99-L101
but preferredDuringSchedulingIgnoredDuringExecution may be used as well.  It is useful if descheduler can evict pods scheduled in a zone (when topologyKey: failure-domain.beta.kubernetes.io/zone is used) or a host (when topologyKey: kubernetes.io/hostname is used) where another pod of same type had been already running.  This may happen if there are no enough resources in the cluster at the time of scheduling.  Later, when more nodes are added by cluster-autoscaler or temporary-failed nodes come back, it is desirable to evict the pods violating inter-pod anti-affinity so that the pods evenly spread across zones/hosts.
Similarly to RemovePodsViolatingNodeAffinity, this behavior should be controlled by an additional parameter.  The resource syntax will be like below:
apiVersion: descheduler/v1alpha1
kind: DeschedulerPolicy
strategies:
  RemovePodsViolatingInterPodAntiAffinity:
    enabled: true
    params:
      nodeAffinityType:
      - preferredDuringSchedulingIgnoredDuringExecution

Closing comment (2020-04-01T19:53:32Z): I think this should be reopened as it is not exactly similar to #211 in which the requirement is to calculate a better scheduling score for the pod from the pool of nodes.
A different use case is presented here which is very valid, is the option to "redistribute" the pods with preferredDuringSchedulingIgnoredDuringExecution across the available AZs to ensure High Availability at all times while preserving pod scale-out operations to have more pods than the number of AZs for the cluster (this is because requiredDuringSchedulingIgnoredDuringExecution will allow a maximum number of pods as the number of AZs the cluster sees).
I feel like this is truly an important piece in Kubernetes as we will not have to choose between High Availability and Scalability.
@damemi Can we please reopen this?
Repository: kubernetes-sigs/descheduler

Issue #984: Does deschedule support argo rollout?
Created: 2022-10-14T09:14:04Z
Does not take effect if the resource type is argo rollout.

Duplicate issue #985: Does deschedule support argo rollout?
Created: 2022-10-14T09:14:06Z
Does not take effect if the resource type is argo rollout.

Closing comment (2022-10-14T12:26:41Z): @damemi: Closing this issue.

In response to this:

dupe of #984 ?
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Repository: kubernetes-sigs/descheduler

Issue #263: RemoveDuplicates should average out based on node count
Created: 2020-04-14T16:31:10Z
When using RemoveDuplicates, if I have 5 nodes and a ReplicaSet of 10, 2 pods should be on each. descheduler instead continuously evicts half of them even though it will end up with the same distribution.

Duplicate issue #252: Descheduler goes into a loop with Remove duplicates strategy
Created: 2020-03-13T13:07:49Z
I try to create a pod using an rc with replicas as 12 and i run descheduler.  I don't think there's anything in the duplicate pods strategy that considers the replica request vs number of available nodes and this causes a deschedling loop. descheduler tries to evict the pods every time the descheduler is run.

Closing comment (2020-07-01T03:13:51Z): @seanmalloy: Closing this issue.

In response to this:

This is a duplicate of #263.
/triage duplicate
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Repository: kubernetes-sigs/descheduler

Issue #225: Use actual node resource utilization in the strategy "LowNodeUtilization"
Created: 2020-02-03T02:42:03Z
Currently, pods' request resource requirements are considered for computing node resource utilization in the strategy "LowNodeUtilization", is it more rational to use actual node resource utilization as judgement?
It is common that resource limit of pod is larger than request, and after the scheduling of default scheduler (by resource request), It's probably that cluster is balanced. But the actual resources usage of pod could be much larger than request, which may lead some nodes under pressure.
So is it much more reasonable to combine with metrics server and use actual node resource utilization.

Duplicate issue #631: Can we provide a feature that balances the load from the node MEM dimension?
Created: 2021-09-18T09:11:45Z
Is your feature request related to a problem? Please describe.
I saw that descheduler calculates the Mem usage of Pod to get the actual usage MEM on each machine, but this will ignore the memory usage of some programs running directly on the host
Describe the solution you'd like
so , can we provide a feature that balances the load from the node MEM dimension?

Closing comment (2021-09-21T10:42:24Z): yes, this issue  is the same as  #225 , thanks
Repository: kubernetes-sigs/gateway-api

Issue #20: Add Initial Conformance Test Framework
Created: 2020-01-08T22:16:25Z
We want to ensure that controllers using these APIs are conformant. Having a good conformance test suite will help establish consistency across community implementations and help developers identify any missing pieces in their implementation. This should work similarly to the existing Kubernetes conformance tests and be accessible with the same workflows.

Duplicate issue #520: Add API Tests
Created: 2021-01-06T19:41:08Z
What would you like to be added:
API tests.
Why is this needed:
The current tests only ensure the CRDs and examples can be installed to a cluster. Tests are needed that compare the current and expected values of API types. For example, many API fields are being defaulted but no tests exist to ensure the defaults are being properly set.
/cc @robscott @hbagdi
xref: #517

Closing comment (2021-07-26T21:30:01Z): Duplicate of #20
Repository: kubernetes-sigs/gateway-api

Issue #2862: (Consider) adoption of `selectableFields`
Created: 2024-03-11T15:22:31Z
kubernetes/kubernetes#122717
I would imagine at least Gateway.spec.gatewayClassName and GatewayClass.spec.controllerName could be handy.
For routes probably nothing; parentRef is nice in theory but a controller needs to cleanup if its removed from parentRefs, and parentRef is a struct which makes it infeasible I suspect.
This is alpha in 1.30 so probably this is a very long term change

Duplicate issue #3519: Add `spec.gatewayClassName` selectable field to Gateway
Created: 2024-12-20T14:53:23Z
What would you like to be added:
Kubernetes 1.31 has promoted CRD selectable field to beta and enabled it by default. 1.32 has promoted it to GA.

Official docs: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resource-field-selectors
KEP kubernetes/enhancements#4359

This proposal is about adding a selectable field (1 or more if the community finds that there's appetite for more) to Gateway, specifically: spec.gatewayClassName.
This proposal can be followed up by separate issues for other types / fields if deemed worthy of doing.
Why this is needed:
This will allow listing Gateways that match a particular GatewayClass more efficient (useful when used with controller-runtime's EnqueueRequestsFromMapFunc
	var gateways gatewayv1.GatewayList
	if err := r.Client.List(ctx, &gateways); err != nil {
		// handle
		return
	}
        var recs []reconcile.Request
	for _, gateway := range gateways.Items {
		if gateway.Spec.GatewayClassName == gatewayv1.ObjectName(gatewayClass.Name) {
			recs = append(recs, reconcile.Request{
				NamespacedName: types.NamespacedName{
					Namespace: gateway.Namespace,
					Name:      gateway.Name,
				},
			})
		}
	}

Becomes:
	var gateways gatewayv1.GatewayList
	if err := r.Client.List(ctx, gateways,
		client.MatchingFieldsSelector{
			Selector: fields.OneTermEqualSelector("spec.gatewayClassName",gatewayClass.Name),
		},
	); err != nil {
		// handle
		return
	}

        recs := ([]reconcile.Request, 0, len(gateways.Items))
	for _, gateway := range gateways.Items {
		recs = append(recs, reconcile.Request{
			NamespacedName: types.NamespacedName{
				Namespace: gateway.Namespace,
				Name:      gateway.Name,
			},
		})
	}

Closing comment (2024-12-20T15:21:24Z): Also tracked in #2862
Repository: kubernetes-sigs/gateway-api

Issue #1802: Add a priority to a backendRef
Created: 2023-03-10T00:34:41Z
What would you like to be added:
Add a field within backendRef allowing the user to specify the priority of a backend. The algo for traffic distribution could be the following

Pick all the healthy backendRefs with the highest priority level
Distribute traffic across them based on the weight ratio
If no healthy backendRef exists for the highest priority, perform above steps for the next priority

Why this is needed:

Cross cluster failover (prioritize service within the cluster before routing outside)
As a user I would like to specify a default / fallback / back up backend in case my main backend is no longer active
also relates to https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#default-backend

Duplicate issue #1818: Support fallback in HTTPRoute
Created: 2023-03-15T09:31:41Z
What would you like to be added:
In springcloud, Feign provides fallback feature, when a calling to a service fails, then it can fall back to call another service.
It is common when the service is serving user's request, directly returning real failure reason sometimes is unacceptable. In this case, if the system can fall back to another service, which can handle kinds of such failure, it is very good for developers to handle it in every services
Why this is needed:

Closing comment (2023-03-15T15:11:19Z): Closing as a duplicate of #1802, thanks @hzxuzhonghu 🖖
Repository: kubernetes-sigs/gateway-api

Issue #333: Add examples to documentation
Created: 2020-09-17T01:00:26Z
At a minimum, these examples should cover:

 a simple GatewayClass, Gateway, HTTPRoute*
 a Gateway that targets routes in multiple namespaces*
 an example of TLS configuration
 working with other route types like TCPRoute or TLSRoute

We should try to embed existing examples from the repo instead of creating new ones.
* = must haves for v1alpha1 release

Duplicate issue #332: Add a User Guide to documentation
Created: 2020-09-17T00:55:32Z
This should include a walkthrough of how to use this API that is generic enough to work with all implementations.

Closing comment (2020-11-10T15:41:32Z): @robscott Can we close this as duplicate of #333?
Is there any difference between these two issues?
Repository: kubernetes-sigs/kui

Issue #1470: Environment variables should be inherited afresh each time I do `kui shell`
Created: 2019-05-23T20:39:34Z
I type kui shell for the first time on my terminal, and kui starts and inherits all the environment variables defined at that point in time
I close the kui window, go back to the terminal and create a new environment variable by export FOO=BAR
I reopen the kui window by typing kui shell. This time, it does not inherit the variable FOO
If go to my dock, and quit kui, and then retype kui shell in the terminal, it picks up the environment variable FOO

Desired feature: It would good not to have to quit kui in 4. above. When I type kui shell, the kui window that comes up needs to pickup the environment variables at that point in time

Duplicate issue #1734: Multiple KUBECONFIGs ?
Created: 2019-06-16T11:52:11Z
Nice work :)
I found a confusing issue (on MacOS at least):
Running multiple kui shell from zsh sessions with different KUBECONFIGs seem to always keep the first KUBECONFIG. Even closing all windows in the Kui Electron application before relaunching kui shell will still keep the very first one.

Closing comment (2019-06-16T12:15:34Z): hello, thanks for the feedback! confirmed.
i believe this is related to #1470. i'll push this one up in priority.
thanks!
Repository: kubernetes-sigs/kui

Issue #2669: [GVT]run 'help' - some strings are translated but still display as English in UI
Created: 2019-09-06T08:56:51Z
Describe the bug
Some strings are translated but still display as English in KUI. This issue happens to all translated languages.
Steps to reproduce the behavior

Go to KUI GUI in macOS
Run the command 'help'
See below screen capture

Expected behavior
The strings in red  rectangles shoud display as translated languages.
Screenshots
The strings in red rectangles are translated, but still display as English.

System

Kui version: 4.0.0-dev.4281.20190904142907
Operating system: macOS Mojave v10.14.6

Duplicate issue #3675: <Translation Verification>some translated strings don't display in KUI Getting Start page
Created: 2020-02-24T23:22:52Z
Describe the bug
Some strings in KUI getting start page are translated, but they display as English when change the locale to non-English.
Steps to reproduce the behavior

Open KUI
run help
Please refer to the attached screen capture.
my mail is bingfang@cn.ibm.com

Expected behavior
The strings should display translated languages.
Screenshots
If applicable, add screenshots to help explain your problem.
Code snippets
If applicable, add code samples to help explain your problem.
System

Kui version:1.0.12
Operating system:Mac OS

Closing comment (2020-02-25T19:02:17Z): duplicate of #2669
Repository: kubernetes-sigs/kui

Issue #232: `kubectl kui` requires kubectl 1.12 or better
Created: 2019-01-18T20:12:14Z
Document that kubectl kui won't work with kubectl versions 1.11 and older.  Suggest kui kubectl as the alternative for people who need to use an older kubectl cli.

Duplicate issue #258: kubectl in readme 
Created: 2019-01-22T13:33:36Z
this readme for installing kui for development suggests using kubctl kui version to sniff test the install: https://github.com/IBM/kui/blob/master/docs/dev/README.md

it didn't work for me following the instructions
kubectl probably not required at this step

Closing comment (2019-01-22T15:05:32Z): related to #232
Repository: kubernetes-sigs/kui

Issue #7405: Kui appears to look for invalid filenames in Windows
Created: 2021-05-17T14:39:06Z
-Open Kui

Create simple notebook (k get ns)
File -> Save as new Notebook -> enter filename and save
Close Kui and Reopen
File -> Open -> Choose file -> Press "Open" button
No visible output in app, error visible in --enable-logging or ProcMon

(screenshots of errors in both attached)
From watching app behavior in ProcMon, it seems to be calling a file whose name is the concatted file path to that file as part of the name, so if I try to open
c:\users\username\desktop\kui\kuitest7.kui
it is looking for
c:\users\username\desktop\kui\usersusernamedesktopkuitest7.kui
System Info

Kui version: 10.2.1
Operating system:
OS Name:                   Microsoft Windows Server 2019 Standard
OS Version:                10.0.17763 N/A Build 17763
(seen in other Win 10 environments as well, but cannot replicate in MacOS current version)



FWIW, it could be something completely different that is keeping me from using Save\Open, but this is at least my best guess at what is causing the issue. Happy to provide additional information as needed.

Duplicate issue #7434: File->Save does not properly handle backslash paths
Created: 2021-05-21T20:30:04Z
On windows, saving a notebook via File -> Save doesn't save the snapshot in correct place, because we used quotes instead of encodeComponent in packages/core/src/main/save.ts saveAsNotebook()

Closing comment (2021-05-21T20:33:47Z): Related to #7405
Repository: kubernetes-sigs/kui

Issue #584: composer is flaky in webpack
Created: 2019-02-27T22:14:01Z
preview @demos/if.js fails because of a readFile for webpack bug with imports


 preview -c @demos/if.js fails for that bug, and a few other similar bugs


 app deployment doesn't work in webpack
Composer client (in openwhisk-composer libararay) is implemented to grab credentials from local wskprops, so in Webpack mode, we need to pass the api_host and api_key in options (in apache-composer/lib/controller/client) based on window.localStorage or process.env.__OW_API_KEY  or process.env.__OW_API_HOST


 clicking Deploy in compose foo.js fails because the composition persister uses tmp.file

Duplicate issue #577: composer @demos files not found in webpack
Created: 2019-02-27T15:27:44Z

Closing comment (2019-03-18T15:09:34Z): Related to #584
Repository: kubernetes-sigs/kui

Issue #572: switch the electron CLI to use pty's
Created: 2019-02-27T03:23:50Z
right now, the electron app uses the in-browser REPL implementation cli.ts. this is great for webpack clients; but, for a local electron client, we should probably be using a pseudo-tty over a platform shell (e.g. bash or zsh).
this change would give users a more or less unadulterated bash (or zsh) experience, including their favorite bash/zsh prompt; it would also solve issues such as #414 where stdin input is needed, including some input that might need to be no-echo (such as password input).
it may also pave the way to more complete ncurses support. though even a minimal PTY switchover would need to handle the basic cursor control characters (e.g. clear line)
currently starpit/pty is tracking this issue

Duplicate issue #556: leverage node-pty in bash-like
Created: 2019-02-26T16:45:18Z
right now, we interact with subprocesses via pipes. as a consequence, the output presented by kui may differ from that experienced from a standard terminal; e.g. if the command being executed modifies its behavior depending on whether stdout is a TTY or a pipe (brew is one such example).
https://www.npmjs.com/package/node-pty offers a solution to this

Closing comment (2019-02-27T12:24:29Z): Dup #572
Repository: kubernetes-sigs/kui

Issue #789: minor REPL spacing tweaks
Created: 2019-03-12T14:25:15Z
there is an odd vertical gap above error output:

Duplicate issue #788: minor spacing tweaks to repl
Created: 2019-03-12T14:24:20Z
there is an odd vertical gap after error text:

Closing comment (2019-03-12T18:50:54Z): duplicate of #789
Repository: kubernetes-sigs/kui

Issue #1420: kubectl cluster-info returns color code in Kui 
Created: 2019-05-15T17:30:36Z
Terminal:

Kui:

Duplicate issue #2892: k8s plugin - kubectl cluster-info is hard to read
Created: 2019-09-30T17:40:19Z
The output is formatted strangely and hard for a user to read, when using the same command in a mac terminal the output is formatted normal.
KUI returning these appended to the output strings:
[0;32m
[0m

Closing comment (2019-09-30T19:30:59Z): Duplicate of #1420
Repository: kubernetes-sigs/kui

Issue #293: with invalid kube creds, proxy returns garbage
Created: 2019-01-28T02:20:17Z
for kubectl get pods, with invalid credentials, the proxy shows
POST /exec 500 4883.641 ms - -
Error preparing usage

and the client shows
{
   "type": "Buffer",
   "data": []
}

Duplicate issue #867: webpack+proxy sometimes throws internal error instead of true error message
Created: 2019-03-15T19:41:02Z
i.e. kubectl commands without k8s auth
Now:

Expected:

Closing comment (2019-03-15T19:51:07Z): Related to #293
Repository: kubernetes-sigs/kui

Issue #5672: after editing a Commentary, the Copy button copies the old text
Created: 2020-09-17T14:16:14Z
THe problem is that we are only updating the response, not the "command" in the BlockModel. WHereas the copy button extracts from BlockModel.command. We need to update BlockModel to avoid having copies of the command and response.

Duplicate issue #5916: prefersReExecute bit on notebooks that contain commentary results in poor rendering
Created: 2020-10-08T13:04:05Z
The commentary gets re-executed... but it shows up in edit mode. You can see the bug by hacking preferReExecute into welcome.json, and then trying to open it
{
  ...,
  "spec": { "preferReExecute": true, "splits": ... }
}

Closing comment (2020-10-08T13:25:50Z): this might be the same as #5672
Repository: kubernetes/autoscaler

Issue #22: Add CA e2e using volumes
Created: 2017-04-24T15:39:27Z
#19 was not covered by existing tests and we should add an e2e to make sure something similar won't happen again.

Duplicate issue #29: Create e2e test for PVCs in Cluster Autoscaler scale up.
Created: 2017-04-28T16:10:15Z

Closing comment (2017-04-28T16:11:36Z): Duplicate of #22, closing.
Repository: kubernetes/autoscaler

Issue #3006: Backport new instance types to 1.14 releases
Created: 2020-03-31T18:41:48Z
Hi, would it be possible to backport the commit introducing the new instance types to 1.14? It's only one version away from the newest in AWS EKS.

  
    
      autoscaler/cluster-autoscaler/cloudprovider/aws/ec2_instance_types.go
    
    
         Line 1591
      in
      1f801e8
    
  
  
    

        
          
           "r5n": { 
        
    
  


Unable to build proper template node for ASG: ASG "ASG" uses the unknown EC2 instance type "r5n.large"

Duplicate issue #3134: CA 1.14: Missing AWS instance types
Created: 2020-05-14T16:22:20Z
CA 1.14.8 is missing several instance types, which master already has.
I'm fine with taking care of it myself, but just to clarify, should I just execute
go run ec2_instance_types/gen.go

and create a PR to merge the newly generated file into the cluster-autoscaler-release-1.14 branch, or should I look for the last commit that generated the ec2 instance types and create a PR to cherry pick it into cluster-autoscaler-release-1.14?

Closing comment (2020-05-25T21:06:40Z): Duplicate of #3006 ?
Repository: kubernetes/autoscaler

Issue #1640: AWS EKS CloudFormation NodeAutoScalingGroupMinSize  NodeAutoScalingGroupMaxSize 
Created: 2019-02-01T02:27:37Z
Hi, I deploy k8s on AWS EKS using cloud formation which lets me speficy NodeAutoScalingGroupMinSize and NodeAutoScalingGroupMaxSize. How does the aws cluster auto-scaler wok with these 2 parameters? Which one takes precedence? Thanks.

Duplicate issue #1646: AWS latest source code cluster-autoscaler-autodiscover.yaml error
Created: 2019-02-01T13:52:59Z
E0201 08:59:01.510099       1 aws_manager.go:237] Failed to fetch ASGs: cannot autodiscover ASGs: MissingRegion: could not find region configuration
F0201 08:59:01.510169       1 cloud_provider_builder.go:137] Failed to create AWS Manager: cannot autodiscover ASGs: MissingRegion: could not find region configuration

Closing comment (2019-02-04T00:11:52Z): This is reported in #1640 You are using latest example yaml with v1.2.x container image. Please consistently use right combination.
Repository: kubernetes/autoscaler

Issue #1949: Scale in of GPU node group sometimes results in 2 nodes being created
Created: 2019-04-23T20:47:01Z
I am experiencing some odd behaviour running on EKS when scaling out my GPU node groups which results in 2 nodes being created, I think it is related to the nvidia-device-plugin having a delay in setting the available GPU after a node comes up, the following seems to happen:

Schedule pod with GPU taint and GPU resource request with no GPU nodes in cluster
CA picks up that a node needs to be created and correctly creates a node in a GPU node group
The node comes up
CA sees that the node does not have any available GPU resources and decides to scale out another node group
The first node appears to get assigned the GPU resource once the nvidia device plugin starts and the pod schedules successfully
There is now another node created which goes away after 15 minutes

Is there a way to handle this correctly so that I am not spinning up an extra uneeded node? it appears to not always happen and sometimes will work as expected.

Duplicate issue #2232: [cluster-autoscaler] AWS EKS scaling multiple GPU nodes for single request
Created: 2019-08-02T10:26:16Z
I have an EKS cluster provisioned with the terraform-aws-eks module and 2 sets of node groups, one regular compute (m5.2xlarge) and one GPU (p2.xlarge), each with an ASG in each AZ (m5.2xlarge-eu-west-1a, m5.2xlarge-eu-west-1b, etc).  We are using cluster-autoscaler:v1.12.6 and the node groups are tagged for auto discovery. I have the GPU nodes to be registered with the taint nvidia.com/gpu=true:NoSchedule and the associated tag on the GPU ASGs:
k8s.io/cluster-autoscaler/node-template/taint/nvidia.com/gpu=true and I have the nvidia gpu daemonset deployed.
When I apply an example deployment that requests some GPU resource and has the correct toleration, I get the expected behaviour of the autoscaler triggering a scale up on one of the GPU ASGs (Desired Capacity 0 -> 1). However, once the new GPU node comes up the cluster-autoscaler seems to find it has no available gpu resource to schedule the GPU pod and triggers a scale up on another of the GPU ASGs. While the second is coming up, it realizes the original GPU node does have GPU resources and schedules the pod but I'm left with an extra GPU node until it's scaled down each time.
The only issue I can see is that the check for GPU resources seems to be done while the node is still "Initializing" in the AWS EC2 console so if it's not fully started the nvidia gpu daemonset may not be running to expose the GPU resources yet. Any advice would be greatly appreciated!

Closing comment (2019-08-02T14:45:44Z): Apologies, duplicate of #1949
Repository: kubernetes/autoscaler

Issue #5452: updateMode: Initial not applied on re-deployment
Created: 2023-01-27T15:13:34Z
I'm trying to use the VPA with the Initial update mode.  I'm seeing the following behavior and trying to understand if I am using this feature incorrectly, if it's not applicable to my use case, or it there is an issue:

Deploy a Helm chart with Pod for a Tomcat web application, no VPA.
Undeploy the Helm release (helm delete)
Deploy the Helm chart with a VPA added, configured with updateMode: Initial
Note timing issue - VPA resource is created, but has no recommendation. Pod is created at the same time with the resource requests configured in the Helm chart.  The VPA then updates with the recommendations, but pod is not using them.
Manually restart the pod (delete the pod so it is automatically recreated), then the VPA recommendations are automatically applied to the pod.
I have tested with the VPA resource configured with a Helm pre-install hook.  This does not resolve the timing issue.  I did notice that when undeploying the Helm release, the VPA is not deleted (as expected), but with the pod removed, the VPA's pod selector doesn't find it anymore, and the recommendations are removed from the VPA.  So next deployment does not apply them on pod creation, as the VPA doesn't get updated with recommendations until after the pod is created.
Deploying with updateMode: Auto shows a similar behavior - pod and vpa are created, pod has configured resource requests (not from VPA), VPA is updated with recommendations, and then a few seconds later the pod is evicted and re-deployed by the updater with the recommended resources.

Seems like a chicken-egg timing problem - even if the VPA exists before the pod is created, the VPA isn't updated with recommendations until the pod is created, and then it's too late for the initial settings to be applied.  How is this expected to work?
AWS EKS 1.22
My VPA configuration:
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: myApp
spec:
  resourcePolicy:
    containerPolicies:
      - containerName: '*'
        controlledResources:
          - cpu
          - memory
  targetRef:
    apiVersion: apps/v1
    kind: StatefulSet
    name: myApp
  updatePolicy:
    updateMode: Initial

Duplicate issue #5619: VPA initial delay
Created: 2023-03-26T09:03:25Z
Hey Guys,
im using VPA on my develop environment and i have enabled the "Initial" mode for adapting my resources.
The problem that since i have enabled it my micro-services are not begin able to startup properly
and it takes a-lot of time, as the VPA update their resources to:
"    resources:
  limits:

    cpu: 66m

    memory: "570387708"

  requests:

    cpu: 50m

    memory: "380258472""

so they cannot start up
is it possible to make the VPA start to update resources after a x mins of delay
something like that:

Closing comment (2023-03-27T15:34:10Z): This seems related to how updateMode: initial works and is very similar to #5452 (comment)
/close duplicate
/kind support
please re-open if you think there's a different issue at hand here.
Repository: kubernetes/autoscaler

Issue #3150: Cluster Autoscaler CAPI provider should support scaling to and from zero nodes
Created: 2020-05-21T19:07:23Z
As a user I would like the ability to have my MachineSets and MachineDeployments scale to and from zero replicas. I should be able to set a minimum size of 0 for a Machine[Set|Deployment] and have the autoscaler take the appropriate actions.
This issue is CAPI provider specific, and will require some modifications to the individual CAPI providers before it could be merged in the autoscaler code.

Duplicate issue #4758: Allow Cluster API node groups to scale to and from zero
Created: 2022-03-22T13:01:24Z
Which component are you using?:
cluster-autoscaler
Is your feature request designed to solve a problem? If so describe the problem this feature should solve.:
I have a Cluster API cluster with some general purpose nodes and some specialist, expensive nodes that is used for batch-type workloads. I would like to be able to scale the specialist nodes down to zero unless a workload needs them.
Describe the solution you'd like.:
For the cluster autoscaler to be able to scale Cluster API machine deployments to and from zero nodes.
Describe any alternative solutions you've considered.:
None - the cluster autoscaler works perfectly for everything except this.
Additional context.:
N/A

Closing comment (2022-04-29T18:17:03Z): @elmiko: Closing this issue.

In response to this:

this appears to be a duplicate of #3150
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Repository: kubernetes/autoscaler

Issue #3097: Update generated clients to 1.18.2
Created: 2020-04-27T15:52:28Z
Update the generated clients to be generated by 1.18.2

Duplicate issue #3219: VerticalPodAutoscaler not compatible with k8s 1.18.x libraries 
Created: 2020-06-11T17:17:46Z
We are trying to vendor in the latest Kubernetes client-libraries. We are blocked from doing so as we also depend on VPA as a library

Closing comment (2020-06-12T03:18:20Z): Duplicate of #3097
I updated them here #3098
Repository: kubernetes/autoscaler

Issue #4016: Support in-place Pod vertical scaling in VPA
Created: 2021-04-15T12:46:07Z
Hey everyone,
as I gather the VPA currently cannot update pods without recreating them:

Once restart free ("in-place") update of pod requests is available
from README

and neither can the GKE vertical scaler:

Due to Kubernetes limitations, the only way to modify the resource requests of a running Pod is to recreate the Pod
from https://cloud.google.com/kubernetes-engine/docs/concepts/verticalpodautoscaler#vertical_pod_autoscaling_in_auto_mode

Unfortunately, I was unable to learn the specific limitation from this (other than the mere absence of any such feature?) nor timeline for this to appear in VPA or how to contribute on this if possible. Could you please outline what is missing in VPA for this to be implemented?
Best regards,
Raffael

Duplicate issue #5744: VPA in-place vertical scaling 
Created: 2023-05-09T02:50:49Z
Which component are you using?:
VerticalPodAutoscaler
Is your feature request designed to solve a problem? If so describe the problem this feature should solve.:
While reading the doc of VPA, I found that "Once restart free ("in-place") update of pod requests is available, it may be used as the preferred update mechanism by the "Auto" mode.".
But when I have a try,it doesn't work at all ！my k8s version is 1.27.1 who has support in-place feature. Then I read the code of VPA, I found that the code of Updater Controller still evict pod !
Kubernetes (>= 1.27 version) has supported updating pods in-place, but VPA currently uses eviction and reconstruction to modify existing pods. This greatly disrupts the stability of the business.And this does not align with the description of Auto mode in your documentation, which states that Auto mode supports in-place updates.
Describe the solution you'd like.:
k8s in-place
We can modify the current code of the Updater module to change the pod updating logic from eviction to both eviction and in-place updates. When the VPA runs in auto mode, it will try to update in-place first, and if it fails, it will evict and then update in-place.
Describe any alternative solutions you've considered.:
I can rely on the existing behavior that replaces Pods with new Pods. This will trigger longer outages than an in-place resize, and even if my legacy app is able to tolerate the replacements that happen, there is a bigger risk of a disruption to the end user experience.
Additional context.:
k8s-inplace
kubernetes/enhancements#1287

Closing comment (2023-05-09T08:16:57Z): @voelzmo: Closing this issue.

In response to this:

Hey @THMAIL, thanks for asking about this feature! There's already an issue tracking this, so I'll go ahead and close this one.
/duplicates #4016
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Repository: kubernetes/kops

Issue #290: Option to turn off basic auth
Created: 2016-08-10T18:10:51Z
This may be as simple as not passing basic-auth-file to the api server, but need to understand what else this disables!

Duplicate issue #5775: How to disable --basic-auth-file  on kops?
Created: 2018-09-12T17:26:08Z
I am trying to find a way to disable --basic-auth-file on my cluster. Can someone help me?

Closing comment (2018-09-13T07:45:34Z): Duplicate of #290 and there is a PR: #5586
Repository: kubernetes/kops

Issue #651: More than one vendor directory - some with more than one copy of the same dependency
Created: 2016-10-15T03:15:29Z
It looks like we have a vendor and _vendor directory for the project. Is this intentional? Or should we consolidate these?
Also I noticed there are a few duplicated dependencies in the project, is this also intentional? Can we clean this up?
_vendor with git submodules - spf13
vendor with included dependencies - spf13

Duplicate issue #910: Multiple vendor directories
Created: 2016-11-16T18:12:48Z
I'm new to golang, so I'm curious why kops has both vendor/ and _vendor/ ? Is one of these directories from a pin/legacy/alt go dependency manager?

Closing comment (2016-11-16T18:37:34Z): Hi @mcandre.
Docs on it are here: https://github.com/kubernetes/kops/blob/master/docs/development/dependencies.md
Long-term, we'll likely move either to bazel or whatever the "official" go solution turns out to be.
This is probably a dup of #651
Repository: kubernetes/kops

Issue #1265: rolling-update should support a single instancegroup
Created: 2016-12-26T16:35:00Z
Rather than requiring a full cluster update

Duplicate issue #171: Should be a way to apply changes only to a particular instance group
Created: 2016-07-18T19:52:35Z
Rather than tweaking the whole cluster

Closing comment (2017-01-03T17:14:36Z): Closing as dup of #1265
Repository: kubernetes/kops

Issue #1208: ConfigureCBR0 was removed from kubernetes 1.5.0 
Created: 2016-12-20T00:45:48Z
We need to allow for ConfigureCBR0 in 1.4.x and remove ConfigureCBR0 in 1.5.x

Duplicate issue #1169: Using --networking=cni does not work with k8s v1.5.1
Created: 2016-12-15T16:33:09Z
Built kops from master trying to run with the --networking=cni option.  Looks like kublet fails to start because of an unrecognized flag.
$ kops version
Version git-fbe62f0

Dec 15 04:50:46 ip-172-30-75-186 kubelet[1467]: unknown flag: --configure-cbr0

Closing comment (2016-12-28T04:17:55Z): Closing as a dup of #1208 (even though this was opened first!)
Repository: kubernetes/kops

Issue #2955: Automate and improve our release process
Created: 2017-07-15T21:01:13Z
At this point, only one maintainer is able to create a release for kops.  This is a risk that needs to be resolved.  Risks include:

single point of failure
if we have a p0 bug only one person can release
if the user wins the lottery we have no release avenue

The release includes both the primary ami that is used for kops, and kops itself.  The primary ami is built using tooling out of https://github.com/kubernetes/kube-deploy/tree/master/imagebuilder
Also, the kernel for the ami is not mainstream, but a custom build.
Proposed Solutions
Interm

we need to document existing process
determine which shared file repository and container registry we can use for the release
We can automate a release process via Travis, but it seems kinda complicated.

Any other ideas
Long Term
We have multiple smaller projects within k8s now that will all need a process.  We can possibly start with looking at what mini-kube and helm are using.   I believe this should be under the purview of sig-release.
Really need ideas for this

Duplicate issue #1779: Automate release process
Created: 2017-02-03T17:45:06Z
@justinsb talked about on the open office hours that it would be good to have an automated release process.

Closing comment (2018-12-10T22:04:58Z): @rifelpet: Closing this issue.

In response to this:

This is a duplicate of #2955
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Repository: kubernetes/kops

Issue #5302: initContainer images are not remapped when assets: containerRegistry is set
Created: 2018-06-11T14:59:29Z
What kops version are you running? The command kops version, will display
this information.
Version 1.8.0 (git-5099bc5)


What Kubernetes version are you running? kubectl version will print the
version if a cluster is running or provide the Kubernetes version specified as
a kops flag.
v1.8.6


What cloud provider are you using?
AWS, Beijing region (cn-north-1)


What commands did you run?  What is the simplest way to reproduce this issue?
After kops edit cluster I set the following in the cluster config:
 assets:
   containerRegistry: docker.mycompany.com:5000

Now when I run kops update cluster, many docker images are uploaded to our internal docker registry.


What happened after the commands executed?
Our k8s nodes are pulling many images from our internal docker registry, which is great, however I can see from the kubelet logs that nodes are still pulling quay.io/coreos/flannel:v0.9.1-amd64 during startup, even though kops pushed quay.io/coreos/flannel:v0.9.1-amd64 to docker.mycompany.com:5000/coreos/flannel:v0.9.1-amd64.
From the logs:
 kube_docker_client.go:330] Pulling image "quay.io/coreos/flannel:v0.9.1-amd64": "16a827ca53c8: Downloading [========>

The problem with nodes in China using quay.io is that nodes sometimes take up to 30mins to start, if access to the internet outside China is slow at the time (which happens frequently in this region).


What did you expect to happen?
I expected that the image coreos/flannel:v0.9.1-amd64 would always be pulled from docker.mycompany.com:5000/coreos/flannel:v0.9.1-amd64.


Please provide your cluster manifest. Execute
kops get --name my.example.com -o yaml to display your cluster manifest.
You may want to remove your cluster name and other sensitive information.
Full manifest info has been dumped here: https://pastebin.com/raw/DG5jLN3d

Duplicate issue #5371: Error from 1.10: "Skipping likely image field: spec.template.spec.initContainers.[0].image"
Created: 2018-06-22T04:04:36Z
From kops update:
Skipping likely image field: spec.template.spec.initContainers.[0].image

Closing comment (2018-06-22T04:53:16Z): Maybe related to #5302
Repository: kubernetes/kops

Issue #1517: Kops --wait
Created: 2017-01-17T23:55:25Z
Executing both kops cluster create ... and kops cluster update took 2.57 minutes for a new cluster. However the kubernetes cluster is not ready for use at this point.
E.g.
$ kubectl get pods
Unable to connect to the server: EOF

$ kops-1.5.0-alpha3 validate  cluster
Using cluster from kubectl context: xxxxxx.photobox.com

Validating cluster xxxxxx.photobox.com


Cannot get nodes for "xxxxxx.photobox.com": Get https://api.xxxxxx.photobox.com/api/v1/nodes: EOF

$ kops-1.5.0-alpha3 validate  cluster

Using cluster from kubectl context: xxxxxx.photobox.com

Validating cluster xxxxxx.photobox.com


Cannot get nodes for "xxxxxx.photobox.com": Get https://api.xxxxxx.photobox.com/api/v1/nodes: EOF

$ kops-1.5.0-alpha3 validate  cluster
Using cluster from kubectl context: xxxxxx.photobox.com

Validating cluster xxxxxx.photobox.com

INSTANCE GROUPS
NAME			ROLE	MACHINETYPE	MIN	MAX	SUBNETS
bastions		Bastion	t2.micro	1	1	utility-eu-west-1b,utility-eu-west-1c,utility-eu-west-1a
master-eu-west-1a	Master	m3.large	1	1	eu-west-1a
master-eu-west-1b	Master	m3.large	1	1	eu-west-1b
master-eu-west-1c	Master	m3.large	1	1	eu-west-1c
nodes			Node	m3.large	5	5	eu-west-1b,eu-west-1c,eu-west-1a

NODE STATUS
NAME						ROLE	READY
ip-10-0-102-114.eu-west-1.compute.internal	master	True
ip-10-0-104-134.eu-west-1.compute.internal	node	False
ip-10-0-120-191.eu-west-1.compute.internal	node	True
ip-10-0-47-148.eu-west-1.compute.internal	node	False
ip-10-0-58-87.eu-west-1.compute.internal	master	True
ip-10-0-78-49.eu-west-1.compute.internal	node	False
ip-10-0-80-192.eu-west-1.compute.internal	master	True
ip-10-0-84-31.eu-west-1.compute.internal	node	False

Validation Failed
Master(s) Not Ready 0 out of 3.
Node(s) Not Ready   4 out of 5.

Your cluster xxxxxx.photobox.com is NOT ready.

It would be ideal to have kops with a --wait option for the cluster to be ready.
There is a similar ticket #139.
There are a few example scripts to wait for a cluster to be initialised, however would be ideal to have this part of kops.
Also to note @chrislovecnm kops cluster validate doesn't do anything with kubectl get cs maybe ideal to add into the kops validate cluster?
kubectl config use-context ${CLUSTER_NAME}
echo -n "Waiting for cluster components to become ready."
until [ $(kubectl get cs 2> /dev/null| grep -e Healthy | wc -l | xargs) -ge 4 ]
do
  echo -n "."
  sleep 1
done
echo "ok"

echo -n "Waiting for minimum nodes to become ready."
min_nodes=$(kops get ig nodes --name ${CLUSTER_NAME} | grep nodes | awk '{print $4}')
until [ "$(kubectl get nodes 2> /dev/null| grep -v master | grep -e Ready | wc -l | xargs)" == "$min_nodes" ]
do
  echo -n "."
  sleep 1
done
echo "ok"

@shadoi
or
while [ 1 ]; do
    kops validate cluster && break || sleep 30
done;

Duplicate issue #139: Add --wait argument to `cluster create`
Created: 2016-07-13T16:04:39Z
Could be optional, but could wait for machines to be started, DNS to resolve etc

Closing comment (2017-09-25T07:07:59Z): @blakebarnett Yes.
I think we should close this ticket as duplicate (of #1517). This one is older but the other has more info/comments.
Repository: kubernetes/kops

Issue #3247: kube-apiserver templates
Created: 2017-08-21T21:01:35Z
kube-apiserver is the only non-addon where we are still using templates.  We need to move all of the templating into code.
All of this templating fun should be moved to logical code: https://github.com/kubernetes/kops/tree/master/upup/models/config/components/kube-apiserver

Duplicate issue #3253: Migrate kube-apiserver cloud provider logic out of tag builders
Created: 2017-08-22T12:58:50Z
Continuing the discussion here with @justinsb.
We currently set the cloud provider using tags. e.g. here. We moved a lot of this logic out of tags and into code like this, we should do the same for the cloud provider option.

Closing comment (2017-08-22T20:05:20Z): Is this a duplicate? #3247
Repository: kubernetes/kube-state-metrics

Issue #1210: Resource Metrics for CRDs
Created: 2020-08-18T07:19:17Z
/kind feature
With the growing use of CRDs in K8s it might be useful to monitor those as well and provide some initial metrics for them.
Idea:
Have kube-state-metrics read a configuration file that allows the user to list further resources.
A list of crds to monitor:
- servicemonitors.monitoring.coreos.com
- certificaterequests.cert-manager.io

could create metrics similar to https://github.com/kubernetes/kube-state-metrics/blob/master/docs/configmap-metrics.md
kube_CRD_NAME_info
kube_CRD_NAME_created
kube_CRD_NAME_metadata_resource_version

Duplicate issue #1640: Extend kube-state-metrics to support Custom Resource metrics
Created: 2021-11-24T03:17:28Z
What would you like to be added:
Since the CRD has been widely used nowadays, is there any chance for kube-state-metrics to support Custom Resource metrics extension, a little bit like kube-scheduler. The repo scheduler-plugin is based on the out-of-tree scheduler plugins framework.
I suppose we could make small changes to make users define their own out-of-tree metrics stores so they could easily depend this project to add the Custom Resource metrics.
Why is this needed:
Now users should copy this repo and modify the source codes to support their own Custom Resource metrics because the availableStores is hard-code here. I hope this could be more flexible so that users just only have to depend this repo in their own project, add their plugin registry and finally build the project to get a new customized kube-state-metrics.
Describe the solution you'd like
A simple solution is add a new func in builder.go and handle some details in main.go. Here is the new function.
func RegisterOutOfTreeStores(
	name string,
	metricFamilies []generator.FamilyGenerator,
	expectedType interface{},
	listWatchFunc func(kubeClient clientset.Interface, ns string, fieldSelector string) cache.ListerWatcher,
) {
	availableStores[name] = func(b *Builder) []cache.Store {
		return b.buildStoresFunc(metricFamilies, expectedType, listWatchFunc, b.useAPIServerCache)
	}
}
The out-of-tree metrics store could be added into the availableStores to prevent hard-code.
Additional context

Closing comment (2021-12-07T02:19:41Z): For what it's worth, a similar effort was tracked in #1210.

Hi @dgrisonnet, this issue is very helpful. I think it focuses on CRD itself rather than CR. IMO, both are important.
#1644 has given a revision that helps ksm to add any out-of-tree CR metrics. As a result, the extension of ksm will be improved and the whole framework of ksm could benefit for CR metrics. Users could define their own metrics or override the built-in metrics just registering their own metrics factories.
How do you think? 😉