Anthos Service Mesh 1.10은 지원 종료되어 더 이상 지원되지 않습니다. 이전 버전에서 업그레이드를 참조하세요.

최신 문서를 보거나 사용 가능한 다른 버전을 선택합니다.

사용 가능한 버전

게이트웨이 설치 및 업그레이드

Anthos Service Mesh는 서비스 메시의 일부로 게이트웨이를 배포 및 관리하는 옵션을 제공합니다. 게이트웨이는 들어오거나 나가는 HTTP/TCP 연결을 수신하는 메시지의 에지에서 작동하는 부하 분산기를 설명합니다. 게이트웨이는 메시로 들어오고 나가는 트래픽을 미세하게 제어할 수 있는 Envoy 프록시입니다. 게이트웨이는 주로 인그레스 트래픽을 관리하는 데 사용되지만 다른 유형의 트래픽을 관리하도록 게이트웨이를 구성할 수도 있습니다. 예를 들면 다음과 같습니다.

이그레스 게이트웨이: 이그레스 게이트웨이를 사용하면 메시에서 나가는 트래픽의 전용 출구 노드를 구성하여 외부 네트워크에 액세스할 수 있거나 액세스해야 하는 서비스를 제한하거나, 이그레스 트래픽을 안전하게 제어할 수 있습니다(예: 메시에 보안 추가).
East-west 게이트웨이: 서비스 워크로드가 다른 네트워크의 다중 기본 메시의 클러스터 경계를 넘어 통신할 수 있도록 하는 east-west 트래픽의 프록시입니다. 기본적으로 이 게이트웨이는 인터넷에 공개됩니다.

이 페이지에서는 게이트웨이 프록시를 배포하고 업그레이드하는 방법과 고유한 istio-ingressgateway 및 istio-egressgateway 게이트웨이 프록시를 구성하는 예시에 대한 권장사항을 설명합니다. 트래픽 분할, 리디렉션, 재시도 논리와 같은 것들은 게이트웨이 구성을 게이트웨이 프록시에 적용하여 사용할 수 있습니다. 그런 후 동일한 API 리소스에 애플리케이션 레이어 트래픽 라우팅(L7)을 추가하는 대신 가상 서비스를 게이트웨이에 바인딩합니다. 이렇게 하면 서비스 메시의 다른 데이터 영역 트래픽과 같이 게이트웨이 트래픽을 관리할 수 있습니다.

다른 방법으로 게이트웨이를 배포할 수 있고 동일한 클러스터 내에서 2개 이상의 토폴로지를 사용하도록 선택할 수 있습니다. 이러한 토폴로지에 대한 자세한 내용은 Istio 문서의 게이트웨이 배포 토폴로지를 참조하세요.

게이트웨이 배포 권장사항

제어 영역과 게이트웨이를 개별적으로 배포하고 관리합니다.
보안 권장사항에 따라 제어 영역의 다른 네임스페이스에 게이트웨이를 배포하는 것이 좋습니다.
자동 사이드카 삽입(auto-injection)을 사용하여 서비스에 대해 사이드카 프록시를 삽입할 때 사용하는 것과 같이 게이트웨이에 대해 프록시 구성을 삽입합니다.

권장사항을 따라 다음을 수행할 수 있습니다.

네임스페이스 관리자가 권한을 전체 클러스터로 승격할 필요 없이 게이트웨이를 관리할 수 있도록 합니다.
관리자가 Kubernetes 애플리케이션 관리를 위해 사용하는 것과 동일한 배포 도구 또는 메커니즘을 사용해서 게이트웨이를 배포하고 관리할 수 있도록 합니다.
관리자에게 게이트웨이 배포에 대한 전체 권한을 부여하고 작업을 간소화합니다. 새 업데이트를 사용할 수 있거나 구성이 변경되었으면 관리자가 단순히 게이트웨이 포드를 다시 시작하여 업데이트합니다. 그러면 게이트웨이 배포를 작동하는 환경이 서비스에 대해 사이드카 프록시를 작동하는 것과 동일하게 됩니다.

게이트웨이 배포

기존 배포 도구를 사용하는 사용자를 지원하기 위해 Anthos Service Mesh에서는 게이트웨이를 Istio로 배포하는 것과 동일한 방법인 IstioOperator, Helm, Kubernetes YAML을 지원합니다. 각 방법은 동일한 결과를 생성합니다. 사용자가 가장 익숙한 방법을 선택할 수 있지만, 수정이 쉽고 소스 제어에 하이드레이션된 매니페스트를 저장할 수 있으므로 Kubernetes YAML 방법을 사용하는 것이 좋습니다.

