Update outdated files in dev-1.24-ko.2 (M27-M30)
Signed-off-by: Seokho Son <shsongist@gmail.com>pull/35677/head
Seokho Son
parent
d50b53c7af
commit
7f083cc80d
|
|
@ -1,9 +1,10 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - erictune
|
||||
# - lavalamp
|
||||
title: 쿠버네티스 API 접근 제어하기
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -164,7 +165,27 @@ API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수
|
|||
- 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
|
||||
- 인증 및 인가 모듈을 실행한다.
|
||||
|
||||
GCE(구글 컴퓨트 엔진) 및 다른 클라우드 제공자에서 `kube-up.sh`로 클러스터를 생성하면
|
||||
API 서버는 포트 443에서 서비스한다.
|
||||
GCE에서는 외부 HTTPS가 API에 접근할 수 있도록 프로젝트에서 방화벽 규칙이 구성된다.
|
||||
이외에 클러스터 설정 방법은 다양하다.
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
인증 및 인가 그리고 API 접근 제어에 대한 추가적인 문서는 아래에서 찾을 수 있다.
|
||||
|
||||
- [인증하기](/docs/reference/access-authn-authz/authentication/)
|
||||
- [부트스트랩 토큰(bootstrap token)으로 인증하기](/docs/reference/access-authn-authz/bootstrap-tokens/)
|
||||
- [어드미션 컨트롤러(admission controller)](/docs/reference/access-authn-authz/admission-controllers/)
|
||||
- [동적 어드미션(admission) 제어](/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
- [인가](/ko/docs/reference/access-authn-authz/authorization/)
|
||||
- [역할 기반 접근 제어(role based access control)](/docs/reference/access-authn-authz/rbac/)
|
||||
- [속성 기반 접근 제어(attribute based access control)](/docs/reference/access-authn-authz/abac/)
|
||||
- [노드 인가](/docs/reference/access-authn-authz/node/)
|
||||
- [웹훅(webhook) 인가](/docs/reference/access-authn-authz/webhook/)
|
||||
- [인증서 서명 요청(Certificate Signing Request)](/docs/reference/access-authn-authz/certificate-signing-requests/)
|
||||
- [CSR 승인](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) 및
|
||||
[인증서 서명](/docs/reference/access-authn-authz/certificate-signing-requests/#signing) 포함하기
|
||||
- 서비스 어카운트
|
||||
- [개발자 가이드](/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
- [운영](/ko/docs/reference/access-authn-authz/service-accounts-admin/)
|
||||
|
||||
또한, 다음 사항을 익힐 수 있다.
|
||||
- 파드가 API 크리덴셜(credential)을 얻기 위해
|
||||
[시크릿(Secret)](/ko/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
|
||||
을 사용하는 방법.
|
||||
|
|
|
|||
|
|
@ -7,26 +7,25 @@ description: >
|
|||
|
||||
## 쿠버네티스 네트워크 모델
|
||||
|
||||
모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다.
|
||||
클러스터의 모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다.
|
||||
이는 즉 `파드`간 연결을 명시적으로 만들 필요가 없으며
|
||||
또한 컨테이너 포트를 호스트 포트에 매핑할 필요가 거의 없음을 의미한다.
|
||||
이로 인해 포트 할당, 네이밍, 서비스 디스커버리,
|
||||
[로드 밸런싱](/ko/docs/concepts/services-networking/ingress/#load-balancing),
|
||||
애플리케이션 구성, 마이그레이션 관점에서 `파드`를
|
||||
VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고 하위 호환성을 갖는 모델이 제시된다.
|
||||
애플리케이션 구성, 마이그레이션 관점에서 `파드`를 VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고
|
||||
하위 호환성을 갖는 모델이 제시된다.
|
||||
|
||||
쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다
|
||||
(이로 인해 모든 의도적인 네트워크 분할 정책이 방지된다)
|
||||
쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다.
|
||||
(이를 통해, 의도적인 네트워크 분할 정책을 방지)
|
||||
|
||||
* [노드](/ko/docs/concepts/architecture/nodes/) 상의 파드가 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
|
||||
* 노드 상의 에이전트(예: 시스템 데몬, kubelet)가 해당 노드의 모든
|
||||
파드와 통신할 수 있다
|
||||
* 파드는 NAT 없이 [노드](/ko/docs/concepts/architecture/nodes/) 상의 모든 파드와
|
||||
통신할 수 있다.
|
||||
* 노드 상의 에이전트(예: 시스템 데몬, kubelet)는 해당 노드의 모든
|
||||
파드와 통신할 수 있다.
|
||||
|
||||
참고: `파드`를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예: 리눅스)에 대해서는
|
||||
다음의 요구사항도 존재한다.
|
||||
|
||||
* 한 노드의 호스트 네트워크에 있는 파드는
|
||||
NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
|
||||
참고: `파드`를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예:
|
||||
리눅스)에 대해서는, 파드가 노드의 호스트 네트워크에 연결되어 있을 때에도 파드는 여전히
|
||||
NAT 없이 모든 노드의 모든 파드와 통신할 수 있다.
|
||||
|
||||
이 모델은 전반적으로 덜 복잡할 뿐만 아니라,
|
||||
무엇보다도 VM에 있던 앱을 컨테이너로 손쉽게 포팅하려는 쿠버네티스 요구사항을 만족시킬 수 있다.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - davidopp
|
||||
# - thockin
|
||||
title: 서비스 및 파드용 DNS
|
||||
content_type: concept
|
||||
weight: 20
|
||||
|
|
@ -226,6 +226,7 @@ DNS 정책은 파드별로 설정할 수 있다.
|
|||
확인할 수 있다.
|
||||
- "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인
|
||||
"`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다.
|
||||
- 참고: 윈도우에서는 지원되지 않는다.상세 정보는 [아래](#dns-windows)에서 확인한다.
|
||||
- "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다.
|
||||
모든 DNS 설정은 파드 스펙 내에 `dnsConfig`필드를 사용하여 제공해야 한다.
|
||||
아래 절인 [파드의 DNS 설정](#pod-dns-config)에서
|
||||
|
|
@ -306,7 +307,7 @@ IPv6 셋업을 위해서 검색 경로와 네임 서버 셋업은 다음과 같
|
|||
kubectl exec -it dns-example -- cat /etc/resolv.conf
|
||||
```
|
||||
출력은 다음과 같은 형식일 것이다.
|
||||
```shell
|
||||
```
|
||||
nameserver fd00:79:30::a
|
||||
search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
|
||||
options ndots:5
|
||||
|
|
@ -323,6 +324,24 @@ kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화
|
|||
쿠버네티스는 최대 32개의 탐색 도메인과
|
||||
최대 2048자의 탐색 도메인 목록을 허용한다.
|
||||
|
||||
## 윈도우 노드에서 DNS 해석(resolution) {#dns-windows}
|
||||
|
||||
- ClusterFirstWithHostNet은 윈도우 노드에서 구동 중인 파드에는 지원되지 않는다.
|
||||
윈도우는 `.`를 포함한 모든 네임(주소)을 FQDN으로 취급하여 FQDN 해석을 생략한다.
|
||||
- 윈도우에는 여러 DNS 해석기가 사용될 수 있다. 이러한 해석기는
|
||||
각자 조금씩 다르게 동작하므로, 네임 쿼리 해석을 위해서
|
||||
[`Resolve-DNSName`](https://docs.microsoft.com/powershell/module/dnsclient/resolve-dnsname)
|
||||
파워쉘(powershell) cmdlet을 사용하는 것을 추천한다.
|
||||
- 리눅스에는 DNS 접미사 목록이 있는데, 이는 네임이 완전한 주소가 아니어서 주소
|
||||
해석에 실패한 경우 사용한다.
|
||||
윈도우에서는 파드의 네임스페이스(예: `mydns.svc.cluster.local`)와 연계된
|
||||
하나의 DNS 접미사만 가질 수 있다. 윈도우는 이러한 단일 접미사 통해 해석될 수 있는
|
||||
FQDNs, 서비스, 또는 네트워크 네임을 해석할 수 있다. 예를 들어, `default`에
|
||||
소속된 파드는 DNS 접미사 `default.svc.cluster.local`를 가진다.
|
||||
윈도우 파드 내부에서는 `kubernetes.default.svc.cluster.local`와
|
||||
`kubernetes`를 모두 해석할 수 있다. 그러나, 일부에만 해당(partially qualified)하는 네임(`kubernetes.default` 또는
|
||||
`kubernetes.default.svc`)은 해석할 수 없다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,16 +1,15 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
title: IPv4/IPv6 이중 스택
|
||||
feature:
|
||||
title: IPv4/IPv6 이중 스택
|
||||
description: >
|
||||
파드와 서비스에 IPv4와 IPv6 주소 할당
|
||||
|
||||
content_type: concept
|
||||
# reviewers:
|
||||
# - lachie83
|
||||
# - khenidak
|
||||
# - aramase
|
||||
# - bridgetkromhout
|
||||
weight: 70
|
||||
---
|
||||
|
||||
|
|
@ -18,11 +17,11 @@ weight: 70
|
|||
|
||||
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
|
||||
|
||||
IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 {{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다.
|
||||
|
||||
IPv4/IPv6 이중 스택 네트워킹은 1.21부터 쿠버네티스 클러스터에 기본적으로 활성화되어 있고, IPv4 및 IPv6 주소를 동시에 할당할 수 있다.
|
||||
|
||||
IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와
|
||||
{{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다.
|
||||
|
||||
IPv4/IPv6 이중 스택 네트워킹은 1.21부터 쿠버네티스 클러스터에 기본적으로
|
||||
활성화되어 있고, IPv4 및 IPv6 주소를 동시에 할당할 수 있다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -38,60 +37,70 @@ IPv4/IPv6 이중 스택 네트워킹은 1.21부터 쿠버네티스 클러스터
|
|||
|
||||
IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음의 필수 구성 요소가 필요하다.
|
||||
|
||||
* 쿠버네티스 1.20 이상
|
||||
이전 버전과 함께 이중 스택 서비스를 사용하는 방법에 대한 정보
|
||||
쿠버네티스 버전, 쿠버네티스 해당 버전에 대한
|
||||
문서 참조
|
||||
* 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
|
||||
* 이중 스택 네트워킹을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
|
||||
* 쿠버네티스 1.20 및 이후 버전
|
||||
|
||||
예전 버전 쿠버네티스에서 이중 스택 서비스를 사용하는
|
||||
방법에 대한 정보는 해당 버전의 쿠버네티스에 대한
|
||||
문서를 참조한다.
|
||||
|
||||
* 이중 스택 네트워킹을 위한 공급자의 지원. (클라우드 공급자 또는 다른 방식으로
|
||||
쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 함.)
|
||||
* 이중 스택 네트워킹을 지원하는
|
||||
[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/).
|
||||
|
||||
## IPv4/IPv6 이중 스택 구성
|
||||
|
||||
IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워크 할당을 설정한다.
|
||||
|
||||
* kube-apiserver:
|
||||
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* kube-controller-manager:
|
||||
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다.
|
||||
* kube-proxy:
|
||||
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* kubelet:
|
||||
* `--cloud-provider`가 명시되지 않았다면
|
||||
관리자는 해당 노드에 듀얼 스택 `.status.addresses`를 수동으로 설정하기 위해
|
||||
쉼표로 구분된 IP 주소 쌍을 `--node-ip` 플래그로 전달할 수 있다.
|
||||
해당 노드의 파드가 HostNetwork 모드로 실행된다면,
|
||||
파드는 이 IP 주소들을 자신의 `.status.podIPs` 필드에 보고한다.
|
||||
노드의 모든 `podIPs`는 해당 노드의 `.status.addresses` 필드에 의해 정의된
|
||||
IP 패밀리 선호사항을 만족한다.
|
||||
* kube-apiserver:
|
||||
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* kube-controller-manager:
|
||||
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다.
|
||||
* kube-proxy:
|
||||
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* kubelet:
|
||||
* `--cloud-provider`가 명시되지 않았다면 관리자는 해당 노드에 듀얼 스택
|
||||
`.status.addresses`를 수동으로 설정하기 위해 쉼표로 구분된 IP 주소 쌍을 `--node-ip` 플래그로 전달할 수 있다.
|
||||
해당 노드의 파드가 HostNetwork 모드로 실행된다면,
|
||||
파드는 이 IP 주소들을 자신의 `.status.podIPs` 필드에 보고한다.
|
||||
노드의 모든 `podIPs`는 해당 노드의 `.status.addresses` 필드에 의해 정의된
|
||||
IP 패밀리 선호사항을 만족한다.
|
||||
|
||||
{{< note >}}
|
||||
IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도)
|
||||
|
||||
IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한 주소는 아니다 - [RFC 4193](https://tools.ietf.org/html/rfc4193)을 본다.)
|
||||
|
||||
IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한
|
||||
주소는 아니다. [RFC 4193](https://tools.ietf.org/html/rfc4193)을 확인한다.)
|
||||
{{< /note >}}
|
||||
|
||||
## 서비스
|
||||
|
||||
IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 생성할 수 있다.
|
||||
|
||||
서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-apiserver에 구성)
|
||||
서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다.
|
||||
(`--service-cluster-ip-range` 플래그를 통해 kube-apiserver에 구성)
|
||||
|
||||
서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 `.spec.ipFamilyPolicy` 필드를
|
||||
다음 값 중 하나로 설정한다.
|
||||
|
||||
* `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
|
||||
* `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스
|
||||
클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
|
||||
* `PreferDualStack`:
|
||||
* 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다.
|
||||
* `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다.
|
||||
* `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다.
|
||||
* `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로
|
||||
`.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다.
|
||||
|
||||
단일 스택에 사용할 IP 계열을 정의하거나 이중 스택에 대한 IP 군의 순서를 정의하려는 경우, 서비스에서 옵션 필드 `.spec.ipFamilies`를 설정하여 주소 군을 선택할 수 있다.
|
||||
단일 스택에 사용할 IP 계열을 정의하거나 이중 스택에 대한 IP 군의
|
||||
순서를 정의하려는 경우, 서비스에서 옵션 필드
|
||||
`.spec.ipFamilies`를 설정하여 주소 군을 선택할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
`.spec.ipFamilies` 필드는 이미 존재하는 서비스에 `.spec.ClusterIP`를 재할당할 수 없기 때문에 변경할 수 없다. `.spec.ipFamilies`를 변경하려면 서비스를 삭제하고 다시 생성한다.
|
||||
`.spec.ipFamilies` 필드는 이미 존재하는 서비스에 `.spec.ClusterIP`를
|
||||
재할당할 수 없기 때문에 변경할 수 없다. `.spec.ipFamilies`를 변경하려면
|
||||
서비스를 삭제하고 다시 생성한다.
|
||||
{{< /note >}}
|
||||
|
||||
`.spec.ipFamilies`를 다음 배열 값 중 하나로 설정할 수 있다.
|
||||
|
|
@ -109,139 +118,196 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서
|
|||
|
||||
#### 새로운 서비스에 대한 이중 스택 옵션
|
||||
|
||||
1. 이 서비스 사양은 `.spec.ipFamilyPolicy`를 명시적으로 정의하지 않는다. 이 서비스를 만들 때 쿠버네티스는 처음 구성된 `service-cluster-ip-range`에서 서비스에 대한 클러스터 IP를 할당하고 `.spec.ipFamilyPolicy`를 `SingleStack`으로 설정한다. ([셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)와 같은 방식으로 동작한다.)
|
||||
1. 이 서비스 사양은 `.spec.ipFamilyPolicy`를 명시적으로 정의하지 않는다.
|
||||
이 서비스를 만들 때 쿠버네티스는 처음 구성된 `service-cluster-ip-range`에서
|
||||
서비스에 대한 클러스터 IP를 할당하고 `.spec.ipFamilyPolicy`를
|
||||
`SingleStack`으로 설정한다. ([셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및
|
||||
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)와
|
||||
같은 방식으로 동작한다.)
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
|
||||
|
||||
1. 이 서비스 사양은 `.spec.ipFamilyPolicy`에 `PreferDualStack`을 명시적으로 정의한다. 이중 스택 클러스터에서 이 서비스를 생성하면 쿠버네티스는 서비스에 대해 IPv4 및 IPv6 주소를 모두 할당한다. 컨트롤 플레인은 서비스의 `.spec`을 업데이트하여 IP 주소 할당을 기록한다. 필드 `.spec.ClusterIPs`는 기본 필드이며 할당된 IP 주소를 모두 포함한다. `.spec.ClusterIP`는 값이 `.spec.ClusterIPs`에서 계산된 보조 필드이다.
|
||||
1. 이 서비스 사양은 `.spec.ipFamilyPolicy`에 `PreferDualStack`을
|
||||
명시적으로 정의한다. 이중 스택 클러스터에서 이 서비스를 생성하면 쿠버네티스는
|
||||
서비스에 대해 IPv4 및 IPv6 주소를 모두 할당한다. 컨트롤 플레인은 서비스의
|
||||
`.spec`을 업데이트하여 IP 주소 할당을 기록한다. 필드 `.spec.ClusterIPs`는
|
||||
기본 필드이며 할당된 IP 주소를 모두 포함한다. `.spec.ClusterIP`는 값이
|
||||
`.spec.ClusterIPs`에서 계산된 보조 필드이다.
|
||||
|
||||
* `.spec.ClusterIP` 필드의 경우 컨트롤 플레인은 첫 번째 서비스 클러스터 IP 범위와 동일한 주소 계열의 IP 주소를 기록한다.
|
||||
* 단일 스택 클러스터에서 `.spec.ClusterIPs` 및 `.spec.ClusterIP` 필드는 모두 하나의 주소만 나열한다.
|
||||
* 이중 스택이 활성화된 클러스터에서 `.spec.ipFamilyPolicy`에 `RequireDualStack`을 지정하면 `PreferDualStack`과 동일하게 작동한다.
|
||||
* `.spec.ClusterIP` 필드의 경우 컨트롤 플레인은 첫 번째 서비스 클러스터 IP
|
||||
범위와 동일한 주소 계열의 IP 주소를 기록한다.
|
||||
* 단일 스택 클러스터에서 `.spec.ClusterIPs` 및 `.spec.ClusterIP` 필드는
|
||||
모두 하나의 주소만 나열한다.
|
||||
* 이중 스택이 활성화된 클러스터에서 `.spec.ipFamilyPolicy`에 `RequireDualStack`을
|
||||
지정하면 `PreferDualStack`과 동일하게 작동한다.
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}}
|
||||
|
||||
1. 이 서비스 사양은 `.spec.ipFamilies`에` IPv6`과 `IPv4`를 명시적으로 정의하고 `.spec.ipFamilyPolicy`에 `PreferDualStack`을 정의한다. 쿠버네티스가 `.spec.ClusterIPs`에 IPv6 및 IPv4 주소를 할당할 때 `.spec.ClusterIP`는 `.spec.ClusterIPs` 배열의 첫 번째 요소이므로 IPv6 주소로 설정되어 기본값을 재정의한다.
|
||||
1. 이 서비스 사양은 `.spec.ipFamilies`에` IPv6`과 `IPv4`를 명시적으로 정의하고
|
||||
`.spec.ipFamilyPolicy`에 `PreferDualStack`을 정의한다. 쿠버네티스가 `.spec.ClusterIPs`에
|
||||
IPv6 및 IPv4 주소를 할당할 때 `.spec.ClusterIP`는 `.spec.ClusterIPs` 배열의
|
||||
첫 번째 요소이므로 IPv6 주소로 설정되어 기본값을 재정의한다.
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" >}}
|
||||
|
||||
#### 기존 서비스의 이중 스택 기본값
|
||||
|
||||
이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (기존 클러스터를 1.21 이상으로 업그레이드하면 이중 스택이 활성화된다.)
|
||||
이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된
|
||||
경우의 기본 동작을 보여준다. (기존 클러스터를 1.21 이상으로 업그레이드하면
|
||||
이중 스택이 활성화된다.)
|
||||
|
||||
1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다.
|
||||
1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이
|
||||
`.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고
|
||||
`.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다.
|
||||
기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다.
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
|
||||
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
|
||||
|
||||
kubectl을 사용하여 기존 서비스를 검사하여 이 동작을 검증할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get svc my-service -o yaml
|
||||
```
|
||||
```shell
|
||||
kubectl get svc my-service -o yaml
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app: MyApp
|
||||
name: my-service
|
||||
spec:
|
||||
clusterIP: 10.0.197.123
|
||||
clusterIPs:
|
||||
- 10.0.197.123
|
||||
ipFamilies:
|
||||
- IPv4
|
||||
ipFamilyPolicy: SingleStack
|
||||
ports:
|
||||
- port: 80
|
||||
protocol: TCP
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: MyApp
|
||||
type: ClusterIP
|
||||
status:
|
||||
loadBalancer: {}
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app: MyApp
|
||||
name: my-service
|
||||
spec:
|
||||
clusterIP: 10.0.197.123
|
||||
clusterIPs:
|
||||
- 10.0.197.123
|
||||
ipFamilies:
|
||||
- IPv4
|
||||
ipFamilyPolicy: SingleStack
|
||||
ports:
|
||||
- port: 80
|
||||
protocol: TCP
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: MyApp
|
||||
type: ClusterIP
|
||||
status:
|
||||
loadBalancer: {}
|
||||
```
|
||||
|
||||
1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는 `.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을 `SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스 클러스터 IP 범위(kube-apiserver에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로 지정한다.
|
||||
1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존
|
||||
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는
|
||||
`.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을
|
||||
`SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스
|
||||
클러스터 IP 범위(kube-apiserver에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로
|
||||
지정한다.
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
|
||||
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
|
||||
|
||||
kubectl을 사용하여 셀렉터로 기존 헤드리스 서비스를 검사하여 이 동작의 유효성을 검사 할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get svc my-service -o yaml
|
||||
```
|
||||
```shell
|
||||
kubectl get svc my-service -o yaml
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app: MyApp
|
||||
name: my-service
|
||||
spec:
|
||||
clusterIP: None
|
||||
clusterIPs:
|
||||
- None
|
||||
ipFamilies:
|
||||
- IPv4
|
||||
ipFamilyPolicy: SingleStack
|
||||
ports:
|
||||
- port: 80
|
||||
protocol: TCP
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: MyApp
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app: MyApp
|
||||
name: my-service
|
||||
spec:
|
||||
clusterIP: None
|
||||
clusterIPs:
|
||||
- None
|
||||
ipFamilies:
|
||||
- IPv4
|
||||
ipFamilyPolicy: SingleStack
|
||||
ports:
|
||||
- port: 80
|
||||
protocol: TCP
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: MyApp
|
||||
```
|
||||
|
||||
#### 단일 스택과 이중 스택 간 서비스 전환
|
||||
|
||||
서비스는 단일 스택에서 이중 스택으로, 이중 스택에서 단일 스택으로 변경할 수 있다.
|
||||
|
||||
1. 서비스를 단일 스택에서 이중 스택으로 변경하려면 원하는 대로 `.spec.ipFamilyPolicy`를 `SingleStack`에서 `PreferDualStack` 또는 `RequireDualStack`으로 변경한다. 이 서비스를 단일 스택에서 이중 스택으로 변경하면 쿠버네티스는 누락된 주소 계열의 것을 배정하므로 해당 서비스는 이제 IPv4와 IPv6 주소를 갖게된다.
|
||||
1. 서비스를 단일 스택에서 이중 스택으로 변경하려면 원하는 대로 `.spec.ipFamilyPolicy`를
|
||||
`SingleStack`에서 `PreferDualStack` 또는 `RequireDualStack`으로 변경한다.
|
||||
이 서비스를 단일 스택에서 이중 스택으로 변경하면 쿠버네티스는 누락된 주소 계열의
|
||||
것을 배정하므로 해당 서비스는 이제 IPv4와 IPv6 주소를 갖는다.
|
||||
|
||||
`.spec.ipFamilyPolicy`를 `SingleStack`에서 `PreferDualStack`으로 업데이트하는 서비스 사양을 편집한다.
|
||||
|
||||
이전:
|
||||
```yaml
|
||||
spec:
|
||||
ipFamilyPolicy: SingleStack
|
||||
```
|
||||
이후:
|
||||
```yaml
|
||||
spec:
|
||||
ipFamilyPolicy: PreferDualStack
|
||||
```
|
||||
이전:
|
||||
|
||||
1. 서비스를 이중 스택에서 단일 스택으로 변경하려면 `.spec.ipFamilyPolicy`를 `PreferDualStack`에서 또는 `RequireDualStack`을 `SingleStack`으로 변경한다. 이 서비스를 이중 스택에서 단일 스택으로 변경하면 쿠버네티스는 `.spec.ClusterIPs` 배열의 첫 번째 요소 만 유지하고 `.spec.ClusterIP`를 해당 IP 주소로 설정하고 `.spec.ipFamilies`를 `.spec.ClusterIPs`의 주소 계열로 설정한다.
|
||||
```yaml
|
||||
spec:
|
||||
ipFamilyPolicy: SingleStack
|
||||
```
|
||||
|
||||
이후:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
ipFamilyPolicy: PreferDualStack
|
||||
```
|
||||
|
||||
1. 서비스를 이중 스택에서 단일 스택으로 변경하려면 `.spec.ipFamilyPolicy`를
|
||||
`PreferDualStack`에서 또는 `RequireDualStack`을 `SingleStack`으로 변경한다.
|
||||
이 서비스를 이중 스택에서 단일 스택으로 변경하면 쿠버네티스는 `.spec.ClusterIPs`
|
||||
배열의 첫 번째 요소 만 유지하고 `.spec.ClusterIP`를 해당 IP 주소로 설정하고
|
||||
`.spec.ipFamilies`를 `.spec.ClusterIPs`의 주소 계열로 설정한다.
|
||||
|
||||
### 셀렉터가 없는 헤드리스 서비스
|
||||
|
||||
[셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 `.spec.ipFamilyPolicy`가 명시적으로 설정되지 않은 경우 `.spec.ipFamilyPolicy` 필드의 기본값은 `RequireDualStack` 이다.
|
||||
[셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 `.spec.ipFamilyPolicy`가
|
||||
명시적으로 설정되지 않은 경우 `.spec.ipFamilyPolicy` 필드의 기본값은
|
||||
`RequireDualStack` 이다.
|
||||
|
||||
### 로드밸런서 서비스 유형
|
||||
|
||||
서비스에 이중 스택 로드밸런서를 프로비저닝하려면
|
||||
* `.spec.type` 필드를 `LoadBalancer`로 설정
|
||||
* `.spec.ipFamilyPolicy` 필드를 `PreferDualStack` 또는 `RequireDualStack`으로 설정
|
||||
|
||||
* `.spec.type` 필드를 `LoadBalancer`로 설정
|
||||
* `.spec.ipFamilyPolicy` 필드를 `PreferDualStack` 또는 `RequireDualStack`으로 설정
|
||||
|
||||
{{< note >}}
|
||||
이중 스택 `LoadBalancer` 유형 서비스를 사용하려면 클라우드 공급자가 IPv4 및 IPv6로드 밸런서를 지원해야 한다.
|
||||
이중 스택 `LoadBalancer` 유형 서비스를 사용하려면 클라우드 공급자가
|
||||
IPv4 및 IPv6로드 밸런서를 지원해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
## 이그레스(Egress) 트래픽
|
||||
|
||||
비공개로 라우팅할 수 있는 IPv6 주소를 사용하는 파드에서 클러스터 외부 대상 (예: 공용 인터넷)에 도달하기 위해 이그레스 트래픽을 활성화하려면 투명 프록시 또는 IP 위장과 같은 메커니즘을 통해 공개적으로 라우팅한 IPv6 주소를 사용하도록 파드를 활성화해야 한다. [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) 프로젝트는 이중 스택 클러스터에서 IP 위장을 지원한다.
|
||||
비공개로 라우팅할 수 있는 IPv6 주소를 사용하는 파드에서 클러스터 외부 대상
|
||||
(예: 공용 인터넷)에 도달하기 위해 이그레스 트래픽을 활성화하려면 투명 프록시 또는
|
||||
IP 위장과 같은 메커니즘을 통해 공개적으로 라우팅한 IPv6 주소를 사용하도록 파드를 활성화해야 한다.
|
||||
[ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent)
|
||||
프로젝트는 이중 스택 클러스터에서 IP 위장을 지원한다.
|
||||
|
||||
{{< note >}}
|
||||
{{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 IPv6를 지원하는지 확인한다.
|
||||
{{< /note >}}
|
||||
|
||||
## 윈도우 지원
|
||||
|
||||
윈도우에 있는 쿠버네티스는 싱글 스택(single-stack) "IPv6-only" 네트워킹을 지원하지 않는다. 그러나, 싱글 패밀리(single-family)
|
||||
서비스로 되어 있는 파드와 노드에 대해서는 듀얼 스택(dual-stack) IPv4/IPv6 네트워킹을
|
||||
지원한다.
|
||||
|
||||
`l2bridge` 네트워크로 IPv4/IPv6 듀얼 스택 네트워킹을 사용할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
윈도우에서 오버레이 (VXLAN) 네트워크은 듀얼 스택 네트워킹을 **지원하지 않는다.**
|
||||
{{< /note >}}
|
||||
|
||||
윈도우의 다른 네트워크 모델에 대한 내용은
|
||||
[윈도우에서의 네트워킹](/docs/concepts/services-networking/windows-networking#network-modes)을 살펴본다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [IPv4/IPv6 이중 스택 검증](/ko/docs/tasks/network/validate-dual-stack) 네트워킹
|
||||
* [kubeadm을 사용하여 이중 스택 네트워킹 활성화
|
||||
](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/)
|
||||
* [kubeadm을 사용하여 이중 스택 네트워킹 활성화](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/)
|
||||
|
|
|
|||
Loading…
Reference in New Issue