
VirtualServer 및 VirtualServerRoute 리소스
VirtualServer 및 VirtualServerRoute 리소스는 Ingress 리소스의 대안으로 권장되는 Load Balancing 구성입니다.
릴리스 1.5에 도입된 VirtualServer 및 VirtualServerRoute 리소스는 트래픽 분할 및 고급 콘텐츠 기반 라우팅과 같이 Ingress 리소스에서 지원되지 않는 사용 사례를 지원합니다. 리소스는 사용자 정의 리소스로 구현됩니다.
이 문서는 리소스에 대한 참조 문서입니다. 특정 사용 사례에 리소스를 사용하는 추가 예제를 보려면 GitHub Repo의 examples/custom-resources 폴더로 이동하세요.
목차
1. VirtualServer 사양
1-1. VirtualServer.TLS
1-2. VirtualServer.TLS.Redirect
1-3. VirtualServer.TLS.CertManager
1-4. VirtualServer.ExternalDNS
1-5. VirtualServer.ExternalDNS.ProviderSpecific
1-6. VirtualServer.Policy
1-7. VirtualServer.Route
2. VirtualServerRoute 사양
2-1. VirtualServerRoute.Subroute
3. VirtualServer 및 VirtualServerRoute의 공통 부분
3-1. Upstream
3-2. Upstream.Buffers
3-3. Upstream.TLS
3-4. Upstream.Queue
3-5. Upstream.Healthcheck
3-6. Upstream.SessionCookie
3-7. Header
3-8. Action
3-9. Action.Redirect
3-10. Action.Return
3-11. Action.Proxy
3-12. Action.Proxy.RequestHeaders
3-13. Action.Proxy.RequestHeaders.Set.Header
3-14. Action.Proxy.ResponseHeaders
3-15. AddHeader
3-16. Split
3-17. Match
3-18. Condition
3-19. ErrorPage
3-20. ErrorPage.Redirect
3-21. ErrorPage.Return
3-22. ErrorPage.Return.Header
4.VirtualServer 및 VirtualServerRoute 사용
4-1. Snippets 사용
4-2. 검증
4-3. 구조 검증
4-4. 포괄적 검증
5.ConfigMap을 통한 사용자 정의
1. VirtualServer 사양
VirtualServer 리소스는 example.com
과 같은 도메인 이름에 대한 Load Balancing 구성을 정의합니다. 다음은 이러한 구성의 예입니다.
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: cafe
spec:
host: cafe.example.com
tls:
secret: cafe-secret
upstreams:
- name: tea
service: tea-svc
port: 80
- name: coffee
service: coffee-svc
port: 80
routes:
- path: /tea
action:
pass: tea
- path: /coffee
action:
pass: coffee
- path: ~ ^/decaf/.*\\.jpg$
action:
pass: coffee
- path: = /green/tea
action:
pass: tea
Field | 설명 | Type | Required |
---|---|---|---|
host | 서버의 호스트(도메인 이름)입니다. my-app 또는 hello.example.com 과 같이 RFC 1123에 정의된 유효한 하위 도메인이어야 합니다. *.example.com 과 같은 와일드 카드 도메인을 사용하는 경우 도메인을 큰따옴표로 묶어야 합니다. host 값은 모든 Ingress 및 VirtualServer 리소스에서 고유해야 합니다. 호스트 및 Listener 충돌 처리도 참조하세요. | string | Yes |
tls | TLS termination 구성. | tls | No |
externalDNS | VirtualServer의 externalDNS 구성입니다. | externalDNS | No |
dos | DosProtectedResource에 대한 참조로 설정하면 VirtualServer의 DOS 보호가 활성화됩니다. | string | No |
policies | 정책 목록입니다. | []policy | No |
upstreams | Upstream 목록입니다. | []upstream | No |
routes | 루트 목록입니다. | []route | No |
ingressClassName | VirtualServer 리소스를 처리해야 하는 Ingress Controller를 지정합니다. | string | No |
http-snippets | http Context에서 사용자 정의 snippet을 설정합니다. | string | No |
server-snippets | server Context에서 사용자 정의 snippet을 설정합니다. server-snippets ConfigMap Key를 재정의합니다. | string | No |
1-1. VirtualServer.TLS
tls 필드는 VirtualServer에 대한 TLS 구성을 정의합니다. 예:
secret: cafe-secret
redirect:
enable: true
Field | 설명 | Type | Required |
---|---|---|---|
secret | TLS 인증서 및 Key가 있는 Secret의 이름입니다. Secret는 VirtualServer와 동일한 Namespace에 속해야 합니다. 보안 Secret은 kubernetes.io/tls 유형이어야 하며 여기에 설명된 인증서와 개인 Key를 포함하는 tls.crt 및 tls.key 라는 Key를 포함해야 합니다. Secret이 존재하지 않거나 유효하지 않은 경우 NGINX는 VirtualServer의 호스트에 대한 TLS 연결을 설정하려는 모든 시도를 중단합니다. Secret가 지정되지 않았지만 wildcard TLS secret가 구성된 경우 NGINX는 TLS Termination에 와일드 카드 Secret를 사용합니다. | string | No |
redirect | VirtualServer에 대한 TLS의 리다이렉션 구성입니다. | tls.redirect | No |
cert-manager | VirtualServer에 대한 TLS의 cert-manager 구성입니다. | tls.cert-manager | No |
1-2. VirtualServer.TLS.Redirect
Redirect 필드는 VirtualServer에 대한 TLS Redirect을 구성합니다.
enable: true
code: 301
basedOn: scheme
Field | 설 | Type | Required |
---|---|---|---|
enable | VirtualServer에 대한 TLS 리다이렉션을 활성화합니다. 기본값은 False 입니다. | boolean | No |
code | 리다이렉션의 상태 코드입니다. 허용되는 값은 301 , 302 , 307 , 308 입니다. 기본값은 301 입니다. | int | No |
basedOn | NGINX가 리다이렉션을 전송하기 위해 평가할 요청의 속성입니다. 허용되는 값은 scheme (요청의 scheme) 또는 x-forwarded-proto (요청의 X-Forwarded-Proto 헤더)입니다. 기본값은 scheme 입니다. | string | No |
1-3. VirtualServer.TLS.CertManager
cert-manager 필드는 cert-manager(cert-manager.io)를 사용하여 VirtualServer 리소스에 대한 x509 자동 인증서 관리를 구성합니다. 발급자 배포 및 구성에 대한 자세한 내용은 cert-manager 구성 설명서를 참조하세요. 예:
cert-manager:
cluster-issuer: "my-issuer-name"
Field | Description | Type | Required |
---|---|---|---|
issuer | Issuer의 이름. Issuer는 인증서에 서명할 수 있는 인증 기관을 설명하는 인증서 관리자 리소스입니다. Issuer는 VirtualServer 리소스와 동일한 Namespace에 있어야 합니다. issuer 및 cluster-issuer 중 하나가 필요하지만 상호 배타적이므로 하나만 정의해야 합니다. | string | No |
cluster-issuer | ClusterIssuer의 이름. ClusterIssuer는 인증서에 서명할 수 있는 인증 기관을 설명하는 인증서 관리자 리소스입니다. ClusterIssuer는 Namespace가 없는 리소스이므로 VirtualServer가 상주하는 Namespace는 중요하지 않습니다. 및 cluster-issuer 중 하나가 필요하지만 상호 배타적이므로 하나만 정의해야 합니다. | string | No |
issuer-kind | 외부 Issuer 리소스의 종류(예: AWSPCAIssuer)입니다. 이는 트리 외부 Issuer에게만 필요합니다. 도 정의된 경우에는 정의할 수 없습니다. | string | No |
issuer-group | 외부 Issuer Controller의 API 그룹(예: awspca.cert-manager.io)입니다. 이는 트리 외부 Issuer에게만 필요합니다. 도 정의된 경우에는 정의할 수 없습니다. | string | No |
common-name | 이 필드를 사용하면 생성할 인증서에 대한 spec.commonName을 구성할 수 있습니다. 이 구성은 x509 인증서에 CN을 추가합니다. | string | No |
duration | 이 필드에서는 생성할 인증서에 대한 spec.duration 필드를 구성할 수 있습니다. Go time.Duration 문자열 형식을 사용하여 지정해야 하며 d(일) 접미사를 허용하지 않습니다. 대신 s, m 및 h 접미사를 사용하여 이러한 값을 지정해야 합니다. | string | No |
renew-before | 이 Annotation을 사용하면 생성할 인증서에 대한 spec.renewBefore 필드를 구성할 수 있습니다. Go time.Duration 문자열 형식을 사용하여 지정해야 하며 d(일) 접미사를 허용하지 않습니다. 대신 s, m 및 h 접미사를 사용하여 이러한 값을 지정해야 합니다. | string | No |
usages | 이 필드를 사용하면 생성할 인증서에 대한 spec.usages 필드를 구성할 수 있습니다. 쉼표로 구분된 값(예: key agreement, digital signature, server auth )이 있는 문자열을 전달합니다. 지원되는 Key 사용의 전체 목록은 cert-manager api 문서에서 찾을 수 있습니다. | string | No |
1-4. VirtualServer.ExternalDNS
externalDNS 필드는 ExternalDNS를 사용하여 VirtualServer 리소스에 대해 DNS 레코드를 동적으로 제어하도록 구성합니다. ExternalDNS 및 공급자 배포 및 구성에 대한 자세한 내용은 ExternalDNS 구성 설명서를 참조하십시오. 예시:
enable: true
Field | 설명 | Type | Required |
---|---|---|---|
enable | VirtualServer 리소스에 대한 ExternalDNS 통합을 활성화합니다. 기본값은 false 입니다. | string | No |
labels | ExternalDNS에서 사용할 Endpoint 리소스에 적용할 Label을 구성합니다. | map[string]string | No |
providerSpecific | 개별 DNS 공급자에 특정한 구성의 이름과 값을 보유하는 공급자별 속성을 구성합니다. | []ProviderSpecific | No |
recordTTL | DNS 레코드용 TTL입니다. 정의되지 않은 경우 기본값은 0입니다. 업체별 기본값은 ExternalDNS TTL 문서를 참조하세요. | int64 | No |
recordType | 생성해야 하는 레코드 유형입니다. 예: “A”, “AAAA”, “CNAME”. 정의되지 않은 경우 외부 Endpoint를 기반으로 자동으로 계산됩니다. | string | No |
1-5. VirtualServer.ExternalDNS.ProviderSpecific
externalDNS 블록의 providerSpecific 필드를 사용하면 개별 DNS 제공자에 고유한 구성의 Key Value 쌍 목록인 제공자 특정 속성을 지정할 수 있습니다. 예:
- name: my-name
value: my-value
- name: my-name2
value: my-value2
Field | 설명 | Type | Required |
---|---|---|---|
name | Key Value 쌍의 name입니다. | string | Yes |
value | Key Value 쌍의 value입니다. | string | Yes |
1-6. VirtualServer.Policy
policy 필드는 이름과 선택적 Namespace로 정책 리소스를 참조합니다. 예:
name: access-control
Field | 설명 | Type | Required |
---|---|---|---|
name | 정책의 이름입니다. 정책이 존재하지 않거나 유효하지 않은 경우 NGINX는 500 상태 코드가 포함된 오류 응답으로 응답합니다. | string | Yes |
namespace | 정책의 Namespace입니다. 지정하지 않으면 VirtualServer 리소스의 Namespace가 사용됩니다. | string | No |
1-7. VirtualServer.Route
Route는 요청을 Upstream에 전달하는 것과 같은 작업에 클라이언트 요청을 일치시키는 규칙을 정의합니다. 예:
path: /tea
action:
pass: tea
Field | 설명 | Type | Required |
---|---|---|---|
path | route의 경로입니다. NGINX는 요청의 URI와 일치시킵니다. 가능한 값은 다음과 같습니다. 접두사( / , /path ), 정확한 일치( =/exact/match ), 대소문자를 구분하지 않는 정규식(~*^/Bar.*\.jpg ) 또는 대소문자를 구분하는 정규식(~^/foo.*\.jpg ). 접두사(/ 로 시작해야 함) 또는 정확히 일치(= 로 시작해야 함)의 경우 경로에 공백 문자({ , } 또는 ; )가 포함되어서는 안 됩니다. 정규식 일치의 경우 모든 큰따옴표는 " 이스케이프되어야 하며 일치는 이스케이프 처리되지 않은 백슬래시 \ 로 끝날 수 없습니다. 경로는 VirtualServer의 모든 경로 경로 중에서 고유해야 합니다. 자세한 내용은 location 지시문을 확인하세요. . | string | Yes |
policies | 정책 목록입니다. 정책은 VirtualServer의 에 정의된 동일한 유형의 정책을 재정의합니다. 자세한 내용은 정책 적용을 참조하세요. | []policy | No |
action | 요청에 대해 수행할 기본 작업입니다. | action | No |
dos | DosProtectedResource에 대한 참조로 설정하면 VirtualServer 경로의 DOS 보호가 활성화됩니다. | string | No |
splits | 트래픽 분할을 위한 기본 분할 구성입니다. 최소 2개의 분할을 포함해야 합니다. | []split | No |
matches | 고급 콘텐츠 기반 라우팅을 위한 일치 규칙입니다. 기본 action 또는 splits 이 필요합니다. 일치하지 않는 요청은 기본 action 또는 splits 로 처리됩니다. | matches | No |
route | 이 경로를 정의하는 VirtualServerRoute 리소스의 이름입니다. VirtualServerRoute가 VirtualServer와 다른 Namespace에 속하는 경우 Namespace를 포함해야 합니다. 예: tea-namespace/tea . | string | No |
errorPages | 오류 코드에 대한 사용자 정의 응답입니다. NGINX는 Upstream 서버의 오류 응답이나 NGINX에서 생성한 기본 응답을 반환하는 대신 해당 응답을 사용합니다. 사용자 정의 응답은 리다이렉션 또는 미리 준비된 응답일 수 있습니다. 예를 들어 Upstream 서버가 404 상태 코드로 응답한 경우 다른 URL로 리다이렉션합니다. | []errorPage | No |
location-snippets | location Context에서 맞춤 Snippet을 설정합니다. location-snippets ConfigMap Key를 재정의합니다. | string | No |
* – 경로에는 action
, splits
또는 route
중 하나를 정확히 포함해야 합니다.
2. VirtualServerRoute 사양
VirtualServerRoute 리소스는 VirtualServer에 대한 경로를 정의합니다. 하나 또는 여러 하위 경로로 구성될 수 있습니다. VirtualServerRoute는 Mergeable Ingress Type의 대안입니다.
아래 예에서 Namespace cafe-ns
의 VirtualServer cafa
는 경로 /coffee
가 있는 경로를 정의하며, 이는 Namespace coffee-ns
의 VirtualServerRoute coffee
에서 추가로 정의됩니다.
VirtualServer:
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: cafe
namespace: cafe-ns
spec:
host: cafe.example.com
upstreams:
- name: tea
service: tea-svc
port: 80
routes:
- path: /tea
action:
pass: tea
- path: /coffee
route: coffee-ns/coffee
VirtualServerRoute:
apiVersion: k8s.nginx.org/v1
kind: VirtualServerRoute
metadata:
name: coffee
namespace: coffee-ns
spec:
host: cafe.example.com
upstreams:
- name: latte
service: latte-svc
port: 80
- name: espresso
service: espresso-svc
port: 80
subroutes:
- path: /coffee/latte
action:
pass: latte
- path: /coffee/espresso
action:
pass: espresso
각 하위 path
에는 VirtualServer의 경로에 정의된 동일한 접두사(여기서는 /coffee
)로 시작하는 Route가 있어야 합니다. 또한 VirtualServerRoute의
는 VirtualServer의 host
와 동일해야 합니다.host
Field | 설명 | Type | Required |
---|---|---|---|
host | 서버의 호스트(도메인 이름)입니다. my-app 또는 hello.example.com 과 같이 RFC 1123에 정의된 유효한 하위 도메인이어야 합니다. *.example.com 과 같은 와일드 카드 도메인을 사용하는 경우 도메인을 큰따옴표로 묶어야 합니다. 이 리소스를 참조하는 VirtualServer의 host와 동일해야 합니다. | string | Yes |
upstreams | Upstreams 목록입니다. | []upstream | No |
subroutes | 하위 경로 목록입니다. | []subroute | No |
ingressClassName | VirtualServerRoute 리소스를 처리해야 하는 Ingress Controller를 지정합니다. 이 리소스를 참조하는 VirtualServer의 ingressClassName 과 동일해야 합니다. | string _ | No |
2-1. VirtualServerRoute.Subroute
하위 경로는 클라이언트 요청을 Upstream에 전달하는 것과 같은 작업에 일치시키는 규칙을 정의합니다. 예:
path: /coffee
action:
pass: coffee
Field | 설명 | Type | Required |
---|---|---|---|
path | subroute의 path입니다. NGINX는 요청의 URI와 일치시킵니다. 가능한 값은 다음과 같습니다. 접두사( / , /path ), 정확한 일치( =/exact/match ), 대소문자를 구분하지 않는 정규식( ~*^/Bar.*\.jp ) 또는 대소문자를 구분하는 정규식( ~^/foo.*\.jpg ). 접두사의 경우 경로는 이 리소스를 참조하는 VirtualServer의 route path와 동일한 path로 시작해야 합니다. 정확한 일치 또는 정규식 일치의 경우 경로는 이 리소스를 참조하는 VirtualServer의 route path와 동일해야 합니다. 접두사 또는 정확히 일치하는 경우 path에 공백 문자({ , } 또는 ; )가 포함되어서는 안 됩니다. 정규식 일치의 경우 모든 큰따옴표 " 는 이스케이프되어야 하며 일치는 이스케이프 처리되지 않은 백슬래시 \ 로 끝날 수 없습니다. path는 VirtualServerRoute의 모든 하위 path에서 고유해야 합니다. | string | Yes |
policies | 정책 목록입니다. 정책은 이 리소스를 참조하는 VirtualServer의 경로에 정의된 모든 정책을 재정의합니다. 정책은 또한 VirtualServer의 spec 에 정의된 동일한 유형의 정책을 재정의합니다. 자세한 내용은 정책 적용을 참조하세요. | []policy | No |
action | 요청에 대해 수행할 기본 작업입니다. | action | No |
dos | DosProtectedResource에 대한 참조로 이를 설정하면 VirtualServerRoute 하위 경로의 DOS 보호가 활성화됩니다. | string | No |
splits | 트래픽 분할을 위한 기본 분할 구성입니다. 최소 2개의 분할을 포함해야 합니다. | []split | No |
matches | 고급 콘텐츠 기반 라우팅을 위한 일치 규칙입니다. 기본 action 또는 splits 이 필요합니다. 일치하지 않는 요청은 기본 action 또는 splits 로 처리됩니다. | matches | No |
errorPages | 오류 코드에 대한 사용자 정의 응답입니다. NGINX는 Upstream 서버의 오류 응답이나 NGINX에서 생성한 기본 응답을 반환하는 대신 해당 응답을 사용합니다. 사용자 정의 응답은 리다이렉션 또는 미리 준비된 응답일 수 있습니다. 예를 들어 Upstream 서버가 404 상태 코드로 응답한 경우 다른 URL로 리다이렉션합니다. | []errorPage | No |
location-snippets | 위치 Context에서 맞춤 Snippet을 설정합니다. VirtualServer(설정된 경우)의 location-snippets 또는 location-snippets ConfigMap Key를 재정의합니다. | string | No |
* – 하위 경로는 action 또는 splits 중 하나를 포함해야 합니다.
3. VirtualServer 및 VirtualServerRoute의 공통 부분
3-1. Upstream
Upstream은 라우팅 구성의 대상을 정의합니다. 예:
name: tea
service: tea-svc
subselector:
version: canary
port: 80
lb-method: round_robin
fail-timeout: 10s
max-fails: 1
max-conns: 32
keepalive: 32
connect-timeout: 30s
read-timeout: 30s
send-timeout: 30s
next-upstream: "error timeout non_idempotent"
next-upstream-timeout: 5s
next-upstream-tries: 10
client-max-body-size: 2m
tls:
enable: true
Note: WebSocket 프로토콜은 추가 구성 없이 지원됩니다.
Field | Description | Type | Required |
---|---|---|---|
name | Upstream의 이름입니다. RFC 1035에 정의된 유효한 DNS Label이어야 합니다. 예를 들어 hello 및 upstream-123 은 유효합니다. 이름은 리소스의 모든 Upstream에서 고유해야 합니다. | string | Yes |
service | 서비스의 이름입니다. 서비스는 리소스와 동일한 Namespace에 속해야 합니다. 서비스가 존재하지 않는 경우 NGINX는 서비스에 Endpoint가 없다고 가정하고 이 Upstream에 대한 요청에 대해 502 응답을 반환합니다. NGINX Plus의 경우에만 ExternalName 유형의 서비스도 지원됩니다(전제 조건 확인). | string | Yes |
subselector | Label Key와 값을 사용하여 서비스 내의 Pod를 선택합니다. 기본적으로 서비스의 모든 Pod가 선택됩니다. Note: 지정된 Label은 생성될 때 Pod에 있어야 합니다. Pod Label이 업데이트되면 Ingress Controller는 Pod 수가 변경될 때까지 해당 변경 사항을 확인하지 않습니다. | map[string]string | No |
use-cluster-ip | Pod의 IP 및 포트를 사용하는 기본 동작 대신 서비스의 클러스터 IP 및 포트를 사용하도록 설정합니다. 이 필드가 활성화되면 Ingress Controller가 서비스 클러스터 IP와 일치하는 하나의 Upstream 서버로만 NGINX를 구성하므로 여러 Upstream 서버와 관련된 NGINX 동작을 구성하는 필드(예: lb-method 및 next-upstream )는 영향을 미치지 않습니다. | boolean | No |
port | 서비스의 포트입니다. 서비스가 해당 포트를 정의하지 않으면 NGINX는 서비스에 Endpoint가 없다고 가정하고 이 Upstream에 대한 요청에 대해 502 응답을 반환합니다. 포트는 1..65535 범위에 속해야 합니다. | uint16 | Yes |
lb-method | Load Balancing 매서드입니다. 라운드 로빈 방법을 사용하려면 round_robin 을 지정하세요. 기본값은 lb-method ConfigMap Key에 지정됩니다. | string | No |
fail-timeout | 서버를 사용할 수 없는 것으로 간주하기 위해 Upstream 서버와의 통신을 시도하는데 지정된 횟수만큼 실패한 시간입니다. sever 지시문의 fail_timeout 매개변수를 참조하세요. 기본값은 fail-timeout ConfigMap Key에 설정되어 있습니다. | string | No |
max-fails | 서버를 사용할 수 없다고 간주하기 위해 fail-timeout 에서 설정한 기간 내에 발생해야 하는 Pustream 서버와의 통신 시도 실패 횟수입니다. server 지시문의 max_fails 매개변수를 참조하세요. 기본값은 max-fails ConfigMap Key에 설정되어 있습니다. | int | No |
max-conns | Upstream 서버에 대한 최대 동시 활성 연결 수입니다. server 지시문의 max_conns 매개변수를 참조하세요. 기본적으로 제한이 없습니다. Note: keepalive 연결이 활성화된 경우 Upstream 서버에 대한 총 활성 및 유휴 keepalive 연결 수가 max_conns 값을 초과할 수 있습니다. | int | No |
keepalive | Upstream 서버에 연결하기 위한 캐시를 구성합니다. 캐시 값을 0으로 사용하지 않도록 설정합니다. keepalive 지시문을 참조하세요. 기본값은 Keepailive ConfigMap Key에 설정되어 있습니다. | int | No |
connect-timeout | Upstream 서버와의 연결을 설정하기 위한 제한 시간입니다. proxy_connect_timeout 지시문을 참조하세요. 기본값은 proxy-connect-timeout ConfigMap Key에 지정됩니다. | string | No |
read-timeout | Upstream 서버에서 응답을 읽기 위한 제한 시간입니다. proxy_read_timeout 지시문을 참조하세요. 기본값은 proxy-read-timeout ConfigMap Key에 지정됩니다. | string | No |
send-timeout | Upstream 서버로 요청을 전송하기 위한 제한 시간입니다. proxy_send_timeout 지시문을 참조하세요. 기본값은 proxy-send-timeout ConfigMap Key에 지정됩니다. | string | No |
next-upstream | 요청을 다음 Upstream 서버로 전달할 경우를 지정합니다. proxy_next_upstream 지시문을 참조하세요. 기본값은 error timeout 입니다. | string | No |
next-upstream-timeout | 요청이 다음 Upstream 서버로 전달될 수 있는 시간입니다. proxy_next_upstream_timeout 지시문을 참조하세요. 0 값은 시간 제한을 끕니다. 기본값은 0 입니다. | string | No |
next-upstream-tries | 요청을 다음 Upstream 서버로 전달하기 위한 가능한 시도 횟수입니다. proxy_next_upstream_tries 지시문을 참조하세요. 0 값은 이 제한을 끕니다. 기본값은 0 입니다. | int | No |
client-max-body-size | 클라이언트 요청 본문의 최대 허용 크기를 설정합니다. client_max_body_size 지시문을 참조하세요. 기본값은 client-max-body-size ConfigMap 키에 설정되어 있습니다. | string | No |
tls | Upstream에 대한 TLS 구성입니다. | tls | No |
healthCheck | Upstream에 대한 Health Check 구성입니다. health_check 지시문을 참조하세요. Note: 이 기능은 NGINX Plus에서만 지원됩니다. | healthcheck | No |
slow-start | Slow Start을 사용하면 Upstream 서버가 복구되거나 사용 가능해진 후 또는 서버가 사용 불가능한 것으로 간주된 일정 기간 후에 사용 가능해지면 가중치를 0에서 공칭 값으로 점진적으로 복구할 수 있습니다. 기본적으로 Slow Start은 비활성화되어 있습니다. server 지시문의 slow_start 매개변수를 참조하세요. Note: 이 매개변수는 random , hash 또는 ip_hash 부하 분산 방법과 함께 사용할 수 없으며 무시됩니다. | string | No |
queue | Upstream에 대한 을 구성합니다. 요청을 처리하는 동안 Upstream 서버를 즉시 선택할 수 없는 경우 클라이언트 요청이 에 배치됩니다. 기본적으로 은 구성되지 않습니다. Note: 이 기능은 NGINX Plus에서만 지원됩니다. | queue | No |
buffering | Upstream 서버의 응답 버퍼링을 활성화합니다. proxy_buffering 지시문을 참조하세요. 기본값은 proxy_buffering ConfigMap 키에 설정되어 있습니다. | boolean | No |
buffers | 단일 연결에 대한 Upstream 서버에서 응답을 읽는 데 사용되는 버퍼를 구성합니다. | buffers | No |
buffer-size | Upstream 서버에서 받은 응답의 첫 번째 부분을 읽는 데 사용되는 버퍼 크기를 설정합니다. proxy_buffer_size 지시문을 참조하세요. 기본값은 proxy-buffer-size ConfigMap 키에 설정됩니다. | string | No |
ntlm | NTLM 인증으로 Proxy 요청을 허용합니다. ntlm 지시문을 참조하세요. NTLM 인증이 작동하려면 keepalive 필드를 사용하여 Upstream 서버에 대한 keepalive 연결을 활성화해야 합니다. Note: 이 기능은 NGINX Plus에서만 지원됩니다. | boolean | No |
type | Upstream의 유형입니다. 지원되는 값은 http 및 grpc 입니다. 기본값은 http 입니다. gRPC의 경우 ConfigMap에서 HTTP/2를 사용 설정하고 VirtualServer에서 TLS 종료를 구성해야 합니다. | string | No |
3-2. Upstream.Buffers
buffers 필드는 단일 연결에 대한 Upstream 서버의 응답을 읽는 데 사용되는 Buffers를 구성합니다.
number: 4
size: 8K
자세한 내용은 proxy_buffers 지침을 참조하십시오.
Field | 설명 | Type | Required |
---|---|---|---|
number | 버퍼 수를 구성합니다. 기본값은 proxy-buffers ConfigMap Key에 설정되어 있습니다. | int | Yes |
size | 버퍼의 크기를 구성합니다. 기본값은 proxy-buffers ConfigMap Key에 설정되어 있습니다. | string | Yes |
3-3. Upstream.TLS
Field | 설명 | Type | Required |
---|---|---|---|
enable | Upstream 서버에 대한 요청에 대해 HTTPS를 활성화합니다. 기본값은 False 이며 HTTP가 사용됨을 의미합니다. Note: 기본적으로 NGINX는 Upstream 서버 인증서를 확인하지 않습니다. 확인을 활성화하려면 EgressMTLS 정책을 구성하십시오. | boolean | No |
3-4. Upstream.Queue
queue 필드는 Queue을 구성합니다. 요청을 처리하는 동안 Upstream 서버를 즉시 선택할 수 없는 경우 클라이언트 요청이 Queue에 배치됩니다.
size: 10
timeout: 60s
자세한 내용은 Queue 지시문을 참조하십시오.
Note: 이 기능은 NGINX Plus에서만 지원됩니다.
Field | 설명 | Type | Required |
---|---|---|---|
size | 큐(Queue)의 크기입니다. | int | Yes |
timeout | 큐(Queue)의 제한시간입니다. 제한 시간보다 긴 기간 동안 요청을 대기할 수 없습니다. 기본값은 60초 입니다. | string | No |
3-5. Upstream.Healthcheck
Healthcheck는 Active Health Check를 정의합니다. 아래 예에서는 Upstream에 대한 Health Check을 활성화하고 Mandatory 및 Persistent와 결합된 Slow-Start 매개변수를 포함하여 사용 가능한 모든 매개변수를 구성합니다.
name: tea
service: tea-svc
port: 80
slow-start: 30s
healthCheck:
enable: true
path: /healthz
interval: 20s
jitter: 3s
fails: 5
passes: 5
port: 8080
tls:
enable: true
connect-timeout: 10s
read-timeout: 10s
send-timeout: 10s
headers:
- name: Host
value: my.service
statusMatch: "! 500"
mandatory: true
persistent: true
Note: 이 기능은 NGINX Plus에서만 지원됩니다.
Field | 설명 | Type | Required |
---|---|---|---|
enable | Upstream 서버에 대한 상태 확인을 활성화합니다. 기본값은 false 입니다. | boolean | No |
path | Health Check 요청에 사용되는 경로입니다. 기본값은 / 입니다. 이것은 gRPC 유형 Upstream에 대해 구성할 수 없습니다. | string | No |
interval | 연속된 두 Health Check 사이의 간격입니다. 기본값은 5s 입니다. | string | No |
jitter | 각 Health Check가 임의로 지연되는 시간입니다. 기본적으로 지연은 없습니다. | string | No |
fails | 이 서버가 비정상으로 간주된 후 특정 Upstream 서버의 Health Check에 연속으로 실패한 횟수입니다. 기본값은 1 입니다. | integer | No |
passes | 서버가 정상 상태로 간주될 때까지 특정 Upstream 서버에 대해 연속적으로 통과된 Health Check 수입니다. 기본값은 1 입니다. | integer | No |
port | Health Check 요청에 사용되는 포트입니다. 기본적으로 server port가 사용됩니다. 참고: Upstream의 포트와 달리 이 포트는 서비스 포트가 아니라 Pod의 포트입니다. | integer | No |
tls | Health Check 요청에 사용되는 TLS 구성입니다. 기본적으로 Upstream의 tls 필드가 사용됩니다. | upstream.tls | No |
connect-timeout | Upstream 서버와의 연결을 설정하기 위한 제한 시간입니다. 기본적으로 Upstream의 connect-timeout 이 사용됩니다. | string | No |
read-timeout | Upstream 서버에서 응답을 읽기 위한 제한 시간입니다. 기본적으로 Upstream의 read-timeout 이 사용됩니다. | string | No |
send-timeout | Upstream 서버로 요청을 전송하기 위한 제한 시간입니다. 기본적으로 Upstream의 send-timeout 이 사용됩니다. | string | No |
headers | Health Check 요청에 사용되는 요청 헤더입니다. NGINX Plus는 항상 Health Check 요청을 위해 , 사용자 User-Agent 및 Connection 헤더를 설정합니다. | []header | No |
statusMatch | Health Check의 예상 응답 상태 코드입니다. 기본적으로 응답에는 상태 코드 2xx 또는 3xx가 있어야 합니다. 예: '200' , '! 500' , '301-303 307' . match 지시어 문서를 참조하세요. gRPC 유형 Upstream에는 지원되지 않습니다. | string | No |
grpcStatus | Check method에 대한 Upstream 서버 응답의 예상 gRPC status code입니다. gRPC 서비스가 gRPC Health Check 프로토콜을 구현하지 않는 경우에만 이 필드를 구성하십시오. 예를 들어 Upstream 서버가 12(UNIMPLEMENTED) 상태 코드로 응답하는 경우 12 를 구성합니다. gRPC 유형 Upstream에서만 유효합니다. | int | No |
grpcService | Upstream 서버에서 모니터링할 gRPC 서비스입니다. gRPC 유형 Upstream에서만 유효합니다. | string | No |
mandatory | NGINX Plus가 트래픽을 전송하기 전에 새로 추가된 모든 서버가 구성된 모든 Health Check을 통과해야 합니다. 이를 지정하지 않거나 false로 설정하면 처음에는 서버가 정상으로 간주됩니다. Slow-Start과 결합하면 새 서버가 데이터베이스에 연결하고 전체 트래픽 공유를 처리하라는 요청을 받기 전에 “Warm Up”할 수 있는 더 많은 시간을 제공합니다. | bool | No |
persistent | Reload하기 전에 서버가 정상으로 간주된 경우 Reload한 후 서버에 대한 초기 “Up” 상태를 설정합니다. 영구적으로 사용을 설정하려면 필수 매개변수도 true 로 설정해야 합니다. | bool | No |
3-6. Upstream.SessionCookie
SessionCookie 필드는 동일한 클라이언트의 요청이 동일한 Upstream 서버로 전달될 수 있도록 하는 세션 지속성을 구성합니다. 지정된 Upstream 서버에 대한 정보는 NGINX Plus에서 생성된 세션 Cookie에 전달됩니다.
아래 예에서는 Upstream에 대한 세션 Cookie를 사용하여 세션 지속성을 구성하고 사용 가능한 모든 매개변수를 구성합니다.
name: tea
service: tea-svc
port: 80
sessionCookie:
enable: true
name: srv_id
path: /
expires: 1h
domain: .example.com
httpOnly: false
secure: true
추가 정보는 sticky 지시문을 참조하십시오. Session Cookie는 sticky cookie
방법에 해당합니다.
Note: 이 기능은 NGINX Plus에서만 지원됩니다.
Field | 설명 | Type | Required |
---|---|---|---|
enable | Upstream 서버에 대한 세션 Cookie로 세션 지속성을 활성화합니다. 기본값은 false 입니다. | boolean | No |
name | Cookie의 이름입니다. | string | Yes |
path | Cookie가 설정된 경로입니다. | string | No |
expires | 브라우저가 Cookie를 보관해야 하는 시간입니다. Cookie가 2037년 12월 31일 23:55:55 GMT에 만료되도록 하는 특수 값 max 로 설정할 수 있습니다. | string | No |
domain | Cookie가 설정된 도메인입니다. | string | No |
httpOnly | Cookie에 HttpOnly 특성을 추가합니다. | boolean | No |
secure | Cookie에 Secure 특성을 추가합니다. | boolean | No |
3-7. Header
header는 HTTP Header를 정의합니다:
name: Host
value: example.com
Field | Description | Type | Required |
---|---|---|---|
name | 헤더의 이름입니다. | string | Yes |
value | 헤더의 값입니다. | string | No |
3-8. Action
action은 요청에 대해 Action 작업을 정의합니다.
아래 예에서 클라이언트 요청은 Upstream coffe
로 전달됩니다.
path: /coffee
action:
pass: coffee
Field | 설명 | Type | Required |
---|---|---|---|
pass | 요청을 Upstream으로 전달합니다. 해당 이름의 Upstream을 리소스에 정의해야 합니다. | string | No |
redirect | 요청을 제공된 URL로 리다이렉션합니다. | action.redirect | No |
return | 미리 구성된 응답을 반환합니다. | action.return | No |
proxy | 요청/응답을 수정할 수 있는 기능(예: URI 재작성 또는 헤더 수정)을 사용하여 요청을 Upstream으로 전달합니다. | action.proxy | No |
* – 작업에는 pass, redirect, return 또는 proxy 중 하나가 정확히 포함되어야 합니다.
3-9. Action.Redirect
redirect 작업은 요청에 대해 반환할 Redirect을 정의합니다.
아래 예에서는 클라이언트 요청이 http://www.nginx.com
URL로 전달됩니다:
redirect:
url: http://www.nginx.com
code: 301
Field | 설 | Type | Required |
---|---|---|---|
url | 요청을 리다이렉션할 URL입니다. 지원되는 NGINX 변수: $scheme , $http_x_forwarded_proto , $request_uri , $host 변수는 중괄호로 묶어야 합니다. 예: ${host}${request_uri} . | string | Yes |
code | 리다이렉션의 상태 코드입니다. 허용되는 값은 301 , 302 , 307 , 308 입니다. 기본값은 301 입니다. | int | No |
3-10. Action.Return
return 작업은 요청에 대해 미리 구성된 응답을 정의합니다.
아래 예에서 NGINX는 모든 요청에 대해 사전 구성된 응답으로 응답합니다:
return:
code: 200
type: text/plain
body: "Hello World\n"
Field | 설명 | Type | Required |
---|---|---|---|
code | 응답의 상태 코드입니다. 허용되는 값은 2XX , 4XX 또는 5XX 입니다. 기본값은 200 입니다. | int | No |
type | 응답의 MIME 유형입니다. 기본값은 text/plain 입니다. | string | No |
body | 응답의 본문입니다. NGINX 변수*를 지원합니다. 변수는 중괄호로 묶어야 합니다. 예: 요청은 ${request_uri}\n 입니다. | string | Yes |
* – 지원되는 NGINX 변수: $request_uri
, $request_method
, $request_body
, $http_
, $args
, $args
, $arg_
, $cookie_
, $hos
t, $request_time
, $request_length
, $nginx_vers
, $pid
, $remote_addr
, $remote_port
, $time_iso8601
, $time_local
, $readdr
, $re
, $readdr
, $servers_connection
, $connections_writing
및 $connections_delays
.
3-11. Action.Proxy
proxy 작업은 요청/응답을 수정할 수 있는 기능(예: URI Rewrite 또는 헤더 수정)을 사용하여 요청을 Upstream으로 전달합니다.
아래 예제에서는 요청 URI가 /
로 다시 작성되고 요청 및 응답 헤더가 수정됩니다:
proxy:
upstream: coffee
requestHeaders:
pass: true
set:
- name: My-Header
value: Value
- name: Client-Cert
value: ${ssl_client_escaped_cert}
responseHeaders:
add:
- name: My-Header
value: Value
- name: IC-Nginx-Version
value: ${nginx_version}
always: true
hide:
- x-internal-version
ignore:
- Expires
- Set-Cookie
pass:
- Server
rewritePath: /
Field | 설명 | Type | Required |
---|---|---|---|
upstream | 요청이 Proxy될 Upstream의 이름입니다. 해당 이름의 Upstream이 리소스에 정의되어 있어야 합니다. | string | Yes |
requestHeaders | 요청 헤더 수정 사항입니다. | action.Proxy.RequestHeaders | No |
responseHeaders | 응답 헤더 수정 사항입니다. | action.Proxy.ResponseHeaders | No |
rewritePath | 재작성된 URI입니다. 루트 경로가 ~ 로 시작하는 정규식인 경우, rewritePath 에는 $1-9 의 캡처 그룹이 포함될 수 있습니다. 예를 들어 첫 번째 그룹에 $1 등이 있습니다. 자세한 내용은 다시 쓰기 예제를 확인하십시오. | string | No |
3-12. Action.Proxy.RequestHeaders
RequestHeaders 필드는 Proxy Upstream 서버에 대한 요청 헤더를 수정합니다.
Field | 설명 | Type | Required |
---|---|---|---|
pass | 원래 요청 헤더를 Proxy Upstream 서버로 전달합니다. 자세한 내용은 proxy_pass_request_header 지시문을 참조하세요. 기본값은 true입니다. | bool | No |
set | Proxy Upstream 서버로 전달된 요청 헤더를 표시하기 위해 필드를 재정의하거나 추가할 수 있습니다. 자세한 내용은 proxy_set_header 지시문를 참조하세요. | []header | No |
3-13. Action.Proxy.RequestHeaders.Set.Header
header는 HTTP Header를 정의합니다:
name: My-Header
value: My-Value
Ingress Controller가 $host
로 설정하는 Host
헤더의 기본값을 재정의할 수 있습니다.
name: Host
value: example.com
Field | 설명 | Type | Required |
---|---|---|---|
name | 헤더의 이름입니다. | string | Yes |
value | 헤더의 값입니다. NGINX 변수*를 지원합니다. 변수는 중괄호로 묶어야 합니다. 예: ${scheme} . | string | No |
* – 지원되는 NGINX 변수: $request_uri
, $request_method
, $request_body
, $http_
, $args
, $args
, $arg_
, $cookie_
, $host
, $request_time
, $request_length
, $nginx_vers
, $pid
, $remote_addr
, $remote_port
, $time_iso8601
, $time_local
, $readdr
, $re
, $readdr
, $servers_connection
, $connections_writing
, $connections_dn
, $ssl_dn
, $ssl_client_cert
, $ssl_client_dn
, $ssl_client_dn_fingerprint
, $ssl_client_writing
, $ssl_client_dn
, $ssl_client_dn_dn
, $ssl_client_dn_dn_dn
, $ssl_client_dn
, $ssl_dn_client_dn_client_dn
, $ssl_dn_dn
, $ss
, $ssl_curves
, $ssl_early_data
, $ssl_protocol
, $ssl_server_name
, $ssl_session_id
, $ssl_session_reuse
, $jwt_claim_
(NGINX Plus 전용) 및 $jwt_header_
(NGINX Plus 전용).
3-14. Action.Proxy.ResponseHeaders
ResponseHeaders 필드는 클라이언트에 대한 응답의 헤더를 수정합니다.
Field | 설명 | Type | Required |
---|---|---|---|
hide | Proxy Upstream 서버에서 클라이언트에 대한 응답으로 전달되지 않는* 헤더입니다. 자세한 내용은 proxy_hide_header 지시문을 참조하세요. | []string | No |
pass | Proxy Upstream 서버에서 클라이언트로 숨겨진 헤더 필드*를 전달할 수 있습니다. 자세한 내용은 proxy_pass_header 지시문을 참조하세요. | []string | No |
ignore | Proxy Uptream 서버에서 클라이언트로의 특정 헤더** 처리를 비활성화합니다. 자세한 내용은 proxy_ignore_headers 지시문을 참조하세요. | []string | No |
add | 클라이언트에 대한 응답에 헤더를 추가합니다. | []addHeader | No |
* – 기본 숨김 헤더: Date
, Server
, X-Pad
및 X-Accel
-… 등.
** – 무시할 수 있는 필드는 X-Acel-Redirect
, X-Acel-Expires
, X-Acel-Limit-Rate
, X-Acel-Buffering
, X-Acel-Charset
, Expires
, Cache-Control
, Set-Cookie
및 Vari
입니다.
3-15. AddHeader
addHeader는 선택적 always
필드가 있는 HTTP 헤더를 정의합니다.
name: My-Header
value: My-Value
always: true
Field | 설명 | Type | Required |
---|---|---|---|
name | 헤더의 이름입니다. | string | Yes |
value | 헤더의 값입니다. NGINX 변수*를 지원합니다. 변수는 중괄호로 묶어야 합니다. 예: ${scheme} . | string | No |
always | true로 설정하면 응답 상태 코드**에 관계없이 헤더를 추가합니다. 기본값은 false입니다. 자세한 내용은 add_header 지시어를 참조하십시오. | bool | No |
* – 지원되는 NGINX 변수: $request_uri
, $request_method
, $request_body
, $http_
, $args
, $args
, $arg_
, $cookie_
, $host
, $request_time
, $request_length
, $nginx_vers
, $pid
, $remote_addr
, $remote_port
, $time_iso8601
, $time_local
, $readdr
, $re
, $readdr
, $servers_connection
, $connections_writing
, $connections_dn
, $ssl_dn
, $ssl_client_cert
, $ssl_client_dn
, $ssl_client_dn_fingerprint
, $ssl_client_writing
, $ssl_client_dn
, $ssl_client_dn_dn
, $ssl_client_dn_dn_dn
, $ssl_client_dn
, $ssl_dn_client_dn_client_dn
, $ssl_dn_dn
, $ss
, $ssl_curves
, $ssl_early_data
, $ssl_protocol
, $ssl_server_name
, $ssl_session_id
, $ssl_session_reuse
, $jwt_claim_
(NGINX Plus 전용) 및 $jwt_header_
(NGINX Plus 전용).
** – always
가 false이면 응답 상태 코드가 200
, 201
, 204
, 206
, 301
, 302
, 303
, 304
, 307
또는 308
인 경우에만 응답 헤더가 추가됩니다.
3-16. Split
split은 Split 구성의 일부로 작업에 대한 가중치를 정의합니다.
아래 예에서 NGINX는 요청의 80%를 Upstream coffee-v1
에 전달하고 나머지 20%를 coffee-v2
에 전달합니다.
splits:
- weight: 80
action:
pass: coffee-v1
- weight: 20
action:
pass: coffee-v2
Field | 설명 | Type | Required |
---|---|---|---|
weight | 작업의 무게입니다. 1..99 범위에 속해야 합니다. 모든 분할 가중치의 합은 100 이어야 합니다. | int | Yes |
action | 요청에 대해 수행할 작업입니다. | action | Yes |
3-17. Match
match는 조건과 작업 또는 Split 간의 일치를 정의합니다.
아래 예에서 NGINX는 Cookie user
의 값에 따라 /coffee
경로가 있는 요청을 다른 Upstream으로 라우팅합니다.
user=john
-> coffee-future
user=bob
-> coffee-deprecated
Cookie가 설정되지 않았거나 john
또는 bob
과 같지 않은 경우 NGINX는 coffee-stable
로 라우팅합니다.
path: /coffee
matches:
- conditions:
- cookie: user
value: john
action:
pass: coffee-future
- conditions:
- cookie: user
value: bob
action:
pass: coffee-deprecated
action:
pass: coffee-stable
다음 예에서 NGINX는 요청의 HTTP 메서드를 나타내는 기본 제공 $request_method
변수의 값을 기반으로 요청을 라우팅합니다.
모든 POST 요청 -> coffee-post
모든 non-POST 요 -> coffee
path: /coffee
matches:
- conditions:
- variable: $request_method
value: POST
action:
pass: coffee-post
action:
pass: coffee
Field | 설명 | Type | Required |
---|---|---|---|
conditions | 조건 목록입니다. 조건을 1개 이상 포함해야 합니다. | []condition | Yes |
action | 요청에 대해 수행할 작업입니다. | action | No |
splits | 트래픽 분할을 위한 분할 구성입니다. 최소 2개의 분할을 포함해야 합니다. | []split | No |
* – Match에는 action
또는 splits
중 정확히 하나가 포함되어야 합니다.
3-18. Condition
condition은 일치 Condition의 조건을 정의합니다.
Field | 설 | Type | Required |
---|---|---|---|
header | 헤더의 이름입니다. 영숫자 또는 - 로 구성되어야 합니다. | string | No |
cookie | Cookie의 이름입니다. 영숫자 문자 또는 _ 로 구성되어야 합니다. | string | No |
argument | Argument의 이름입니다. 영숫자 문자 또는 _ 로 구성되어야 합니다. | string | No |
variable | NGINX 변수의 이름입니다. $ 로 시작해야 합니다. 표 아래에서 지원되는 변수 목록을 참조하십시오. | string | No |
value | 조건과 일치하는 값입니다. 값을 정의하는 방법은 표 아래에 나와 있습니다. | string | Yes |
* – 조건은 header
, cookie
, argument
또는 variable
중 하나를 정확하게 포함해야 합니다.
지원되는 NGINX 변수: $args
, $http2
, $https
, $remote_addr
, $remote_port
, $query_string
, $request
, $request_body
, $request_uri
, $request_method
, $scheme
. 여기에서 각 변수에 대한 설명서를 확인하십시오.
이 값은 두 가지 유형의 Matching를 지원합니다:
- 대소문자를 구분하지 않는 문자열 비교. 예:
john
– 문자열(예:john
,John
,JOHN
)에 대해 대소문자를 구분하지 않는 일치.!john
–bob
,anything
,' '
(빈 문자열)과 같은 문자열에 대해 john에 대한 대소문자 구분 일치를 부정합니다.
- 정규식과 일치합니다. NGINX는 PCRE(Perl 프로그래밍 언어)에서 사용하는 것과 호환되는 정규식을 지원합니다. 예를 들어:
~^yes
–yes
로 시작하는 모든 문자열과 일치하는 대소문자를 구분하는 정규식입니다. 예를 들어yes
,yes123
입니다.!~^yes
–YES
,Yes123
,noyes
와 같은 문자열에 대해 성공하는 이전 정규식의 부정. (부정 메커니즘은 PCRE 구문의 일부가 아닙니다.).~*no$
–no
로 끝나는 모든 문자열과 일치하는 대소문자를 구분하지 않는 정규식입니다. 예:no
,123no
,123NO
.
Note: 값에는 이스케이프 처리되지 않은 큰따옴표("
)가 포함되어서는 안 되며 이스케이프 처리되지 않은 백슬래시(\
)로 끝나지 않아야 합니다. 예를 들어 다음은 유효하지 않은 값입니다. some"value
, somevalue\
.
3-19. ErrorPage
errorPage는 Upstream 서버가 오류 상태 코드로 응답(또는 NGINX가 생성)하는 경우 경로에 대한 사용자 정의 응답을 정의합니다. 사용자 정의 응답은 리다이렉션 또는 미리 준비된 응답일 수 있습니다. 자세한 내용은 error_page 지시문을 참조하십시오.
path: /coffee
errorPages:
- codes: [502, 503]
redirect:
code: 301
url: https://nginx.org
- codes: [404]
return:
code: 200
body: "Original resource not found, but success!"
Field | 설명 | Type | Required |
---|---|---|---|
codes | 오류 상태 코드 목록입니다. | []int | Yes |
redirect | 지정된 상태 코드에 대한 리다이렉션 작업입니다. | errorPage.Redirect | No |
return | 지정된 상태 코드에 대한 미리 준비된 응답 작업입니다. | errorPage.Return | No |
* – errorPage는 다음 중 하나를 정확히 포함해야 합니다: return
또는 redirect.
3-20. ErrorPage.Redirect
redirect은 errorPage에 대한 Redirect을 정의합니다.
아래 예에서 NGINX는 Upstream 서버의 응답에 404 상태 코드가 있을 때 리다이렉션으로 응답합니다.
codes: [404]
redirect:
code: 301
url: ${scheme}://cafe.example.com/error.html
Field | 설명 | Type | Required |
---|---|---|---|
code | 리디렉션의 상태 코드입니다. 허용되는 값은 301 , 302 , 307 , 308 입니다. 기본값은 301 입니다. | int | No |
url | 요청을 리다이렉션할 URL입니다. 지원되는 NGINX 변수: $scheme 및 $http_x_forwarded_proto 변수는 중괄호로 묶어야 합니다. 예: ${scheme} . | string | Yes |
3-21. ErrorPage.Return
반환은 errorPage에 대한 미리 준비된 응답을 정의합니다.
아래 예에서 NGINX는 Upstream 서버의 응답에 401 또는 403 상태 코드가 있을 때 준비된 응답으로 응답합니다.
codes: [401, 403]
return:
code: 200
type: application/json
body: |
{\"msg\": \"You don't have permission to do this\"}
headers:
- name: x-debug-original-statuses
value: ${upstream_status}
Field | 설 | Type | Required |
---|---|---|---|
code | 응답의 상태 코드입니다. 기본값은 원래 응답의 상태 코드입니다. | int | No |
type | 응답의 MIME 유형입니다. 기본값은 text/html입니다. | string | No |
body | 응답의 본문입니다. 지원되는 NGINX 변수: $upstream_status . 변수는 중괄호로 묶어야 합니다. 예: ${upstream_status} . | string | Yes |
headers | 응답의 사용자 정의 헤더입니다. | errorPage.Return.Header | No |
3-22. ErrorPage.Return.Header
헤더는 errorPage에서 검색된 응답에 대한 HTTP 헤더를 정의합니다:
name: x-debug-original-statuses
value: ${upstream_status}
Field | 설명 | Type | Required |
---|---|---|---|
name | 헤더의 이름입니다. | string | Yes |
value | 헤더의 값입니다. 지원되는 NGINX 변수: $upstream_status . 변수는 중괄호로 묶어야 합니다. 예: ${upstream_status} . | string | No |
4. VirtualServer 및 VirtualServerRoute 사용
일반적인 kubectl
명령을 사용하여 Ingress 리소스와 유사한 VirtualServer 및 VirtualServerRoute 리소스로 사용할 수 있습니다.
예를 들어 다음 명령은 cafe-virtual-server.yaml
에 이름이 cafe
인 VirtualServer 리소스를 생성합니다.
$ kubectl apply -f cafe-virtual-server.yaml
virtualserver.k8s.nginx.org "cafe" created
다음을 실행하여 리소스를 가져올 수 있습니다:
$ kubectl get virtualserver cafe
NAME STATE HOST IP PORTS AGE
cafe Valid cafe.example.com 12.13.23.123 [80,443] 3m
kubectl get 및 유사한 명령에서 virtualserver
대신 vs
라는 짧은 이름을 사용할 수도 있습니다.
VirtualServerRoute 리소스 작업은 유사합니다. kubectl 명령에서 virtualserverroute
또는 단축 이름 vsr
을 사용합니다.
4-1. Snippets 사용
Snippets을 사용하면 Raw NGINX 구성을 다른 NGINX 구성 Context에 삽입할 수 있습니다. 아래 예에서는 Snippets을 사용하여 VirtualServer에서 여러 NGINX 기능을 구성합니다.
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: cafe
namespace: cafe
spec:
http-snippets: |
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
proxy_cache_path /tmp keys_zone=one:10m;
host: cafe.example.com
tls:
secret: cafe-secret
server-snippets: |
limit_req zone=mylimit burst=20;
upstreams:
- name: tea
service: tea-svc
port: 80
- name: coffee
service: coffee-svc
port: 80
routes:
- path: /tea
location-snippets: |
proxy_cache one;
proxy_cache_valid 200 10m;
action:
pass: tea
- path: /coffee
action:
pass: coffee
Snippets은 생성된 NGINX 구성에 대해 더 많은 제어가 필요한 고급 NGINX 사용자가 사용하기 위한 것입니다.
그러나 아래에 설명된 단점 때문에 Snippets은 기본적으로 비활성화되어 있습니다. Snippets을 사용하려면 enable-snippets
Command-line를 설정합니다.
Snippets 사용의 단점:
- 복잡성. Snippets을 사용하려면 다음이 필요합니다:
- NGINX 구성 기본 요소를 이해하고 올바른 NGINX 구성을 구현합니다.
- IC가 NGINX 구성을 생성하여 구성의 다른 기능을 Snippets이 간섭하지 않도록 하는 방법을 이해합니다.
- 견고성 감소. 잘못된 Snippets은 NGINX 구성을 무효화하여 Reload에 실패하게 합니다. 이렇게 하면 Snippets이 수정될 때까지 다른 VirtualServer 및 VirtualServerRoute 리소스에 대한 업데이트를 포함하여 새로운 구성 업데이트가 방지됩니다.
- 보안에 영향을 미칩니다. Snippets은 NGINX 구성 기본 요소에 액세스할 수 있으며 이러한 기본 요소는 Ingress Controller에서 검증되지 않습니다. 예를 들어, Snippets은 입력 및 가상 서버 리소스에 대한 TLS Termination에 사용되는 TLS 인증서 및 Key를 제공하도록 NGINX를 구성할 수 있습니다.
Snippets을 사용할 때 오류를 감지할 수 있도록 Ingress Controller는 로그뿐 아니라 VirtualServer 및 VirtualServerRoute 리소스의 이벤트 및 상태 필드에 구성 Reload 오류를 보고합니다. 또한 다수의 Prometeus 메트릭은 실패한 Reload에 대한 통계(controller_nginx_last_reload_status
및 controller_nginx_reload_errors_total
)를 보여줍니다.
Note: NGINX 구성에 잘못된 Snippets이 포함된 기간 동안 NGINX는 유효한 최신 구성으로 계속 작동합니다.
4-2. 검증
VirtualServer 및 VirtualServerRoute 리소스에 대해 두 가지 유형의 유효성 검증을 사용할 수 있습니다.
Kubectl
및 Kubernetes API 서버에 의한 구조 검증.- Ingress Controller에 의한 포괄적인 검증.
4-3. 구조 검증
VirtualServer 및 VirtualServerRoute에 대한 사용자 정의 리소스 정의에는 해당 리소스의 모든 필드 유형을 설명하는 구조적 OpenAPI 스키마가 포함됩니다.
구조적 스키마를 위반하는 리소스를 생성(또는 업데이트)하려고 하면(예: Upstream의 포트 필드에 문자열 값 사용) kubectl
및 Kubernetes API 서버는 이러한 리소스를 거부합니다.
kubectl
검증의 예:
$ kubectl apply -f cafe-virtual-server.yaml
error: error validating "cafe-virtual-server.yaml": error validating data: ValidationError(VirtualServer.spec.upstreams[0].port): invalid type for org.nginx.k8s.v1.VirtualServer.spec.upstreams.port: got "string", expected "integer"; if you choose to ignore these errors, turn validation off with --validate=false
Kubernetes API 서버 검증의 예:
$ kubectl apply -f cafe-virtual-server.yaml --validate=false
The VirtualServer "cafe" is invalid: []: Invalid value: map[string]interface {}{ ... }: validation failure list:
spec.upstreams.port in body must be of type integer: "string"
리소스가 거부되지 않으면(구조 스키마를 위반하지 않음) Ingress Controller가 리소스를 추가로 검증합니다.
4-4. 포괄적 검증
Ingress Controller는 VirtualServer 및 VirtualServerRoute 리소스의 필드 유효성을 검사합니다. 리소스가 유요하지 않은 경우 Ingress Controller가 리소스를 거부합니다. 리소스는 클러스터에 계속 존재하지만 Ingress Controller는 이를 무시합니다.
Ingress Controller가 VirtualServer에 대한 구성을 성공적으로 적용했는지 확인할 수 있습니다. Example cafe
VirtualServer의 경우 다음을 실행할 수 있습니다.
$ kubectl describe vs cafe
. . .
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal AddedOrUpdated 16s nginx-ingress-controller Configuration for default/cafe was added or updated
구성이 성공적으로 적용되었음을 알리는 AddedOrUpdated 사유가 있는 Normal 이벤트가 이벤트 섹션에 어떻게 포함되어 있는지 확인하십시오.
잘못된 리소스를 생성하면 Ingress Controller가 이를 거부하고 Rejected 이벤트를 내보냅니다. 예를 들어, 같은 이름의 tea
를 가진 두 개의 Upstream이 있는 VirtualServer cafe
를 만들면 다음과 같은 결과를 얻게 됩니다.
$ kubectl describe vs cafe
. . .
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Rejected 12s nginx-ingress-controller VirtualServer default/cafe is invalid and was rejected: spec.upstreams[1].name: Duplicate value: "tea"
이벤트 섹션에 Rejected 사유가 있는 경고 이벤트가 어떻게 포함되어 있는지 확인하십시오.
또한 이 정보는 VirtualServer 리소스의 status
필드에서도 사용할 수 있습니다. VirtualServer의 상태 섹션에 유의하십시오.
$ kubectl describe vs cafe
. . .
Status:
External Endpoints:
Ip: 12.13.23.123
Ports: [80,443]
Message: VirtualServer default/cafe is invalid and was rejected: spec.upstreams[1].name: Duplicate value: "tea"
Reason: Rejected
State: Invalid
Ingress Controller는 유사한 방식으로 VirtualServerRoute 리소스의 유효성을 검사합니다.
Note: 기존 리소스를 유효하지 않게 만들면 Ingress Controller는 이를 거부하고 NGINX에서 해당 구성을 제거합니다.
5. ConfigMap을 통한 사용자 정의
ConfigMap을 사용하여 VirtualServer 및 VirtualServerRoutes 리소스에 대한 NGINX 구성을 사용자 정의할 수 있습니다. 다음을 제외하고 대부분의 ConfigMap Key가 지원됩니다.
proxy-hide-headers
proxy-pass-headers
hsts
hsts-max-age
hsts-include-subdomains
hsts-behind-proxy
redirect-to-https
ssl-redirect