From 500ed81c26bfe2fc0475f27c52ad2229286f0a51 Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Thu, 4 Aug 2022 01:15:13 +0900 Subject: [PATCH] Update outdated files in dev-1.24-ko.2 (M27-M30) Signed-off-by: Seokho Son --- .../concepts/security/controlling-access.md | 35 +- .../concepts/services-networking/_index.md | 25 +- .../services-networking/dns-pod-service.md | 27 +- .../services-networking/dual-stack.md | 316 +++++++++++------- 4 files changed, 254 insertions(+), 149 deletions(-) diff --git a/content/ko/docs/concepts/security/controlling-access.md b/content/ko/docs/concepts/security/controlling-access.md index ad30adf3c67c2..f75e4c418592b 100644 --- a/content/ko/docs/concepts/security/controlling-access.md +++ b/content/ko/docs/concepts/security/controlling-access.md @@ -1,9 +1,10 @@ --- - - - +# reviewers: +# - erictune +# - lavalamp title: 쿠버네티스 API 접근 제어하기 content_type: concept +weight: 50 --- @@ -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) + 을 사용하는 방법. diff --git a/content/ko/docs/concepts/services-networking/_index.md b/content/ko/docs/concepts/services-networking/_index.md index b80c3a40f69c6..2ebb1a0b4a94e 100644 --- a/content/ko/docs/concepts/services-networking/_index.md +++ b/content/ko/docs/concepts/services-networking/_index.md @@ -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에 있던 앱을 컨테이너로 손쉽게 포팅하려는 쿠버네티스 요구사항을 만족시킬 수 있다. diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 9b4521e2b7746..e85fe7d07ecb6 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -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" %}} diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index 1e8c9c2a03268..de367d7546808 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -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 주소를 동시에 할당할 수 있다. @@ -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=,` - * kube-controller-manager: - * `--cluster-cidr=,` - * `--service-cluster-ip-range=,` - * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다. - * kube-proxy: - * `--cluster-cidr=,` - * kubelet: - * `--cloud-provider`가 명시되지 않았다면 - 관리자는 해당 노드에 듀얼 스택 `.status.addresses`를 수동으로 설정하기 위해 - 쉼표로 구분된 IP 주소 쌍을 `--node-ip` 플래그로 전달할 수 있다. - 해당 노드의 파드가 HostNetwork 모드로 실행된다면, - 파드는 이 IP 주소들을 자신의 `.status.podIPs` 필드에 보고한다. - 노드의 모든 `podIPs`는 해당 노드의 `.status.addresses` 필드에 의해 정의된 - IP 패밀리 선호사항을 만족한다. +* kube-apiserver: + * `--service-cluster-ip-range=,` +* kube-controller-manager: + * `--cluster-cidr=,` + * `--service-cluster-ip-range=,` + * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다. +* kube-proxy: + * `--cluster-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 -``` - -```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` 플래그를 통해 구성)의 주소 계열으로 지정한다. - -{{< codenew file="service/networking/dual-stack-default-svc.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: {} + ``` + +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" >}} kubectl을 사용하여 셀렉터로 기존 헤드리스 서비스를 검사하여 이 동작의 유효성을 검사 할 수 있다. -```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 -``` + ```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 + ``` #### 단일 스택과 이중 스택 간 서비스 전환 서비스는 단일 스택에서 이중 스택으로, 이중 스택에서 단일 스택으로 변경할 수 있다. -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 -``` + 이전: + + ```yaml + spec: + ipFamilyPolicy: SingleStack + ``` + + 이후: + + ```yaml + spec: + ipFamilyPolicy: PreferDualStack + ``` -1. 서비스를 이중 스택에서 단일 스택으로 변경하려면 `.spec.ipFamilyPolicy`를 `PreferDualStack`에서 또는 `RequireDualStack`을 `SingleStack`으로 변경한다. 이 서비스를 이중 스택에서 단일 스택으로 변경하면 쿠버네티스는 `.spec.ClusterIPs` 배열의 첫 번째 요소 만 유지하고 `.spec.ClusterIP`를 해당 IP 주소로 설정하고 `.spec.ipFamilies`를 `.spec.ClusterIPs`의 주소 계열로 설정한다. +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 >}} -## {{% heading "whatsnext" %}} +## 윈도우 지원 + +윈도위에 있는 쿠버네티스는 싱글 스택(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/)