Este artículo presenta las ventajas, la arquitectura y el principio de funcionamiento de Argo CD, y demuestra sus funciones a través de un ejemplo simple. Por ejemplo, después de modificar el contenido del almacén de Git, la actualización puede activarse automáticamente. Event Source and Trigger también se puede usar para lograr requisitos de implementación más automatizados. Al implementar recursos de Kubernetes, Argo CD también es compatible con Kustomize, Helm, Ksonnet y otros métodos de descripción de recursos, incluidos otros métodos de uso más avanzados.

Argo CD es una herramienta de entrega continua (CD) que utiliza Kubernetes como infraestructura y sigue el concepto declarativo de GitOps. Es compatible con una variedad de herramientas de administración de configuración, incluidas ksonnet/jsonnet, kustomize y Helm. Es muy simple de configurar y usar, y viene con una interfaz visual fácil de usar.

De acuerdo con la definición oficial, Argo CD se implementa como un controlador de Kubernetes, que monitorea continuamente la aplicación en ejecución y compara el estado real actual con el estado esperado declarado en el repositorio de Git. Si el estado real no cumple con el estado esperado, Actualice el estado real de la aplicación para que coincida con el estado deseado.

Antes de comenzar oficialmente a interpretar y usar Argo CD, debemos averiguar por qué necesitamos Argo CD. ¿Qué valor puede aportarnos?

1. Flujo de trabajo de CD tradicional

La mayoría de las herramientas de CI/CD utilizan actualmente un modelo de implementación basado en Push, como Jenkins, CircleCI, etc. Este modo generalmente ejecuta un comando (como kubectl) para implementar la aplicación en el entorno de destino una vez que se completa la canalización de CI.

Los defectos de este modelo de CD son obvios:

Necesita instalar y configurar herramientas adicionales (como kubectl);
Requiere que Kubernetes lo autorice;
Se requiere autorización de la plataforma en la nube;
No se puede detectar el estado de implementación. También es imposible percibir la desviación entre el estado deseado y el estado real, y se necesitan esquemas adicionales para asegurar la consistencia.

2. Flujo de trabajo de CD usando Argo CD

Al igual que las herramientas tradicionales de CI/CD, no hay diferencia en la parte de CI, que no es más que probar, construir espejos, empujar espejos, modificar listas de implementación, etc. El foco está en la sección de CD.

Argo CD se implementará en el clúster de Kubernetes, utilizando el modo de implementación basado en extracción, que monitoreará periódicamente el estado real de la aplicación y también extraerá periódicamente la lista de configuración en el repositorio de Git y comparará el estado real con el esperado. Se compara el estado y, si el estado real no coincide con el estado deseado, el estado real de la aplicación se actualiza para que coincida con el estado deseado.

Ya sea que se active el archivo de orquestación de K8s para que se actualice a través de la canalización de CI, o si el ingeniero de DevOps modifica directamente el archivo de orquestación de K8s, Argo CD extraerá automáticamente la configuración más reciente y la aplicará al clúster de K8s.

El resultado final es una canalización de CI y CD aislada, la canalización de CI suele estar controlada por el personal de I+D (o el equipo de DevOps) y la canalización de CD suele estar controlada por el administrador del clúster (o el equipo de DevOps).

3. Ventajas de Argo CD

Echemos un vistazo a las ventajas obvias de Argo CD en comparación con las herramientas de CD tradicionales.

3.1 Git como única fuente de verdad para las aplicaciones

Todas las configuraciones declarativas de K8 se almacenan en Git, y Git se usa como la única fuente de verdad para la aplicación. Ya no necesitamos actualizar manualmente la aplicación (como ejecutar scripts, ejecutar kubectl apply o comandos de instalación de helm), solo a través de un interfaz unificada (Git) para actualizar la aplicación.

Además, Argo CD no solo monitoreará el estado esperado declarado en el almacén de Git, sino que también monitoreará el estado real de la aplicación en el clúster y comparará los dos estados. Siempre que el estado real no cumpla con el estado esperado, el estado real será corregido y el estado esperado unánimemente. Entonces, incluso si alguien modifica el estado de la aplicación en el clúster (como cambiar la cantidad de réplicas), Argo CD aún la restaurará al estado anterior. Esto realmente garantiza que los archivos de orquestación en el repositorio de Git se puedan usar como la única fuente de verdad para el estado del clúster.

Por supuesto, a veces necesitamos actualizar rápidamente la aplicación y depurarla. Todavía es un poco lento activar la actualización a través de Git. Esto no es imposible. Podemos modificar la configuración de Argo CD para que no se sobrescriba o retroceda. la parte modificada manualmente En su lugar, las alertas se envían directamente para recordar a los administradores que no olviden enviar actualizaciones al repositorio de Git.

3.2 Retroceso rápido

Argo CD extraerá periódicamente la última configuración y la aplicará al clúster. Una vez que la última configuración hace que la aplicación falle (por ejemplo, la aplicación no se inicia), podemos restaurar rápidamente el estado de la aplicación al último estado disponible a través de Git History .

kubectl delete Si tiene varios clústeres de Kubernetes que usan el mismo almacén de Git, esta ventaja será más obvia, porque no necesita retroceder manualmente o esperar en diferentes clústeres helm uninstall , solo necesita retroceder el almacén de Git a la última versión disponible. , Argo CD se sincronizará automáticamente.

3.3 Recuperación ante desastres del clúster

Si su clúster KubeSphere[4] en Qingyun[3] Beijing District 3 falla y no se puede recuperar en un período corto de tiempo, puede crear directamente un nuevo clúster y luego conectar Argo CD al almacén de Git, que contiene todos los recursos. de todo el clúster Declaración de configuración. Eventualmente, el estado del nuevo clúster será consistente con el estado del antiguo clúster sin ninguna intervención manual.

3.4 Usando Git para implementar el control de acceso

Por lo general, en un entorno de producción, no todos pueden acceder al clúster de Kubernetes.Si el acceso se controla directamente en el clúster de Kubernetes, se deben usar reglas RBAC complejas. Es relativamente simple controlar los permisos en el almacén de Git. Por ejemplo, todos (equipo de DevOps, equipo de operación y mantenimiento, equipo de I+D, etc.) pueden enviar solicitudes de extracción al almacén, pero solo los ingenieros senior pueden fusionar solicitudes de extracción.

La ventaja de esto es que, a excepción del administrador del clúster y algunas personas, otras personas ya no necesitan acceder directamente al clúster de Kubernetes, solo necesitan acceder al repositorio de Git. Lo mismo ocurre con los programas. Las herramientas de CI como Jenkins ya no necesitan permiso para acceder a Kubernetes, porque solo Argo CD puede aplicar la lista de configuración, y Argo CD se implementó en el clúster de Kubernetes y los permisos de acceso necesarios se configuraron correctamente. , por lo que no es necesario proporcionar certificados de acceso a nadie ni herramientas ajenas al clúster, lo que puede proporcionar mayores garantías de seguridad.

3.5 Ampliación de Kubernetes

Aunque Argo CD se puede implementar en un clúster de Kubernetes y disfrutar de los beneficios que brinda Kubernetes, ¡esto no es exclusivo de Argo CD! ¿No se puede implementar Jenkins también en Kubernetes? ¿Hay algo especial en el CD de Argo?

Por supuesto que lo hay, sin este diamante, no me atrevería a hacer este trabajo de porcelana. Argo CD utiliza inteligentemente muchas funciones en el clúster de Kubernetes para lograr sus propios objetivos. Por ejemplo, todos los recursos se almacenan en el clúster de Etcd, usando el control del monitor de Kubernetes para monitorear el estado real de la aplicación y compararlo con el estado deseado, y así sucesivamente.

El beneficio más intuitivo de hacer esto es que puede percibir el estado de implementación de la aplicación en tiempo real . Por ejemplo, cuando actualiza la versión de la imagen en la lista de configuración en el repositorio de Git, Argo CD actualizará las aplicaciones en el clúster a la última versión y puede verificar el estado de actualización en tiempo real en la interfaz visual de Argo CD (por ejemplo, ejemplo, el Pod se creó correctamente, la aplicación La aplicación se ejecuta correctamente y está en buen estado, o la aplicación falla y debe revertirse).

4. Arquitectura de CD Argo

Desde la perspectiva de la arquitectura funcional, Argo CD tiene principalmente tres componentes: API Server, Repository Server y Application Controller. Desde la perspectiva del flujo de trabajo de GitOps, hay 3 fases en total: recuperación, ajuste y presentación.

