Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
El Sincronizador de configuración es un servicio de GitOps que se ofrece como parte de la edición empresarial de Google Kubernetes Engine (GKE). El Sincronizador de configuración se compila en un núcleo de código abierto y permite que los operadores de clústeres y los administradores de plataformas implementen parámetros de configuración desde una fuente de información. El servicio tiene la flexibilidad de admitir uno o varios clústeres y cualquier cantidad de repositorios por clúster o espacio de nombres. Los clústeres pueden estar en un entorno híbrido o de múltiples nubes.
El Sincronizador de configuración está disponible con una licencia de Google Kubernetes Engine (GKE) Enterprise Edition.
Beneficios del sincronizador de configuración
GitOps se considera una práctica recomendada universal para las organizaciones que administran la configuración de Kubernetes a gran escala. Los beneficios de una mayor estabilidad, mejor legibilidad, coherencia, auditoría y seguridad son comunes a todas las herramientas de GitOps. El Sincronizador de configuración forma parte de la edición Enterprise de Google Kubernetes Engine (GKE), que te brinda un conjunto de ventajas únicas:
Integración en la edición Enterprise de Google Kubernetes Engine (GKE): Los administradores de la plataforma pueden instalar el Sincronizador de configuración con unos pocos clics en la consola de Google Cloud, con Terraform o con Google Cloud CLI en cualquier clúster conectado a tu flota. El servicio está preconfigurado para funcionar con otros servicios de Google Kubernetes Engine (GKE) de edición empresarial y de Google Cloud, como Policy Controller, Workload Identity Federation for GKE y Cloud Monitoring.
Observabilidad integrada: El Sincronizador de configuración tiene un panel de observabilidad integrado en la consola de Google Cloud, que no requiere configuración adicional. Los administradores de la plataforma pueden ver el estado de su sincronización y conciliación visitando la consola de Google Cloud o usando Google Cloud CLI.
Información sobre el Sincronizador de configuración
En el siguiente diagrama, se muestra una descripción general de cómo los equipos pueden sincronizar sus clústeres en un solo repositorio raíz (administrado por un administrador) y varios repositorios de espacios de nombres (administrados por los operadores de la aplicación):
Un administrador central administra la infraestructura centralizada de la organización y aplica políticas en el clúster y en todos los espacios de nombres de la organización. Los operadores de la aplicación, que son responsables de administrar las implementaciones en vivo, aplican configurations a las aplicaciones en los espacios de nombres en los que operan.
Configura clústeres
El Sincronizador de configuración te permite crear un conjunto común de parámetros de configuración y políticas, como Restricciones de Policy Controller, y aplicarlos de forma coherente en clústeres registrados y conectados en una flota desde una única fuente de información.
En lugar de ejecutar repetidas veces el comando kubectl apply de forma manual, puedes organizar la implementación de los cambios de configuración en flotas de clústeres a través de herramientas de estilo GitOps. Para obtener más información, consulta Lanzamientos seguros con el Sincronizador de configuración.
Si bien este y otros instructivos usan un repositorio de Git como fuente de información, también es posible usar una imagen de OCI o un gráfico de Helm.
Configurar espacios de nombres
La configuración de espacios de nombres con el Sincronizador de configuración te brinda las siguientes funciones:
Puedes aprovisionar espacios de nombres de Kubernetes de forma coherente con políticas de alcance de espacio de nombres, como funciones de RBAC, en clústeres registrados y conectados. Las políticas con alcance de espacio de nombres facilitan la implementación y la administración de multiusuarios dentro de los clústeres.
Aplica políticas a varios espacios de nombres relacionados, sin duplicar los archivos de configuración y con la capacidad de anular o extender uno de estos archivos para un espacio de nombres o conjunto de espacios de nombres determinados, lo que facilita la aplicación de políticas coherentes en las instancias.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2024-11-21 (UTC)"],[],[],null,["# Config Sync overview\n\nThis page provides a high-level explanation of Config Sync and its benefits.\n\nConfig Sync can help you to simplify management of Kubernetes configuration objects.\nYou can use Config Sync to centralize your configuration files in a single\n, such as a Git repository, which helps to ensure consistency and eliminate\nconfiguration drift.\n\nThis page is for Operators who want to\nimplement [GitOps](https://opengitops.dev/) tools to centralize configuration management for their teams.\nTo learn more about common roles and\nexample tasks that we reference in Google Cloud content, see\n[Common GKE user roles and tasks](/kubernetes-engine/enterprise/docs/concepts/roles-tasks).\n\nPricing\n-------\n\nConfig Sync requires a Google Kubernetes Engine (GKE) Enterprise edition license.\n\nConfig Sync benefits\n--------------------\n\nConfig Sync is a GitOps service for platform administrators that\ncentralizes configuration management by letting teams sync resources across\nclusters or namespaces from a single source of truth.\n\nGitOps is considered a universal best\npractice for organizations managing Kubernetes configuration at scale. The\nbenefits of improved stability, better readability, consistency, audit and\nsecurity are common to all GitOps tools. Config Sync is a part of\nGoogle Kubernetes Engine (GKE) Enterprise edition, which provides you with a set of unique advantages:\n\n- **Integrated with Google Kubernetes Engine (GKE) Enterprise edition**: platform admins can install Config Sync using a few clicks in the Google Cloud console, using Terraform, or by using Google Cloud CLI on any cluster connected to your fleet. The service is pre-configured to work with other Google Kubernetes Engine (GKE) Enterprise edition and Google Cloud services like Policy Controller, Workload Identity Federation for GKE and Cloud Monitoring.\n- **Built-in observability**: Config Sync has an observability dashboard that is built into the Google Cloud console, requiring no additional setup. Platform administrators can view the state of their synchronization and reconciliation by visiting the Google Cloud console or by using the Google Cloud CLI.\n- **Multi-cloud and hybrid support** : Config Sync is tested across several cloud providers and in hybrid environments prior to every GA release. To view the support matrix, see [Google Kubernetes Engine (GKE) Enterprise edition version and upgrade support](/anthos/docs/version-and-upgrade-support).\n\nHow Config Sync works\n---------------------\n\nThe following diagram shows you an overview of how teams might sync their\nclusters to a single root repository (managed by an admin) and multiple\nnamespace repositories (managed by application operators):\n\nA central administrator manages the centralized\ninfrastructure for the organization and enforces policies on the cluster and on\nall namespaces in the organization. The application operators, who are\nresponsible for managing live deployments, apply\n[configurations](/kubernetes-engine/enterprise/config-sync/docs/concepts/configs) to the applications in the\nnamespaces that they work on.\n\n### Configuring clusters\n\nConfig Sync lets you create a common set of configuration and policies, such as\n[Policy Controller constraints](/kubernetes-engine/enterprise/policy-controller/docs/overview#constraints),\nand consistently apply them across [registered](/anthos/multicluster-management/connect/registering-a-cluster) and\n[connected](/anthos/multicluster-management/connect/overview)\nclusters from a single source of truth.\n\nInstead of repeatedly running the `kubectl apply` command manually, you can\norchestrate deployment of configuration changes to fleets of clusters through\nGitOps-style tools. For more information, see\n[Safe rollouts with Config Sync](/kubernetes-engine/enterprise/config-sync/docs/tutorials/safe-rollouts-with-config-sync).\nWhile this and other tutorials use a Git repository as the source of truth, it's\nalso possible to use an\n[OCI image](/kubernetes-engine/enterprise/config-sync/docs/how-to/sync-oci-artifacts-from-artifact-registry)\nor [Helm chart](/kubernetes-engine/enterprise/config-sync/docs/how-to/sync-helm-charts-from-artifact-registry).\n\n### Configuring namespaces\n\nConfiguring namespaces with Config Sync provides you with the following\ncapabilities:\n\n- You can consistently provision Kubernetes namespaces with namespace-scoped policies, such as [RBAC roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), across registered and connected clusters. Namespace-scoped policies make it easier to implement and manage [multi-tenancy](/kubernetes-engine/docs/best-practices/enterprise-multitenancy) within your clusters.\n- Apply policies to multiple related namespaces, without duplicating configs, and with the ability to override or extend a config for a given namespace or set of namespaces, making it easier to apply consistent policies across tenants.\n\nWhat's next\n-----------\n\n- [Get started with Config Sync](/kubernetes-engine/enterprise/config-sync/docs/tutorials/config-sync-multi-repo)\n- [Review GitOps best practices](/kubernetes-engine/enterprise/config-sync/docs/concepts/gitops-best-practices)"]]
