-
Notifications
You must be signed in to change notification settings - Fork 45
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
Move Control Plane Ingress VIP management to MetalK8s Operator instead of MetalLB #4000
Move Control Plane Ingress VIP management to MetalK8s Operator instead of MetalLB #4000
Conversation
TeddyAndrieux
commented
Feb 24, 2023
- Fix some flaky tests
- Rework the Sub reconciler handling in MetalK8s Operator
- Rework VirtualIPPool to be less "WP Ingress linked"
- Move Control Plane Ingress IP handling in MetalK8s Operator
- Properly handle upgrade and migration from MetalLB
- Remove everything linked to MetalLB
Hello teddyandrieux,My role is to assist you with the merge of this Status report is not available. |
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
Peer approvals must include at least 1 approval from the following list: |
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.
(first batch, only read the first 3 commits)
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
Peer approvals must include at least 1 approval from the following list: |
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.
Last few comments, but LGTM overall 👌
operator/config/crd/bases/metalk8s.scality.com_clusterconfigs.yaml
Outdated
Show resolved
Hide resolved
for link in netifaces.ifaddresses(interface).get(netifaces.AF_INET) or []: | ||
if link.get("addr") == ip: | ||
return interface | ||
|
||
# NOTE: We do not have any easy way (without an external lib) |
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.
We included said external lib, should we still keep the previous logic? What about the bug with loopback you mentioned?
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.
This is the logic to handle the "loopback" bug, we see if there is an interface that already has the VIP.
AFAIK, this lib cannot be used to get the route.
The logic is if the VIP already sits on an interface (it usually shouldn't happen but it could if for whatever reason keepavlied get killed) we keep it, otherwise we "search" it based on the routes
salt/metalk8s/addons/nginx-ingress-control-plane/certs/server.sls
Outdated
Show resolved
Hide resolved
4132813
to
a9199fa
Compare
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.
Still unsure about our risk of script injection :/ Although we don't really document how to use it, nor expose this functionality to users, so I guess it's mostly safe. Could be reworked in a follow-up ticket, TBH.
be84bb1
to
bd160fe
Compare
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.
LGTM!
SALT_MASTER=\$(sudo crictl ps --label="io.kubernetes.container.name=salt-master" -q) | ||
sudo crictl exec \$SALT_MASTER salt-run state.sls metalk8s.orchestrate.update-control-plane-ingress-ip saltenv=metalk8s-${{ inputs.metalk8s-version }} |
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.
Nit: Just for my own information, is there a specific reason why we perform this through crictl instead of a simple kubectl exec ?
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 orchestrate may restart kube-apiserver 😉
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 initial reason was because this orchestrate may restart the APIServer (and then break the kubectl command) but since nowadays we actually do the "local" APIServer first we shouldn't have any issue
And rework the sub reconciler logic so that they all run in a dedicated Goroutine and wait for all of them to complete
From time to time we may have flaky on DynamicClient creation especially since some tests restart the Kubernetes APIServer, in order to avoid those flakiness, retry on k8s_client creation
If for whatever reason keepalived Pod crash and is not able to release the VIP, then the VIP will still be available on the host and when the Pod will try to start again it will pick the loopback interface instead of the actual interface, which make keepalived Crash To avoid this issue ensure the VIP is not yet assigned to one interface
e3db87b
bd160fe
to
e3db87b
Compare
/approve |
Build failedThe build for commit did not succeed in branch feature/move-cp-vips-handling-to-operator. The following options are set: approve |
In the queueThe changeset has received all authorizations and has been added to the The changeset will be merged in:
The following branches will NOT be impacted:
There is no action required on your side. You will be notified here once IMPORTANT Please do not attempt to modify this pull request.
If you need this pull request to be removed from the queue, please contact a The following options are set: approve |
I have successfully merged the changeset of this pull request
The following branches have NOT changed:
Please check the status of the associated issue None. Goodbye teddyandrieux. |