4.1 Recuperación: servidor de repositorio

La fase de recuperación clona el repositorio de Git donde reside el manifiesto de configuración declarativa de la aplicación y lo almacena en caché en el almacenamiento local. Contiene la lista de configuración nativa de Kubernetes, Helm Chart y la lista de configuración de Kustomize. El componente que realiza estas responsabilidades es el Servidor de Repositorio .

4.2 Ajuste: controlador de aplicaciones

La etapa Reconcile es la más complicada, en esta etapa se comparará la lista de configuración obtenida por el Repository ServerOutOfSync con la lista de configuración en tiempo real que refleja el estado actual del clúster, una vez que se detecta que la aplicación está en el estado, el controlador de la aplicación tomará medidas correctivas para que el estado real del clúster sea consistente con el estado deseado.

4.3 Representación -- Servidor API

La última etapa es la etapa de renderizado, que está a cargo del servidor API de Argo CD , que es esencialmente un servidor gRPC/REST que proporciona una interfaz visual sin estado para mostrar los resultados de la etapa de ajuste. También proporciona las siguientes funciones:

Gestión de aplicaciones e informes de estado;
Llamar a operaciones relacionadas con la aplicación (como sincronización, reversión y operaciones definidas por el usuario);
Gestión de credenciales de clúster y almacén de Git (almacenadas en forma de Kubernetes Secret);
Proporcionar autenticación y delegación de autorización para componentes de autenticación externos;
mejoras de RBAC;
Oyente/reenviador para eventos de webhook de Git.

5. Implementar el CD de Argo

Argo CD tiene dos modos de implementación diferentes:

5.1 Multiusuario

El modo de implementación más comúnmente utilizado para Argo CD es el de múltiples inquilinos, que generalmente se adopta si la organización contiene varios equipos de desarrollo de aplicaciones. Los usuarios pueden acceder a Argo CD mediante la interfaz visual o la CLI de argocd. La CLI de argocd primero debe tener argocd login <server-host> acceso al CD de Argo.

$ argocd login SERVER [flags] 

## Iniciar sesión en Argo CD usando un nombre de usuario y contraseña 
$ argocd login cd.argoproj.io 

## Iniciar sesión en Argo CD usando SSO 
$ argocd login cd.argoproj.io --sso 

## Configurar acceso directo utilizando el servidor API de Kubernetes 
$ argocd login cd.argoproj.io --core

El modo multiinquilino proporciona dos manifiestos de configuración diferentes:

no muy disponible

Recomendado para entornos de prueba y demostración, no recomendado para entornos de producción. Hay dos manifiestos de implementación para elegir:

install.yaml[5]: un manifiesto de implementación estándar de Argo CD, con privilegios de administrador de clúster. Las aplicaciones se pueden implementar utilizando Argo CD dentro del clúster en el que se ejecuta o en un clúster externo con credenciales para acceder al clúster externo.
namespace-install.yaml[6]: este manifiesto de implementación solo requiere permisos de nivel de espacio de nombres. Si no necesita implementar la aplicación en el clúster donde se ejecuta Argo CD, solo necesita implementar la aplicación en el clúster externo a través de las credenciales para acceder al clúster externo, se recomienda usar esta lista de verificación de implementación. Un giro más, puede implementar instancias de Argo CD separadas para cada equipo, pero cada instancia de Argo CD puede usar credenciales especiales (por ejemplo) argocd cluster add <CONTEXT> --in-cluster --namespace <YOUR NAMESPACE>para implementar la aplicación en el mismo clúster (es decir, kubernetes.svc.defaultclúster interno).

⚠️Nota: El CRD de Argo CD no está incluido en la lista de configuración de namespace-install.yaml y debe implementarse por separado con anticipación: kubectl apply -k https://github.com/argoproj/argo-cd/manifests/crds\?ref\=stable.

alta disponibilidad

Los componentes incluidos en la lista de implementación que no son de alta disponibilidad son los mismos, pero las capacidades de resiliencia y alta disponibilidad están mejoradas, y se recomienda su uso en un entorno de producción.

ha/install.yaml[7]: el mismo contenido que install.yaml mencionado anteriormente, pero configura varias copias de los componentes relevantes.
ha/namespace-install.yaml[8]: igual que namespace-install.yaml mencionado anteriormente, pero configura varias copias de los componentes relevantes.

