이 기사 는 작성자가 Huawei Cloud 커뮤니티 " Istio 기반 다중 클러스터 트래픽 관리 구현 "에서 공유한 것입니다. 친구를 사귈 수 있습니다.
배경
멀티 클라우드 및 하이브리드 클라우드와 같은 이기종 인프라에 대한 서비스 거버넌스는 Istio가 지원하는 데 중점을 둔 시나리오 중 하나입니다. 서비스 가용성을 향상하고 벤더 종속을 방지하기 위해 기업은 일반적으로 여러 지역의 여러 클러스터에 애플리케이션을 배포하거나 멀티 클라우드 및 하이브리드 클라우드와 같은 여러 클라우드 환경에서 애플리케이션을 배포하는 것을 선택합니다. 엔터프라이즈 애플리케이션 배포를 위한 선택입니다. 따라서 점점 더 많은 사용자가 클러스터 간 서비스 거버넌스에 대한 강력한 요구를 갖고 있습니다. 이러한 맥락에서 ServiceMesh 분야의 사실상 표준인 Istio는 다양한 다중 클러스터 관리 솔루션을 출시했습니다.
2. 소개
현재 Istio는 4개의 다중 클러스터 모델을 지원합니다.
- 플랫 네트워크 단일 제어 평면 모델
- 플랫 네트워크 다중 제어 평면 모델
- 비평탄 네트워크 단일 제어 평면 모델
- 비평탄 네트워크 다중 제어 평면 모델
멀티 클러스터의 단일 제어 플레인 모델은 여러 클러스터가 동일한 Istio 제어 플레인을 공유한다는 것을 의미합니다. 멀티 클러스터의 다중 제어 플레인 모델은 각 클러스터가 단일 제어인지 여부에 관계없이 Istio 제어 플레인 세트를 독립적으로 사용해야 함을 의미합니다. plane 또는 다중 제어 평면 모델의 경우 각 Istio 제어 평면 세트(istiod)는 모든 클러스터의 Kube-apiserver에 연결되어야 하며 List-Watch는 모든 클러스터를 획득하고 Service、Endpoint、Pod 、Node 클러스터 내 또는 클러스터 간 서비스 액세스를 제어하지만 기본 클러스터의 Istio API 개체 만 모니터링합니다 VirtualService、DestinationRule、Gateway.
클러스터 간 네트워크가 플랫한지 여부에 따라 Istio는 두 개의 제어 평면 모델을 세분화합니다.
- 플랫 네트워크: 멀티 클러스터 컨테이너 네트워크는 VPN 및 기타 기술을 통해 연결되며 포드는 클러스터 전체에 직접 액세스할 수 있습니다.
- 비플랫 네트워크: 각 클러스터의 컨테이너 네트워크는 서로 격리되어 있습니다. 클러스터 간 액세스는 통과할 수 없으며 East-West 게이트웨이를 통과해야 합니다.
프로덕션 환경에서 Istio 다중 클러스터 모델을 선택할 때는 물론 실제 시나리오를 기반으로 결정을 내려야 합니다. 클러스터 간 네트워크가 플랫한 경우 플랫 네트워크 모델을 선택할 수 있고, 클러스터 간 네트워크가 격리된 경우 비플랫 네트워크 모델을 선택할 수 있습니다. 클러스터 크기가 작으면 단일 제어 평면 모델을 선택할 수 있습니다. 클러스터 크기가 크면 다중 제어 평면 모델을 선택할 수 있습니다.
이 문서에서는 설치 지침을 위해 비플랫 네트워크 다중 제어 평면 모델을 선택합니다. 설치 모델은 다음과 같은
특징을 갖습니다.
- 서로 다른 클러스터가 하나의 대규모 네트워크 아래에 있을 필요가 없습니다. 즉, 컨테이너 네트워크가 3개 계층으로 연결될 필요가 없으며 클러스터 간 서비스 액세스는
Istio East-West Gateway전달을 통해 이루어집니다. - 각 kubernetes 클러스터의 포드 주소 범위 및 서비스 주소 범위에는 제한이 없으며, 다른 클러스터와 겹칠 수 있으며, 서로 다른 클러스터가 서로 간섭하지 않습니다.
- 각 Kubernetes 클러스터의 사이드카는 이 클러스터의 Istio 제어 플레인에만 연결되어 통신을 더욱 효율적으로 만듭니다.
- Istiod는 기본 클러스터의 Istio 구성만 모니터링하므로 다른 리소스에 대한 중복 복제 문제가 있습니다.
VirtualService、DestinationRule、Gateway - 동일한 클러스터의 내부 서비스 액세스: 포드 간 직접 연결, 클러스터 간 서비스 액세스: DNS 프록시를 사용하여 다른 클러스터의 서비스 도메인 이름을 확인합니다 . 원격 클러스터.
East-west Gateway
3개의 ClusterMesh 환경 구축
두 개의 클러스터(cluster1 및 Cluster2)를 구축한 후 각 클러스터에 Istio 제어 플레인을 설치하고 둘 다 기본 클러스터로 설정합니다. 클러스터 Cluster1은 network1 네트워크에 있고 클러스터 Cluster2는 network2 네트워크에 있습니다.
3.1 전제조건
이 빌드에 대한 환경 정보는 다음과 같습니다. Kind를 사용하여 Kubernetes 클러스터를 빌드하며 Kind 버전은 v0.19.0입니다. Kubernetes 버전은 1.27.3이고 Istio 버전은 1.20.1입니다.
k8s 클러스터를 구축하기 전에 docker kubectl 및 kind가 Linux 노드에 설치되어 있는지 확인하세요.
istioctl 바이너리 다운로드
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.20.1 TARGET_ARCH=x86_64 sh -
경로에 istioctl 클라이언트 추가
3.2 쿠버네티스 클러스터 설치
Cluster1 및 Cluster2 클러스터 설치 스크립트는 다음과 같습니다.
# 생성-cluster.sh
# 이 스크립트는 종류와 유형을 사용하여 여러 클러스터 생성을 처리합니다.
# 안전하지 않은 컨테이너 레지스트리를 생성하고 구성하는 기능.
설정 -o xtrace
세트 -o 제기
세트 -o 명사
set -o 파이프실패
# 쉘체크 소스=util.sh
NUM_CLUSTERS="${NUM_CLUSTERS:-2}"
KIND_IMAGE="${KIND_IMAGE:-}"
KIND_TAG="${KIND_TAG:-v1.27.3@sha256:3966ac761ae0136263ffdb6cfd4db23ef8a83cba8a463690e98317add2c9ba72}"
OS="$(이름)"
함수 생성-클러스터() {
로컬 num_clusters=${1}
로컬 이미지_arg=""
if [[ "${KIND_IMAGE}" ]]; 그 다음에
image_arg="--image=${KIND_IMAGE}"
elif [[ "${KIND_TAG}" ]]; 그 다음에
image_arg="--image=kindest/node:${KIND_TAG}"
BE
for i in $(seq "${num_clusters}"); 하다
종류 생성 클러스터 --name "cluster${i}" "${image_arg}"
수정 클러스터 "${i}"
에코
완료
}
함수 수정 클러스터() {
local i=${1} # 클러스터 번호
if [ "$OS" != "다윈" ];then
# 클러스터가 다른 클러스터의 kube API 서버에 도달할 수 있도록 컨테이너 IP 주소를 kube API 엔드포인트로 설정합니다.
로컬 docker_ip
docker_ip=$(docker informa --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "cluster${i}-control-plane")
kubectl config set-cluster "kind-cluster${i}" --server="https://${docker_ip}:6443"
BE
# 컨텍스트 이름을 단순화합니다.
kubectl config rename-context "kind-cluster${i}" "cluster${i}"
}
echo "${NUM_CLUSTERS}개의 클러스터 생성 중"
클러스터 생성 "${NUM_CLUSTERS}"
kubectl 구성 사용 컨텍스트 클러스터1
echo "종류 CIDR은 $(docker networkspect -f '{{$map := index .IPAM.Config 0}}{{index $map "Subnet"}}' kind)입니다."
에코 "완료"
apiserver위의 클러스터 설치 과정에서 istiod가 다른 클러스터의 주소에 접근하기 위해 kube-apiserver클러스터 주소를 마스터 노드의 주소로 설정합니다. 종류별로 배포된 클러스터이기 때문에 두 클러스터의 마스터 노드는 기본적으로 동일한 호스트에서 docker를 실행하는 컨테이너입니다.
Cluster1과 Cluster2가 준비되었는지 확인
3.3 MetalLB를 사용하여 게이트웨이에 외부 IP 할당
종류는 여러 클러스터를 배포하는 데 사용되므로 istio 북-남 게이트웨이 및 동-서 게이트웨이를 생성하려면 LoadBalencer 서비스를 생성해야 하며, 두 서비스 모두 외부IP를 사용해야 합니다. 여기서 metalLB는 LB IP 주소의 배포 및 공지를 구현하는 데 사용됩니다.
노드 서브넷 세그먼트를 사용하여 클러스터를 구축하려면 종류를 참조하세요. metalLB L2 모드로 배포하세요. 172.18.0.0/16
Cluster1의 metalLB 구성 목록: metallb-config-1.yaml
### 클러스터1의 경우
##lbip 주소 할당을 위해 IPAddressPool을 구성합니다. L2 모드에서는 ippool 주소와 작업자 노드가 동일한 서브넷에 있을 수 있습니다.
api버전: metallb.io/v1beta1
종류: IPAddressPool
metadata:
이름: 첫 번째 풀
네임스페이스: metallb-system
투기:
구애:
- 172.18.1.230-172.18.1.240
---
##주소 공지를 위한 L2Advertisement 구성
api버전: metallb.io/v1beta1
종류: L2광고
metadata:
이름: 첫 번째 광고
네임스페이스: metallb-system
투기:
IP주소풀:
- 첫 번째 풀
Cluster2 클러스터의 metalLB 구성 목록: metallb-config-2.yaml
클러스터2의 경우 ###
##lbip 주소 할당을 위해 IPAddressPool을 구성합니다. L2 모드에서는 ippool 주소와 작업자 노드가 동일한 서브넷에 있을 수 있습니다.
api버전: metallb.io/v1beta1
종류: IPAddressPool
metadata:
이름: 두 번째 풀
네임스페이스: metallb-system
투기:
구애:
- 172.18.1.241-172.18.1.252
---
##주소 공지를 위한 L2Advertisement 구성
api버전: metallb.io/v1beta1
종류: L2광고
metadata:
이름: 두 번째 광고
네임스페이스: metallb-system
투기:
IP주소풀:
- 두 번째 풀
스크립트를 사용하여 설치
#!/usr/bin/env bash
설정 -o xtrace
세트 -o 제기
세트 -o 명사
set -o 파이프실패
NUM_CLUSTERS="${NUM_CLUSTERS:-2}"
for i in $(seq "${NUM_CLUSTERS}"); 하다
echo "클러스터${i}에서 metallb 배포 시작 중"
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.10/config/manifests/metallb-native.yaml --context "cluster${i}"
kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)" --context "cluster${i}"
## 대기 시간을 늘립니다. metallb 로드가 배포되지 않으면 IPAddressPool L2Advertisement 생성 시 오류가 보고됩니다.
잠 10
kubectl apply -f ./metallb-config-${i}.yaml --context "cluster${i}"
에코 "----"
완료
metalLB 배포 상태 확인
IPAddressPool 정보를 확인합니다.
3.4 클러스터 공유 루트 CA 구성 신뢰 관계
안전한 클러스터 간 mTLS 통신을 지원하기 위해 다중 제어 플레인 모델에서는 각 클러스터의 제어 플레인 Istiod가 Citatel이 클러스터 간 TLS 양방향 인증을 지원하는 인증서를 발급할 수 있도록 동일한 CA 기관에서 발급한 중간 CA 인증서를 사용해야 합니다. .
Istio east-west 게이트웨이(교차 클러스터 액세스)는 작업 시 SNI 기반 라우팅을 사용합니다. 따라서 TLS에서 요청한 SNI를 기반으로 SNI에 해당하는 클러스터로 자동 라우팅합니다. 모든 트래픽은 TLS로 암호화되어야 합니다.
인증서와 키를 클러스터에 삽입합니다. 스크립트는 다음과 같습니다(스크립트를 istio 설치 패키지 디렉터리로 이동해야 함).
#!/usr/bin/env bash
설정 -o xtrace
#set -o 제기
세트 -o 명사
set -o 파이프실패
NUM_CLUSTERS="${NUM_CLUSTERS:-2}"
##istio 설치 패키지의 최상위 디렉터리에 인증서와 키를 저장할 디렉터리를 만듭니다.
mkdir -p 인증서
푸시된 인증서
##루트 인증서 및 키 생성
make -f ../tools/certs/Makefile.selfsigned.mk root-ca
for i in $(seq "${NUM_CLUSTERS}"); 하다
##각 클러스터에 대해 Istio CA용 중간 인증서와 키를 생성합니다.
make -f ../tools/certs/Makefile.selfsigned.mk "cluster${i}-cacerts"
##각 클러스터에 대해 istio-system 네임스페이스를 생성합니다.
kubectl create 네임스페이스 istio-system --context "cluster${i}"
## 각 클러스터에 대해 istio 시스템 네임스페이스에 topology.istio.io/network 태그를 지정하여 네트워크 식별을 추가합니다.
kubectl --context="cluster${i}" 라벨 네임스페이스 istio-system topology.istio.io/network="network${i}"
##각 클러스터에 대해 istio가 지역 장애 조치 및 지역 로드 밸런싱을 쉽게 구현할 수 있도록 작업 노드 노드에 지역 및 가용성 영역 레이블을 지정합니다.
kubectl --context="cluster${i}" 레이블 노드 "cluster${i}-control-plane" topology.kubernetes.io/region="region${i}"
kubectl --context="cluster${i}" 레이블 노드 "cluster${i}-control-plane" topology.kubernetes.io/zone="zone${i}"
#각 클러스터에서 모든 입력 파일 ca-cert.pem, ca-key.pem, root-cert.pem 및 cert-chain.pem을 사용하여 개인 cacerts를 만듭니다.
kubectl delete secret cacerts -n istio-system --context "cluster${i}"
kubectl create secret generic cacerts -n istio-system --context "cluster${i}" \
--from-file="cluster${i}/ca-cert.pem" \
--from-file="cluster${i}/ca-key.pem" \
--from-file="cluster${i}/root-cert.pem" \
--from-file="cluster${i}/cert-chain.pem"
에코 "----"
완료
3.5 Istio 서비스 메시 설치
Cluster1 및 Cluster2 클러스터에 다중 제어 영역 istio 그리드를 설치합니다.
Cluster1을 기본 클러스터로 설정하고 istio 설치 디렉터리에서 다음 명령을 실행합니다.
고양이 <<EOF> Cluster1.yaml
api버전: install.istio.io/v1alpha1
종류: IstioOperator
투기:
값:
글로벌:
메쉬ID: mesh1
multiCluster: ##다중 클러스터 구성 활성화
ClusterName: Cluster1 #k8s 클러스터 이름 지정
network: network1 #네트워크 식별자를 지정합니다.
벌채 반출:
레벨: 디버그
EOF
Cluster2를 기본 클러스터로 설정하고 istio 설치 디렉터리에서 다음 명령을 실행합니다.
고양이 <<EOF> Cluster2.yaml
api버전: install.istio.io/v1alpha1
종류: IstioOperator
투기:
값:
글로벌:
메쉬ID: mesh2
multiCluster: ##다중 클러스터 구성 활성화
ClusterName: Cluster2 #k8s 클러스터 이름 지정
network: network2 #네트워크 식별자를 지정합니다.
벌채 반출:
레벨: 디버그
EOF
#!/usr/bin/env bash
설정 -o xtrace
세트 -o 제기
세트 -o 명사
set -o 파이프실패
OS="$(이름)"
NUM_CLUSTERS="${NUM_CLUSTERS:-2}"
for i in $(seq "${NUM_CLUSTERS}"); 하다
echo "클러스터${i}에서 istio 배포 시작 중"
istioctl install --force --context="cluster${i}" -f "cluster${i}.yaml"
echo "클러스터${i}에서 eastwest 게이트웨이 생성"
## 각 클러스터에 east-west 게이트웨이를 설치합니다.
bash 샘플/multicluster/gen-eastwest-gateway.sh \
--mesh "메쉬${i}" --cluster "클러스터${i}" --network "네트워크${i}" | \
istioctl --context="cluster${i}" 설치 -y -f -
에코
완료
스크립트를 실행하여 istio를 설치하고 배포합니다.
설치가 완료될 때까지 잠시 기다리세요
3.6 동서 게이트웨이 서비스 개시
클러스터가 서로 다른 네트워크에 있기 때문에 두 클러스터의 east-west 게이트웨이에서 모든 서비스(*.local)를 열어야 합니다. 이 게이트웨이는 인터넷에서 공개되지만, 그 뒤에 있는 서비스는 마치 동일한 네트워크에 있는 것처럼 신뢰할 수 있는 mTLS 인증서가 있는 서비스에서만 액세스할 수 있습니다. 다음 명령을 실행하여 두 클러스터 모두에 서비스를 노출합니다.
api버전:네트워킹.istio.io/v1beta1
종류: 게이트웨이
metadata:
이름: 교차 네트워크 게이트웨이
투기:
선택자:
istio: eastwestgateway # 동서 트래픽을 위한 전용 게이트웨이
서버:
- 포트:
번호: 15443 # 이미 선언됨
이름: tls
프로토콜: TLS
TLS:
mode: AUTO_PASSTHROUGH # East-West 게이트웨이의 작업 모드는 TLS입니다. AUTO_PASSTHROUGH
호스트:
- "*.local" # 모든 서비스 노출
위의 게이트웨이 구성을 각 클러스터에 개별적으로 적용합니다.
kubectl -n istio-system --context=cluster${i} apply -f samples/multicluster/expose-services.yaml
3.7 istiod가 원격 클러스터 apiserver에 액세스할 수 있도록 비밀을 구성합니다.
각 k8s 클러스터의 istiod는 다른 클러스터의 Kube-APIServer를 목록 감시하고 K8s 클러스터의 자격 증명을 사용하여 Istio가 원격 Kubernetes API 서버에 액세스할 수 있도록 하는 Secret 객체를 생성해야 합니다.
#!/usr/bin/env bash
설정 -o xtrace
세트 -o 제기
세트 -o 명사
set -o 파이프실패
OS="$(이름)"
NUM_CLUSTERS="${NUM_CLUSTERS:-2}"
for i in $(seq "${NUM_CLUSTERS}"); 하다
for j in $(seq "${NUM_CLUSTERS}"); 하다
if [ "$i" -ne "$j" ]
그 다음에
echo "cluster${i}와 Cluster${j} 사이에서 엔드포인트 검색 활성화"
if [ "$OS" == "다윈" ]
그 다음에
# 클러스터가 다른 클러스터의 kube API 서버에 도달할 수 있도록 컨테이너 IP 주소를 kube API 엔드포인트로 설정합니다.
docker_ip=$(dockerspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "cluster${i}-control-plane")
istioctl 생성-원격-비밀 \
--context="클러스터${i}" \
--server="https://${docker_ip}:6443" \
--name="클러스터${i}" | \
kubectl apply --validate=false --context="cluster${j}" -f -
또 다른
istioctl 생성-원격-비밀 \
--context="클러스터${i}" \
--name="클러스터${i}" | \
kubectl apply --validate=false --context="cluster${j}" -f -
BE
BE
완료
완료
위 스크립트를 실행하면 원격 비밀이 생성됩니다.
istiod 로그를 확인하고 원격 클러스터가 이미 모니터링되고 있는지 확인합니다.
4가지 Istio 다중 클러스터 트래픽 관리 사례
kubectl create --context=cluster1 네임스페이스 샘플
kubectl create --context=cluster2 네임스페이스 샘플
kubectl label --context=cluster1 네임스페이스 샘플 \
istio 주입=활성화됨
kubectl label --context=cluster2 네임스페이스 샘플 \
istio 주입=활성화됨
kubectl apply --context=cluster1 \
-f 샘플/helloworld/helloworld.yaml \
-l 서비스=helloworld -n 샘플
kubectl apply --context=cluster2 \
-f 샘플/helloworld/helloworld.yaml \
-l 서비스=helloworld -n 샘플
다양한 클러스터에 다양한 버전의 서비스 배포
애플리케이션 helloworld-v1을 Cluster1에 배포합니다.kubectl apply --context=cluster1 \
-f 샘플/helloworld/helloworld.yaml \
-l 버전=v1 -n 샘플
애플리케이션 helloworld-v2를 Cluster2에 배포합니다.
kubectl apply --context=cluster2 \ -f 샘플/helloworld/helloworld.yaml \ -l 버전=v2 -n 샘플테스트 클라이언트 배포
kubectl apply --context=cluster1 \
-f 샘플/수면/sleep.yaml -n 샘플
kubectl apply --context=cluster2 \
-f 샘플/수면/sleep.yaml -n 샘플
로드 인스턴스가 성공적으로 배포되고 사이드카가 삽입되었는지 확인
4.1 클러스터 간 트래픽 확인
Sleep Pod를 사용하여 HelloWorld 서비스를 반복적으로 호출합니다. 로드 밸런싱이 예상대로 작동하는지 확인하려면 모든 클러스터에서 HelloWorld 서비스를 호출해야 합니다.
Cluster1의 Sleep Pod에서 HelloWorld 서비스에 요청을 보냅니다.
Cluster2의 Sleep Pod에서 HelloWorld 서비스에 요청을 보냅니다.
4.3 게이트웨이에서 액세스 확인
게이트웨이를 통해 Helloworld 서버에 액세스합니다.
virtualservice, Gateway 등 istio 리소스를 생성합니다. 구성 목록은 다음과 같습니다.
# helloworld-gateway.yaml
api버전:네트워킹.istio.io/v1beta1
종류: 게이트웨이
metadata:
이름: helloworld-gateway
투기:
선택자:
istio: ingressgateway # istio 기본 컨트롤러 사용
서버:
- 포트:
번호: 80
이름: http
프로토콜: HTTP
호스트:
- "*"
---
api버전:네트워킹.istio.io/v1beta1
종류: 가상 서비스
metadata:
이름: 헬로월드
투기:
호스트:
- "*"
게이트웨이:
- helloworld-게이트웨이
http:
- 성냥:
- 유형:
정확한 내용: /안녕하세요
노선:
- 목적지:
호스트: helloworld
포트:
번호: 5000
참고: 이 구성은 두 클러스터 모두에 적용되어야 합니다.
액세스 효과는 다음과 같습니다.
4.3 지역별 부하 분산 확인
트래픽을 보다 세밀하게 제어하려면 두 지역의 가중치를 각각 80%와 20%로 설정하고 DestinationRule을 사용하여 가중치 분포를 구성하세요 . region1 -> zone1 region1 -> zone2
# 지역성-lb-weight.yaml
api버전:네트워킹.istio.io/v1beta1
종류: DestinationRule
metadata:
이름: 헬로월드
네임스페이스: 샘플
투기:
호스트: helloworld.sample.svc.cluster.local
트래픽 정책:
연결 풀:
http:
maxRequestsPerConnection: 1
로드밸런서:
단순: ROUND_ROBIN
localityLb설정:
활성화됨: 사실
분배하다:
- 출발: 지역 1/*
에게:
"지역1/*": 80
"지역2/*": 20
- 출발: 지역 2/*
에게:
"지역2/*": 80
"지역1/*": 20
이상값 감지:
연속5xx오류: 1
간격: 1초
베이스제거 시간: 1m
참고: 이 구성은 두 클러스터 모두에 적용되어야 합니다.
게이트웨이를 통해 Cluster1에서 HelloWorld 서비스에 요청을 보냅니다.
게이트웨이를 통해 Cluster2에서 HelloWorld 서비스에 요청을 보냅니다.
4.4 지역 장애 조치 확인
여러 서비스 인스턴스가 여러 지역/지역에 배포되는 경우 특정 지역/지역의 서비스 인스턴스를 사용할 수 없는 경우 트래픽을 다른 지역/지역의 서비스 인스턴스로 전송하여 지역 장애 조치를 수행할 수 있으므로 서비스 안정성이 보장됩니다.
# locality-lb-failover.yaml
api버전:네트워킹.istio.io/v1beta1
종류: DestinationRule
metadata:
이름: 헬로월드
네임스페이스: 샘플
투기:
호스트: helloworld.sample.svc.cluster.local
트래픽 정책:
연결 풀:
http:
maxRequestsPerConnection: 1 # HTTP 연결 유지를 끄고 각 HTTP 요청이 새로운 연결 정책을 사용하도록 강제합니다.
로드밸런서:
단순: ROUND_ROBIN
localityLbSetting: # 지역 로드 밸런싱 구성은 이상치 감지를 활성화한 후 기본적으로 활성화됩니다.
활성화됨: 사실
장애 조치: # 지역 장애 조치 전략
- 출발: 지역 1
받는 사람: 지역 2
- 출발: 지역 2
받는 사람: 지역 1
이상값 감지:
연속5xxErrors: 1 # 1 연속 5xx 오류
간격: 1s # 감지 간격 1s
baseEjectionTime: 1m #기본 배출 시간 1m
참고: 이 구성은 두 클러스터 모두에 적용되어야 합니다.
게이트웨이를 통해 Cluster1에서 HelloWorld 서비스에 요청을 보냅니다.
오류를 시뮬레이션하고 Cluster1 클러스터의 Helloworld V1 버전을 실패하도록 수동으로 설정합니다.
다시 액세스하면 오류 감지가 적용되고 장애 조치가 트리거되며 응답 버전이 항상 v2인지 확인합니다. 이는 지역 2의 helloworld 서비스에 액세스하여 지역 장애 조치를 달성한다는 의미입니다.
장애 조치의 전제는 현재 지역의 모든 인스턴스를 사용할 수 없으면 현재 지역으로 전송된다는 것입니다. 그렇지 않으면 트래픽은 현재 지역에서 사용 가능한 다른 인스턴스로 전송됩니다.
비고 5개
참고문헌은 다음과 같습니다:
-
istio 오픈 소스 커뮤니티(교차 네트워크 다중 기본 아키텍처에 대한 설치 지침): https://istio.io/latest/zh/docs/setup/install/multicluster/multi-primary_multi-network/
-
종류 설치 클러스터 스크립트 참조: https://github.com/cnych/multi-cluster-istio-kind/tree/main/kind-create
-
멀티 클러스터 인증서 관리 참조: https://istio.io/latest/zh/docs/tasks/security/cert-management/plugin-ca-cert/
JetBrains 2024(2024.1)의 첫 번째 메이저 버전 업데이트는 오픈소스 인데 Microsoft도 비용을 지불할 계획인데 아직도 오픈소스라는 비판을 받는 이유는 무엇일까요? [복구] Tencent Cloud 백엔드 충돌: 콘솔에 로그인한 후 많은 서비스 오류가 발생하고 데이터가 없습니다. 독일도 "독립적으로 제어 가능"해야 합니다. 주 정부는 30,000대의 PC를 Windows에서 Linux deep-IDE로 마이그레이션하여 마침내 달성했습니다. 부트스트래핑! Visual Studio Code 1.88이 출시되었습니다. Tencent는 Switch를 "생각하는 학습 기계"로 전환했습니다. RustDesk 원격 데스크톱이 시작되고 웹 클라이언트를 재구성합니다. WeChat의 SQLite 기반 오픈 소스 터미널 데이터베이스인 WCDB가 크게 업그레이드되었습니다.