아직 없으면 게이트웨이의 네임스페이스를 만듭니다. GATEWAY_NAMESPACE를 네임스페이스의 이름으로 바꿉니다.
```
kubectl create namespace GATEWAY_NAMESPACE
```
게이트웨이 네임스페이스에서 버전 라벨을 적용하여 게이트웨이에서 자동 삽입을 사용 설정합니다. 버전 라벨은 사이드카 인젝터 웹훅에서 삽입된 프록시를 특정 제어 영역 버전과 연결하는 데 사용됩니다. 사용하는 버전 라벨은 Google 관리 제어 영역 또는 클러스터 내 제어 영역을 배포했는지에 따라 달라집니다.
Google 관리
Google 관리형 제어 영역의 경우 버전 라벨은 출시 채널에 해당합니다.

버전 라벨 채널

istio.io/rev=asm-managed 일반

istio.io/rev=asm-managed-rapid 신속

istio.io/rev=asm-managed-stable 정식

게이트웨이 네임스페이스는 서비스와 동일한 출시 채널에 있거나 다른 출시 채널에 있을 수 있습니다. 한 클러스터에서는 동일한 출시 채널을 사용하는 것이 좋습니다. 네임스페이스에 사용되는 출시 채널을 보려면 다음 안내를 따르세요.
```
kubectl get namespace NAMESPACE -L istio.io/rev
```
클러스터 내
클러스터 내 제어 영역의 경우 istiod 서비스 및 배포에는 일반적으로 istio.io/rev=asm-1106-2과 유사한 버전 라벨이 있습니다. 여기서 asm-1106-2은 Anthos Service Mesh 버전을 식별합니다. 버전은 istiod 서비스 이름의 일부가 됩니다(예: istiod-asm-1106-2.istio-system).

다음 명령어를 사용하여 클러스터 제어 영역에 대해 istiod에서 버전 라벨을 찾습니다.
```
kubectl get deploy -n istio-system -l app=istiod -o jsonpath="{.items[*].metadata.labels.'istio\.io\/rev'}"'{"\n"}'
```
네임스페이스의 삽입을 사용 설정합니다. REVISION을 버전 라벨의 값으로 바꿉니다.
```
kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
```
출력에서 "istio-injection not found" 메시지는 무시해도 됩니다. 즉, 네임스페이스에 이전에 istio-injection 라벨이 사용되지 않았으며, Anthos Service Mesh를 새로 설치하거나 새로 배포해야 합니다. 네임스페이스에 istio-injection 및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든 kubectl label 명령어에는 istio-injection 라벨 삭제가 포함됩니다.
asmcli를 사용하여 Anthos Service Mesh를 설치한 경우 --output_dir에서 지정한 디렉터리로 변경한 다음 cd를 samples 디렉터리로 변경합니다.

중요: 올바른 samples 디렉터리에 있는지 확인합니다. ls 명령어를 사용하여 디렉터리 콘텐츠를 나열하고 다음 단계에서 액세스할 gateways 디렉터리 및 online-boutique 디렉터리가 있는지 확인합니다.

asmcli를 사용하여 설치하지 않은 경우 anthos-service-mesh 저장소에서 게이트웨이의 구성 파일을 복사합니다.
samples/gateways/ 디렉터리에 있는 예시 게이트웨이 구성을 있는 그대로 배포하거나 필요에 따라 수정할 수 있습니다.
인그레스
```
kubectl apply -n GATEWAY_NAMESPACE -f gateways/istio-ingressgateway
```
이그레스
```
kubectl apply -n GATEWAY_NAMESPACE -f gateways/istio-egressgateway
```

버전 라벨	채널
`istio.io/rev=asm-managed`	일반
`istio.io/rev=asm-managed-rapid`	신속
`istio.io/rev=asm-managed-stable`	정식

배포를 만든 후에 새 서비스가 올바르게 작동하는지 확인합니다.

kubectl get pod,service -n GATEWAY_NAMESPACE

출력이 다음과 비슷한지 확인합니다.

NAME                                      READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s

NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

게이트웨이 선택기

istio-ingressgateway 및 istio-egressgateway 프록시에 게이트웨이 구성을 적용하면 어떤 트래픽을 메시로 보내고 내보낼지 지정하여 메시의 인바운드 및 아웃바운드 트래픽을 관리할 수 있습니다. 게이트웨이 배포 포드의 라벨은 게이트웨이 구성 리소스에서 사용되므로 게이트웨이 선택기가 이러한 라벨과 일치하는 것이 중요합니다.

예를 들어 위 배포에서 istio=ingressgateway 라벨은 게이트웨이 포드에 설정됩니다. 이러한 배포에 게이트웨이 구성을 적용하려면 동일한 라벨을 선택해야 합니다.

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
...

게이트웨이 구성 및 가상 서비스 예시는 Online Boutique 샘플 애플리케이션에서 frontend.yaml을 참조하세요.

게이트웨이 업그레이드

인플레이스 업그레이드

대부분의 사용 사례에서는 인플레이스 업그레이드 패턴에 따라 게이트웨이를 업그레이드해야 합니다. 게이트웨이는 포드 삽입을 사용하므로, 생성된 새 게이트웨이 포드는 버전을 포함하는 최신 구성으로 자동 삽입됩니다.

게이트웨이에서 사용 중인 제어 영역 버전을 변경하려면 게이트웨이 배포에서 istio.io/rev 라벨을 설정합니다. 이렇게 하면 순차적 재시작도 트리거됩니다.

Google 관리형 제어 영역
Google이 Google 관리 제어 영역의 제어 영역 업그레이드를 관리하므로 게이트웨이 배포를 다시 시작하기만 하면 새 포드가 최신 구성 및 버전으로 삽입됩니다.

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

클러스터 내 제어 영역
클러스터 내 제어 영역이 있을 때 게이트웨이에 동일한 패턴을 적용하려면 게이트웨이에서 사용되는 제어 영역 버전을 변경해야 합니다. 게이트웨이 배포에서 순차적 재시작을 트리거하는 istio.io/rev 라벨을 설정합니다.

네임스페이스 또는 게이트웨이 포드의 버전 라벨을 업데이트합니다.
- 삽입하도록 네임스페이스에 라벨을 지정한 경우 다음 안내를 따릅니다.
- 네임스페이스의 istio.io/rev 라벨을 새로운 버전 값으로 설정합니다.

kubectl label namespace GATEWAY_NAMESPACE \
  istio-injection- istio.io/rev=REVISION \
  --overwrite

또는

게이트웨이 포드에만 삽입을 사용 설정한 경우:
- 배포의 istio.io/rev 라벨을 새로운 버전 값으로 설정합니다.
  - Kubernetes YAML

cat <<EOF > gateway-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Anthos Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
EOF

kubectl apply -f gateway-deployment.yaml

카나리아 업그레이드(고급)

클러스터 내 제어 영역을 사용 중이고 새 제어 영역 버전의 출시를 더 느리게 제어하려면 카나리아 업그레이드 패턴을 따를 수 있습니다. 게이트웨이 배포의 여러 버전을 실행하고 트래픽 일부에서 모두 예상한 대로 작동하는지 확인할 수 있습니다. 예를 들어 새 버전을 카나리아로 출시하려면 istio.io/rev=REVISION 라벨을 새 버전 및 새 이름으로 설정하여 게이트웨이 배포 복사본을 만듭니다(예: istio-ingressgateway-canary).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway-canary
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION # Set to the control plane revision you want to deploy
    spec:
      containers:
      - name: istio-proxy
        image: auto

이 배포가 생성되면 두 가지 버전의 게이트웨이가 생기고, 두 버전은 모두 동일한 서비스에서 선택됩니다.

kubectl get endpoints -o "custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name"

NAME                   PODS
istio-ingressgateway   istio-ingressgateway-788854c955-8gv96,istio-ingressgateway-canary-b78944cbd-mq2qf

애플리케이션이 예상한 대로 작동하면 다음 명령어를 사용해서 이전 istio.io/rev 라벨이 설정된 배포를 삭제하여 새 버전으로 전환합니다.

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

새 버전의 게이트웨이를 사용해서 애플리케이션을 테스트할 때 문제가 발생한 경우 다음 명령어를 사용해서 새 istio.io/rev 라벨이 설정된 배포를 삭제하여 이전 버전으로 다시 전환합니다.

kubectl delete deploy/istio-ingressgateway-canary -n GATEWAY_NAMESPACE

게이트웨이 설치 및 업그레이드

게이트웨이 배포 권장사항

게이트웨이 배포

Google 관리

클러스터 내

인그레스

이그레스

게이트웨이 선택기

게이트웨이 업그레이드

인플레이스 업그레이드

카나리아 업그레이드(고급)