Skip to content

Add subnet-len configuration option. - #70

Draft
freyes wants to merge 1 commit into
charmed-kubernetes:mainfrom
freyes:bug/1930087
Draft

Add subnet-len configuration option.#70
freyes wants to merge 1 commit into
charmed-kubernetes:mainfrom
freyes:bug/1930087

Conversation

@freyes

@freyes freyes commented May 28, 2021

Copy link
Copy Markdown

By default flannel chops the configured cidr in /24 subnets that are
assigned to each node, this allows kubelet to run up to 254 hosts, for
clusters where the machines are large enough to host more than 254 pods
or have a large number of create-destroy pod operations (e.g. a CI/CD
pipeline) would produce an starvation of available IP addresses.

This configuration option will allow flannel to be configured with
a different size for each subnet. When this configuration option
changes the cni0 bridge is destroyed and flannel restarted.

Fixes lp:1930087

By default flannel chops the configured cidr in /24 subnets that are
assigned to each node, this allows kubelet to run up to 254 hosts, for
clusters where the machines are large enough to host more than 254 pods
or have a large number of create-destroy pod operations (e.g. a CI/CD
pipeline) would produce an starvation of available IP addresses.

This configuration option will allow flannel to be configured with
a different size for each subnet. When this configuration option
changes the cni0 bridge is destroyed and flannel restarted.

Fixes [lp:1930087](https://bugs.launchpad.net/charm-flannel/+bug/1930087)
@freyes

freyes commented May 31, 2021

Copy link
Copy Markdown
Author

I was giving some rounds of testing to this patch and I realize my approach is susceptible of a race condition, since I'm using whatever is stored in etcd to determine if the SubnetLen changed, I should simply rely on config.changed().

Another approach I was giving some thoughts is to make the leader do the "etcdctl set" and then do a leader-set to make the peers react and restart flannel, I believe it will be more clean and less prone to issues (e.g. many units doing the "etcdctl set" concurrently).

@freyes
freyes marked this pull request as draft May 31, 2021 00:14
@freyes

freyes commented May 31, 2021

Copy link
Copy Markdown
Author

I'm confused in what would be the best approach to force the cni0 device to pick up the change of the subnet, when I'm deleting it and then restarting flannel the bridge doesn't get recreated. Any guidance on what would be the less disruptive way to achieve this?

@addyess addyess left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know precisely what this changes in flannel, but i don't understand why we're only setting SubnetLen to 24?

Maybe I'm reading the if statement incorrectly. Can you confirm this PR is still necessary?

Comment thread reactive/flannel.py
# the subnet-len configured is 24 which will be the case for environments
# upgrading the charm and in those situations we don't want to add
# disruption restating flannel without need.
if current_config.get("SubnetLen") != config("subnet-len") \

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

readability suggestion:

Suggested change
if current_config.get("SubnetLen") != config("subnet-len") \
current_subnet = current_config.get("SubnetLen")
target_subnet = config("subnet-len")
if (current_subnet != target_subnet) and (current_subnet is not None) and (target_subnet == 24):

@freyes why would you only apply this when subnet-len is 24?

@seedplicity-admin

Copy link
Copy Markdown

Is there any movement on this? We've had some decent downtime attributed to Juju defaulting /24 in a large production cluster. There's also a bug posted in launchpad with no movement in over a year.

https://bugs.launchpad.net/charm-flannel/+bug/1930087

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants