Anthos Service Mesh를 사용하여 사이드카 프록시 삽입

이 문서에서는 Anthos Service Mesh를 사용하여 사이드카 프록시 삽입을 구성하여 네트워크 보안, 안정성, 관측 가능성을 개선하는 방법을 설명합니다. 이러한 기능이 애플리케이션의 기본 컨테이너에서 추상화되고 동일한 포드에서 별도의 컨테이너로 제공되는 프로세스 외부의 공통 프록시로 구현됩니다. 여기서는 서비스 메시에 참여하도록 프로덕션 애플리케이션을 재설계하지 않아도 Anthos Service Mesh의 기능을 제공합니다.

Anthos Service Mesh가 워크로드의 pod에 구성한 네임스페이스 라벨을 감지하면 자동 사이드카 프록시 삽입(자동 삽입)이 발생합니다. 프록시는 워크로드에 대한 모든 인바운드 및 아웃바운드 트래픽을 가로채고 Anthos Service Mesh와 통신합니다.

이 태스크에 필요한 권한

이 페이지에서 태스크를 수행하려면 roles/container.clusterAdmin 이상의 역할이 있어야 합니다. 이 역할에 포함된 권한에 대한 자세한 내용은 Google Kubernetes Engine 역할을 참조하세요.

자동 사이드카 삽입 사용 설정

권장되는 사이드카 프록시 삽입 방법은 pod의 Kubernetes 구성을 수동으로 업데이트할 수 있도록 웹훅 기반 자동 사이드카 인젝터를 사용하는 것입니다.

자동 삽입을 사용 설정하려면 네임스페이스에 기본 삽입 라벨을 지정하거나(기본 태그가 설정되어 있는 경우), 버전 라벨을 네임스페이스에 지정합니다. 추가하는 라벨은 관리형 Anthos Service Mesh를 배포했는지(Fleet API 또는 asmcli 사용) 또는 클러스터 내 제어 영역을 설치했는지 여부에 따라 다릅니다. 라벨은 사이드카 인젝터 웹훅에서 삽입된 사이드카를 특정 제어 영역 버전과 연결하는 데 사용됩니다.

자동 삽입을 사용 설정하려면 다음을 실행하세요.

클러스터 내

다음 명령어를 사용하여 istiod에서 버전 라벨을 찾습니다.

kubectl -n istio-system get pods -l app=istiod --show-labels

출력은 다음과 유사합니다.

NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-1157-23-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1157-23,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1157-23-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1157-23,istio=istiod,pod-template-hash=5788d57586

출력의 LABELS 열 아래에서 istio.io/rev= 프리픽스 다음에 있는 istiod 버전 라벨의 값을 확인합니다. 이 예시에서 값은 asm-1157-23입니다.

참고: 기본 태그가 구성된 경우 istio.io/rev 대신 istio-injection=enabled 라벨을 사용할 수 있습니다. OUTPUT_DIR에서 istioctl로 istioctl tag list를 실행하여 기본 태그가 있는지 확인합니다.

네임스페이스에 버전 라벨을 적용하고 istio-injection 라벨을 삭제합니다(있는 경우). 다음 명령어에서 NAMESPACE는 자동 삽입을 사용 설정할 네임스페이스의 이름이며 REVISION은 이전 단계에서 표시된 버전 라벨입니다.
```
kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite
```
출력에서 "istio-injection not found" 메시지는 무시해도 됩니다. 즉, 네임스페이스에 이전에 istio-injection 라벨이 사용되지 않았으며, Anthos Service Mesh를 새로 설치하거나 새로 배포해야 합니다. 네임스페이스에 istio-injection 및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든 kubectl label 명령어는 두 라벨을 모두 명시적으로 지정합니다.
다음 섹션의 단계를 사용하여 영향을 받는 pod를 다시 시작합니다.

관리형 서비스 메시

다음 명령어를 사용하여 사용 가능한 출시 채널을 찾습니다.
```
kubectl -n istio-system get controlplanerevision
```
출력은 다음과 비슷합니다.
```
NAME                AGE
asm-managed         6d7h
```
출력에서 Anthos Service Mesh 버전에 사용 가능한 출시 채널에 해당하는 REVISION 라벨인 NAME 열 아래의 값을 선택합니다. 이 라벨을 네임스페이스에 적용하고 istio-injection 라벨(있는 경우)을 삭제합니다. 다음 명령어에서 REVISION을 위에서 확인된 버전 라벨로 바꾸고 NAMESPACE 를 자동 삽입을 사용 설정하려는 네임스페이스 이름으로 바꿉니다.
```
kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite
```
출력에서 "istio-injection not found" 메시지는 무시해도 됩니다. 즉, 네임스페이스에 이전에 istio-injection 라벨이 사용되지 않았으며, Anthos Service Mesh를 새로 설치하거나 새로 배포해야 합니다. 네임스페이스에 istio-injection 및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든 kubectl label 명령어는 두 라벨을 모두 명시적으로 지정합니다.
다음 섹션의 단계를 사용하여 영향을 받는 pod를 다시 시작합니다.
선택사항인 Google 관리 데이터 영역도 배포한 경우 다음과 같이 demo 네임스페이스에 주석을 추가합니다.
```
kubectl annotate --overwrite namespace YOUR_NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'
```

pod를 다시 시작하여 사이드카 프록시 업데이트

자동 사이드카 삽입을 사용하면 pod를 다시 시작하여 기존 pod의 사이드카를 업데이트할 수 있습니다.

pod를 다시 시작하는 방법은 pod가 배포의 일부로 생성되었는지에 따라 달라집니다.

배포를 사용한 경우 사이드카가 있는 모든 pod가 다시 시작되도록 배포를 다시 시작합니다.
```
kubectl rollout restart deployment -n YOUR_NAMESPACE
```
배포를 사용하지 않은 경우, pod를 삭제하면 사이드카로 자동으로 재생성됩니다.
```
kubectl delete pod -n YOUR_NAMESPACE --all
```
네임스페이스의 모든 pod에 사이드카가 삽입되어 있는지 확인합니다.
```
kubectl get pod -n YOUR_NAMESPACE
```
위 명령어의 결과로 반환된 다음 출력 예시의 경우 READY 열에서 각 워크로드마다 컨테이너가 2개(기본 컨테이너와 사이드카 프록시 컨테이너)가 있다는 것을 확인할 수 있습니다.
```
NAME                    READY   STATUS    RESTARTS   AGE
YOUR_WORKLOAD           2/2     Running   0          20s
...
```

다음 단계

다음에 대해 자세히 알아보기