Skip to content
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

automation: Optimize cluster-up time #2

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

ormergi
Copy link
Contributor

@ormergi ormergi commented Feb 28, 2024

Rebased on #1 (first two commits)

Creating cluster takes may take long time, about 10 minutes (depends on connection).
The most time consuming operations is pulling cluster components images
(e.g.: Kubevirt, Multus) and building OVN-Kubernetes images.
Every time the cluster is deleted, all images are discarded and has to be pulled
again next time the cluster is created.

This PR setup a local registry that serves will serve as a cache for the cluster components images.

  • The local registry data is backed by a container volume therefore all images are
    persisted and can be reused next time the cluster is created.

This PR also:

  • Deploy OVN-Kubernetes image [1] instead of building it from sources.
  • Deploy Kubevirt and Multus outside kind.sh script in a way all images are persisted in the local registry.

With this PR changes cluster-up time is reduced to about 4 minutes.

[1] https://github.com/ovn-org/ovn-kubernetes/pkgs/container/ovn-kubernetes%2Fovn-kube-f

@ormergi ormergi marked this pull request as draft February 28, 2024 11:06
@ormergi ormergi force-pushed the cluster-up-opt branch 4 times, most recently from 06dcec8 to ebfc4ad Compare March 3, 2024 12:02
ormergi added 3 commits March 4, 2024 11:05
Creating cluster takes may take long time (10 minutes, depends on connection).
The most time consuming operations is pulling cluster components images
(e.g.: Kubevirt, Multus) and building OVN-k8s image.
Every time the cluster is deleted, all images are discarded and has to be pulled
again next time the cluster is created.

Setup a local registry that will serve as a cache for the cluster components
images.

The local registry data is backed by a container volume therefore all images are
persisted and will be used next time the cluster is created.

'KIND_LOCAL_REGISTRY_NAME' enviroment variable is set to make 'kind.sh' realize
local registry exist and work with it.
'local-kind-registry' parameter is set to make 'kind.sh' configure the cluster
to use the local registry.

Signed-off-by: Or Mergi <[email protected]>
By default, 'kind.sh' script build ovn-k8s container images from sources and deploy
ovn-k8s in the cluster.
Buiding ovn-k8s from sources takes time and has some less common prequisites
(e.g.: Jinja, templating tool).

Use OVN-Kubernetes image that is provided by ovn-org/ovn-kubernetes repo [1]
instead of building it from sources.

The image is pulled (to the local container runtime registry) to enable 'kind.sh'
script detect its digest and use it in ovn-k8s manifests, then the image is
pushed to the tests local registery to have it persisted.

[1] https://github.com/ovn-org/ovn-kubernetes/pkgs/container/ovn-kubernetes%2Fovn-kube-f

Signed-off-by: Or Mergi <[email protected]>
'kind.sh' script enable deploying Muluts, but there is no control which images
will be used, and its not possilbe to use chached images.
Once the cluster is deleted the image is discarded and pulled again next time the
cluster is created, which is wasteful.

Deploy Multus outside 'kind.sh' script, pull the images before creating the
cluster and store them in the the local registry.
Since the local registry data is backed by a container volume, all images are
persisted and will be reused next time the cluster is created.

Multus manifest is patched to use the local image tag, stored at the local
registry.

Export waiting for Kubevirt ready logic to enable deploying Multus & Kubevirt in
parallel, optimizing Multus & Kubevirt deployment time.

Signed-off-by: Or Mergi <[email protected]>
@ormergi ormergi mentioned this pull request Mar 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant