Repository navigation
kubernetes: prefer the node SSH rule when scaling a cluster with etcd nodes #14165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 4.22
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -80,6 +80,7 @@ | |
| import com.cloud.hypervisor.Hypervisor; | ||
| import com.cloud.kubernetes.cluster.KubernetesCluster; | ||
| import com.cloud.kubernetes.cluster.KubernetesClusterManagerImpl; | ||
| import com.cloud.kubernetes.cluster.KubernetesClusterService; | ||
| import com.cloud.kubernetes.cluster.KubernetesClusterVO; | ||
| import com.cloud.network.IpAddress; | ||
| import com.cloud.network.Network; | ||
|
|
@@ -544,20 +545,45 @@ protected FirewallRule removeApiFirewallRule(final IpAddress publicIp) { | |
| } | ||
|
|
||
| protected FirewallRule removeSshFirewallRule(final IpAddress publicIp, final long networkId) { | ||
| FirewallRule rule = null; | ||
| FirewallRuleVO rule = null; | ||
| List<FirewallRuleVO> firewallRules = firewallRulesDao.listByIpPurposeProtocolAndNotRevoked(publicIp.getId(), FirewallRule.Purpose.Firewall, NetUtils.TCP_PROTO); | ||
| for (FirewallRuleVO firewallRule : firewallRules) { | ||
| PortForwardingRuleVO pfRule = portForwardingRulesDao.findByNetworkAndPorts(networkId, firewallRule.getSourcePortStart(), firewallRule.getSourcePortEnd()); | ||
| if (Objects.equals(firewallRule.getSourcePortStart(), CLUSTER_NODES_DEFAULT_START_SSH_PORT) || (Objects.nonNull(pfRule) && pfRule.getDestinationPortStart() == DEFAULT_SSH_PORT) ) { | ||
| if (Objects.equals(firewallRule.getSourcePortStart(), CLUSTER_NODES_DEFAULT_START_SSH_PORT)) { | ||
| rule = firewallRule; | ||
| firewallService.revokeIngressFwRule(firewallRule.getId(), true); | ||
| logger.debug("The SSH firewall rule {} with the id {} was revoked", firewallRule.getName(), firewallRule.getId()); | ||
| break; | ||
| } | ||
| if (rule == null && firewallRule.getSourcePortStart() != null | ||
| && firewallRule.getSourcePortStart() < KubernetesClusterService.KubernetesEtcdNodeStartPort.value()) { | ||
| PortForwardingRuleVO pfRule = portForwardingRulesDao.findByNetworkAndPorts(networkId, firewallRule.getSourcePortStart(), firewallRule.getSourcePortEnd()); | ||
| if (Objects.nonNull(pfRule) && pfRule.getDestinationPortStart() == DEFAULT_SSH_PORT) { | ||
| rule = firewallRule; | ||
| } | ||
| } | ||
| } | ||
| if (rule != null) { | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. on destroy in a network the user keeps, should the etcd rules from 50000 up go too? they stay open and the next cluster with etcd nodes would clash on those ports
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed, the etcd firewall rules at 50000+ were not being revoked on destroy and would linger in a network the user keeps, clashing with the next etcd cluster on those ports. Fixed in the same push: the destroy path now revokes the etcd ingress rules alongside the node and API rules, with a test. 75edb36.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. revoking the etcd rules on destroy in 75edb36 covers it |
||
| firewallService.revokeIngressFwRule(rule.getId(), true); | ||
| logger.debug("The SSH firewall rule {} with the id {} was revoked", rule.getName(), rule.getId()); | ||
| } | ||
| return rule; | ||
| } | ||
|
|
||
| protected void removeEtcdFirewallRules(final IpAddress publicIp) { | ||
| Long etcdNodeCount = kubernetesCluster.getEtcdNodeCount(); | ||
| if (etcdNodeCount == null || etcdNodeCount <= 0) { | ||
| return; | ||
| } | ||
| int etcdStartPort = KubernetesClusterService.KubernetesEtcdNodeStartPort.value(); | ||
| int etcdEndPort = etcdStartPort + etcdNodeCount.intValue() - 1; | ||
| List<FirewallRuleVO> firewallRules = firewallRulesDao.listByIpPurposeProtocolAndNotRevoked(publicIp.getId(), FirewallRule.Purpose.Firewall, NetUtils.TCP_PROTO); | ||
| for (FirewallRuleVO firewallRule : firewallRules) { | ||
| Integer startPort = firewallRule.getSourcePortStart(); | ||
| if (startPort != null && startPort >= etcdStartPort && startPort <= etcdEndPort) { | ||
| firewallService.revokeIngressFwRule(firewallRule.getId(), true); | ||
| logger.debug("The etcd SSH firewall rule {} with the id {} was revoked", firewallRule.getName(), firewallRule.getId()); | ||
| } | ||
| } | ||
| } | ||
|
|
||
| protected void removePortForwardingRules(final IpAddress publicIp, final Network network, final Account account, final List<Long> removedVMIds) throws ResourceUnavailableException { | ||
| if (!CollectionUtils.isEmpty(removedVMIds)) { | ||
| List<PortForwardingRuleVO> pfRules = new ArrayList<>(); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if the 2222 rule was deleted by hand, can this still pick an etcd rule and wipe the etcd forwarding again? the caller already falls back to a safe range when nothing is found
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. You are right that with the 2222 range rule gone, the fallback matches the first rule forwarding to 22, and the etcd rules at 50000+ do, so it could grab one and the scale path would then wipe 2222..50000. Since the caller already bounds its cleanup safely on a null return, I capped the fallback below KubernetesEtcdNodeStartPort so it never crosses into the etcd range, with a test for the no-node-rule case. Pushed in 75edb36.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the cap below the etcd start port in 75edb36 covers it