5.2 Núcleo

El modo Core es el modo de implementación más simplificado. No incluye el servidor API ni la interfaz visual, y solo implementa una versión ligera (sin alta disponibilidad) de cada componente.

Los usuarios necesitan acceso a Kubernetes para administrar Argo CD, por lo que la CLI de argocd debe configurarse con el siguiente comando:

$ kubectl config set-context --current --namespace=argocd # cambiar el contexto de kube actual al espacio de nombres argocd 
$ argocd login --core

argocd admin dashboard La interfaz visual también se puede habilitar manualmente usando el comando .

La lista de configuración específica se encuentra en core-install.yaml[9] en el repositorio de Git.

Además de implementarse directamente a través de manifiestos nativos, Argo CD también admite herramientas adicionales de gestión de manifiestos.

5.3 Personalizar

La lista de configuración de CD de Argo también se puede implementar usando Kustomize. Se recomienda llamar a la lista de configuración a través de una URL remota y usar el parche para configurar las opciones personalizadas.

apiVersion: kustomize.config.k8s.io/v1beta1 
tipo: espacio de nombres de personalización : 
recursos 

argocd : 
- https://raw.githubusercontent.com/argoproj/argo-cd/v2.0.4/manifests/ha/install.yaml

5.4 Timón

El Helm Chart para Argo CD es mantenido actualmente por la comunidad,

Dirección: https://github.com/argoproj/argo-helm/tree/master/charts/argo-cd[10].

A continuación se muestra el proceso de implementación. Si no hay un entorno de Kubernetes listo para usar, puede crear uno rápidamente a través del servicio de clúster administrado de KubeSphere Cloud [11]. El tiempo de prueba gratuito es de 2 horas. Después de la expiración, el clúster se eliminará automáticamente y se podrá reconstruir un número ilimitado de veces. .

El proceso de creación de un clúster de Kubernetes es muy simple. Primero, regístrese e inicie sesión en la consola https://kubesphere.cloud[12], luego haga clic en Servicio de clúster administrado para abrir la página Nuevo clúster de Kubernetes , complete el nombre del clúster, seleccione el entorno operativo y haga clic en el menú Nuevo para crear un clúster.

Después de unos segundos, se creará y se mostrará la información básica del clúster. Después de descargar kubeconfig, puede usar kubectl para acceder al clúster.

A continuación, comience a implementar Argo CD:

$ kubectl crear espacio de nombres argocd 
$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Ver los resultados de la implementación:

$ kubectl -n argocd get pod 
argocd-applicationset-controller-69879c47c-pcbkg 1/1 En ejecución 0 26m 
argocd-notifications-controller-6b4b74d8d8-s7mrz 1/1 En ejecución 0 26m 
argocd-redis-65596bf87-2hzcv 1/1 En ejecución 0 2 6 metros 
argocd-dex-server-78c9764884-6lcww 1/1 En ejecución 0 26m 
argocd-repo-server-657d46f8b-87rzq 1/1 En ejecución 0 26m 
argocd-application-controller-0 1/1 En ejecución 0 26m 
argocd-server-6b48df79dd-b7bkw 1/1 Corriendo 0 26m

6. Acceder al CD de Argo

Una vez completada la implementación, puede argocd-server acceder a la interfaz visual a través de Servicio.

$ kubectl -n argocd get svc                                                              
NOMBRE TIPO CLÚSTER-IP IP-EXTERNA PUERTO(S) EDAD 
argocd-applicationset-controller ClusterIP 10.105.250.212 <ninguno> 7000/TCP,8080/TCP 5m10s 
argocd-dex-server ClusterIP 10.108.88.97 < ninguno> 5556/TCP,5557/TCP,5558/TCP 5m10s 
argocd-metrics ClusterIP 10.103.11.245 <ninguno> 8082/TCP 5m10s  
argocd-notifications-controller-metrics ClusterIP 10.98.136.200 <ninguno> 9001/TCP 5m9s
argocd-redis ClusterIP 10.110.151.108 <ninguno> 6379/TCP 5m9s 
argocd-repo-server ClusterIP 10.109.131.197 <ninguno> 8081/TCP,8084/TCP 5m9s 
argocd-server ClusterIP 10.98.23.255 <ninguno> 80 /TCP,443/ TCP 5m9s 
argocd-server-metrics ClusterIP 10.103.184.121 <ninguno> 8083/TCP 5m8s

