Expected behavior for Deployment replicas with HPA during update
I am seeing unexpected behavior from a user standpoint when `kubectl apply -f mydeployment.yml` The existing Deployment has an HPA associated with it and the current replica count is 3. When the deployment is accepted, the number of replicas jumps to 9, then scales down to 6, the value in the deployment. Eventually, the new pods info starts flowing in and the HPA does its thing and scales back to satisfaction. The behavior I expected is that the rollout would use the current replicas from the HPA and the strategy parameters from the Deployment to keep replica count in line with the current target set by the HPA. k8s version: 1.2.3 ``` apiVersion: extensions/v1beta1 kind: Deployment metadata: name: mydeployment spec: replicas: 6 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: "40%" maxSurge: "50%" template: metadata: labels: app: myapp spec: containers: - name: myapp image: "someimage" ``` ``` apiVersion: extensions/v1beta1 kind: HorizontalPodAutoscaler metadata: name: mydeployment namespace: default spec: scaleRef: kind: Deployment name: mydeployment subresource: scale minReplicas: 3 maxReplicas: 12 cpuUtilization: targetPercentage: 50 ```
Posted by verdverm on May 6, 2016, 12:02 AM
Tags
Related issues
- Many devs love to shit on the guy from the 'I just want the exe.
- Now imagine how poor people stress if their smartphone bricks or gets damaged or lost.
- Resuming an extended-thinking session fails permanently with 400 "thinking blocks cannot be modified" (transcript stores thinking text as empty but keeps signat
- I'll preface this with a statement that as a European I want European alternatives to succeed, and MS-owned GitHub to shrivel and disappear.
- Yeah, but there’s a world of difference between “not perfect” and “we rounded a few sliders, and now the modal is a nightmare to use”.
- I used to write a lot of native Windows corporate software in the 90's and 2000's and my standard login window was a floating draggable o...
Raise real-world problems, find people facing the same issue, and discuss solutions.5,000 issues0 comments
reliability (SaaS)
Many devs love to shit on the guy from the 'I just want the exe.
Now imagine how poor people stress if their smartphone bricks or gets damaged or lost.
Resuming an extended-thinking session fails permanently with 400 "thinking blocks cannot be modified" (transcript stores thinking text as empty but keeps signat
I'll preface this with a statement that as a European I want European alternatives to succeed, and MS-owned GitHub to shrivel and disappear.
Yeah, but there’s a world of difference between “not perfect” and “we rounded a few sliders, and now the modal is a nightmare to use”.
I used to write a lot of native Windows corporate software in the 90's and 2000's and my standard login window was a floating draggable o...
App broken with Mosquitto broker 7.0.0
[BUG] Remote Control: automatic reconnection doesn't work -- connection drops silently with no recovery
Expected behavior for Deployment replicas with HPA during update
I am seeing unexpected behavior from a user standpoint when `kubectl apply -f mydeployment.yml` The existing Deployment has an HPA associated with it and the current replica count is 3. When the deployment is accepted, the number of replicas jumps to 9, then scales down to 6, the value in the deployment. Eventually, the new pods info starts flowing in and the HPA does its thing and scales back to satisfaction. The behavior I expected is that the rollout would use the current replicas from the HPA and the strategy parameters from the Deployment to keep replica count in line with the current target set by the HPA. k8s version: 1.2.3 ``` apiVersion: extensions/v1beta1 kind: Deployment metadata: name: mydeployment spec: replicas: 6 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: "40%" maxSurge: "50%" template: metadata: labels: app: myapp spec: containers: - name: myapp image: "someimage" ``` ``` apiVersion: extensions/v1beta1 kind: HorizontalPodAutoscaler metadata: name: mydeployment namespace: default spec: scaleRef: kind: Deployment name: mydeployment subresource: scale minReplicas: 3 maxReplicas: 12 cpuUtilization: targetPercentage: 50 ```
Comments (0)
No comments yet. Start the discussion.