서비스 프로파일 설정
서비스 프로파일 설정 (Setting Up Service Profiles)
서비스 프로파일(ServiceProfile)로 Linkerd에 서비스에 대한 추가 정보를 제공하고, 라우트별 메트릭·재시도·타임아웃을 구성하는 방법을 알아봐요.
본문
경고
Linkerd 2.16부터 ServiceProfiles는 라우트별 메트릭, 타임아웃 지정, 재시도 지정을 포함해 Gateway API 타입으로 완전히 대체됐어요. 서비스 프로파일은 하위 호환성을 위해 계속 지원되지만, 더 이상의 기능 개발은 이루어지지 않아요.
서비스 프로파일은 Linkerd에 서비스에 대한 추가 정보와, 해당 서비스의 요청을 처리하는 방법을 제공해요.
Linkerd 프록시가 HTTP(HTTPS 아님) 요청을 받으면 그 요청의 destination service가 식별돼요. 해당 대상 서비스에 대한 서비스 프로파일이 존재하면, 그 서비스 프로파일을 사용해 라우트별 메트릭, 재시도, 타임아웃을 제공해요.
요청의 destination service는 l5d-dst-override, :authority, Host 중 존재하는 첫 번째 헤더의 값을 선택해 계산해요. 포트 구성 요소(콜론 포함, 포함된 경우)는 제거돼요. 그 값은 완전한 DNS 이름으로 매핑돼요. destination service가 보내는 쪽이나 받는 쪽의 네임스페이스에 있는 서비스 프로파일의 이름과 일치하면, Linkerd는 이를 추가 기능에 사용해요.
때로는 통제하지 않는 네임스페이스에 있는 서비스에 대해 서비스 프로파일을 정의해야 하는 경우가 있어요. 그럴 때는 평소처럼 서비스 프로파일을 만들되, 서비스 프로파일의 네임스페이스를 서비스를 호출하는 pod의 네임스페이스로 수정하면 돼요. Linkerd가 서비스에 요청을 프록시할 때, 소스 네임스페이스의 서비스 프로파일이 대상 네임스페이스의 서비스 프로파일보다 우선해요.
destination service가 ExternalName 서비스일 수 있어요. 그런 경우 spec.metadata.name과 spec.metadata.namespace 값을 사용해 ServiceProfile의 이름을 지어요. 예를 들어,
apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: prod
spec:
type: ExternalName
externalName: my.database.example.com
이 경우 ServiceProfile의 이름으로 my-service.prod.svc.cluster.local을 사용해요.
현재로서는 이 ServiceProfile의 라우트에 대해 수집된 통계를 웹 대시보드에서 볼 수 없다는 점을 주의하세요. 통계는 CLI를 사용해 얻을 수 있어요.
전체 데모 워크스루는 books 데모를 확인하세요.
linkerd profile로 서비스 프로파일을 만드는 방법에는 몇 가지가 있어요.
- Swagger
- Protobuf
- 자동 생성 (Auto-Creation)
- 템플릿 (Template)
라우트와 연결된 요청에는 rt_route 어노테이션이 붙어요. 요청이 올바르게 연결되는지 수동으로 확인하려면 자신의 디플로이먼트에서 tap을 실행하세요.
linkerd viz tap -o wide | grep req
출력은 deploy/webapp이 받고 있는 요청을 실시간으로 스트리밍해요. 예시는 다음과 같아요.
req id=0:1 proxy=in src=10.1.3.76:57152 dst=10.1.3.74:7000 tls=disabled :method=POST :authority=webapp.default:7000 :path=/books/2878/edit src_res=deploy/traffic src_ns=foobar dst_res=deploy/webapp dst_ns=default rt_route=POST /books/{id}/edit
반대로 rt_route가 없다면 요청이 어떤 라우트와도 연결되지 않았다는 뜻이에요. 실행해 보면:
linkerd viz tap -o wide | grep req | grep -v rt_route
Swagger
서비스에 대한 OpenAPI(Swagger) 스펙이 있다면 --open-api 플래그를 사용해 OpenAPI 스펙 파일로 서비스 프로파일을 생성할 수 있어요.
linkerd profile --open-api webapp.swagger webapp
이 명령은 webapp 서비스에 대해 webapp.swagger OpenAPI 스펙 파일에서 서비스 프로파일을 생성해요. 생성된 서비스 프로파일은 kubectl apply로 바로 파이프할 수 있고 서비스의 네임스페이스에 설치돼요.
linkerd profile --open-api webapp.swagger webapp | kubectl apply -f -
Protobuf
서비스에 대한 protobuf 형식이 있다면 --proto 플래그로 서비스 프로파일을 생성할 수 있어요.
linkerd profile --proto web.proto web-svc
이 명령은 web-svc 서비스에 대해 web.proto 형식 파일에서 서비스 프로파일을 생성해요. 생성된 서비스 프로파일은 kubectl apply로 바로 파이프할 수 있고 서비스의 네임스페이스에 설치돼요.
자동 생성 (Auto-Creation)
OpenAPI 스펙이나 protobuf 형식이 없는 경우가 흔해요. 라이브 트래픽을 관찰해서 서비스 프로파일을 생성할 수도 있어요. 이는 tap 데이터를 기반으로 하며, 서비스 프로파일이 무엇을 해줄 수 있는지 이해하는 훌륭한 방법이에요. 이 생성 과정을 시작하려면 --tap 플래그를 사용하면 돼요.
linkerd viz profile -n emojivoto web-svc --tap deploy/web --tap-duration 10s
이 명령은 이 명령이 실행되는 10초 동안 deploy/web으로 관찰된 트래픽으로 서비스 프로파일을 생성해요. 생성된 서비스 프로파일은 kubectl apply로 바로 파이프할 수 있고 서비스의 네임스페이스에 설치돼요.
템플릿 (Template)
서비스 프로파일을 자동 생성하는 모든 방법과 함께, 라우트를 수동으로 추가할 수 있는 템플릿을 얻을 수도 있어요. 템플릿을 생성하려면 다음을 실행하세요.
linkerd profile -n emojivoto web-svc --template
이 명령은 수동으로 업데이트할 수 있는 예시가 포함된 서비스 프로파일 템플릿을 생성해요. 서비스 프로파일을 업데이트한 후 kubectl apply를 사용해 클러스터의 서비스 네임스페이스에 설치하면 돼요.