Update mixer deployment configuration

[juliawu]

No description provided.

[gemini-code-assist]

Code Review

This pull request updates the Mixer Helm chart by hardcoding maxSurge to 1, introducing a soft pod anti-affinity configuration, and defining CPU requests for multiple service groups. Feedback suggests reverting the hardcoded maxSurge to a default value to maintain configurability and avoid slow deployments for large groups. Additionally, it is recommended to enable pod anti-affinity for other high-replica service groups to enhance fault tolerance.

[gemini-code-assist]

Hardcoding maxSurge to 1 removes the ability to customize the rollout strategy per service group and environment. This change ignores existing configurations such as maxSurge: 0 in deploy/helm_charts/envs/mixer_staging.yaml. Additionally, for large deployments (e.g., the recon group with 90 replicas in production), a maxSurge of 1 will significantly slow down the rollout process as it only creates one new pod at a time. It is recommended to use 1 as a default while still allowing overrides from values.yaml.

      # Set to 1 to reduce resource overhead during deployment, but allow overrides.
      maxSurge: {{ $group.maxSurge | default 1 }}

References

1. For mixer container deployments, configuration keys can be added to the base values.yaml file to provide default values that are then overridden by environment-specific files.

[gemini-code-assist]

Pod anti-affinity is currently only enabled for the observation group. Given that other service groups like recon and node also have a high number of replicas in production (90 and 60 respectively), it is recommended to enable anti-affinity for them as well. This ensures that replicas are spread across different nodes, improving the service's resilience to node failures.

References

1. Configuration keys for mixer deployments can be added to the base values.yaml file to establish default behaviors across environments.