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

[WIP] Install argocd and kuadrant in single cluster #1

Closed
wants to merge 1 commit into from

Conversation

roivaz
Copy link
Contributor

@roivaz roivaz commented Oct 22, 2024

This PR adds the minimal setup to have a Kuadrant installation managed by argocd in a local kind cluster. ArgoCD manages itself using the app-of-apps pattern and all the Kuadrant related Applications are managed by an ApplicationSet that automatically generates them based on the paths that exist in the GitHub repo under manifests/kuadrant.

There is an outstanding issue with the installation of Istio using sail-operator, which the kuadrant-operator is not detecting. It seems to be somehow with this work Kuadrant/kuadrant-operator#944 (comment), where similar issues were detected, but right now this installation method is not working properly. I really wanted to use sail here as it is the only install method for Istio that provides upgrade funtionality using GitOps, but we might need to switch to a different one while the issue is not addressed, wdyt @maleck13 ?

Steps to bring up the environment

Issue the following commands in order

make kind-create-cluster-1
make kind-apply-argocd

Open argocd UI in a browser using the url, user and pass shown by the follwing command:

make argocd-url

@roivaz roivaz requested a review from maleck13 October 22, 2024 13:12
@roivaz roivaz self-assigned this Oct 22, 2024
@roivaz roivaz force-pushed the argocd-setup branch 4 times, most recently from 3b99bf0 to 3787efd Compare October 23, 2024 07:58
@eguzki
Copy link

eguzki commented Oct 23, 2024

There is an outstanding issue with the installation of Istio using sail-operator, which the kuadrant-operator is not detecting. It seems to be somehow with this work Kuadrant/kuadrant-operator#944 (comment), where similar issues were detected, but right now this installation method is not working properly. I really wanted to use sail here as it is the only install method for Istio that provides upgrade funtionality using GitOps, but we might need to switch to a different one while the issue is not addressed, wdyt @maleck13 ?

Yeah, kuadrant v0.11.X is not compatible with Sail operator. Reason being, new Istio CRDs deployed by the Sail operator are not known by kuadrant controller and hence it assumes Istio is not installed. Hence, external authorization is not registered in the meshconfig.

On v0.12.0, that is about to change. External authorization happens through wasm, so no need to register and configure meshconfig. It is happening in Kuadrant/kuadrant-operator#952. Once merged, kuadrant will work with the Sail operator deployed Istio version. Internal testing and onboarding of the Sail operator in development environment happens in Kuadrant/kuadrant-operator#944

project: default
source:
path: manifests/argocd-install
# repoURL: https://github.com/kuadrant/deployment
Copy link
Contributor

Choose a reason for hiding this comment

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

is that once this merges we will update this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, once the main branch has the actual code, we can point all apps to main.

@@ -0,0 +1,21 @@
apiVersion: argoproj.io/v1alpha1
Copy link
Contributor

Choose a reason for hiding this comment

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

does this also need to be setup for an OCP cluster?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, in Openshift OLM comes pre-installed. This is just needed for other k8s distributions. We could just install the operators from their manifests (or helm if available) and not use OLM entirely, but OLM provides some features that make upgrading operators a bit safer and I would definitely recommend it for production. For example it checks that all your existing custom resources are compatible with the CRDs that is about to update, which is a crucial step to avoid problems.

argocd.argoproj.io/sync-wave: "-1"
spec:
sourceType: grpc
image: quay.io/kuadrant/kuadrant-operator-catalog:v0.11.0
Copy link
Contributor

Choose a reason for hiding this comment

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

not something needed to be solved right now, but but I wonder how we might keep this in sync with each release of kuadrant itself. Ideally it would always install the latest released version

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I assume that once a stable release is hit, there would be a stable channel that just keeps adding new releases when they are out. If the subscription is set to Automatic new releases would be installed as soon as they are available in the catalog.
A different concern is to keep gateway-api CRDs and istio in sync. That would require custom logic. If kuadrant-operator provided somehow the version constraints (maybe a configmap?) for Istio and gateway-api we could create a Config Management Plugin for argocd to dynamically determine the versions to install. Same for envoy-gateway.
Just throwing out the idea, haven't really given it much thought ...

@maleck13
Copy link
Contributor

hit this error when running the first command

tmp/cloud-provider-kind.pid: No such file or directory
make: *** [start-cloud-provider-kind] Error 1
cbrookes1-mac:deployment maleck13$ hack/run-background-process.sh: line 18: tmp/cloud-provider-kind.log: No such file or directory

@roivaz
Copy link
Contributor Author

roivaz commented Oct 24, 2024

Aps, the tmp folder was missing, should work now:

start-cloud-provider-kind: tmp

Signed-off-by: Roi Vazquez <[email protected]>
@maleck13
Copy link
Contributor

maleck13 commented Oct 25, 2024

@roivaz got much further this time but still failed on final step

make argocd-url
	URL: 	https://
	user: 	admin
        pass:  xxxxx

@roivaz
Copy link
Contributor Author

roivaz commented Oct 28, 2024

@maleck13 testing it with @david-martin he saw that the cloud-provider-kind, which is kind's implementation of a cloud provider to provision local LoadBalancer type Services, is not working properly on macos. I am going to change it and use metallb instead.

@roivaz
Copy link
Contributor Author

roivaz commented Oct 29, 2024

Closing this in favor of #2

@roivaz roivaz closed this Oct 29, 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.

3 participants