Category: Kubernetes

2025
0
Kubernetes

[쿠버네티스 DevOps 구축] - OpenSearch 설치하기

목차 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 참고 https://blog.pages.kr/2844 https://opendistro.github.io/for-elasticsearch-docs/docs/security/access-control/api/#reserved-and-hidden-resources https://forum.opensearch.org/t/default-password-reset/102/10 Admin Password 변경 https://github.com/opendistro-for-elasticsearch/opendistro-build/issues/558 https://opendistro.github.io/for-elasticsearch-docs/docs/security/configuration/yaml/#internal_usersyml https://github.com/opensearch-project/helm-charts/issues/161 ✅ OpenSearch 설치# Helm Repo 추가helm repo add opensearch https://opensearch-project.github.io/helm-charts/# OpenSearch 설치helm upgrade --install opensearch \ -f ./values-opensearch.yaml opensearch/opensearch \ -n logging --create-namespace Release "opensearch" has been upgraded. Happy Helming!NAME: opensearchLAST DEPLOYED: Thu Jan 18 15:55:28 2024NAMESPACE: loggingSTATUS: deployedREVISION: 2TEST SUITE: NoneNOTES:Watch all cluster members come up. $ kubectl get pods --namespace=logging -l app.kubernetes.io/component=opensearch-cluster-master -w ✅ OpenSearch Dashboard 설치helm upgrade --install opensearch-dashboard \ -f ./values-opensearch-dashboards.yaml opensearch/opensearch-dashboards \ -n logging --create-namespace

0
Kubernetes

[쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기

목차 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 ✅ 메트릭 수집을 위한 Prometheus서비스를 올렸다고 해서 끝이 아니다! 서비스를 운용하는 입장에서는 시스템이 안정적인지 지속적으로 확인을 해야 하는데, 운영하는 서비스의 CPU 사용률, 메모리 사용률과 같은 메트릭 정보를 지속적으로 수집하는 시스템을 구축해야 합니다. 저는 대중적으로 많이 알려진 Prometheus 를 이용해 쿠버네티스에서 운영중인 서비스에 대한 메트릭 정보를 수집하려고 합니다. Helm 을 이용한 Prometheus 설치# helm repo 추가helm repo add prometheus-community https://prometheus-community.github.io/helm-charts# prometheus 설치helm upgrade --install -f ./values-prometheus.yaml prometheus prometheus-community/prometheus -n monitoring --create-namespace Release "prometheus" does not exist. Installing it now.NAME: prometheusLAST DEPLOYED: Fri Nov 15 10:11:47 2024NAMESPACE: monitoringSTATUS: deployedREVISION: 1TEST SUITE: NoneNOTES:The Prometheus server can be accessed via port 80 on the following DNS name from within your cluster:prometheus-server.monitoring.svc.cluster.localGet the Prometheus server URL by running these commands in the same shell: export POD_NAME=$(kubectl get pods --namespace monitoring -l "app.kubernetes.io/name=prometheus,app.kubernetes.io/instance=prometheus" -o jsonpath="{.items[0].metadata.name}") kubectl --namespace monitoring port-forward $POD_NAME 9090####################################################################################### WARNING: Persistence is disabled!!! You will lose your data when ########### the Server pod is terminated. ######################################################################################The Prometheus alertmanager can be accessed via port 9093 on the following DNS name from within your cluster:prometheus-alertmanager.monitoring.svc.cluster.localGet the Alertmanager URL by running these commands in the same shell: export POD_NAME=$(kubectl get pods --namespace monitoring -l "app.kubernetes.io/name=alertmanager,app.kubernetes.io/instance=prometheus" -o jsonpath="{.items[0].metadata.name}") kubectl --namespace monitoring port-forward $POD_NAME 9093####################################################################################### WARNING: Persistence is disabled!!! You will lose your data when ########### the AlertManager pod is terminated. ############################################################################################################################################################################# WARNING: Pod Security Policy has been disabled by default since ########### it deprecated after k8s 1.25+. use ########### (index .Values "prometheus-node-exporter" "rbac" ########### . "pspEnabled") with (index .Values ########### "prometheus-node-exporter" "rbac" "pspAnnotations") ########### in case you still need it. ######################################################################################The Prometheus PushGateway can be accessed via port 9091 on the following DNS name from within your cluster:prometheus-prometheus-pushgateway.monitoring.svc.cluster.localGet the PushGateway URL by running these commands in the same shell: export POD_NAME=$(kubectl get pods --namespace monitoring -l "app=prometheus-pushgateway,component=pushgateway" -o jsonpath="{.items[0].metadata.name}") kubectl --namespace monitoring port-forward $POD_NAME 9091For more information on running Prometheus, visit:https://prometheus.io/ ✅ 모니터링을 위한 Grafana메트릭 수집을 위한 Prometheus 를 설치 했는데! 단순 메트릭 정보만 있으면 운영하는 입장에서 가시적으로 와 닿지 않습니다.

0
Kubernetes

[쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기

목차 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 참고 https://kubernetes.github.io/ingress-nginx/ https://github.com/nginxinc/kubernetes-ingress https://artifacthub.io/packages/helm/ingress-nginx/ingress-nginx https://www.nginx.com/blog/guide-to-choosing-ingress-controller-part-4-nginx-ingress-controller-options/ https://kubernetes.github.io/ingress-nginx/deploy/#bare-metal-clusters Ingress Controller 설치현재 설치된 쿠버네티스에서는 Ingress 를 생성 하더라도 외부 요청을 Ingress 설정에 맞게 외부 요청을 내부 서비스로 전달해주는 Controller 가 따로 없습니다. 다시 말해, 규칙을 생성하더라도 규칙을 읽어서 적용시켜주는 모듈이 없는 상태입니다. 보통, 클라우스 서비스에서는 ALB 나 NLB 와 같은 서비스를 이용해 Ingress 정책을 읽어 Load Balancing 규칙을 적용해주는데, 개인 쿠버네티스 서비스에서는 저런 시스템을 기대하기 힘듦으로 저는 Nginx 에서 제공해주는 Ingress Controller 를 이용하려고 합니다. Helm 설치helm upgrade --install ingress-nginx ingress-nginx \ --repo https://kubernetes.github.io/ingress-nginx \ --namespace ingress-nginx --create-namespace

0
Kubernetes

[쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치

목차 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 참고 https://github.com/rancher/local-path-provisioner 🔎 로컬 쿠버네티스 동적 프로비저닝로컬 쿠버네티스 환경에서는 기본적으로 동적 PV 프로비저닝을 지원하지 않습니다. 다시 말해, 사용자가 직접 PV 를 생성한 후 PVC 에 수동으로 PV 를 연결해야 합니다. EKS 에서는 CSI 드라이버를 통해 동적 프로비저닝을 제공하는데, 로컬 환경에서 동일한 기능을 제공해주는 플러그인을 찾다가 local-path-provisioner 를 발견했습니다. 1. local-path-provisioner 설치아래 명령어를 사용해 local-path-provisioner를 설치합니다.

0
Kubernetes

[쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기

목차 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 참고 https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/ https://cocococo.tistory.com/entry/k8s-%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%82%AC%EC%9A%A9%EC%9D%84-%EC%9C%84%ED%95%9C-kubeadm-kubelet-%EB%B0%8F-kubectl-%EC%84%A4%EC%B9%98-%EB%B0%A9%EB%B2%95 https://jongsky.tistory.com/112 https://www.youtube.com/watch?v=Wr6nrBRqYYE 📝 회고Vitality 팀에 있을때 EKS 로 구축된 시스템을 운영했었습니다. 지금은 해당 팀이 해체 되면서 운영하고 있지는 않지만 그때 내부적으로 진행했던 프로젝트들의 기억을 되살리고자 포스트로 남기려고 합니다. 🤔 쿠버네티스 운영환경 선택지속적으로 쿠버네티스 환경을 운영도 하면서 공부도 하고 싶어 여러가지 환경을 검토해봤는데, EKS 는 일단 컨트롤 플레인 자체만으로도 한달에 7만원 정도가 나와 Pass (너무 비싸 😭), 로컬 PC 에 Minikube 를 이용하는 방법은 노트북을 너무 핫하게 만드는 방법이라 Pass 요즘 알리에서 미니 PC 가 싸게 풀리고 있고 시스템 초기 구입 비용 빼면 운용하는데는 매월 전기세만 내면 돼 크게 부담이 안될 것 같아 미니 PC 를 이용한 서버를 구축하기로 했습니다.

2023
0
KubernetesConfig

쿠버네티스 - ServiceAccount

목차 쿠버네티스 - Secret 쿠버네티스 - ConfigMap 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod 쿠버네티스 - Data Plane 쿠버네티스 - Control Plane Post not found: k8s/k8s 참고 https://findstar.pe.kr/2023/04/09/access-k8s-api-from-pod/ https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/ https://kubernetes.io/ko/docs/reference/access-authn-authz/service-accounts-admin/ 🔎 ServiceAccount 란? ServiceAccount 는 쿠버네티스 API 서버와 통신하고 클러스터 내의 다른 리소스에 접근하기 위한 인증 정보를 제공합니다. ServiceAccount 는 Pod 가 Kubernetes API Server 에 인증 하기 위한 Account 입니다. 때문에 Pod 를 생성할때 ServiceAccount 를 할당해야 하며 지정하지 않을 경우 default 가 자동으로 할당됩니다. Rule 과 RuleBinding 을 이용해 ServiceAccount 에 권한을 부여함으로써 Pod 가 다른 리소스에 접근할 수 있게 해줍니다. ServiceAccount 는 Namespace 단위로 생성되는 리소스며 다른 Namespace 에서 정의된 ServiceAccount 를 사용할 수 없습니다.

0
KubernetesIstio

Istio - Istio 설치 및 addon 설치

목차 Istio - Locality Load Balancing (지역 로드 밸런싱) Istio - Sidecar Injection Istio - istioctl Istio 란? 공식 홈페이지 https://istio.io/latest/docs/setup/getting-started/ istioctl 설치Mac 을 사용하는 경우 HomeBrew 를 이용해 istioctl 을 설치할 수 있습니다. brew install istioctl 다른 OS 를 사용하거나 특정 버전의 Istio 를 사용하고 싶은 경우 다음과 같이 Istio 버전을 Setting 한 후 해당 버전을 내려받아 사용할 수 있습니다. export ISTIO_VERSION=1.14.5curl -L https://istio.io/downloadIstio | ISTIO_VERSION=$ISTIO_VERSION TARGET_ARCH=x86_64 sh -

0
KubernetesCustom

쿠버네티스 - CustomResource

참고 https://frozenpond.tistory.com/111 CustomResourceCustom Resource는 쿠버네티스에서 사용자가 정의한 리소스를 나타냅니다. 이는 일반적으로 클러스터 내에 존재하지 않는 기본 리소스의 새로운 종류를 정의하고, 이를 통해 사용자의 애플리케이션에 특화된 동작을 수행할 수 있도록 합니다. Custom Resource 는 클러스터 상태의 일부로서 존재하며, 일반적인 리소스와 동일한 방식으로 쿠버네티스 API를 통해 작동합니다. 예를 들어, 사용자는 Custom Resource 를 생성, 조회, 수정 및 삭제할 수 있습니다. Custom Resource 를 사용하기 위해 먼저 Custom Resource Definition(CRD) 을 정의해야 합니다. CRD는 Custom Resource 의 스키마를 설명하는 쿠버네티스 API 개체입니다. 이를 통해 Custom Resource 의 구조, 필드 및 기타 특성을 정의할 수 있습니다. CRD는 일종의 템플릿으로서, Custom Resource 의 정의를 기반으로 생성됩니다. CRD를 생성하면 쿠버네티스 API 서버가 새로운 Custom Resource 타입을 이해하고 처리할 수 있게 됩니다. Custom Resource Definition 을 작성한 후, 사용자는 해당 정의를 사용하여 Custom Resource 인스턴스를 생성하고 관리할 수 있습니다. Custom Resource 인스턴스는 일반적으로 YAML 또는 JSON 형식으로 정의되며, 클러스터에 배포됩니다. 이후 Custom Resource 는 클러스터 내에서 다른 리소스와 유사하게 다룰 수 있으며, 사용자는 쿠버네티스 API를 사용하여 Custom Resource 를 조작할 수 있습니다. Custom Resource 와 Custom Resource Definition 은 쿠버네티스의 확장성과 유연성을 높여줍니다. 사용자는 쿠버네티스 API를 통해 고유한 리소스 유형을 정의하고 제어할 수 있으며, 이를 통해 자신의 애플리케이션을 더욱 쉽게 관리할 수 있습니다.

0
KubernetesAutoscaler

쿠버네티스 - CA (Cluster Autoscaler)

목차 쿠버네티스 - HPA (Horizontal Pod Autoscaler) 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod Post not found: k8s/k8s CA

0
KubernetesAutoscaler

쿠버네티스 - VPA (Vertical Pod Autoscaler)

목차 쿠버네티스 - HPA (Horizontal Pod Autoscaler) 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod Post not found: k8s/k8s VPA

0
KubernetesAutoscaler

쿠버네티스 - HPA (Horizontal Pod Autoscaler)

목차 쿠버네티스 - VPA (Vertical Pod Autoscaler) 쿠버네티스 - HPA (Horizontal Pod Autoscaler) HPAHPA (Horizontal Pod Autoscaler)는 Kubernetes 클러스터에서 자동으로 파드 수를 조정하는 기능입니다. HPA는 애플리케이션의 수요에 따라 파드의 수를 스케일 업 또는 스케일 다운하여 애플리케이션의 가용성과 성능을 유지하는 데 도움이 됩니다. HPA는 리소스 사용량을 기반으로 파드의 수를 동적으로 조정합니다. 일반적으로 CPU 사용률 또는 커스텀 메트릭을 기반으로 합니다. HPA는 설정된 임계값과 현재 리소스 사용량을 비교하여 파드 수를 조정합니다. HPA를 설정하려면 다음 단계를 수행해야 합니다: HPA를 적용할 리소스를 선택합니다. 대부분의 경우 Deployment 또는 ReplicaSet과 같은 컨트롤러 리소스를 선택합니다. HPA 정의를 작성합니다. HPA 정의에는 스케일링 대상 리소스, 스케일링 조건, 스케일링 조정량 등이 포함됩니다. 예를 들어, CPU 사용률이 80%를 초과하면 파드 수를 2배로 스케일 업할 수 있도록 설정할 수 있습니다. HPA를 적용합니다. HPA를 적용하면 Kubernetes는 지정된 간격으로 리소스 사용량을 확인하고 스케일링 결정을 내립니다. HPA는 애플리케이션의 부하가 증가하면 파드 수를 자동으로 늘리고, 부하가 감소하면 파드 수를 줄여 리소스를 효율적으로 관리합니다. 이를 통해 애플리케이션의 가용성과 성능을 최적화할 수 있습니다.

0
KubernetesConfig

쿠버네티스 - Secret

목차 쿠버네티스 - Secret 쿠버네티스 - ConfigMap 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod 쿠버네티스 - Data Plane 쿠버네티스 - Control Plane Post not found: k8s/k8s Secret 쿠버네티스(Secret)는 애플리케이션에서 민감한 데이터를 안전하게 저장하고 관리하기 위한 리소스 Secret은 기본적으로 ConfigMap과 유사한 방식으로 동작하지만, 암호화된 형태로 데이터를 저장하여 더 높은 보안 수준을 제공합니다. Secret은 애플리케이션에서 사용되는 비밀번호, API 토큰, 데이터베이스 자격증명 등과 같은 중요한 정보를 저장할 수 있습니다. 이러한 데이터는 애플리케이션의 컨테이너 이미지와 분리되어, 보안성을 유지하면서 애플리케이션을 배포하고 관리할 수 있습니다. Secret은 Base64 인코딩을 사용하여 데이터를 인코딩하고, 쿠버네티스 클러스터 내부에서 저장됩니다. 이를 통해 데이터는 안전하게 저장되며, 컨테이너 내부에서 필요할 때만 디코딩하여 사용됩니다. Secret은 YAML 또는 JSON 형식으로 정의되며, 쿠버네티스 클러스터에 생성 및 적용됩니다. Secret을 생성한 후에는 해당 Secret을 사용하려는 Pod의 컨테이너에 마운트하거나 환경 변수로 설정할 수 있습니다. 이렇게 하면 애플리케이션은 Secret에서 정의된 중요한 정보를 사용할 수 있습니다. 예를 들어, Secret에서 “db_password”라는 키에 대한 값으로 “mysecretpassword”를 설정하면, 애플리케이션은 이 값을 디코딩하여 데이터베이스 비밀번호로 사용할 수 있습니다. Secret은 ConfigMap과 마찬가지로 클러스터나 네임스페이스 수준에서 변경 및 관리할 수 있으므로, 변경된 비밀번호는 애플리케이션을 다시 시작하지 않고도 즉시 적용될 수 있습니다.

0
KubernetesIstio

Circuit Breaker

Circuit Breaker분산 시스템에서 Circuit Breaker 는 일종의 예외 처리 메커니즘으로, 서비스 호출의 실패, 지연 등을 모니터링하고, 이를 감지하면 해당 서비스의 호출을 일시 중단시키는 역할을 합니다. 분산 시스템에서는 여러 대의 서버로 구성되어 있기 때문에, 서비스 간의 호출은 시스템의 다른 부분과 독립적으로 처리됩니다. 따라서, 서비스 호출 시에 실패가 발생하면 이를 처리하는 데 시간이 걸리고, 이를 무한정 대기하게 된다면 전체 시스템의 성능에 악영향을 미칠 수 있습니다. 이 때, Circuit Breaker는 이러한 지연을 방지하기 위해 호출을 일시 중단시킵니다. 이후, 일정 시간 동안 호출을 차단한 뒤, 정상적으로 작동하면 다시 호출을 허용합니다. Circuit Breaker 는 분산 시스템에서 안정성을 보장하기 위한 매우 중요한 요소 중 하나입니다. Circuit Breaker 가 없다면, 서비스 호출 실패와 지연에 대한 처리가 지연되어 시스템 전체의 성능에 영향을 미칠 가능성이 높습니다. Circuit Breaker 는 분산 시스템에서 발생할 수 있는 여러 가지 문제를 빠르게 감지하고, 시스템 전체의 안정성을 유지할 수 있도록 도와줍니다.

0
KubernetesIstio

Istio - DestinationRule

목차 Istio - Locality Load Balancing (지역 로드 밸런싱) Istio - Sidecar Injection Istio - Istio 설치 및 addon 설치 Istio 란? 참고 https://istio.io/latest/docs/ops/deployment/architecture/ https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/ https://happycloud-lee.tistory.com/104 DestinationRule DestinationRule은 서비스 요청이 특정 서비스 버전 또는 인스턴스로 라우팅되도록 지정하는 규칙을 정의하는 리소스 DestinationRule은 Istio 서비스 메시에서 트래픽을 관리하는 중요한 요소 중 하나입니다. 이를 사용하여 서비스를 라우팅할 때 사용할 서비스 버전, 인스턴스 및 연결 방식을 지정할 수 있습니다. DestinationRule은 Istio의 다른 기능과 통합됩니다. 예를 들어, VirtualService와 함께 사용하여 특정 경로 및 트래픽 유형에 대한 규칙을 지정할 수 있습니다. 또한, 서비스 인스턴스의 로드 밸런싱 및 서킷 브레이커와 같은 기능도 DestinationRule을 사용하여 정의할 수 있습니다. 서비스 이름: 규칙을 적용할 대상 서비스의 이름을 지정합니다. 서비스 버전: 규칙을 적용할 대상 서비스의 버전을 지정합니다. 서비스 서브셋: 대상 서비스의 서브셋을 지정하여 트래픽을 특정 서브셋으로 라우팅할 수 있습니다. 연결 풀: 서비스 요청에 사용될 연결 풀을 정의합니다. 예를 들어, 서비스 인스턴스의 최대 연결 수 및 연결 유지 시간 등을 지정할 수 있습니다. 트래픽 정책: 대상 서비스의 트래픽을 제어하는 정책을 정의합니다. 예를 들어, 연결 시간 초과 및 연결 오류를 처리하는 방법 등을 정의할 수 있습니다.

0
KubernetesIstio

Istio - Locality Load Balancing (지역 로드 밸런싱)

목차 Istio - Locality Load Balancing (지역 로드 밸런싱) Istio - Sidecar Injection Istio - Istio 설치 및 addon 설치 Istio 란? 참고 https://istio.io/latest/docs/ops/deployment/architecture/ https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/ https://happycloud-lee.tistory.com/104 http://itnp.kr/post/istio-circuit-break https://istiobyexample.dev/locality-load-balancing/ Istio - Locality Load Balancing Istio 의 Locality Load Balance 는 서비스 요청을 지역적으로 분산시키는 기능을 제공합니다. Locality Load Balance는 서비스 요청이 클러스터 내에서 발생할 때 해당 요청이 가장 가까운 지역의 서비스 인스턴스에 배정되도록 보장합니다. 이를 통해 클라이언트와 서비스 인스턴스 사이의 대기 시간을 줄이고, 네트워크 대역폭을 절약하며, 네트워크 병목 현상을 방지할 수 있습니다. Locality Load Balance는 Istio의 Envoy 프록시에서 구현됩니다. Envoy는 클러스터 내의 모든 서비스 인스턴스에 대한 위치 정보를 유지 관리하며, 클러스터의 지리적 분포를 파악하여 요청을 지역적으로 분산시킵니다. Locality Load Balance는 또한 Istio의 트래픽 관리 기능과 통합됩니다. Istio는 트래픽 관리 규칙을 정의하여 특정 서비스 인스턴스가 특정 지역에서만 처리되도록 할 수 있습니다. 이를 통해 서비스의 가용성을 높이고, 서비스 인스턴스 간의 부하를 균형있게 분산시킬 수 있습니다.