Increasing sidecar default CPU limits and memory.

[davinchia]

What

Related to https://github.com/airbytehq/airbyte-cloud/issues/3814.

These vars govern the heartbeat and socat Kube sidecars.

Testing has shown that socat requires at least 1.5 CPU to support > 20 MB/s throughput.

Bump to 2.0 CPU just in case. This is fine because CPU limits affect throttling, and not scheduling, so this change will not affect OSS users or baseline Kube deployment requirements.

Also a modest increase in default resource request for the sidecars for better reliability.

How

See what section.

Recommended reading order

1. the one file.

🚨 User Impact 🚨

Are there any breaking changes? What is the end result perceived by the user? If yes, please merge this PR with the 🚨🚨 emoji so changelog authors can further highlight this if needed.

Pre-merge Checklist

Expand the relevant checklist and delete the others.

New Connector

Community member or Airbyter

• Community member? Grant edit access to maintainers (instructions)
• Secrets in the connector's spec are annotated with airbyte_secret
• Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
• Code reviews completed
• Documentation updated
  • Connector's README.md
  • Connector's bootstrap.md. See description and examples
  • docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
  • docs/integrations/README.md
  • airbyte-integrations/builds.md
• PR name follows PR naming conventions

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

• Create a non-forked branch based on this PR and test the below items on it
• Build is successful
• If new credentials are required for use in CI, add them to GSM. Instructions.
• /test connector=connectors/<name> command is passing
• New Connector version released on Dockerhub by running the /publish command described here
• After the connector is published, connector added to connector index as described here
• Seed specs have been re-generated by building the platform and committing the changes to the seed spec files, as described here

Updating a connector

Community member or Airbyter

• Grant edit access to maintainers (instructions)
• Secrets in the connector's spec are annotated with airbyte_secret
• Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
• Code reviews completed
• Documentation updated
  • Connector's README.md
  • Connector's bootstrap.md. See description and examples
  • Changelog updated in docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
• PR name follows PR naming conventions

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

• Create a non-forked branch based on this PR and test the below items on it
• Build is successful
• If new credentials are required for use in CI, add them to GSM. Instructions.
• /test connector=connectors/<name> command is passing
• New Connector version released on Dockerhub and connector version bumped by running the /publish command described here

Connector Generator

• Issue acceptance criteria met
• PR name follows PR naming conventions
• If adding a new generator, add it to the list of scaffold modules being tested
• The generator test modules (all connectors with -scaffold in their name) have been updated with the latest scaffold by running ./gradlew :airbyte-integrations:connector-templates:generator:testScaffoldTemplates then checking in your changes
• Documentation which references the generator is updated as needed

Tests

Unit

Put your unit tests output here.

Integration

Put your integration tests output here.

Acceptance

Put your acceptance tests output here.

[evantahler]

⏩

[github-actions]

Airbyte Code Coverage

File	Coverage [45.16%]	❌
EnvConfigs.java	45.16%	❌

Total Project Coverage	26.77%	🍏

[git-phu]

@davinchia one thing to note though is that with our current node sizes in cloud today, we almost always run out of CPU before memory on our nodes, so with this change the problem could potentially get worse so that we end up needing to spin up more nodes (and have even more unused memory). Just something to keep an eye out for after deploying this change and possibly consider resizing our job nodes to be more efficient depending on how things look.

[davinchia]

@git-phu good point. Maybe it's worth pairing this with

1. a prod jobs pool resize
2. higher CPU request injected into prod env via helm to guarantee a higher sidecar cpu

Happy to do the work. Want your thoughts on if we should

[git-phu]

@davinchia yeah we can probably test in PR in dev with a sync that pushes more data and see how it behaves.

I don't know how much leeway we have to increase the max size of node pools in prod, so to optimize I think we may just want nodes with more CPU (and same amount of memory).

But I also don't think we'll start hitting the max pool size because of this change so it should be safe to deploy it first and collect some metrics before deciding to change node sizes.