-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
🌱 Add KubeVirt support to Tilt dev workflow #11697
base: main
Are you sure you want to change the base?
Conversation
Is there someone who is familiar with KubeVirt that could do a first review? |
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.
Thanks for writing this down.
It will be great if we can do a further step and re-use the existig scrpt for creating kind + registry as well as create a new script for automating most of the steps described in this doc
a560441
to
7bbd562
Compare
@fabriziopandini I've refactored the PR and converted most of the instructions to code. We now have Thanks for the suggestion 👍 |
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
The changes make sense to me. I tried this out with make kind-cluster-kubevirt
and everything seems to work as advertised in Tilt. I did make serve
to follow through the docs, and I think they're clear and the tab formatting works fine.
LGTM label has been added. Git tree hash: b986b25002289d3e30b1412e76e01616859efe9d
|
Thx! /lgtm /assign @nunnatsa @fabriziopandini |
LGTM label has been added. Git tree hash: 7ed72e93e4c435b3aa65698c9f8e2b0d42626dff
|
kubectl apply -f \ | ||
"https://raw.githubusercontent.com/projectcalico/calico/${CALICO_VERSION}/manifests/calico.yaml" |
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.
Question: What feature is missing in Kindnet to require calico?
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.
Quoting from the quickstart:
KubeVirt is a cloud native virtualization solution. The virtual machines we’re going to create and use for the workload cluster’s nodes, are actually running within pods in the management cluster. In order to communicate with the workload cluster’s API server, we’ll need to expose it. We are using Kind which is a limited environment. The easiest way to expose the workload cluster’s API server (a pod within a node running in a VM that is itself running within a pod in the management cluster, that is running inside a Docker container), is to use a LoadBalancer service.
To allow using a LoadBalancer service, we can’t use the kind’s default CNI (kindnet), but we’ll need to install another CNI, like Calico.
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.
Not sure how calico is able to do LoadBalancer services, I guess metallb is doing that instead for the kubevirt setup? Normally the CPI does so
FYI: kind also has a CPI: https://kind.sigs.k8s.io/docs/user/loadbalancer
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.
Yes, MetalLB handles the LoadBalancer services. I took these instructions almost verbatim from the official CAPI quickstart (check the KubeVirt tabs).
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.
To allow using a LoadBalancer service, we can’t use the kind’s default CNI (kindnet), but we’ll need to install another CNI, like Calico.
Nit: so that doc is simply not true, because metallb is doing the LoadBalancer service job. I guess metallb does not work with kindnet and that may be the reason at the end.
Feel free to resolve here, I'm okay with that. However, might be good to clarify the docs :-)
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.
I haven't looked into this in depth as my focus here is to contribute a KubeVirt-based dev workflow. IIUC, the need to swap the default CNI with Calico is due to the fact that there is some conflict between the default CNI and MetalLB.
Please feel free to look into this and open a PR to fix the quickstart if you find a mistake there.
c887629
to
e51ef64
Compare
New changes are detected. LGTM label has been removed. |
56bb5e7
to
fe92230
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.
Just some comments on the doc.
Great work on the bash scripts!
Signed-off-by: Johanan Liebermann <[email protected]>
Signed-off-by: Johanan Liebermann <[email protected]>
fe92230
to
eb53bc0
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
I think I've addressed all the feedback. Happy to get a final review 🙏 |
What this PR does / why we need it:
This PR adds support for local development using KubeVirt as an alternative to CAPD.
This is useful in cases where CAPD can't be used for whatever reason, with one example being developing Ignition-related features (since Ignition runs in early boot and therefore can't be containerized easily).
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged): None/area devtools