Si su cliente puede conectarse directamente a la IP del servicio, se puede acceder directamente a través de la IP del clúster de argocd-server. O se puede acceder directamente a través del reenvío de puerto local:

$ kubectl port-forward svc/argocd-server -n argocd 8080:443 
Reenvío desde 127.0.0.1:8080 -> 8080 
Reenvío desde [::1]:8080 -> 8080

La contraseña inicial se almacena en Secret en texto sin formato argocd-initial-admin-secret , y se puede obtener a través del siguiente comando:

$ kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; eco

También puede modificar la contraseña de inicio de sesión con el siguiente comando:

$ argocd actualización-contraseña de cuenta --administrador de cuenta --contraseña-actual xxxx --nueva-contraseña xxxx

La interfaz después de iniciar sesión:

7. El concepto central de Argo CD

Antes de comenzar oficialmente a usar Argo CD, hay dos conceptos básicos que deben entenderse.

7.1 Aplicación de CD de Argo

La aplicación en Argo CD define el origen (Origen) y el destino (Destino) de los recursos de Kubernetes. El origen se refiere a dónde reside el manifiesto de configuración de recursos de Kubernetes en el repositorio de Git, mientras que el destino se refiere a dónde se implementa el recurso en el clúster de Kubernetes.

El origen puede ser un manifiesto de configuración nativo de Kubernetes, o un manifiesto de implementación de Helm Chart o Kustomize.

El objetivo especifica la URL del servidor API en el clúster de Kubernetes y el espacio de nombres asociado, de modo que Argo CD sepa en qué espacio de nombres de qué clúster implementar la aplicación.

En resumen, la responsabilidad de la aplicación es conectar el espacio de nombres en el clúster de Kubernetes de destino con el estado deseado declarado en el repositorio de Git .

Ejemplo de manifiesto de configuración para la aplicación:

Si hay varios equipos y cada equipo mantiene una gran cantidad de aplicaciones, es necesario utilizar otro concepto de Argo CD: Proyecto .

7.2 Proyecto CD Argo

Los proyectos en Argo CD se pueden usar para agrupar aplicaciones, y diferentes equipos usan diferentes proyectos, logrando así un entorno de múltiples inquilinos. El proyecto también admite un control de acceso más detallado:

Limite el contenido de implementación (repositorios Git confiables);
Limite el entorno de implementación de destino (clúster de destino y espacio de nombres);
Limite el tipo de recursos implementados (como RBAC, CRD, DaemonSets, NetworkPolicy, etc.);
Defina los roles del proyecto y proporcione RBAC para la aplicación (vinculado con el grupo OIDC o el token JWT).

8. Demostración de demostración

Finalmente, se utiliza un ejemplo simple para mostrar el flujo de trabajo de Argo CD.

8.1 Preparar el repositorio de Git

Cree un proyecto en GitHub, denominado argocd-lab[13], y configure el almacén como un almacén público para facilitar los experimentos. Cree un nuevo directorio de desarrollo en el almacén y cree dos listas de configuración YAML en el directorio, a saber deployment.yaml y service.yaml.

El contenido de la lista de configuración es el siguiente:

# deployment.yaml 
apiVersion: apps/v1 
tipo: 
Metadatos de implementación: 
  nombre: 
especificación de mi aplicación: 
  selector: etiquetas 
    de coincidencia: 
      aplicación: 
  réplicas de mi aplicación: 2 
  plantilla: 
    metadatos: 
      etiquetas: 
        aplicación: 
    especificación de mi aplicación: 
      contenedores: 
      - nombre: 
        imagen de mi aplicación: nginx: puertos más recientes 
        : 
        - containerPort: 80 
        
# service.yaml 
apiVersion: v1 
tipo: 
Metadatos del servicio: 
  nombre: myapp-service 
spec: 
  selector: 
    app: myapp 
  ports:  
  - puerto: 80
    protocol: TCP
    puerto de destino: 80

A continuación, cree una lista de configuración de la aplicación en el directorio raíz del almacén:

# application.yaml 
apiVersion: argoproj.io/v1alpha1 
tipo: 
metadatos de la aplicación: 
  nombre: myapp-argo-application 
  namespace: argocd 
