이 페이지에서는 GKE Ingress의 핵심 기능과 네트워킹 아키텍처를 설명합니다. 특히 클라이언트에서 부하 분산기로, 부하 분산기에서 애플리케이션 포드로의 연결을 보호하고, 여러 백엔드 서비스 간의 복잡한 라우팅을 관리하고, 클러스터 내에서 부하 분산기 상태 점검이 오케스트레이션되는 방식을 이해합니다.
이 페이지에서는 GKE 인그레스 개요에 설명된 기본 개념을 기반으로 합니다. FrontendConfig 및 BackendConfig와 같은 커스텀 리소스를 사용하는 단계별 안내 및 구현 예시는 GKE 애플리케이션의 인그레스 기능 구성을 참고하세요.
이 페이지는 조직의 네트워크를 계획 및 설계하고 네트워크 장비를 설치, 구성, 지원하는 네트워킹 전문가를 대상으로 합니다.Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참조하세요.
HTTPS로 인그레스 보안
GKE 인그레스는 클라이언트와 애플리케이션 부하 분산기 간의 트래픽과 부하 분산기에서 애플리케이션 포드로의 트래픽을 보호합니다.
클라이언트와 부하 분산기 간 TLS 구성
HTTP(S) 부하 분산기는 클라이언트와 애플리케이션 사이의 프록시 역할을 합니다. 클라이언트의 HTTPS 요청을 수락하려는 경우, 부하 분산기에 인증서가 있어야 부하 분산기가 클라이언트에게 ID를 증명할 수 있습니다. HTTPS 핸드셰이크를 완료하려면 부하 분산기에 비공개 키도 있어야 합니다.
부하 분산기가 클라이언트의 HTTPS 요청을 수락하면 클라이언트와 부하 분산기 간 트래픽은 TLS를 사용하여 암호화됩니다. 하지만 부하 분산기는 TLS 암호화를 종료하고 암호화 없이 요청을 애플리케이션에 전달합니다. 자세한 내용은 부하 분산기와 애플리케이션 간 암호화 구성을 참고하세요.
SSL 인증서 제공 방법
다음 방법을 사용하여 HTTP(S) 부하 분산기에 SSL 인증서를 제공할 수 있습니다.
Google 관리형 인증서: Google에서 도메인 이름을 프로비저닝, 갱신, 관리하는 도메인 유효성 검사 (DV) 인증서입니다. 이 인증서에는 개인 또는 조직의 ID가 표시되지 않습니다. Google 관리 인증서는 와일드 카드가 아닌 도메인을 최대 100개까지 지원합니다. 자세한 내용은 Google 관리형 인증서 사용을 참고하세요.
Google Cloud와 공유되는 자체 관리형 인증서: 자체 SSL 인증서를 프로비저닝하고 Google Cloud 프로젝트에 인증서 리소스를 만들 수 있습니다. 그런 다음 인그레스의 주석에 인증서 리소스를 나열하여 인증서를 사용하는 HTTP(S) 부하 분산기를 만듭니다. 자세한 내용은 사전 공유된 인증서 사용을 참고하세요.
Kubernetes 보안 비밀을 사용하는 자체 관리형 인증서: 자체 SSL 인증서를 프로비저닝하고 저장할 보안 비밀을 만들 수 있습니다. 그런 다음 인그레스 매니페스트의
tls필드에서 보안 비밀을 참조하여 HTTP(S) 부하 분산기를 만들 수 있습니다. 자세한 내용은 Kubernetes 보안 비밀 사용을 참고하세요.
여러 인증서로 HTTPS 트래픽 제공
최대 15개의 TLS 인증서를 클라이언트에 제공하도록 애플리케이션 부하 분산기를 구성할 수 있습니다. 여러 인증서를 사용하는 것은 서로 다른 인증서가 필요한 여러 호스트 이름에서 콘텐츠를 제공해야 하는 경우에 필수적입니다 (예: your-store.example과 your-experimental-store.example에 별도의 인증서). 인그레스 매니페스트 내에서 이러한 여러 인증서를 지정합니다.
인증서 선택 및 우선순위
부하 분산기는 클라이언트에 제공할 인증서를 결정하기 위해 서버 이름 표시 (SNI)를 사용합니다.
클라이언트가 SNI를 사용하거나 사용 가능한 인증서 중 하나의 일반 이름(CN)과 일치하는 도메인 이름을 사용하는 경우 부하 분산기는 CN이 클라이언트가 요청한 호스트 이름과 가장 일치하는 인증서를 사용합니다.
클라이언트가 SNI를 지원하지 않거나 요청된 도메인 이름이 사용 가능한 인증서의 CN과 일치하지 않으면 부하 분산기는 인그레스 매니페스트에 나열된 첫 번째 인증서를 기본값으로 사용합니다. 부하 분산기는 다음 규칙에 따라 이 인증서를 선택합니다.
tls블록에 나열된 보안 비밀의 경우 기본 인증서는tls블록의 첫 번째 보안 비밀입니다.pre-shared-cert주석의 사전 공유 인증서: 기본 인증서는 주석에 나열된 첫 번째 인증서입니다.managed-certificates주석의 Google 관리형 인증서: 모든 관리형 인증서가 이름별로 알파벳순으로 정렬됩니다. 기본 인증서는 이 알파벳 목록에서 가장 먼저 나오는 인증서입니다. 특정 인증서를 기본으로 설정하려면 정렬 순서를 제어할 수 있도록ManagedCertificate객체 이름을 적절하게 지정해야 합니다. 예를 들어another-cert보다my-default-cert를 기본으로 설정하려면 이름을0-my-default-cert및1-another-cert로 지정하면 됩니다.
부하 분산기가 여러 GKE 메서드를 통해 여러 인증서를 제공하는 경우 사전 공유 인증서가 인그레스 tls 블록에 나열된 보안 비밀보다 우선시됩니다.
아래 다이어그램은 요청에서 사용되는 도메인 이름에 따라 트래픽을 다른 백엔드로 보내는 부하 분산기를 보여줍니다.
인증서 순환 권장사항
보안 비밀 또는 사전 공유 인증서의 콘텐츠를 순환하려면 다음 권장사항을 따르세요.
- 새 인증서 데이터가 포함된 새 보안 비밀 또는 사전 공유 인증서를 다른 이름으로 만듭니다. 새 인증서 리소스를 사용하도록 인그레스를 업데이트합니다.
- 트래픽 중단을 원하지 않으면 인그레스에서 이전 리소스를 삭제하고 이름은 같지만 콘텐츠가 다른 새 리소스를 프로비저닝한 후 인그레스에 다시 연결합니다.
인증서 순환을 직접 관리하지 않으려면 Google 관리 SSL 인증서를 사용하세요.
HTTPS 전용 트래픽 적용
클라이언트와 HTTP(S) 부하 분산기 사이의 모든 트래픽이 HTTPS를 사용하도록 하려면 인그레스 매니페스트에 kubernetes.io/ingress.allow-http 주석을 포함시키고 값을 "false"로 설정하여 HTTP를 사용 중지하면 됩니다. 자세한 내용은 HTTP 사용 중지를 참고하세요.
부하 분산기와 애플리케이션 간 암호화 구성
이 섹션에서는 부하 분산기에서 애플리케이션 포드로의 연결을 보호하는 방법을 설명합니다.
HTTPS 또는 HTTP/2 백엔드 프로토콜 사용 설정
외부 애플리케이션 부하 분산기는 클라이언트와 GKE 애플리케이션 사이의 프록시 역할을 합니다. 클라이언트는 HTTPS (암호화용) 및 다양한 프로토콜 (HTTP/1.1 또는 HTTP/2)을 사용하여 부하 분산기에 연결할 수 있지만 부하 분산기에서 백엔드 포드로의 연결은 기본적으로 암호화되지 않은 HTTP/1.1입니다.
애플리케이션에서 고급 구성을 처리할 수 있는 경우 다음을 사용하도록 외부 애플리케이션 부하 분산기를 수동으로 업데이트할 수 있습니다.
- HTTP/2: 포드가 지원하는 경우 성능을 최적화합니다.
- HTTPS (TLS): 부하 분산기 프록시와 포드 간 트래픽에 엔드 투 엔드 암호화를 적용합니다.
Kubernetes 서비스 매니페스트에서 cloud.google.com/app-protocols 주석을 사용하여 백엔드 연결에 사용되는 프로토콜 (HTTP 또는 HTTPS)과 HTTP 버전 (HTTP/1.1 또는 HTTP/2)을 모두 제어합니다.
컨테이너 기반 부하 분산을 사용하지 않는 한 이 서비스 매니페스트에는 type: NodePort가 포함되어야 합니다. 컨테이너 기반 부하 분산을 사용하는 경우 type: ClusterIP를 사용합니다.
HTTPS 부하 분산기용 고정 IP 주소
외부 애플리케이션 부하 분산기의 인그레스 객체를 만들면 클라이언트가 서비스 및 실행 중인 컨테이너에 액세스하는 데 사용할 수 있는 안정적인 외부 IP 주소를 얻게 됩니다. 이 IP 주소는 Ingress 객체의 수명 동안 지속된다는 점에서 안정적입니다. 인그레스를 삭제하고 동일한 매니페스트 파일에서 새 인그레스를 만드는 경우, 동일한 외부 IP 주소를 얻게 된다고 보장할 수 없습니다.
인그레스를 삭제하고 새 인그레스를 만들어도 동일하게 유지되는 영구 IP 주소를 원하면 전역 고정 외부 IP 주소를 예약해야 합니다. 그런 다음 인그레스 매니페스트에 예약된 고정 IP 주소의 이름을 제공하는 주석을 포함합니다. 기존 인그레스에서 임시 IP 주소 대신 고정 IP 주소를 사용하도록 수정하면 GKE가 부하 분산기의 전달 규칙을 다시 만들 때 부하 분산기의 IP 주소를 변경할 수 있습니다.
트래픽 라우팅
GKE 인그레스는 URL 맵을 사용하여 들어오는 요청이 특정 백엔드 서비스로 라우팅되는 방식을 정의합니다. 호스트 이름, URL 경로 또는 둘의 조합을 기반으로 라우팅 규칙을 구성하여 단일 부하 분산기를 통해 여러 애플리케이션의 트래픽을 관리할 수 있습니다.
여러 백엔드 서비스
각각의 외부 애플리케이션 부하 분산기 또는 내부 애플리케이션 부하 분산기는 하나 이상의 백엔드 서비스를 참조하는 단일 URL 맵을 사용합니다. 하나의 백엔드 서비스는 인그레스로 참조되는 각 서비스에 해당합니다.
예를 들어 URL 경로에 따라 서로 다른 백엔드 서비스로 요청을 라우팅하도록 부하 분산기를 구성할 수 있습니다. your-store.example로 전송되는 요청은 정가 품목을 표시하는 백엔드 서비스로 라우팅될 수 있고, your-store.example/discounted로 전송되는 요청은 할인 품목을 표시하는 백엔드 서비스로 라우팅될 수 있습니다.
호스트 이름에 따라 요청을 라우팅하도록 부하 분산기를 구성할 수도 있습니다. your-store.example로 전송되는 요청과 your-experimental-store.example로 전송되는 요청은 서로 다른 백엔드 서비스로 라우팅될 수 있습니다.
GKE 클러스터에서는 Kubernetes Ingress 객체를 만들어 HTTP(S) 부하 분산기를 만들고 구성합니다. 인그레스 객체는 각각 Pod 집합과 연결된 서비스 객체 한 개 이상과 연결되어야 합니다.
동일한 호스트에 여러 백엔드가 있는 GKE 인그레스를 구성하려면 단일 호스트와 여러 경로가 있는 단일 규칙이 있어야 합니다. 그렇지 않으면 GKE 인그레스 컨트롤러가 하나의 백엔드 서비스만 프로비저닝합니다.
다음은 my-ingress라는 인그레스의 매니페스트입니다.
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: your-store.example http: paths: - path: /products pathType: ImplementationSpecific backend: service: name: my-products port: number: 60000 - path: /discounted pathType: ImplementationSpecific backend: service: name: my-discounted-products port: number: 80
인그레스를 만들면 GKE 인그레스 컨트롤러는 인그레스 및 연결된 서비스에 있는 정보에 따라 외부 애플리케이션 부하 분산기 또는 내부 애플리케이션 부하 분산기를 만들고 구성합니다. 또한 부하 분산기에는 도메인 이름과 연결할 수 있는 안정적인 IP 주소가 제공됩니다.
앞의 예에서 부하 분산기의 IP 주소를 도메인 이름 your-store.example에 연결했다고 가정해 보세요. 클라이언트가 your-store.example/products에 요청을 전송하면 요청은 포트 60000에서 my-products라는 Kubernetes 서비스로 라우팅됩니다. 클라이언트가 your-store.example/discounted에 요청을 전송하면 요청은 포트 80에서 my-discounted-products라는 Kubernetes 서비스로 라우팅됩니다.
인그레스의 path 필드에서 지원되는 유일한 와일드카드 문자는 * 문자입니다. * 문자는 슬래시(/) 다음에 와야 하며, 패턴의 마지막 문자여야 합니다. 예를 들어 /*, /foo/*, /foo/bar/*는 유효한 패턴이지만, *, /foo/bar*, /foo/*/bar는 그렇지 않습니다.
보다 구체적인 패턴이 덜 구체적인 패턴보다 우선합니다. /foo/*와 /foo/bar/*가 있다면 /foo/bar/*에 맞춰 /foo/bar/bat가 사용됩니다.
경로 제한사항과 패턴 일치에 대한 자세한 내용은 URL 맵 문서를 참조하세요.
my-products 서비스의 매니페스트는 다음과 같습니다.
apiVersion: v1 kind: Service metadata: name: my-products spec: type: NodePort selector: app: products department: sales ports: - protocol: TCP port: 60000 targetPort: 50000
위 매니페스트에서 다음 사항에 유의하세요.
spec.type필드는 사용하는 부하 분산 방법에 따라 달라집니다.- 컨테이너 기반 부하 분산을 사용하는 경우
type: ClusterIP를 사용합니다. - 인스턴스 그룹을 사용하는 경우
type: NodePort을 사용합니다.
- 컨테이너 기반 부하 분산을 사용하는 경우
selector필드는app: products라벨과department: sales라벨이 모두 있는 포드가 이 서비스의 구성원임을 나타냅니다.포트 60000에서 서비스에 도달하는 요청은 TCP 포트 50000에서 구성원 Pod 중 하나로 라우팅됩니다.
각 구성원 Pod에는 TCP 포트 50000에서 리슨하는 컨테이너가 있어야 합니다.
my-discounted-products 서비스의 매니페스트는 다음과 같습니다.
apiVersion: v1 kind: Service metadata: name: my-discounted-products spec: type: NodePort selector: app: discounted-products department: sales ports: - protocol: TCP port: 80 targetPort: 8080
위 매니페스트에서 다음 사항에 유의하세요.
selector필드는app: discounted-products라벨과department: sales라벨이 모두 있는 Pod가 이 서비스의 구성원임을 나타냅니다.포트 80에서 서비스에 도달하는 요청은 TCP 포트 8080에서 구성원 Pod 중 하나로 라우팅됩니다.
각 구성원 Pod에는 TCP 포트 8080에서 리슨하는 컨테이너가 있어야 합니다.
기본 백엔드
인그레스 매니페스트에 spec.defaultBackend 필드를 제공하여 인그레스의 기본 백엔드를 지정할 수 있습니다. 이렇게 하면 rules 필드에 정의된 경로와 일치하지 않는 모든 요청이 처리됩니다. 예를 들어 다음 인그레스에서 /discounted와 일치하지 않는 요청은 포트 60001에서 my-products라는 서비스로 전송됩니다.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
defaultBackend:
service:
name: my-products
port:
number: 60001
rules:
- http:
paths:
- path: /discounted
pathType: ImplementationSpecific
backend:
service:
name: my-discounted-products
port:
number: 80
기본 백엔드를 지정하지 않으면 GKE은 404를 반환하는 기본 백엔드를 제공합니다. 이것은 kube-system 네임스페이스의 클러스터에 default-http-backend NodePort 서비스로 생성됩니다.
404 HTTP 응답은 다음과 비슷합니다.
response 404 (backend NotFound), service rules for the path non-existent
커스텀 기본 백엔드로 GKE 인그레스를 설정하려면 커스텀 기본 백엔드로 GKE 인그레스를 참고하세요.
상태 점검
기본 인그레스 컨트롤러를 사용하여 인그레스를 통해 서비스를 하나 이상 노출하면 GKE는기본 애플리케이션 부하 분산기 또는 내부 애플리케이션 부하 분산기를 만듭니다. 이러한 부하 분산기는 모두 단일 URL 맵에서 여러 백엔드 서비스를 지원합니다. 각 백엔드 서비스는 Kubernetes 서비스에 해당하며 각 백엔드 서비스가 Google Cloud 상태 점검을 참조해야 합니다. 상태 점검은 클러스터 외부에서 구현되기 때문에 Kubernetes 활성 또는 준비 프로브와 다릅니다.
부하 분산기 상태 점검은 백엔드 서비스별로 지정됩니다. 부하 분산기의 모든 백엔드 서비스에 대해 동일한 상태 점검을 사용할 수 있지만, 상태 점검 참조는 인그레스 객체 자체에서 전체 부하 분산기에 대해 지정되지 않습니다.
GKE는 다음 메서드 중 하나를 기반으로 상태 점검을 만듭니다.
BackendConfigCRD: 서비스가 부하 분산기와 상호작용하는 방식을 정밀하게 제어할 수 있는 커스텀 리소스 정의(CRD)입니다.BackendConfigCRD를 사용하면 해당 백엔드 서비스와 연결된 상태 점검에 대한 커스텀 설정을 지정할 수 있습니다. 이러한 커스텀 설정을 사용하면 기존 애플리케이션 부하 분산기와 인그레스에서 만든 내부 애플리케이션 부하 분산기 모두의 상태 점검을 보다 유연하게 제어할 수 있습니다.- 준비 프로브: 포드 내 컨테이너가 트래픽을 처리할 준비가 되었는지 확인하는 진단 검사입니다. GKE 인그레스 컨트롤러는 서비스의 서빙 포드에서 사용되는 준비 프로브를 기반으로 서비스의 백엔드 서비스에 대한 상태 점검을 만듭니다. 준비 프로브 정의에서 경로, 포트, 프로토콜과 같은 상태 점검 파라미터를 파생할 수 있습니다.
- 기본값:
BackendConfigCRD를 구성하지 않거나 준비 프로브의 속성을 정의하지 않을 때 사용되는 파라미터입니다.
BackendConfig CRD를 사용하여 부하 분산기 상태 점검 설정을 최대한 제어합니다.
GKE는 다음 절차에 따라 Kubernetes 서비스에 해당하는 각 백엔드 서비스에 대해 상태 점검을 만듭니다.
서비스가
healthCheck정보로BackendConfigCRD를 참조하는 경우, GKE는 이를 사용하여 상태 점검을 만듭니다. GKE Enterprise 인그레스 컨트롤러 및 GKE 인그레스 컨트롤러 모두 이 방식으로 상태 점검을 만들 수 있습니다.서비스가
BackendConfigCRD를 참조하지 않는 경우에는 다음과 같이 수행됩니다.GKE는 제공 pod가 상태 점검 매개변수로 해석될 수 있는 속성을 가진 준비 프로브가 있는 컨테이너와 함께 pod 템플릿을 사용하는 경우 상태 점검의 매개변수 일부 또는 전체를 추론할 수 있습니다. 구현 세부정보는 준비 프로브의 매개변수를, 상태 점검 매개변수를 만드는 데 사용할 수 있는 속성 목록은 기본 및 추론된 매개변수를 참조하세요. GKE 인그레스 컨트롤러만 준비 프로브의 추론 매개변수를 지원합니다.
서비스 서빙 포드의 포드 템플릿에 상태 점검 매개변수로 해석될 수 있는 준비 프로브가 있는 컨테이너가 없는 경우 기본값을 사용하여 상태 점검을 만듭니다. GKE Enterprise 인그레스 컨트롤러와 GKE 인그레스 컨트롤러는 기본값을 사용해서만 상태 점검을 만들 수 있습니다.
기본 및 추론된 매개변수
다음 매개변수는 BackendConfig CRD를 사용하여 상응하는 서비스의 상태 점검 매개변수를 지정하지 않는 경우에 사용됩니다.
| 상태 점검 매개변수 | 기본값 | 추론 가능 값 |
|---|---|---|
| 프로토콜 | HTTP | 서비스 주석 cloud.google.com/app-protocols에 제공된 경우
|
| 요청 경로 | / |
제공 pod의 spec에 있는 경우:containers[].readinessProbe.httpGet.path
|
| 요청 호스트 헤더 | Host: backend-ip-address |
제공 pod의 spec에 있는 경우:containers[].readinessProbe.httpGet.httpHeaders
|
| 예상 응답 | HTTP 200 (정상) | HTTP 200 (정상) 변경 불가 |
| 확인 간격 |
|
제공 Pod의 spec에 있는 경우:
|
| 제한 시간 확인 | 5초 | 제공 pod의 spec에 있는 경우:containers[].readinessProbe.timeoutSeconds |
| 정상 기준 | 1 | 1 변경 불가 |
| 비정상 기준 |
|
기본값과 동일:
|
| 포트 지정 |
|
다음 조건에 모두 해당하는 한 상태 점검 프로브는 spec.containers[].readinessProbe.httpGet.port에 지정된 포트 번호로 전송됩니다.
|
| 대상 IP 주소 |
|
기본값과 동일:
|
준비 프로브의 매개변수
GKE가 서비스의 백엔드 서비스에 대해 상태 점검을 만들 때, GKE는 해당 서비스의 제공 Pod에서 사용되는 한 컨테이너의 준비 프로브에서 특정 매개변수를 복사할 수 있습니다. 이 옵션은 GKE 인그레스 컨트롤러에서만 지원됩니다.
상태 점검 매개변수로 해석될 수 있는 지원되는 준비 프로브 속성은 기본 및 추론된 매개변수에 기본값과 함께 나열됩니다. 기본값은 준비 프로브에서 지정되지 않은 모든 속성이나 준비 프로브를 전혀 지정하지 않은 경우에 사용됩니다.
서비스의 서빙 포드에 여러 컨테이너가 포함되었거나 GKE Enterprise 인그레스 컨트롤러를 사용 중이면 BackendConfig CRD를 사용하여 상태 점검 매개변수를 정의해야 합니다. 자세한 내용은 BackendConfig CRD를 대신 사용해야 하는 경우를 참조하세요.
BackendConfig CRD를 대신 사용해야 하는 경우
다음 상황의 경우, 포드 준비 프로브의 매개변수에 의존하는 대신 서비스에서 BackendConfig CRD를 만들어 백엔드 서비스의 상태 점검 매개변수를 명시적으로 정의해야 합니다.
GKE Enterprise를 사용하는 경우: GKE Enterprise 인그레스 컨트롤러는 서빙 포드의 준비 프로브에서 상태 점검 매개변수 가져오기를 지원하지 않습니다. 암시적 매개변수를 사용하거나
BackendConfigCRD에 정의된 대로만 상태 점검을 만들 수 있습니다.제공 포드에 컨테이너가 두 개 이상 있는 경우: GKE에는 상태 점검 매개변수를 추론할 특정 컨테이너의 준비 프로브를 선택할 방법이 없습니다. 각 컨테이너에는 자체 준비 프로브가 있을 수 있고 준비 프로브가 컨테이너에 필요한 매개변수가 아니기 때문에 해당 서비스에서
BackendConfigCRD를 참조하여 해당 백엔드 서비스에 대한 상태 점검을 정의해야 합니다.부하 분산기의 상태 점검에 사용되는 포트를 제어해야 하는 경우: GKE가 백엔드 서비스의 상태 점검에 준비 프로브의
containers[].readinessProbe.httpGet.port를 사용하는 것은 인그레스spec.rules[].http.paths[].backend.servicePort에서 참조되는 서비스의 서비스 포트와 일치하는 경우에만 가능합니다.
BackendConfig CRD의 매개변수
해당 서비스에서 참조하는 BackendConfig CRD의 healthCheck 매개변수를 사용하여 백엔드 서비스의 상태 점검 매개변수를 지정할 수 있습니다. 이렇게 하면 인그레스에서 만든 기본 애플리케이션 부하 분산기나 내부 애플리케이션 부하 분산기의 상태 점검을 보다 유연하게 제어할 수 있습니다. GKE 버전 호환성은 인그레스 구성을 참조하세요.
이 BackendConfig CRD 예시는 spec.healthCheck 속성에서 상태 점검 프로토콜(유형), 요청 경로, 포트, 확인 간격을 정의합니다.
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: http-hc-config
spec:
healthCheck:
checkIntervalSec: 15
port: 15020
type: HTTPS
requestPath: /healthz
BackendConfig 상태 점검을 구성할 때 사용 가능한 모든 필드를 구성하려면 커스텀 상태 점검 구성 예시를 사용합니다.
커스텀 HTTP 상태 점검을 사용하여 GKE 인그레스를 설정하려면 커스텀 HTTP 상태 점검으로 GKE 인그레스를 참조하세요.
포드 준비
앞의 방법 중 하나를 사용하여 부하 분산기의 상태 점검을 구성하면 GKE 인그레스 컨트롤러는 백엔드 엔드포인트의 상태를 사용하여 Pod 준비 상태를 확인합니다. 이는 순차적 업데이트 및 전체 트래픽 안정성을 관리하는 데 중요합니다.
관련 포드의 경우 해당 인그레스 컨트롤러는 cloud.google.com/load-balancer-neg-ready 유형의 준비 게이트를 관리합니다. 인그레스 컨트롤러는 NEG에 있는 모든 엔드포인트 상태를 포함하여 부하 분산기의 상태 점검 상태를 폴링합니다. 부하 분산기의 상태 점검 상태가 특정 포드에 해당하는 엔드포인트가 정상임을 나타내면 인그레스 컨트롤러는 포드의 준비 게이트 값을 True로 설정합니다.
이 준비 게이트의 값과 포드의 준비 프로브(정의된 경우)를 고려하여 각 노드에서 실행되는 kubelet이 포드의 유효 준비를 계산합니다.
포드 준비 게이트는 인그레스를 통해 컨테이너 기반 부하 분산을 사용할 때 자동으로 사용 설정됩니다.
준비 게이트는 순차적 업데이트 속도를 관리합니다. 순차적 업데이트를 시작하면 GKE에서 새 포드를 만들 때 각 새 포드의 엔드포인트가 NEG에 추가됩니다. 엔드포인트가 부하 분산기의 관점에서 정상이면 인그레스 컨트롤러는 준비 게이트를 True로 설정합니다. 따라서 새로 만든 포드는 GKE에서 이전 포드를 제거하기 전에 최소한 준비 게이트를 통과해야 합니다. 이렇게 하면 포드의 해당 엔드포인트가 이미 부하 분산기의 상태 점검을 통과하고 백엔드 용량이 유지되도록 할 수 있습니다.
컨테이너 이미지가 잘못되었거나 부하 분산기 상태 점검이 잘못 구성되어 포드의 준비 게이트가 포드가 준비되었음을 나타내지 않으면 부하 분산기가 트래픽을 새 포드로 전송하지 않습니다. 업데이트된 배포를 롤아웃하는 동안 이러한 오류가 발생하면 포드의 준비 게이트가 True가 아니므로 새 포드를 만들려고 시도할 때 롤아웃이 중지됩니다. 이 상황을 감지하고 해결하는 방법은 문제 해결 섹션을 참조하세요.
컨테이너 기반 부하 분산 및 준비 게이트가 없으면 GKE는 포드를 준비 상태로 표시하기 전에 부하 분산기의 엔드포인트가 정상인지 감지할 수 없습니다. 이전 Kubernetes 버전에서는 지연 기간(배포 사양에서 minReadySeconds)을 지정하여 포드가 삭제되고 대체되는 속도를 관리합니다.
GKE는 다음 조건 중 하나가 충족되면 포드의 cloud.google.com/load-balancer-neg-ready 값을 True로 설정합니다.
- 포드의 IP 주소가 GKE 컨트롤 플레인에서 관리하는
GCE_VM_IP_PORTNEG의 엔드포인트가 아닙니다. - 하나 이상의 포드 IP 주소는 GKE 컨트롤 플레인에서 관리되는
GCE_VM_IP_PORTNEG의 엔드포인트입니다. NEG는 백엔드 서비스에 연결됩니다. 백엔드 서비스에는 성공한 부하 분산기 상태 점검이 포함됩니다. - 하나 이상의 포드 IP 주소는 GKE 컨트롤 플레인에서 관리되는
GCE_VM_IP_PORTNEG의 엔드포인트입니다. NEG는 백엔드 서비스에 연결됩니다. 백엔드 서비스에 대한 부하 분산기 상태 점검은 시간 초과됩니다. - 하나 이상의 포드 IP 주소는 하나 이상의
GCE_VM_IP_PORTNEG의 엔드포인트입니다. NEG가 백엔드 서비스에 연결되지 않습니다. 부하 분산기 상태 확인 데이터를 사용할 수 없습니다.
WebSocket 지원
외부 애플리케이션 부하 분산기를 사용하면 WebSocket 프로토콜이 구성 없이 작동합니다.
WebSocket 프로토콜을 사용하려는 경우 기본값인 30초보다 큰 제한 시간 값을 사용하려 할 수 있습니다.Google Cloud 외부 애플리케이션 부하 분산기를 통해 전송된 WebSocket 트래픽의 경우 백엔드 서비스 제한 시간은 유휴 상태 여부에 관계없이 WebSocket 연결이 열린 상태로 유지될 수 있는 최대 시간으로 해석됩니다.
백엔드 서비스의 제한 시간 값을 설정하려면 백엔드 응답 제한 시간을 참고하세요.
고급 네트워킹 시나리오
GKE 인그레스는 프로젝트 간 네트워크 리소스 공유, 커스텀 인그레스 컨트롤러 사용과 같은 고급 네트워킹 구성을 지원합니다.
공유 VPC
인그레스 및 MultiClusterIngress 리소스는 공유 VPC에서 지원되지만 추가 준비가 필요합니다.
인그레스 컨트롤러는 GKE 컨트롤 플레인에서 실행되며 클러스터 프로젝트의 GKE 서비스 계정을 사용하여 Google Cloud 에 API 호출을 수행합니다. 기본적으로 공유 VPC 서비스 프로젝트에 있는 클러스터에 공유 VPC 네트워크가 사용될 때 인그레스 컨트롤러는 서비스 프로젝트의 GKE 서비스 계정을 사용해서 호스트 프로젝트에서 인그레스 허용 방화벽 규칙을 만들고 업데이트할 수 없습니다.
호스트 프로젝트에서 VPC 방화벽 규칙을 만들고 관리하도록 서비스 프로젝트의 GKE 서비스 계정에 권한을 부여할 수 있습니다. 이러한 권한을 부여함으로써 GKE는 다음에 대해 인그레스 허용 방화벽 규칙을 만듭니다.
외부 인그레스를 위한 외부 애플리케이션 부하 분산기에서 사용하는 Google 프런트엔드(GFE) 프록시 및 상태 점검 시스템입니다. 자세한 내용은 외부 애플리케이션 부하 분산기 개요를 참조하세요.
내부 인그레스에서 사용되는 내부 애플리케이션 부하 분산기의 상태 점검 시스템입니다.
호스트 프로젝트에서 수동으로 방화벽 규칙 프로비저닝
보안 정책으로 호스트 프로젝트에서의 방화벽 관리만 허용될 경우, 이러한 방화벽 규칙을 수동으로 프로비저닝할 수 있습니다. 공유 VPC에서 인그레스를 배포할 때 인그레스 리소스 이벤트는 액세스 권한을 제공하는 데 필요한 특정 방화벽 규칙을 제공합니다.
규칙을 수동으로 프로비저닝하려면 다음 안내를 따르세요.
인그레스 리소스 이벤트를 확인합니다.
kubectl describe ingress INGRESS_NAMEINGRESS_NAME을 인그레스의 이름으로 바꿉니다.
다음과 비슷한 출력이 표시됩니다.
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Sync 9m34s (x237 over 38h) loadbalancer-controller Firewall change required by security admin: `gcloud compute firewall-rules update k8s-fw-l7--6048d433d4280f11 --description "GCE L7 firewall rule" --allow tcp:30000-32767,tcp:8080 --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`권장 필수 방화벽 규칙은
Message열에 표시됩니다.호스트 프로젝트에서 추천한 방화벽 규칙을 복사하여 적용합니다. 규칙을 적용하면 부하 분산기 및Google Cloud 상태 점검기에서 포드에 대한 액세스를 제공합니다.
호스트 프로젝트 방화벽 규칙을 관리하기 위한 인그레스 컨트롤러 권한 제공
서비스 프로젝트의 GKE 클러스터가 호스트 프로젝트의 방화벽 리소스를 만들고 관리하도록 하려면 서비스 프로젝트의 GKE 서비스 계정에 다음 전략 중 하나를 사용하여 적절한 IAM 권한을 부여해야 합니다.
서비스 프로젝트의 GKE 서비스 계정에 호스트 프로젝트에 대한 Compute 보안 관리자 역할을 부여합니다. 다음 예시에서는 이 전략을 보여줍니다.
세분화된 방식의 경우
compute.networks.updatePolicy,compute.firewalls.list,compute.firewalls.get,compute.firewalls.create,compute.firewalls.update,compute.firewalls.delete,compute.subnetworks.list권한만 포함된 커스텀 IAM 역할을 만듭니다. 서비스 프로젝트의 GKE 서비스 계정에 호스트 프로젝트에 대한 해당 커스텀 역할을 부여합니다.
둘 이상의 서비스 프로젝트에 클러스터가 있는 경우 전략 중 하나를 선택하고 각 서비스 프로젝트의 GKE 서비스 계정에 이를 반복해야 합니다.
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
--member=serviceAccount:service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
--role=roles/compute.securityAdmin
다음을 바꿉니다.
HOST_PROJECT_ID: 공유 VPC 호스트 프로젝트의 프로젝트 ID입니다.SERVICE_PROJECT_NUMBER: 클러스터가 포함된 서비스 프로젝트의 프로젝트 번호입니다.
커스텀 인그레스 컨트롤러 사용
HttpLoadBalancing 부가기능을 사용 중지하여 커스텀 인그레스 컨트롤러를 실행할 수 있습니다. 이렇게 하면 GKE 인그레스 컨트롤러가 인그레스 리소스를 처리하지 못합니다.
HttpLoadBalancing 부가기능이 사용 설정된 커스텀 인그레스 컨트롤러를 실행하려면(예: 하위 집합 및Private Service Connect와 같은 기능 사용) 다음 방법 중 하나를 사용할 수 있습니다.
- 인그레스 매니페스트에서
kubernetes.io/ingress.class주석 설정. 이 구성은 모든 GKE 버전을 실행하는 클러스터에서 지원됩니다. ingressClassName필드 구성- 기본 인그레스 클래스 구성
프로세스가 실수로 spec.ingressClassName을 덮어쓰지 않도록 해야 합니다. spec.IngressClassName을 유효한 값에서 빈 문자열("")로 변경하는 업데이트 작업은 GKE 인그레스 컨트롤러가 인그레스를 처리하도록 합니다.
ingressClassName 필드 구성
인그레스 매니페스트에서 ingressClassName 필드를 설정하여 커스텀 인그레스 컨트롤러를 사용할 수 있습니다. 다음 매니페스트는 cilium 인그레스 컨트롤러를 지정하는 인그레스를 설명합니다.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
spec:
ingressClassName: cilium
tls:
- hosts:
- cafe.example.com
secretName: cafe-secret
rules:
- host: cafe.example.com
기본 인그레스 클래스 구성
주석 ingressclass.kubernetes.io/is-default-class가 true로 설정된 IngressClass 리소스를 만들어 클러스터의 모든 인그레스 리소스에 대해 기본 인그레스 클래스를 구성할 수 있습니다.
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: gce
annotations:
ingressclass.kubernetes.io/is-default-class: "true"
spec:
controller: k8s.io/ingress-gce
GKE 인그레스 컨트롤러 동작 요약
GKE 버전 1.18 이상을 실행하는 클러스터의 경우 GKE 인그레스 컨트롤러가 인그레스를 처리하는지 여부는 kubernetes.io/ingress.class 주석의 값과 인그레스 매니페스트의 ingressClassName 필드에 따라 다릅니다. 자세한 내용은 GKE 인그레스 컨트롤러 동작을 참조하세요.
인그레스 구성 템플릿
- GKE 네트워킹 레시피에는 GKE가 제공하는 템플릿은 일반적으로 많은 인그레스 섹션에서 여러 일반적인 인그레스 사용에 대해 확인할 수 있습니다.