[[["์ดํดํ๊ธฐ ์ฌ์","easyToUnderstand","thumb-up"],["๋ฌธ์ ๊ฐ ํด๊ฒฐ๋จ","solvedMyProblem","thumb-up"],["๊ธฐํ","otherUp","thumb-up"]],[["์ดํดํ๊ธฐ ์ด๋ ค์","hardToUnderstand","thumb-down"],["์๋ชป๋ ์ ๋ณด ๋๋ ์ํ ์ฝ๋","incorrectInformationOrSampleCode","thumb-down"],["ํ์ํ ์ ๋ณด/์ํ์ด ์์","missingTheInformationSamplesINeed","thumb-down"],["๋ฒ์ญ ๋ฌธ์ ","translationIssue","thumb-down"],["๊ธฐํ","otherDown","thumb-down"]],["์ต์ข ์ ๋ฐ์ดํธ: 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)."]]
