Answers: <p>I only used Fluxcd in the past so I'm not 107% confident it will work in exactly the same way in Argos but what I needed to do was to deploy those deployments in stages. In the first stage I've deployed an operator application itself, together with its CRDs. One of the CRDs would be e.g an <code>IstioOperator</code> or <code>GitLab</code> in your case.</p>
  <p>After that stage was deployed to the cluster (especially after the CRDs got applied), there was the next stage depending on the first one, which was deploying a single manifest file like e.g.:</p>
  <pre class="lang-yaml prettyprint-override"><code>apiVersion: apps.gitlab.com/v1beta1
  kind: GitLab
  metadata:
    name: gitlab
  spec:
    chart:
      version: &quot;X.Y.Z&quot; # https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/blob/0.8.1/CHART_VERSIONS
      values:
        global:
          hosts:
            domain: example.com # use a real domain here
          ingress:
            configureCertmanager: true
        certmanager-issuer:
          email: youremail@example.com # use your real email address here
  </code></pre>
  <p>As you can see, the manifest is a simple &quot;recipe&quot; monitored by the operator application which would deploy all the required GitLab resources according to the manifest above.</p>
  <p>From my experience, the first stage is responsible for keeping the operator application installed and running on its proper version release etc. The second stage is keeping the &quot;recipe&quot; file synced and reconciling its content, in case somebody e.g. changed its values directly in the Kubernetes cluster. On the other hand, the Operator agent will take care of keeping the deployed resources right according to the &quot;recipe&quot; manifest.</p>
  <p>In general, I believe Argos needs to behave in a similar way as you can't apply <code>GitLab</code> manifest before you created the CRD defining it etc.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-02-02T15:36:31.920Z
Answers: 2023-02-02T15:36:31.920Z
Answers: Oliniusz
Body: <p>I intend to build a local Kubernetes cluster to host services in my home lab and share them with family and friends. If I'm already planning to deploy Argo CD as a GitOps solution and it'll already have a reconciliation loop for all my services, is it overkill to also use Operators for these same services? E.g. to deploy GitLab Operator through Argo CD. Would that be two tools doing the same thing, or did I get the Operator concept wrong?</p>
  
Tags: <kubernetes><argocd>
Title: Argo CD + Operators = Overkill?
UserDisplayName: donjuardo
ThreadText: # Argo CD + Operators = Overkill?
  
  (Asked by: username_0 on 2023-02-01)
  
  I intend to build a local Kubernetes cluster to host services in my home lab and share them with family and friends. If I'm already planning to deploy Argo CD as a GitOps solution and it'll already have a reconciliation loop for all my services, is it overkill to also use Operators for these same services? E.g. to deploy GitLab Operator through Argo CD. Would that be two tools doing the same thing, or did I get the Operator concept wrong?
  
  **Tags:** kubernetes, argocd
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-02-02. Score: 1
  
  I only used Fluxcd in the past so I'm not 107% confident it will work in exactly the same way in Argos but what I needed to do was to deploy those deployments in stages. In the first stage I've deployed an operator application itself, together with its CRDs. One of the CRDs would be e.g an `IstioOperator` or `GitLab` in your case.
  
  After that stage was deployed to the cluster (especially after the CRDs got applied), there was the next stage depending on the first one, which was deploying a single manifest file like e.g.:
  
  ```yaml
  apiVersion: apps.gitlab.com/v1beta1
  kind: GitLab
  metadata:
    name: gitlab
  spec:
    chart:
      version: "X.Y.Z" # https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/blob/0.8.1/CHART_VERSIONS
      values:
        global:
          hosts:
            domain: example.com # use a real domain here
          ingress:
            configureCertmanager: true
        certmanager-issuer:
          email: youremail@example.com # use your real email address here
  
  ```
  
  As you can see, the manifest is a simple "recipe" monitored by the operator application which would deploy all the required GitLab resources according to the manifest above.
  
  From my experience, the first stage is responsible for keeping the operator application installed and running on its proper version release etc. The second stage is keeping the "recipe" file synced and reconciling its content, in case somebody e.g. changed its values directly in the Kubernetes cluster. On the other hand, the Operator agent will take care of keeping the deployed resources right according to the "recipe" manifest.
  
  In general, I believe Argos needs to behave in a similar way as you can't apply `GitLab` manifest before you created the CRD defining it etc.
  
  
  ---
  
  