spec: 
  project: default 

  source: 
    repoURL: https://github.com/yangchuansheng/argocd-lab.git 
    targetRevision: HEAD 
    ruta: dev 
  destino: 
    servidor: https://kubernetes.default.svc 
    espacio de nombres: myapp 

  syncPolicy: 
    syncOptions: 
    - CreateNamespace=true 

    automatizado: 
      selfHeal: true 
      prune: true

Explicación de parámetros:

syncPolicy : especifica la frecuencia y la política de sincronización automática. Si no se configura, la sincronización debe activarse manualmente.
syncOptions : define el método de sincronización.
- CreateNamespace=true : si el espacio de nombres no existe, se creará automáticamente.
Automatizado : Medidas sincrónicas que se tomarán cuando se detecte que el estado real no es consistente con el estado esperado.
- selfHeal : sincroniza automáticamente cuando el estado del siglo del clúster no cumple con el estado deseado.
- podar : cuando se sincroniza automáticamente, elimina los recursos que no existen en Git.

De forma predeterminada, Argo CD detectará el repositorio de Git cada 3 minutosOutOfSync para determinar si el estado real de la aplicación es coherente con el estado esperado declarado en Git. De lo contrario, el estado se convertirá a . De forma predeterminada, no se activan actualizaciones a menos que syncPolicy se configure la sincronización automática.

Si cree que la sincronización periódica es demasiado lenta, también puede configurar un Webhook para activar la sincronización inmediatamente cuando se actualice el repositorio de Git. El método de uso específico se incluirá en el tutorial de seguimiento, por lo que no entraré en detalles en este artículo.

8.2 Crear aplicación

Ahora todo está listo, simplemente cree la aplicación a través de application.yaml.

$ kubectl apply -f application.yaml 
application.argoproj.io/myapp-argo-application created

En la interfaz visual de Argo CD, puede ver que la aplicación se ha creado correctamente.

Haga clic para ver los detalles de sincronización de la aplicación y el estado de salud de cada recurso.

Si actualiza la imagen en deployment.yaml, Argo CD detectará automáticamente la actualización en el repositorio de Git y actualizará la imagen de la implementación en el clúster a la última versión de imagen establecida en el repositorio de Git.

KubeSphere también ha proporcionado una solución de CD basada en GitOps desde 3.3.0[14]. Argo CD se presenta como el backend de CD, y la interfaz visual es más interesante. Los socios interesados pueden intentar usar KubeSphere para crear una aplicación de administración.

Nueve Resumen

Al implementar recursos de Kubernetes, Argo CD también admite métodos de descripción de recursos como Kustomize, Helm y Ksonnet, y otros métodos de uso más avanzados se presentarán uno por uno en tutoriales posteriores, así que permanezca atento.

referencias:

[1] Introducción a GitOps: https://icloudnative.io/

[2] Introducción a GitOps: https://icloudnative.io/

[3] Qingyun: https://www.qingcloud.com/

[4] KubeSphere: https://kubesphere.com.cn

[5]instalar.yaml: https://github.com/argoproj/argo-cd/blob/master/manifests/install.yaml

[6]instalación de espacio de nombres.yaml: https://github.com/argoproj/argo-cd/blob/master/manifests/instalación de espacio de nombres.yaml

[7]ha/install.yaml: https://github.com/argoproj/argo-cd/blob/master/manifests/ha/install.yaml

[8]ha/namespace-install.yaml: https://github.com/argoproj/argo-cd/blob/master/manifests/ha/namespace-install.yaml

[9]core-install.yaml: https://github.com/argoproj/argo-cd/blob/master/manifests/core-install.yaml

[10]https://github.com/argoproj/argo-helm/tree/master/charts/argo-cd: https://github.com/argoproj/argo-helm/tree/master/charts/argo-cd

[11] Servicio de clúster administrado de KubeSphere Cloud: https://kubesphere.cloud/console/resource/

[12]https://kubesphere.cloud: https://kubesphere.cloud/

[13]argocd-lab: https://github.com/yangchuansheng/argocd-lab

[14] KubeSphere comienza en 3.3.0: https://kubesphere.com.cn/news/kubesphere-3.3.0-ga-announcemen

[15] https://cloud.tencent.com/developer/article/2024541

Argo CD Tutorial detallado de introducción