Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Last reviewed 2024-12-13 UTC
Un servizio Kubernetes è un'astrazione che consente di esporre un insieme di pod come singola entità. I servizi sono componenti fondamentali per esporre e gestire le applicazioni containerizzate in un cluster Kubernetes. I servizi in questo
blueprint sono progettati in modo standardizzato in considerazione di
spazi dei nomi, identità, esposizione dei servizi e comunicazione service-to-service.
Spazi dei nomi
Ogni spazio dei nomi ha il proprio insieme di risorse, come pod, servizi e deployment. I namespace ti consentono di organizzare le tue applicazioni e di isolarle tra loro. Il blueprint utilizza gli spazi dei nomi per raggruppare i servizi in base alla loro finalità.
Ad esempio, puoi creare uno spazio dei nomi per tutti i servizi frontend e uno per i servizi di backend. Questo raggruppamento semplifica la gestione
e il controllo dell'accesso ai servizi.
Esposizione del servizio
Un servizio è esposto a internet tramite il controller GKE Gateway.
Il controller di gateway GKE crea un bilanciatore del carico utilizzando
Cloud Load Balancing
in una configurazione multi-cluster e multi-regione.
Cloud Load Balancing utilizza l'infrastruttura di rete di Google per fornire al servizio un indirizzo IP anycast che consente l'accesso a bassa latenza al servizio. L'accesso dei client al servizio avviene tramite connessioni HTTPS e le richieste HTTP dei client vengono reindirizzate a HTTPS.
Il bilanciatore del carico utilizza
Certificate Manager
per gestire i certificati pubblici. I servizi sono ulteriormente protetti da Cloud Armor
e Cloud CDN. Il seguente diagramma mostra come i servizi sono esposti a internet.
Cloud Service Mesh
Il blueprint utilizza
Cloud Service Mesh per l'autenticazione e l'autorizzazione reciproca di tutte le comunicazioni tra i servizi. Per questo deployment, Cloud Service Mesh utilizza Certificate Authority Service per emettere certificati TLS per autenticare i peer e contribuire ad assicurare che solo i client autorizzati possano accedere a un servizio. L'utilizzo di TLS reciproca (mTLS) per l'autenticazione contribuisce inoltre a garantire che tutte le comunicazioni TCP tra i servizi siano criptate in transito. Per il traffico in entrata del servizio nel mesh di servizi, il blueprint utilizza il controller GKE Gateway.
Servizi distribuiti
Un servizio distribuito è un'astrazione di un servizio Kubernetes che viene eseguito nello stesso spazio dei nomi su più cluster. Un servizio distribuito rimane disponibile anche se uno o più
cluster GKE non sono disponibili, a condizione che gli eventuali cluster in buono stato rimanenti siano
in grado di gestire il carico. Per creare un servizio distribuito su più cluster, Cloud Service Mesh fornisce connettività di livello 4 e 7 tra i servizi di un'applicazione su tutti i cluster dell'ambiente. Questa connettività consente ai servizi Kubernetes su più cluster di comportarsi come un unico servizio logico. Il traffico tra i cluster viene indirizzato a un'altra
regione solo se il traffico intraregionale non può verificarsi a causa di un errore regionale.
Identità di servizio
I servizi in esecuzione su GKE hanno identità associate. Il blueprint configura Workload Identity Federation for GKE in modo che un account di servizio Kubernetes agiti come Google Cloud account di servizio. Ogni istanza di un servizio distribuito nello stesso ambiente ha un'identità comune che semplifica la gestione delle autorizzazioni. Quando accedi alle API Google Cloud,
i servizi che vengono eseguiti come account di servizio Kubernetes si autenticano automaticamente
come Google Cloud account di servizio. Ogni servizio dispone solo delle autorizzazioni minime necessarie per il suo funzionamento.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2024-12-13 UTC."],[],[],null,["# Service architecture\n\nA Kubernetes service is an abstraction that lets you expose a set of pods as a\nsingle entity. Services are fundamental building blocks for exposing and\nmanaging containerized applications in a Kubernetes cluster. Services in this\nblueprint are architected in a standardized manner in consideration to\nnamespaces, identity, service exposure, and service-to-service communication.\n\nNamespaces\n----------\n\nEach namespace has its own set of resources, such as pods, services, and\ndeployments. Namespaces let you organize your applications and isolate them from\neach other. The blueprint uses namespaces to group services by their purpose.\nFor example, you can create a namespace for all your frontend services and a\nnamespace for your backend services. This grouping makes it easier to manage\nyour services and to control access to them.\n\nService exposure\n----------------\n\nA service is exposed to the internet through the [GKE Gateway controller](/kubernetes-engine/docs/concepts/gateway-api).\nThe GKE Gateway controller creates a load balancer using\n[Cloud Load Balancing](/load-balancing/docs/load-balancing-overview)\nin a [multi-cluster, multi-region configuration](/kubernetes-engine/docs/how-to/deploying-multi-cluster-gateways#external-gateway).\nCloud Load Balancing uses Google's network infrastructure to provide the\nservice with an [anycast IP address](/load-balancing/docs/load-balancing-overview#global_versus_regional_load_balancing)\nthat enables low-latency access to the service. Client access to the service is\ndone over HTTPS connections and client HTTP requests are redirected to HTTPS.\nThe load balancer uses\n[Certificate Manager](/certificate-manager/docs/overview)\nto manage public certificates. Services are further protected by Cloud Armour\nand Cloud CDN. The following diagram shows how services are exposed to\nthe internet.\n\nCloud Service Mesh\n------------------\n\nThe blueprint uses\n[Cloud Service Mesh](/anthos/service-mesh) for mutual\nauthentication and authorization for all communications between services. For\nthis deployment, the Cloud Service Mesh uses\n[CA Service](/service-mesh/docs/security/security-overview#ca_service)\nfor issuing [TLS certificates](/service-mesh/docs/security/security-overview#mutual_tls)\nto authenticate peers and to help ensure that only authorized clients can access\na service. Using [mutual TLS (mTLS)](https://en.wikipedia.org/wiki/Mutual_authentication#mTLS) for\nauthentication also helps ensure that all TCP communications between services\nare encrypted in transit. For service ingress traffic into the service mesh, the\nblueprint uses the GKE Gateway controller.\n\nDistributed services\n--------------------\n\nA [distributed service](https://istio.io/latest/docs/ops/deployment/deployment-models/#multiple-clusters)\nis an abstraction of a Kubernetes service that runs in the same namespace across\nmultiple clusters. A distributed service remains available even if one or more\nGKE clusters are unavailable, as long as any remaining healthy clusters are\nable to serve the load. To create a distributed service across clusters,\nCloud Service Mesh provides Layer 4 and Layer 7 connectivity between an\napplication's services on all clusters in the environment. This connectivity\nenables the Kubernetes services on multiple clusters to act as a single logical\nservice. Traffic between clusters is only routed to another\n[region](/docs/geography-and-regions#regions_and_zones) if\nintra-region traffic cannot occur because of a regional failure.\n\nService identity\n----------------\n\nServices running on GKE have identities that are associated\nwith them. The blueprint configures Workload Identity Federation for GKE to let a [Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)\nact as a [Google Cloud service account](/iam/docs/service-accounts). Each instance of a\ndistributed service within the same environment has a common identity which\nsimplifies permission management. When accessing Google Cloud APIs,\nservices that run as the Kubernetes service account automatically authenticate\nas the Google Cloud service account. Each service has only the minimal\npermissions necessary for the service to operate.\n\nWhat's next\n-----------\n\n- Read about [logging and monitoring](/architecture/blueprints/enterprise-application-blueprint/logging-monitoring) (next document in this series)."]]
