Kubernetes에서 장애 조치 서비스 구성

Kubernetes에서 장애 조치 서비스 구성 (Configure failover services on Kubernetes)

이 주제에서는 프록시가 투명 프록시(transparent proxy) 모드일 때 Consul on Kubernetes에서 장애 조치(failover) 서비스 인스턴스를 구성하는 방법을 설명해요. 서비스가 비정상이 되거나 응답하지 않으면 Consul이 service resolver 구성 항목을 사용하여 인바운드 요청을 백업 서비스로 보낼 수 있어요.

출처: 문서

본문

이 주제에서는 프록시가 투명 프록시 모드일 때 Consul on Kubernetes에서 장애 조치 서비스 인스턴스를 구성하는 방법을 설명합니다. 서비스가 비정상이 되거나 응답하지 않으면 Consul이 service resolver 구성 항목을 사용하여 인바운드 요청을 백업 서비스로 보낼 수 있습니다. Service resolver는 서비스 메시 프록시 업스트림 발견 체인(discovery chain)의 일부입니다. 자세한 내용은 Service mesh traffic management을 참조하세요.

개요 (Overview)

프록시가 투명 프록시 모드일 때 Consul on Kubernetes에서 장애 조치 서비스 인스턴스를 구성하려면 다음 단계를 완료하세요:

service resolver 구성 항목 만들기
다운스트림 서비스가 기본 및 장애 조치 서비스 인스턴스에 액세스할 수 있게 하는 의도(intentions) 만들기
Consul DNS 또는 KubeDNS를 사용하여 발견 체인을 호출하도록 애플리케이션 구성

요구 사항 (Requirements)

consul-k8s v1.2.0 이상.
Consul 서비스 메시가 활성화되어 있어야 합니다. Kubernetes에서 Consul Service Mesh 작동 방식을 참조하세요.
프록시가 투명 프록시 모드로 실행되도록 구성되어 있어야 합니다.
가상 DNS 이름을 쿼리하려면 Consul DNS를 사용해야 합니다.
KubeDNS를 사용하여 발견 체인을 쿼리하려면 service resolver가 실행 중인 서비스와 동일한 파티션에 있어야 합니다.

ACL 요구 사항 (ACL requirements)

Consul Helm 차트가 구성하는 기본 ACL은 대부분의 경우에 적합하지만, Consul API 액세스에 대한 더 복잡한 보안 정책이 있는 경우 ACL 문서를 참조하세요.

service resolver 구성 항목 만들기 (Create a service resolver configuration entry)

service resolver 구성 항목의 spec.failover.targets 필드에 대상 장애 조치를 지정합니다. 다음 예제에서 api-beta 서비스는 모든 서비스 하위 집합에서 api 서비스로 장애 조치하도록 구성됩니다:

api-beta-failover.yaml

apiversion: consul.hashicorp.com/v1alpha1
kind: ServiceResolver
metadata:
  name: api-beta
spec:
  failover:
    '*':
      targets:
        - service: api

모든 service resolver 구성에 대한 정보는 service resolver 구성 항목 참조 문서를 참조하세요.

kubectl apply 명령으로 구성을 적용할 수 있습니다:

$ kubectl apply -f api-beta-failover.yaml

서비스 의도 만들기 (Create service intentions)

의도가 아직 정의되지 않은 경우, 적절한 다운스트림이 대상 서비스와 장애 조치 서비스에 액세스할 수 있게 하는 의도를 만들고 적용하세요. 다음 예제에서 frontend 서비스는 api 서비스에 메시지를 보낼 수 있고, api 서비스는 api-beta 장애 조치 서비스에 메시지를 보낼 수 있습니다.

frontend-api-api-beta-allow.yaml

apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceIntentions
metadata:
  name: api
spec:
  destination:
    name: api
      sources:
        - name: frontend
     action: allow
---
apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceIntentions
metadata:
  name: api-beta
spec:
  destination:
    name: api-beta
      sources:
   - name: frontend
     action: allow

서비스 의도 구성에 대한 자세한 내용은 service intentions 구성 항목 참조를 참조하세요.

kubectl apply 명령으로 구성을 적용할 수 있습니다:

$ kubectl apply -f frontend-api-api-beta-allow.yaml

DNS를 호출하도록 애플리케이션 구성 (Configure your application to call the DNS)

Consul DNS 또는 KubeDNS에서 발견 체인에 접촉하도록 애플리케이션을 구성하세요.

Consul DNS

<service>.virtual.consul 조회 형식을 사용하여 Consul DNS를 쿼리할 수 있습니다. Consul Enterprise의 경우 쿼리 문자열에 namespace, partition 또는 둘 다를 포함해야 할 수 있습니다. 가상 서비스 조회 구축에 대한 자세한 내용은 DNS 문서를 참조하세요.

다음 예제에서 애플리케이션은 HTTP를 통해 api-beta를 Consul 카탈로그에 쿼리합니다. 기본적으로 조회는 Consul Enterprise가 네트워크 인프라를 관리하는 경우 default 파티션과 default namespace를 쿼리합니다:

http://api-beta.virtual.consul/

KubeDNS

장애 조치 서비스가 기본 서비스와 동일한 Kubernetes 클러스터에 있으면 KubeDNS를 쿼리할 수 있습니다. 다음 예제에서 애플리케이션은 HTTP를 통해 api-beta를 KubeDNS에 쿼리합니다:

http://api-beta.<namespace>.svc.cluster.local

해당하는 Kubernetes 서비스와 포드가 없으면 KubeDNS를 사용할 수 없습니다.

Kubernetes에서 장애 조치 서비스 구성