10장. DNS [operator.openshift.io/v1]
- 설명
- DNS는 CoreDNS 구성 요소를 관리하여 클러스터의 pod 및 서비스에 대한 이름 확인 서비스를 제공합니다. 이는 DNS 기반 서비스 검색 사양을 지원합니다. https://github.com/kubernetes/dns/blob/master/docs/specification.md 자세한 내용은 https://kubernetes.io/docs/tasks/administer-cluster/coredns 호환성 수준 1: 최소 12 개월 또는 3 개의 마이너 릴리스 (더 긴 버전) 동안 주요 릴리스 내에서 사용할 수 있습니다.
- 유형
-
object
10.1. 사양
속성 | 유형 | 설명 |
---|---|---|
|
| APIVersion은 버전이 지정된 이 오브젝트 표현의 스키마를 정의합니다. 서버는 인식된 스키마를 최신 내부 값으로 변환해야 하며, 인식되지 않는 값을 거부할 수 있습니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources |
|
| kind는 이 오브젝트가 나타내는 REST 리소스에 해당하는 문자열 값입니다. 서버는 클라이언트에서 요청을 제출한 끝점에서 이를 유추할 수 있습니다. CamelCase로 업데이트할 수 없습니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds |
| 표준 오브젝트의 메타데이터입니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata | |
|
| spec은 DNS의 원하는 동작의 사양입니다. |
|
| 상태는 DNS의 가장 최근에 관찰된 상태입니다. |
10.1.1. .spec
- 설명
- spec은 DNS의 원하는 동작의 사양입니다.
- 유형
-
object
속성 | 유형 | 설명 |
---|---|---|
|
| 캐시는 Corefile에 나열된 모든 서버 블록에 적용되는 캐싱 구성을 설명합니다. 이 필드를 사용하면 클러스터 관리자가 선택적으로 양의 응답을 캐시해야 하는 기간인 * positiveTTL을 구성할 수 있습니다. * 음수 응답을 캐시해야 하는 기간인 negativeTTL입니다. 이 설정이 구성되지 않은 경우 OpenShift는 변경될 수 있는 기본값을 사용하여 양수 및 음수 캐싱을 구성합니다. 작성 시 기본 positiveTTL은 900초이고 기본 negativeTTL은 30초 또는 OpenShift 버전에 대해 각 Corefile에 명시된 대로 설정됩니다. |
|
| loglevel은 CoreDNS에 대해 원하는 로깅 세부 정보 표시를 설명합니다. 다음 값 중 하나를 지정할 수 있습니다. * 업스트림 확인자의 일반 로그 오류입니다. * 디버그 로그 오류, NXDOMAIN 응답 및 NODATA 응답. * 로그 오류 및 모든 응답을 추적합니다. logLevel 설정: 추적은 매우 자세한 로그를 생성합니다. 유효한 값은 "Normal", "Debug", "Trace"입니다. 기본값은 "Normal"입니다. |
|
| managementState는 DNS 운영자가 클러스터 DNS를 관리해야 하는지 여부를 나타냅니다. |
|
| nodePlacement는 DNS Pod의 스케줄링을 명시적으로 제어합니다. 일반적으로 네트워크를 다른 노드의 DNS pod로 이동하는 대신 로컬 DNS 포드에서 DNS 쿼리를 처리하도록 모든 노드에서 DNS Pod를 실행하는 것이 유용합니다. 그러나 보안 정책에 따라 DNS Pod의 배치를 특정 노드로 제한해야 할 수 있습니다. 예를 들어 보안 정책이 임의의 노드의 Pod가 API와 통신하지 못하도록 하는 경우 노드 선택기를 지정하여 API와 통신할 수 있는 노드로 DNS Pod를 제한할 수 있습니다. 반대로 특정 테인트를 사용하여 노드에서 DNS Pod를 실행하는 경우 해당 테인트에 대한 허용 오차를 지정할 수 있습니다. 설정되지 않은 경우 기본값이 사용됩니다. 자세한 내용은 nodePlacement를 참조하십시오. |
|
| operatorLogLevel은 DNS Operator의 로깅 수준을 제어합니다. 유효한 값은 "Normal", "Debug", "Trace"입니다. 기본값은 "Normal"입니다. operatorLogLevel: Trace를 설정하면 매우 자세한 로그가 생성됩니다. |
|
| 서버는 클러스터 도메인 범위를 벗어나는 하나 이상의 하위 도메인에 대한 이름 쿼리 위임을 제공하는 DNS 확인자 목록입니다. 서버가 두 개 이상의 서버로 구성된 경우 서버를 결정하는 데 가장 긴 접미사 일치가 사용됩니다. 예를 들어 두 개의 서버가 있는 경우 "foo.com"과 다른 하나는 "a.foo.com"이고 다른 하나는 "www.a.foo.com"에 대한 이름 쿼리는 Zone "a.foo.com"을 사용하여 서버로 라우팅됩니다. 이 필드가 nil이면 서버가 생성되지 않습니다. |
|
| server는 CoreDNS의 인스턴스별로 실행되는 서버의 스키마를 정의합니다. |
|
| upstreamResolvers는 기본(".") 서버의 경우 DNS 메시지를 업스트림 해석기에 프록시하도록 CoreDNS를 구성하기 위한 스키마를 정의합니다. 이 필드가 지정되지 않은 경우 사용되는 업스트림은 정책 "sequential"을 사용하여 /etc/resolv.conf로 기본 설정됩니다. |
10.1.2. .spec.cache
- 설명
- 캐시는 Corefile에 나열된 모든 서버 블록에 적용되는 캐싱 구성을 설명합니다. 이 필드를 사용하면 클러스터 관리자가 선택적으로 양의 응답을 캐시해야 하는 기간인 * positiveTTL을 구성할 수 있습니다. * 음수 응답을 캐시해야 하는 기간인 negativeTTL입니다. 이 설정이 구성되지 않은 경우 OpenShift는 변경될 수 있는 기본값을 사용하여 양수 및 음수 캐싱을 구성합니다. 작성 시 기본 positiveTTL은 900초이고 기본 negativeTTL은 30초 또는 OpenShift 버전에 대해 각 Corefile에 명시된 대로 설정됩니다.
- 유형
-
object
속성 | 유형 | 설명 |
---|---|---|
|
| negativeTTL은 선택 사항이며 음수 응답을 캐시해야 하는 시간을 지정합니다. 구성된 경우 1s(1초)의 값이거나 이론적으로 최대 몇 년까지 커야 합니다. 이 필드에는 10진수의 부호 없는 기간 문자열, 각각 선택적 분수와 단위 접미사가 필요합니다. 예를 들면 다음과 같습니다. "100s", "1m30s", "12h30m10s". 초의 분수에 해당하는 값은 가장 가까운 초로 반올림됩니다. 구성된 값이 1s 미만이면 기본값이 사용됩니다. 구성되지 않은 경우 값은 0s이고 OpenShift는 OpenShift 버전에 대해 해당 Corefile에 달리 명시하지 않는 한 기본값 30초를 사용합니다. 기본값인 30초는 변경될 수 있습니다. |
|
| positiveTTL은 선택 사항이며 양수 응답을 캐시해야 하는 시간을 지정합니다. 구성된 경우 1s(1초)의 값이거나 이론적으로 최대 몇 년까지 커야 합니다. 이 필드에는 10진수의 부호 없는 기간 문자열, 각각 선택적 분수와 단위 접미사가 필요합니다. 예를 들면 다음과 같습니다. "100s", "1m30s", "12h30m10s". 초의 분수에 해당하는 값은 가장 가까운 초로 반올림됩니다. 구성된 값이 1s 미만이면 기본값이 사용됩니다. 구성되지 않은 경우 값은 0s이고 OpenShift는 OpenShift 버전에 대해 해당 Corefile에 달리 명시하지 않는 한 기본값 900초를 사용합니다. 900초의 기본값은 변경될 수 있습니다. |
10.1.3. .spec.nodePlacement
- 설명
- nodePlacement는 DNS Pod의 스케줄링을 명시적으로 제어합니다. 일반적으로 네트워크를 다른 노드의 DNS pod로 이동하는 대신 로컬 DNS 포드에서 DNS 쿼리를 처리하도록 모든 노드에서 DNS Pod를 실행하는 것이 유용합니다. 그러나 보안 정책에 따라 DNS Pod의 배치를 특정 노드로 제한해야 할 수 있습니다. 예를 들어 보안 정책이 임의의 노드의 Pod가 API와 통신하지 못하도록 하는 경우 노드 선택기를 지정하여 API와 통신할 수 있는 노드로 DNS Pod를 제한할 수 있습니다. 반대로 특정 테인트를 사용하여 노드에서 DNS Pod를 실행하는 경우 해당 테인트에 대한 허용 오차를 지정할 수 있습니다. 설정되지 않은 경우 기본값이 사용됩니다. 자세한 내용은 nodePlacement를 참조하십시오.
- 유형
-
object
속성 | 유형 | 설명 |
---|---|---|
|
| nodeSelector는 DNS Pod에 적용되는 노드 선택기입니다. 비어 있는 경우 기본값은 현재 다음과 같습니다. kubernetes.io/os: linux 이 기본값은 변경될 수 있습니다. 설정된 경우 지정된 선택기가 사용되고 기본값을 대체합니다. |
|
| 허용 오차는 DNS Pod에 적용되는 허용 오차 목록입니다. 비어 있는 경우 DNS Operator는 "node-role.kubernetes.io/master" 테인트에 대한 허용 오차를 설정합니다. 이 기본값은 변경될 수 있습니다. "node-role.kubernetes.io/master" 테인트에 대한 허용 오차를 포함하지 않고 허용 오차를 지정하면 모든 작업자 노드를 사용할 수 없게 되면 중단될 수 있으므로 위험할 수 있습니다. 데몬 컨트롤러는 일부 허용 오차도 추가합니다. https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/에서 참조하십시오. |
|
| 이 허용 오차는 일치하는 연산자 <operator>를 사용하여 트리플 <key,value,effect>와 일치하는 테인트를 허용하도록 연결됩니다. |
10.1.4. .spec.nodePlacement.tolerations
- 설명
- 허용 오차는 DNS Pod에 적용되는 허용 오차 목록입니다. 비어 있는 경우 DNS Operator는 "node-role.kubernetes.io/master" 테인트에 대한 허용 오차를 설정합니다. 이 기본값은 변경될 수 있습니다. "node-role.kubernetes.io/master" 테인트에 대한 허용 오차를 포함하지 않고 허용 오차를 지정하면 모든 작업자 노드를 사용할 수 없게 되면 중단될 수 있으므로 위험할 수 있습니다. 데몬 컨트롤러는 일부 허용 오차도 추가합니다. https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/에서 참조하십시오.
- 유형
-
array
10.1.5. .spec.nodePlacement.tolerations[]
- 설명
- 이 허용 오차는 일치하는 연산자 <operator>를 사용하여 트리플 <key,value,effect>와 일치하는 테인트를 허용하도록 연결됩니다.
- 유형
-
object
속성 | 유형 | 설명 |
---|---|---|
|
| effect는 일치시킬 테인트 효과를 나타냅니다. 비어있는 것은 모든 테인트 효과와 일치함을 의미합니다. 지정된 경우 허용되는 값은 NoSchedule, PreferNoSchedule 및 NoExecute입니다. |
|
| 키는 허용 오차가 적용되는 taint 키입니다. 비어있는 것은 모든 taint 키와 일치함을 의미합니다. 키가 비어 있으면 연산자가 Exists여야 합니다. 이 조합은 모든 값과 모든 키와 일치하는 것을 의미합니다. |
|
| Operator는 값에 대한 키의 관계를 나타냅니다. 유효한 연산자는 Exists 및 Equal입니다. 기본값은 Equal입니다. exists는 값에 대한 와일드카드와 동일하므로 Pod에서 특정 카테고리의 모든 테인트를 허용할 수 있습니다. |
|
| tolerationSeconds는 허용 오차(영향이 NoExecute여야 하며, 그렇지 않으면 이 필드가 무시됨) 테인트를 허용하는 기간을 나타냅니다. 기본적으로 설정되어 있지 않습니다. 즉, 테인트를 영구적으로 허용합니다(제거되지 않음). 0 및 음수 값은 시스템에서 0( 즉시 제거)으로 처리됩니다. |
|
| 값은 허용 오차와 일치하는 taint 값입니다. 연산자가 Exists인 경우 값은 비어 있어야 합니다. 그렇지 않으면 일반 문자열만 사용해야 합니다. |
10.1.6. .spec.servers
- 설명
- 서버는 클러스터 도메인 범위를 벗어나는 하나 이상의 하위 도메인에 대한 이름 쿼리 위임을 제공하는 DNS 확인자 목록입니다. 서버가 두 개 이상의 서버로 구성된 경우 서버를 결정하는 데 가장 긴 접미사 일치가 사용됩니다. 예를 들어 두 개의 서버가 있는 경우 "foo.com"과 다른 하나는 "a.foo.com"이고 다른 하나는 "www.a.foo.com"에 대한 이름 쿼리는 Zone "a.foo.com"을 사용하여 서버로 라우팅됩니다. 이 필드가 nil이면 서버가 생성되지 않습니다.
- 유형
-
array
10.1.7. .spec.servers[]
- 설명
- server는 CoreDNS의 인스턴스별로 실행되는 서버의 스키마를 정의합니다.
- 유형
-
object
속성 | 유형 | 설명 |
---|---|---|
|
| forwardPlugin은 DNS 메시지를 업스트림 해석기로 프록시하도록 CoreDNS를 구성하기 위한 스키마를 정의합니다. |
|
| 이름은 필수이며 서버의 고유 이름을 지정합니다. name은 rfc6335의 서비스 이름 구문을 준수해야 합니다. |
|
| 영역은 필수이며 Server가 권한이 있는 하위 도메인을 지정합니다. zones은 하위 도메인의 rfc1123 정의를 준수해야 합니다. 클러스터 도메인(예: "cluster.local")을 지정하는 것은 유효하지 않습니다. |
10.1.8. .spec.servers[].forwardPlugin
- 설명
- forwardPlugin은 DNS 메시지를 업스트림 해석기로 프록시하도록 CoreDNS를 구성하기 위한 스키마를 정의합니다.
- 유형
-
object
속성 | 유형 | 설명 |
---|---|---|
|
| 정책은 업스트림 서버가 쿼리용으로 선택한 순서를 결정하는 데 사용됩니다. 다음 값 중 하나를 지정할 수 있습니다. * "Random"은 각 쿼리에 대해 임의의 업스트림 서버를 선택합니다. * "roundrobin"은 라운드 로빈 순서로 업스트림 서버를 선택하여 새 쿼리마다 다음 서버로 이동합니다. * "sequential"은 새 쿼리마다 첫 번째 서버부터 시작하여 순차적 순서로 업스트림 서버를 쿼리합니다. 기본값은 "Random"입니다. |
|
| protocolStrategy는 업스트림 DNS 요청에 사용할 프로토콜을 지정합니다. protocolStrategy의 유효한 값은 "TCP"이고 생략되었습니다. 생략하면 이는 의견이 없으며 플랫폼은 시간이 지남에 따라 변경될 수 있는 적절한 기본값을 선택할 수 있음을 의미합니다. 현재 기본값은 원래 클라이언트 요청의 프로토콜을 사용하는 것입니다. "TCP"는 클라이언트 요청이 UDP를 사용하는 경우에도 플랫폼에서 모든 업스트림 DNS 요청에 TCP를 사용하도록 지정합니다. "TCP"는 비호환 업스트림 확인자가 생성한 것과 같은 UDP 관련 문제에 유용하지만 더 많은 대역폭을 사용하거나 DNS 응답 시간을 늘릴 수 있습니다. protocolStrategy는 CoreDNS가 업스트림 해석기에 수행하는 DNS 요청 프로토콜에만 영향을 미칩니다. 클라이언트와 CoreDNS 간 DNS 요청 프로토콜에는 영향을 미치지 않습니다. |
|
| transportConfig는 DNS 요청을 업스트림 확인기로 전달할 때 사용할 전송 유형, 서버 이름 및 선택적 사용자 정의 CA 또는 CA 번들을 구성하는 데 사용됩니다. 기본값은 ""(비어 있음)이므로 DNS 요청을 업스트림 확인기로 전달할 때 표준 일반 텍스트 연결이 사용됩니다. |
|
| 업스트림은 영역의 하위 도메인에 대한 이름 쿼리를 전달하는 확인자 목록입니다. CoreDNS의 각 인스턴스는 Upstreams의 상태 점검을 수행합니다. 정상 업스트림에서 교환 중에 오류를 반환하면 Upstreams에서 다른 해결 프로그램이 시도됩니다. Upstreams는 정책에 지정된 순서로 선택됩니다. 업스트림이 53 이외의 포트에서 수신 대기하는 경우 각 업스트림은 IP 주소 또는 IP:port로 표시됩니다. ForwardPlugin당 최대 15개의 업스트림이 허용됩니다. |
10.1.9. .spec.servers[].forwardPlugin.transportConfig
- 설명
- transportConfig는 DNS 요청을 업스트림 확인기로 전달할 때 사용할 전송 유형, 서버 이름 및 선택적 사용자 정의 CA 또는 CA 번들을 구성하는 데 사용됩니다. 기본값은 ""(비어 있음)이므로 DNS 요청을 업스트림 확인기로 전달할 때 표준 일반 텍스트 연결이 사용됩니다.
- 유형
-
object
속성 | 유형 | 설명 |
---|---|---|
|
| TLS에는 Transport가 "TLS"로 설정될 때 사용할 추가 구성 옵션이 포함되어 있습니다. |
|
| 클러스터 관리자는 전송을 통해 클러스터 DNS와 업스트림 확인자 간에 DNS-over-TLS 연결을 사용할 수 있습니다. CABundle을 구성하지 않고 이 수준에서 TLS를 전송으로 구성하면 시스템 인증서가 업스트림 확인자의 제공 인증서를 확인하는 데 사용됩니다. 가능한 값: ""(비어 있음) - 이는 명시적 선택이 이루어지지 않았으며 플랫폼은 시간이 지남에 따라 변경될 수 있는 기본값을 선택합니다. 현재 기본값은 "text"입니다. "cleartext" - 클러스터 관리자가 일반 텍스트 옵션을 지정합니다. 이렇게 하면 빈 값과 동일한 기능이 생성되지만 클러스터 관리자가 전송에 대해 보다 명확하게 설명하거나 "TLS"에서 "text"로 명시적으로 전환하려는 경우 유용할 수 있습니다. "TLS" - DNS 쿼리를 TLS 연결을 통해 전송해야 함을 나타냅니다. Transport가 TLS로 설정된 경우 ServerName도 설정해야 합니다. 업스트림 IP에 포트가 포함되어 있지 않은 경우 기본적으로 RFC 7858 섹션 3.1; https://datatracker.ietf.org/doc/html/rfc7858#section-3.1.에 따라 포트 853을 시도합니다. |
10.1.10. .spec.servers[].forwardPlugin.transportConfig.tls
- 설명
- TLS에는 Transport가 "TLS"로 설정될 때 사용할 추가 구성 옵션이 포함되어 있습니다.
- 유형
-
object
- 필수 항목
-
serverName
-
속성 | 유형 | 설명 |
---|---|---|
|
|
cabundle은 단일 CA 인증서 또는 CA 번들을 포함해야 하는 ConfigMap을 참조합니다. 이를 통해 클러스터 관리자는 업스트림 리졸버의 인증서를 검증하기 위해 자체 CA 또는 CA 번들을 제공할 수 있습니다. 1. configmap에는 |
|
| ServerName은 DNS 쿼리를 전달할 때 연결할 업스트림 서버입니다. 이는 Transport가 "TLS"로 설정된 경우 필요합니다. ServerName은 RFC 1123의 DNS 이름 지정 규칙에 대해 검증되며 업스트림 확인자에 설치된 TLS 인증서와 일치해야 합니다. |
10.1.11. .spec.servers[].forwardPlugin.transportConfig.tls.caBundle
- 설명
-
cabundle은 단일 CA 인증서 또는 CA 번들을 포함해야 하는 ConfigMap을 참조합니다. 이를 통해 클러스터 관리자는 업스트림 리졸버의 인증서를 검증하기 위해 자체 CA 또는 CA 번들을 제공할 수 있습니다. 1. configmap에는
ca-bundle.crt
키가 포함되어야 합니다. 2. 값은 PEM 인코딩 CA 인증서 또는 CA 번들이어야 합니다. 3. 관리자는 openshift-config 네임스페이스에 이 configmap을 생성해야 합니다. 4. 업스트림 서버 인증서에는 ServerName과 일치하는 SAN(주체 대체 이름)이 포함되어야 합니다. - 유형
-
object
- 필수 항목
-
name
-
속성 | 유형 | 설명 |
---|---|---|
|
| name은 참조된 구성 맵의 metadata.name입니다. |
10.1.12. .spec.upstreamResolvers
- 설명
- upstreamResolvers는 기본(".") 서버의 경우 DNS 메시지를 업스트림 해석기에 프록시하도록 CoreDNS를 구성하기 위한 스키마를 정의합니다. 이 필드가 지정되지 않은 경우 사용되는 업스트림은 정책 "sequential"을 사용하여 /etc/resolv.conf로 기본 설정됩니다.
- 유형
-
object
속성 | 유형 | 설명 |
---|---|---|
|
| 정책은 업스트림 서버가 쿼리용으로 선택한 순서를 결정하는 데 사용됩니다. 다음 값 중 하나를 지정할 수 있습니다. * "Random"은 각 쿼리에 대해 임의의 업스트림 서버를 선택합니다. * "roundrobin"은 라운드 로빈 순서로 업스트림 서버를 선택하여 새 쿼리마다 다음 서버로 이동합니다. * "sequential"은 새 쿼리마다 첫 번째 서버부터 시작하여 순차적 순서로 업스트림 서버를 쿼리합니다. 기본값은 "Sequential"입니다. |
|
| protocolStrategy는 업스트림 DNS 요청에 사용할 프로토콜을 지정합니다. protocolStrategy의 유효한 값은 "TCP"이고 생략되었습니다. 생략하면 이는 의견이 없으며 플랫폼은 시간이 지남에 따라 변경될 수 있는 적절한 기본값을 선택할 수 있음을 의미합니다. 현재 기본값은 원래 클라이언트 요청의 프로토콜을 사용하는 것입니다. "TCP"는 클라이언트 요청이 UDP를 사용하는 경우에도 플랫폼에서 모든 업스트림 DNS 요청에 TCP를 사용하도록 지정합니다. "TCP"는 비호환 업스트림 확인자가 생성한 것과 같은 UDP 관련 문제에 유용하지만 더 많은 대역폭을 사용하거나 DNS 응답 시간을 늘릴 수 있습니다. protocolStrategy는 CoreDNS가 업스트림 해석기에 수행하는 DNS 요청 프로토콜에만 영향을 미칩니다. 클라이언트와 CoreDNS 간 DNS 요청 프로토콜에는 영향을 미치지 않습니다. |
|
| transportConfig는 DNS 요청을 업스트림 확인기로 전달할 때 사용할 전송 유형, 서버 이름 및 선택적 사용자 정의 CA 또는 CA 번들을 구성하는 데 사용됩니다. 기본값은 ""(비어 있음)이므로 DNS 요청을 업스트림 확인기로 전달할 때 표준 일반 텍스트 연결이 사용됩니다. |
|
| 업스트림은 "." 도메인에 대한 이름 쿼리를 전달하는 확인자 목록입니다. CoreDNS의 각 인스턴스는 Upstreams의 상태 점검을 수행합니다. 정상 업스트림에서 교환 중에 오류를 반환하면 Upstreams에서 다른 해결 프로그램이 시도됩니다. Upstreams는 정책에 지정된 순서로 선택됩니다. ForwardPlugin당 최대 15개의 업스트림이 허용됩니다. Upstreams를 지정하지 않으면 기본적으로 /etc/resolv.conf가 사용됩니다. |
|
| 업스트림 유형은 SystemResolvConf 유형 중 하나일 수 있습니다. - SystemResolvConf 유형의 Upstream의 경우 추가 필드는 필요하지 않습니다. - 업스트림 유형은 /etc/resolv.conf를 사용하도록 구성됩니다. - 유형의 Upstream의 경우 NetworkResolver 필드는 IP 주소 또는 IP:port를 사용하여 정의해야 합니다. |
10.1.13. .spec.upstreamResolvers.transportConfig
- 설명
- transportConfig는 DNS 요청을 업스트림 확인기로 전달할 때 사용할 전송 유형, 서버 이름 및 선택적 사용자 정의 CA 또는 CA 번들을 구성하는 데 사용됩니다. 기본값은 ""(비어 있음)이므로 DNS 요청을 업스트림 확인기로 전달할 때 표준 일반 텍스트 연결이 사용됩니다.
- 유형
-
object
속성 | 유형 | 설명 |
---|---|---|
|
| TLS에는 Transport가 "TLS"로 설정될 때 사용할 추가 구성 옵션이 포함되어 있습니다. |
|
| 클러스터 관리자는 전송을 통해 클러스터 DNS와 업스트림 확인자 간에 DNS-over-TLS 연결을 사용할 수 있습니다. CABundle을 구성하지 않고 이 수준에서 TLS를 전송으로 구성하면 시스템 인증서가 업스트림 확인자의 제공 인증서를 확인하는 데 사용됩니다. 가능한 값: ""(비어 있음) - 이는 명시적 선택이 이루어지지 않았으며 플랫폼은 시간이 지남에 따라 변경될 수 있는 기본값을 선택합니다. 현재 기본값은 "text"입니다. "cleartext" - 클러스터 관리자가 일반 텍스트 옵션을 지정합니다. 이렇게 하면 빈 값과 동일한 기능이 생성되지만 클러스터 관리자가 전송에 대해 보다 명확하게 설명하거나 "TLS"에서 "text"로 명시적으로 전환하려는 경우 유용할 수 있습니다. "TLS" - DNS 쿼리를 TLS 연결을 통해 전송해야 함을 나타냅니다. Transport가 TLS로 설정된 경우 ServerName도 설정해야 합니다. 업스트림 IP에 포트가 포함되어 있지 않은 경우 기본적으로 RFC 7858 섹션 3.1; https://datatracker.ietf.org/doc/html/rfc7858#section-3.1.에 따라 포트 853을 시도합니다. |
10.1.14. .spec.upstreamResolvers.transportConfig.tls
- 설명
- TLS에는 Transport가 "TLS"로 설정될 때 사용할 추가 구성 옵션이 포함되어 있습니다.
- 유형
-
object
- 필수 항목
-
serverName
-
속성 | 유형 | 설명 |
---|---|---|
|
|
cabundle은 단일 CA 인증서 또는 CA 번들을 포함해야 하는 ConfigMap을 참조합니다. 이를 통해 클러스터 관리자는 업스트림 리졸버의 인증서를 검증하기 위해 자체 CA 또는 CA 번들을 제공할 수 있습니다. 1. configmap에는 |
|
| ServerName은 DNS 쿼리를 전달할 때 연결할 업스트림 서버입니다. 이는 Transport가 "TLS"로 설정된 경우 필요합니다. ServerName은 RFC 1123의 DNS 이름 지정 규칙에 대해 검증되며 업스트림 확인자에 설치된 TLS 인증서와 일치해야 합니다. |
10.1.15. .spec.upstreamResolvers.transportConfig.tls.caBundle
- 설명
-
cabundle은 단일 CA 인증서 또는 CA 번들을 포함해야 하는 ConfigMap을 참조합니다. 이를 통해 클러스터 관리자는 업스트림 리졸버의 인증서를 검증하기 위해 자체 CA 또는 CA 번들을 제공할 수 있습니다. 1. configmap에는
ca-bundle.crt
키가 포함되어야 합니다. 2. 값은 PEM 인코딩 CA 인증서 또는 CA 번들이어야 합니다. 3. 관리자는 openshift-config 네임스페이스에 이 configmap을 생성해야 합니다. 4. 업스트림 서버 인증서에는 ServerName과 일치하는 SAN(주체 대체 이름)이 포함되어야 합니다. - 유형
-
object
- 필수 항목
-
name
-
속성 | 유형 | 설명 |
---|---|---|
|
| name은 참조된 구성 맵의 metadata.name입니다. |
10.1.16. .spec.upstreamResolvers.upstreams
- 설명
- 업스트림은 "." 도메인에 대한 이름 쿼리를 전달하는 확인자 목록입니다. CoreDNS의 각 인스턴스는 Upstreams의 상태 점검을 수행합니다. 정상 업스트림에서 교환 중에 오류를 반환하면 Upstreams에서 다른 해결 프로그램이 시도됩니다. Upstreams는 정책에 지정된 순서로 선택됩니다. ForwardPlugin당 최대 15개의 업스트림이 허용됩니다. Upstreams를 지정하지 않으면 기본적으로 /etc/resolv.conf가 사용됩니다.
- 유형
-
array
10.1.17. .spec.upstreamResolvers.upstreams[]
- 설명
- 업스트림 유형은 SystemResolvConf 유형 중 하나일 수 있습니다. - SystemResolvConf 유형의 Upstream의 경우 추가 필드는 필요하지 않습니다. - 업스트림 유형은 /etc/resolv.conf를 사용하도록 구성됩니다. - 유형의 Upstream의 경우 NetworkResolver 필드는 IP 주소 또는 IP:port를 사용하여 정의해야 합니다.
- 유형
-
object
- 필수 항목
-
type
-
속성 | 유형 | 설명 |
---|---|---|
|
| Type이 Network로 설정된 경우 주소를 정의해야 합니다. 그렇지 않으면 무시됩니다. 유효한 ipv4 또는 ipv6 주소여야 합니다. |
|
| Type이 Network로 설정된 경우 포트를 정의할 수 있습니다. 그렇지 않으면 무시됩니다. 포트는 65535 사이여야 합니다. |
|
| type은 이 업스트림에 IP/IP:port 확인자 또는 로컬 /etc/resolv.conf가 포함되어 있는지 여부를 정의합니다. type은 SystemResolvConf 또는 Network의 두 가지 가능한 값을 허용합니다. * SystemResolvConf를 사용하는 경우 Upstream 구조에 추가 필드를 정의할 필요가 없습니다. /etc/resolv.conf를 사용할 때 네트워크 사용 시 Upstream 구조에 적어도 하나의 주소가 포함되어야 합니다. |
10.1.18. .status
- 설명
- 상태는 DNS의 가장 최근에 관찰된 상태입니다.
- 유형
-
object
- 필수 항목
-
clusterDomain
-
clusterIP
-
속성 | 유형 | 설명 |
---|---|---|
|
| clusterDomain은 DNS 서비스의 로컬 클러스터 DNS 도메인 접미사입니다. RFC 1034에 정의된 하위 도메인입니다. 3.5 섹션: https://tools.ietf.org/html/rfc1034#section-3.5 예: "cluster.local" 추가 정보: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service |
|
| ClusterIP는 이 DNS를 사용할 수 있는 서비스 IP입니다. 기본 DNS의 경우 기본 ClusterFirst DNS 정책을 사용하는 Pod의 기본 이름 서버로 사용되는 잘 알려진 IP입니다. 일반적으로 이 IP는 Pod의 spec.dnsConfig.nameservers 목록에 지정하거나 클러스터 내에서 이름 확인을 수행할 때 명시적으로 사용할 수 있습니다. 예: dig foo.com @<service IP> 추가 정보: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies |
|
| 조건은 클러스터의 DNS 상태에 대한 정보를 제공합니다. 지원되는 DNS 조건: * Available - True if the following conditions are met: * DNS 컨트롤러 데몬 세트를 사용할 수 있습니다. - 해당 조건 중 하나라도 만족스럽지 않은 경우 False입니다. |
|
| OperatorCondition은 표준 조건 필드입니다. |
10.1.19. .status.conditions
- 설명
- 조건은 클러스터의 DNS 상태에 대한 정보를 제공합니다. 지원되는 DNS 조건: * Available - True if the following conditions are met: * DNS 컨트롤러 데몬 세트를 사용할 수 있습니다. - 해당 조건 중 하나라도 만족스럽지 않은 경우 False입니다.
- 유형
-
array
10.1.20. .status.conditions[]
- 설명
- OperatorCondition은 표준 조건 필드입니다.
- 유형
-
object
- 필수 항목
-
type
-
속성 | 유형 | 설명 |
---|---|---|
|
| |
|
| |
|
| |
|
| |
|
|